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 statusbewaking. Gecentraliseerde gegevensteams gebruiken ETL-processen om de gegevens die deze toepassingen produceren te gebruiken en te verwerken. Teams voor toepassingsbewerkingen hebben vaak aanvullende gegevensverwerkingsstromen voor zaken zoals de status van toepassingen en het bewaken van DE KPI-status.

De traditionele benadering van een waterval van teams en verantwoordelijkheden in uw gegevensintegratie is niet ideaal. Dit kan leiden tot kennislacunes, eigendomsproblemen en communicatieconflicten die van invloed zijn op de kwaliteit, tijdigheid en waarde van uw gegevens voor eindgebruikers. Toepassingsteams zijn verantwoordelijk voor de prestaties en het succes van toepassingen. In hun werk moeten ze wijzigingen aanbrengen in downstreamprocessen die eigendom zijn van andere teams, maar deze wijzigingen verlopen vaak niet volgens plan. U kunt bijvoorbeeld merken dat een zogenaamde kleine upstream-wijziging de trend van een KPI drastisch wijzigt. Dit soort gegevensproblemen kunnen van invloed zijn op uw vermogen om kritieke beslissingen te nemen.

De data mesh-benadering voorkomt deze problemen door het concept van gegevens als een product te gebruiken. Toepassingseigenaren en toepassingsteams behandelen gegevens als een volledig ingesloten product waarvoor ze verantwoordelijk zijn, in plaats van een bijproduct van een proces dat door anderen wordt beheerd. Zowel toepassingen als analytische gegevens die taken uitvoeren, bevinden zich binnen domeinverantwoordelijkheidsgebieden.

Gegevensproducten worden specifiek gemaakt voor analytische consumptie. Ze hebben shapes, verbruiksinterfaces en onderhouds- en vernieuwingscycli gedefinieerd en overeengekomen, die allemaal worden gedocumenteerd.

Gegevensproducten worden verwerkt domeingegevensassets/gegevenssets die worden gedeeld met downstreamprocessen via interfaces in een SLO. Tenzij anders vereist, moeten uw onbewerkte gegevens worden verwerkt, vormgegeven, opgeschoond, geaggregeerd en genormaliseerd om te voldoen aan overeengekomen kwaliteitsnormen voordat u ze beschikbaar maakt voor gebruik.

In de volgende secties worden algemene kenmerken beschreven die goede gegevensproducten hebben.

Kenmerken van gegevensproduct

Goed ontworpen gegevensproducten zijn:

Detecteerbaar, begrijpelijk en betrouwbaar: Domeinteams bieden vindbaarheid en begrijpelijkheid door informatie te delen en bij te werken over elk gegevensproduct, de gegevens, de betekenis, de vorm van de gegevens en de vernieuwingscyclus. Ze communiceren wijzigingen in gegevens of vormen tijdig aan downstreamgebruikers. Interfaces garanderen betrouwbaarheid door tijdgebonden achterwaartse compatibiliteit te bieden voor gegevensproductshapes.

Adresseerbaar, systeemeigen toegankelijk en veilig: Gedefinieerde processen voor het zoeken naar en verkrijgen van toegang tot elk gegevensproduct bieden adresseerbaarheid. De nodige beveiligingsmaatregelen voor verschillende toegangsvereisten zijn van kracht. De mentaliteit van het eigendom van gegevensdomeinen verschuift van gatekeepinggegevens naar het leveren van gegevens met goed gedefinieerde beveiligingsmaatregelen. De aangeboden toegangsinterfaces zijn goed gedocumenteerd en kunnen variëren in verschillende technologieën. Veelgebruikte interfaces voor systeemeigen toegankelijke gegevensproducten zijn API's, databasegebruikers, tabellen of weergaven en bestanden met de benodigde toegangsrechten.

Interoperabel, waarheidsgetrouw en waardevol: Gegevens bieden interoperabiliteit door het volgen van gedefinieerde algemene standaarden, zoals dezelfde waarden die altijd dezelfde naam en hetzelfde gegevenstype hebben. Een kolom met klantidentificatiegegevens kan bijvoorbeeld de naam CustomerID hebben in elk gegevensproduct en de gegevens kunnen altijd een geheel getal zijn of in elk geval snake_case of camelCase gebruiken. Gegevensproducten bieden waarde voor klanten en kunnen ook worden gebruikt als upstream-bronnen voor nieuwe gegevensproducten in dezelfde of verschillende domeinen. U kunt hetzelfde gegevensproduct echter niet op meerdere plaatsen meenemen en kopiëren. Elk gegevensproduct dat afkomstig is van een eerder gegevensproduct, moet nieuwe waarde en informatie bieden aan downstreamgebruikers. Gegevensproducten moeten ook altijd waarheidsgetrouwe, niet-onjuiste gegevens bieden.

Goed ontworpen, goed onderhouden gegevensproducten en hun interfaces helpen organisaties het dupliceren van gegevens te voorkomen en kunnen helpen bij het creëren van één systeemeigen bron van waarheid.

Aanbevelingen voor het ontwerpen van gegevensproducten

Als u wilt voldoen aan de vereisten voor het leveren van gegevensproducten, moeten uw domeinteams een nieuwe set vaardigheden verwerven en nieuwe hulpprogramma's en platforms gebruiken.

Uw domeintoepassingsteams volledig uitrusten om de gegevenstoepassingen te bouwen en gegevensproducten te produceren of te leveren. Uw teams kunnen gegevensproducten bouwen met behulp van een vertrouwde technologiestack. Indien mogelijk willen ze ook liever hun eigen Spark-exemplaar of pijplijnengine hebben. Een groot domein dat veel gegevensproducten bedient, kan bijvoorbeeld besluiten om gegevensproducten te verwerken en te leveren vanuit hun eigen Azure Synapse Analytics. Kleinere organisaties en kleinere domeinen van grote ondernemingen kunnen besluiten om hun gegevenstoepassingen te ontwikkelen en uit te voeren op een gedeeld platform, zoals een centraal gelegen Azure Data Factory, Azure Synapse Analytics of Azure Databricks.

Zorg ervoor dat uw gegevensproducten de gemeenschappelijke kenmerken hebben die in dit artikel worden beschreven, dat uw herkomstopslagplaats overeenkomt met de herkomst van uw gegevenstoepassing en dat uw implementatie en toegang worden beheerd.

Diagram met mogelijke logische indelingen voor gegevenstoepassingen in domeinen en landingszones.

Richtlijnen voor gegevensproducten en gegevenstoepassing voor Azure

U kunt alle mogelijke benaderingen voor uw gegevenstoepassingsomgeving in Azure-gegevenslandingszones plaatsen als uw domeintoepassingsteams een gedeeld platform en een set services gebruiken.

Diagram met de resourcegroep data-application-rg uit De context van gegevenstoepassingen en de resourcegroep shared-application-rg uit Core Services Context.

U vindt drie verschillende sjablonen voor gegevenstoepassingspatronen voor Azure-gegevenslandingszones in Gegevensproducten op cloudschaal in Azure - Voorbeeldgegevenstoepassingen.

Volgende stappen