Wat is een gegevensproduct?
Elke toepassing maakt en slaat gegevens tijdelijk of permanent op. Veel toepassingen maken en opslaan ook gegevens voor operationele beheerdoeleinden, zoals foutenlogboeken en statuscontrole. Als u de gegevens wilt gebruiken en verwerken die door deze toepassingen worden geproduceerd, gebruiken gecentraliseerde gegevensteams ETL-processen (extract, transform en load). Toepassingsbewerkingsteams hebben vaak andere gegevensverwerkingsstromen voor gegevens zoals toepassingsstatusgegevens en KPI-statusbewakingsgegevens.
Voor gegevensintegratie is een traditionele watervalbenadering, waarbij teams een specifieke volgorde van fasen volgen, niet ideaal. Dit kan leiden tot kennisproblemen, eigendomsproblemen en communicatieconflicten die van invloed zijn op de kwaliteit, tijdigheid en waarde van uw gegevens voor gebruikers. Toepassingsteams zijn verantwoordelijk voor de prestaties en het succes van de toepassing. Wanneer ze een watervalbenadering gebruiken, brengen ze wijzigingen aan in downstreamprocessen die andere teams bezitten. Soms kunnen deze wijzigingen van invloed zijn op andere gebieden. Een kleine upstreamwijziging kan bijvoorbeeld de trend van een KPI drastisch wijzigen. Deze conflicten kunnen van invloed zijn op uw vermogen om kritieke beslissingen te nemen.
Gegevens als product
Om deze problemen te voorkomen, hanteert de data mesh benaderingswijze het concept van gegevens als een product. Toepassingseigenaren en toepassingsteams behandelen gegevens als een volledig ingesloten product waarvoor ze verantwoordelijk zijn, in plaats van een bijproduct van het proces van een ander team. Zowel toepassingen als analytische gegevensverdieningstaken bevinden zich binnen de verantwoordelijkheidsgebieden van het domein.
Gegevensproducten worden specifiek gemaakt voor analytische consumptie. Ze hebben gedefinieerde en overeengekomen vormen, consumptie-interfaces en onderhouds- en vernieuwingscycli, die allemaal zijn gedocumenteerd.
Gegevensproducten zijn verwerkte domeingegevens of gegevenssets die u met downstreamprocessen kunt delen via interfaces in een dienstniveaudoelstelling. Tenzij anders vereist, moet u uw onbewerkte gegevens verwerken, vormgeven, opschonen, aggregeren en normaliseren om te voldoen aan de overeengekomen kwaliteitsnormen voordat u deze beschikbaar maakt voor gebruik.
In de volgende secties worden algemene kenmerken van goede gegevensproducten beschreven.
Kenmerken van gegevensproduct
Zorg ervoor dat uw gegevensproducten het volgende zijn:
Vindbaar, begrijpelijk en betrouwbaar. Om vindbaarheid en duidelijkheid te bieden, informatie te delen en bij te werken over elk gegevensproduct, de gegevens, de betekenis, de vormindeling van de gegevens en de vernieuwingscyclus. Communiceer tijdig gegevenswijzigingen of shapewijzigingen aan downstreamgebruikers. Om betrouwbaarheid te garanderen, bieden interfaces tijdgebonden achterwaartse compatibiliteit voor gegevensproductvormen.
Adresseerbaar, systeemeigen toegankelijk en veilig. Als u adresseerbaarheid wilt bieden, maakt u gedefinieerde processen om elk gegevensproduct te vinden en er toegang toe te krijgen. Implementeer beveiligingsmaatregelen voor verschillende toegangsvereisten. Verander de mentaliteit van eigendom van uw gegevensdomein van het bewaken van gegevens naar het beheren van gegevens met goed gedefinieerde beveiligingsmaatregelen. Goed gedocumenteerde toegangsinterfaces kunnen per verschillende technologieën verschillen. Veelgebruikte interfaces voor systeemeigen toegankelijke gegevensproducten zijn API's, databasegebruikers, tabellen of weergaven en bestanden met de benodigde toegangsrechten.
Interoperabel, waarheidsgetrouw en waardevol. Als u interoperabiliteit wilt bieden, moet u ervoor zorgen dat uw gegevens voldoen aan gedefinieerde algemene standaarden, zoals waarden met dezelfde naam en hetzelfde gegevenstype. U kunt bijvoorbeeld een kolom noemen die klantidentificatiegegevens bevat CustomerID in elk gegevensproduct en de bijbehorende gegevens kunnen altijd een geheel getal zijn. Gegevensproducten bieden waarde voor klanten en u kunt ze gebruiken als upstream-bronnen voor nieuwe gegevensproducten in hetzelfde domein of verschillende domeinen. Maar u kunt niet alleen hetzelfde gegevensproduct op meerdere plaatsen meenemen en kopiëren. Elk gegevensproduct dat afkomstig is van een vorig gegevensproduct, moet nieuwe waarde en informatie bieden aan downstreamgebruikers. Gegevensproducten moeten ook waarheidsgetrouwe, nauwkeurige gegevens leveren.
Gebruik goed ontworpen, goed onderhouden gegevensproducten en hun interfaces om te voorkomen dat gegevens worden gedupliceerd en een systeemeigen bron van waarheid ontstaat.
Aanbevelingen voor het ontwerpen van gegevensproduct
Om te voldoen aan vereisten voor het leveren van gegevensproduct, moeten uw domeinteams een nieuwe set vaardigheden verkrijgen en nieuwe hulpprogramma's en platforms gebruiken.
Als u de gegevenstoepassingen wilt bouwen en gegevensproducten wilt produceren of leveren, moet u uw domeintoepassingsteams volledig uitrusten. Uw teams kunnen een vertrouwde technologiestack gebruiken om gegevensproducten te bouwen. Ze willen mogelijk ook hun eigen Spark-exemplaar of pijplijnengine hebben. Een groot domein dat veel gegevensproducten ondersteunt, kan bijvoorbeeld gegevensproducten verwerken en bedienen vanuit hun eigen Azure Synapse Analytics-instance. Kleinere organisaties en kleinere domeinen van grote organisaties kunnen hun gegevenstoepassingen ontwikkelen en uitvoeren op een gedeeld platform, zoals een centraal gelegen Azure Data Factory-, Azure Synapse Analytics- of Azure Databricks-exemplaar.
Zorg ervoor dat uw gegevensproducten de algemene kenmerken hebben die in dit artikel worden beschreven, dat uw herkomstopslagplaats overeenkomt met de herkomst van uw gegevenstoepassing en dat u uw implementatie en toegang beheert.
In het volgende diagram ziet u een logische indeling van een gegevenstoepassing in een domein en landingszone.
