Freigeben über


Was ist ein Datenprodukt?

Jede Anwendung erstellt und speichert Daten entweder vorübergehend oder dauerhaft. Viele Anwendungen erstellen und speichern auch Daten für die Betriebsverwaltung. Beispiele wären etwa Fehlerprotokollierung und Integritätsüberwachung. Zentralisierte Datenteams verwenden ETL-Prozesse, um die von diesen Anwendungen generierten Daten zu nutzen und zu verarbeiten. Anwendungsbetriebsteams verfügen häufig über zusätzliche Datenverarbeitungsflüsse für Aspekte wie Anwendungsintegrität und KPI-Statusüberwachung.

Das herkömmliche Modell eines Wasserfalls von Teams und Zuständigkeiten in Ihrer Datenintegration ist nicht ideal. Es kann zu Wissenslücken, Zuständigkeitsproblemen und Kommunikationskonflikten führen, die sich auf Qualität, Pünktlichkeit und Nutzen für Endbenutzer auswirken. Anwendungsteams sind für die Leistung und den Erfolg der Anwendung verantwortlich. Im Rahmen ihrer Aufgabe müssen sie Änderungen an nachgelagerten Prozessen vornehmen, für die andere Teams zuständig sind. Diese Änderungen verlaufen jedoch häufig nicht wie geplant. So kann sich beispielsweise herausstellen, dass eine vermeintlich kleine vorgelagerte Änderung drastische Auswirkungen auf den Trend eines KPI hat. Solche Datenprobleme können sich auf Ihre Fähigkeit auswirken, kritische Entscheidungen zu treffen.

Beim Datengitter werden diese Probleme durch Einführung des Konzepts Daten als Produkt verhindert. Anwendungsbesitzer und Anwendungsteams behandeln Daten als vollständig eigenständiges Produkt, für das sie verantwortlich sind, und nicht als ein Nebenprodukt eines Prozesses, der von anderen verwaltet wird. Sowohl Anwendungen als auch Aufgaben, die analytische Daten liefern, liegen innerhalb von Domänenzuständigkeitsbereichen.

Datenprodukte werden speziell für die Nutzung zu Analysezwecken erstellt. Sie verfügen über definierte, vereinbarte und dokumentierte Formen, Nutzungsschnittstellen und Wartungs-/Aktualisierungszyklen.

Bei Datenprodukten handelt es sich um verarbeitete Domänendatenressourcen/Datasets, die über Schnittstellen in einem SLO mit nachgelagerten Prozessen geteilt werden. Sofern nichts dagegenspricht, sollten Ihre Rohdaten verarbeitet, geformt, bereinigt, aggregiert und normalisiert werden, um vereinbarte Qualitätsstandards zu erfüllen, bevor Sie sie nutzbar machen.

In den folgenden Abschnitten werden allgemeine Merkmale guter Datenprodukte beschrieben.

Merkmale von Datenprodukten

Gut gestaltete Datenprodukte zeichnen sich durch folgende Eigenschaften aus:

Auffindbar, verständlich und vertrauenswürdig: Auffindbarkeit und Verständlichkeit werden von Domänenteams gewährleistet, indem sie Informationen zu jedem Datenprodukt, zu seinen Daten, zu seiner Bedeutung, zum Format der Datenform und zum Aktualisierungszyklus freigeben und aktualisieren. Änderungen an Daten oder Formen werden zeitnah an nachgeschaltete Consumer kommuniziert. Schnittstellen gewährleisten Vertrauenswürdigkeit durch zeitgebundene Abwärtskompatibilität für Datenproduktformen.

Adressierbar, nativ zugänglich und sicher: Definierte Prozesse für die Suche nach Datenprodukten sowie für den Zugriff auf Datenprodukte sorgen für Adressierbarkeit. Es sind erforderliche Sicherheitsmaßnahmen für unterschiedliche Zugriffsanforderungen vorhanden. Die Mentalität beim Datendomänenbesitz verlagert sich von einem Gatekeeping-Ansatz für Daten auf die Bereitstellung von Daten mit klar definierten Sicherheitsvorkehrungen. Angebotene Zugriffsschnittstellen sind gut dokumentiert und können in verschiedenen Technologien variieren. Zu gängigen Schnittstellen für nativ zugängliche Datenprodukte zählen APIs, Datenbankbenutzer, Tabellen oder Ansichten sowie Dateien mit erforderlichen Zugriffsberechtigungen.

Interoperabel, wahrheitsgetreu und nützlich: Daten bieten Interoperabilität durch Einhaltung definierter allgemeine Standards. Hierzu gehört etwa, dass die gleichen Werte immer den gleichen Namen und den gleichen Datentyp haben. Beispielsweise kann eine Spalte, die Kundenidentifikationsdaten enthält, in jedem Datenprodukt den Titel CustomerID haben, und die Daten können immer eine ganze Zahl sein oder in jeder Instanz das Snake-Case- oder Camel-Case-Format verwenden. Datenprodukte bieten Kunden einen Mehrwert und können auch als Upstreamquellen für neue Datenprodukte in der gleichen Domäne oder in anderen Domänen verwendet werden. Sie können jedoch nicht einfach das gleiche Datenprodukt an mehreren Orten platzieren und kopieren. Jedes Datenprodukt, das aus einem vorherigen Datenprodukt hervorgeht, muss einen neuen Nutzen und neue Informationen für nachgelagerte Consumer bieten. Datenprodukte müssen auch immer wahrheitsgetreue, nicht fehlerhafte Daten bereitstellen.

Gut konzipierte und gepflegte Datenprodukte und ihre Schnittstellen helfen Organisationen dabei, Daten zu duplizieren und eine native Single Source of Truth zu erstellen.

Entwurfsempfehlungen für Datenprodukte

Um die Bereitstellungsanforderungen für Datenprodukte zu erfüllen, müssen Ihre Domänenteams neue Fähigkeiten erwerben und neue Tools und Plattformen verwenden.

Statten Sie Ihre Domänenanwendungsteams so aus, dass sie die Datenanwendungen erstellen und Datenprodukte produzieren oder bereitstellen können. Ihre Teams können Datenprodukte mithilfe eines vertrauten Technologiestapels erstellen. Falls möglich, kann auf Wunsch auch eine eigene Spark-Instanz oder Pipeline-Engine verwendet werden. Im Falle einer großen Domäne, die zahlreiche Datenprodukte bereitstellt, kann beispielsweise entschieden werden, Datenprodukte über eine eigene Azure Synapse Analytics-Instanz zu verarbeiten und bereitzustellen. In kleineren Organisationen und kleineren Domänen großer Unternehmen können ggf. eigene Datenanwendungen auf einer gemeinsam genutzten Plattform entwickelt und ausgeführt werden. Ein Beispiel wäre etwa eine zentrale Azure Data Factory-, Azure Synapse Analytics- oder Azure Databricks-Instanz.

Stellen Sie sicher, dass Ihre Datenprodukte über die allgemeinen Merkmale verfügen, die in diesem Artikel beschrieben wurden, und achten Sie darauf, dass Ihr Datenherkunftsrepository die Herkunft Ihrer Datenanwendung widerspiegelt und dass Ihre Implementierung und Ihr Zugriff gesteuert werden.

Diagramm: Mögliche Layouts für Datenanwendungslogik in Domänen und Zielzonen

Datenprodukt- und Datenanwendungsleitfaden für Azure

Sie können alle möglichen Ansätze für Ihre Datenanwendungsumgebung in Azure-Datenzielzonen platzieren, wenn Ihre Domänenanwendungsteams eine gemeinsam genutzte Plattform und einen gemeinsam genutzten Satz von Diensten verwenden.

Diagramm: Ressourcengruppe „data-application-rg” im Datenanwendungskontext (Data Applications) und Ressourcengruppe „shared-application-rg” im Kerndienstkontext (Core Services)

Im Artikel „Datenprodukte für Analysen auf Cloudebene in Azure“ stehen unter Beispieldatenanwendungen drei verschiedene Vorlagen für Datenanwendungsmuster für Azure-Datenzielzonen zur Verfügung.

Nächste Schritte