Data-as-a-Product (DaaP) ist eine Methodik, bei der das Produktkonzept auf die Datenverwaltung angewendet wird. Der Fokus verschiebt sich von der reinen Datenerhebung hin zur Bereitstellung von Daten. In diesem Modell werden Daten als eigenständiges Asset mit bestimmten „Verbrauchern“ (Entwickler, Data Scientists, Analysten) und einem „Produktinhaber“ betrachtet, der für ihren Nutzen verantwortlich ist.
Dieses Konzept ist ein grundlegendes Element der Data-Mesh-Architektur. Es wird vorgeschlagen, dass die Teams, die mit den Daten am besten vertraut sind (z. B. aus den Bereichen Vertrieb, Inventar oder Logistik), für die Aufbereitung und Bereitstellung der Daten für den Rest des Unternehmens verantwortlich sein sollten, anstatt sich auf ein zentrales Team zu verlassen, das alles verwaltet.
Obwohl diese Begriffe oft synonym verwendet werden, bezeichnen sie unterschiedliche Aspekte desselben Frameworks.
Beispielsweise führt die Strategie (DaaP) ein Team dazu, ein sauberes, dokumentiertes Dataset mit „vierteljährlichen Umsatzzahlen“ zu erstellen. Dieses spezielle Dataset mit Zugriffssteuerungen und Anleitungen zur Nutzung ist das Datenprodukt.
Damit ein Dataset als Produkt fungieren kann, muss es in der Regel bestimmte Nutzbarkeitsstandards erfüllen (die oft von den Prinzipien des Data Mesh abgeleitet werden). Eine Datei, die sich einfach in einem Speicher-Bucket befindet, reicht nicht aus. Wichtige Merkmale:
Die Einführung eines Produktansatzes für Daten dient oft dazu, die Reibungsverluste zwischen Datenproduzenten und -konsumenten zu verringern.
Marketing- und Supportteams benötigen oft Daten aus unterschiedlichen Quellen (Weblogs, CRM, Transaktionsverlauf). Statt dass jedes Team seine eigenen Extraktionspipelines erstellt, kann ein zentrales Team für den Kundenbereich ein einzelnes, validiertes Datenprodukt als „Kundenprofil“ veröffentlichen. Entwickler, die Apps erstellen, können dieses Standardprodukt abonnieren und so für Konsistenz im gesamten Unternehmen sorgen.
In der Logistik ändern sich die Daten zu den Lagerbeständen oft sehr schnell. Ein Datenprodukt mit „Echtzeitinventar“ ermöglicht es nachgelagerten Teams (z. B. Website-Frontend oder Beschaffung), genaue Lagerbestände abzufragen, ohne die Komplexität der zugrunde liegenden Lagerverwaltungssysteme zu verstehen.
Data Scientists verbringen viel Zeit mit dem Bereinigen von Daten, bevor sie Modelle trainieren. Ein Datenprodukt vom Typ „Feature Store“ bietet vorab berechnete, validierte Features (wie das Risiko von Nutzerabwanderung oder die durchschnittliche Warenkorbgröße). Data Scientists können die Bereinigungsphase überspringen und sich auf die Modellarchitektur konzentrieren.
Die Umstellung auf eine produktbasierte Denkweise erfordert zwar etwas Aufwand, kann aber mehrere strukturelle Vorteile für technische Teams und das gesamte Unternehmen bieten.
Höhere Datenqualität
Da Datenprodukte zugewiesene Verantwortliche und SLAs haben, gibt es eine Rechenschaftspflicht für Fehler. Dies führt in der Regel zu saubereren, zuverlässigeren Datasets als bei nicht verwalteten „Datenhalden“.
Schnellere Entwicklung
Entwickler müssen weniger Zeit mit der Suche nach Daten oder dem Entschlüsseln kryptischer Spaltennamen verbringen. Dank Self-Service-Zugriff und klarer Dokumentation können sie Daten schneller in Anwendungen einbinden.
Weniger Engpässe
Durch die Dezentralisierung der Dateninhaberschaft an Domainteams beseitigen Unternehmen den Engpass eines einzelnen zentralen Datenteams. So können mehrere Teams gleichzeitig Datenprodukte erstellen und veröffentlichen.
Klarere Governance
Sicherheits- und Zugriffsrichtlinien werden auf Produktebene definiert. So lässt sich leichter prüfen, wer Zugriff auf welche Daten hat. Das sorgt für Compliance, ohne den Zugriff für berechtigte Nutzer zu verlangsamen.
Um DaaP besser zu verstehen, zeigen wir, wie die theoretischen Konzepte von DaaP mit Knowledge Catalog (ehemals Dataplex) und BigQuery als technologischer Grundlage praktisch umgesetzt werden können.
Szenario: Ein Entwickler muss ein Empfehlungssystem erstellen und benötigt dafür einen zuverlässigen Datensatz mit dem Wiedergabeverlauf von Nutzern.
In einer DaaP-Umgebung muss das Entwicklungsteam keine manuellen Anfragen stellen. Sie verwenden Knowledge Catalog, eine zentrale Plattform für die Governance von Daten und KI. Durch die Suche im Katalog nach „Nutzer-Seitenaufrufe“ finden sie ein registriertes Asset namens „ecommerce-user-activity“. Damit ist die Anforderung an die Auffindbarkeit erfüllt.
Vor dem Schreiben des Codes überprüft der Entwickler den Eintrag. Er sieht:
Der Entwickler fordert über die Katalogoberfläche Zugriff an. Der Dateninhaber (ein bestimmtes Domainteam) genehmigt die Anfrage und gewährt die Rolle „Data Viewer“ für diese bestimmte Ressource. Damit ist die Anforderung an die Sicherheit erfüllt.
Nachdem der Zugriff gewährt wurde, fragt der Entwickler das Datenprodukt direkt in BigQuery ab.
Da die Daten als Produkt behandelt werden, verlässt sich der Entwickler darauf, dass das Schema stabil bleibt (oder er über Versionsänderungen informiert wird), sodass die Anwendung zuverlässig ausgeführt werden kann.
Für Entwickler, die von der Ad-hoc-Datenerstellung zur Entwicklung verwalteter Datenprodukte übergehen möchten, bietet Knowledge Catalog einen speziellen Dienst zum Verpacken, Verwalten und Freigeben von Assets. Der folgende Workflow bietet eine Grundlage für den verwalteten Lebenszyklus.
Profitieren Sie von einem Guthaben in Höhe von 300 $ und mehr als 20 immer kostenlose Produkten, um Google Cloud kennenzulernen.