Was ist ein Datenprodukt?

Jochen Christ

Dr. Simon Harrer

This article is also available in English

Datenprodukt vs. Data as a Product

Der Begriff Produkt geht auf das Konzept Product Thinking zurück, das in den vergangenen Jahren auch in der Softwareentwicklung Einzug gehalten hat. Zhamak Dehghani wendet den Begriff im zweiten Kernprinzip von Data Mesh an: Data as a Product. Das bedeutet, dass Softwareprodukte – oder nun Daten – stets aus Perspektive der Data Consumer entwickelt werden, und zwar so, dass sie die beste User Experience erhalten. Bei ihrer Entwicklung sollten genau wie bei einem physischen Produkt die Anforderungen von Data Consumers eine zentrale Rolle spielen. Daten werden ihnen verständlich (intuitiv oder über eine Anleitung) erklärt, sie werden optimiert, damit sie für den Nutzer auf die für ihn beste Art zugänglich sind und möglicherweise auch in der Organisation beworben, um ihr Potenzial zu verdeutlichen. Und dementsprechend haben sie auch einen Preis, den Data Consumers zu zahlen bereit sind. Daten werden damit als wertvolle Ressource für Unternehmen erachtet und sind nicht mehr nur ein Nebenprodukt bei der Softwareentwicklung.

Der Begriff Datenprodukt ist aus dem Prinzip Data as a Product abgeleitet und folgt dessen Ideen, ist aber keineswegs als Synonym aufzufassen. Versuchen wir uns an einer Definition:

Ein Datenprodukt ist also etwas Technisches, das von Datenproduktentwicklern umgesetzt wird. Dabei werden große Datensätze, typischerweise Millionen von Einträgen anhand von Datentechnologien gespeichert und verarbeitet. Im Hinblick auf die Größe von Datenprodukten sind diese so konzipiert, dass sie zusammenhängende Domain-Konzepte oder Use Cases abdecken, die eigenständig sinnvoll und wertvoll sind. Die maximale Größe wird durch den Umfang bestimmt, den ein Team bewältigen kann. Datenprodukte können etwa mit Microservices oder Self-Contained Systems verglichen werden, setzen aber Datentechnologien ein und dienen vor allem Analysezwecken. Auch wenn es der Begriff Produkt vermuten lassen könnte, sind sie für die Nutzung innerhalb des Unternehmens gedacht und werden meistens nicht an externe Kunden verkauft.

Beispiele für Datenprodukte

• Das Team Product Search bietet das Datenprodukt Search Queries an, das alle von Benutzern in die Suchleiste eingegebenen Abfragen, die Anzahl der Ergebnisse und Informationen zum vom Benutzer angeklickten Eintrag enthält.
• Das Team Article Management bietet das Datenprodukt Articles an, das Masterdaten zum Artikel enthält, die sowohl den aktuellen Status als auch den Verlauf umfassen.
• Das Team Checkout bietet das Datenprodukt Orders mit allen Bestellungen seit 2020 an. Dieses Datenprodukt hat zwei Output-Ports: einen mit personenbezogenen Daten und einen, bei dem personenbezogene Daten unkenntlich gemacht wurden.
• Das Team Fulfillment verwaltet das Datenprodukt Shelf Warmers (Ladenhüter), das alle Artikel enthält, die in den letzten 3 Monaten nicht verkauft wurden.
• Das Team Management-Support nutzt andere Datenprodukte, um das Datenprodukt Realtime-Business-Dashboard für den CEO zu erstellen. Daten werden nicht ausgetauscht und es sind auch keine Output-Ports vorhanden.
• Das Team Recommendations nutzt andere Datenprodukte, um ein ML-Modell für Empfehlungen zu trainieren. Das ML-Modell wird als SavedModel-Verzeichnis von Tensorflow in einem Objektspeicher freigegeben. Das Team Marketing erstellt anhand dieses Modells kundenspezifische Empfehlungen im Newsletter.

Architektur von Datenprodukten

Ein Datenprodukt umfasst mehrere Komponenten, die eine zusammenhängende Einheit bilden und in der Regel in einem Git-Repository definiert sind. Im folgenden Diagramm werden die typischen Komponenten eines Datenprodukts dargestellt.

Bei Datenprodukten wird das Designprinzip Information Hiding angewendet. Es gibt klare Schnittstellen nach außen und gekapselte interne Komponenten. Die genaue Implementierung der Komponenten hängt vom Use Case und der Datenplattform ab.

Output-Ports

Output-Ports stellen die API eines Datenprodukts dar: Sie bieten in Form von Tabellen, Dateien oder Topics lesenden Zugriff auf strukturierte Datensätze. Ein Datenprodukt kann mehrere Output-Ports haben: Sie können denselben Datensatz mit unterschiedlichen Technologien oder unterschiedliche Datensätze mit derselben Technologie bereitstellen. So kann beispielweise ein Output-Port personenbezogene Daten enthalten und bei einem zweiten Output-Port können diese anonymisiert sein. Ein neuer Output-Port kann hinzugefügt werden, beispielweise dann, wenn eine strukturelle Änderung erforderlich ist. Output-Ports sind somit ein Mittel, um ein Datenprodukt im Laufe der Zeit weiterzuentwickeln.

Als primäre Schnittstellentechnologie für Output-Ports wird SQL verwendet. SQL ermöglicht einfachen Zugriff auf große Datensätze und wird von so gut wie allen Analysetools unterstützt. Ein Output-Port wird oft in Form einer SQL-View als Abstraktions-Layer implementiert. Damit können die zugrundeliegende Datenstruktur geändert werden kann – ohne Auswirkungen auf Data Consumers. Weitere Interface-Technologien für Output-Ports sind Dateien oder Topics zur Streamverarbeitung oder als asynchrone API in operative Systeme.

Output-Ports definieren das Modell des bereitgestellten Datensatzes. Dieses Modell wird in einem Schema mit allen Tabellen, Attributen und Typen definiert. Zu den häufig verwendeten Technologien gehören SQL DDL, dbt Models, Protobuf, Avro oder JSON Schema. Das Modell kann auch in einem Eintrag in einem Datenkatalog beschrieben werden.

models:
    - name: stock_last_updated_v1
      description: >
        Current state of the stock.
        One record per SKU and location with the last updated timestamp.
      columns:
        - name: sku
          type: string
          description: Stock Keeping Unit (SKU), the business key of an article.
          tests:
            - not_null
        - name: location
          type: string
          description: The ID of the warehouse location.
          tests:
            - not_null
        - name: available
          type: number
          description: The number of articles with this SKU that are available at this location.
          tests:
            - not_null
            - dbt_utils.expression_is_true:
                expression: "col_a >= 0"
        - name: updated_at
          type: timestamptz
          description: The business timestamp in UTC when the available was changed.
          tests:
            - not_null

Output-Ports sind optional oder können als privat festgelegt werden, wenn ein Datenprodukt nur teaminternen analytischen Use Cases dient. Der Zugriff auf Output-Ports wird über Data Contracts geregelt.

Input-Ports

Ein Datenprodukt kann zwei Typen von Datenquellen aufweisen: Operative Systeme oder andere Datenprodukte.

Bei Data Mesh machen die Teams, die die operativen Systeme entwickeln, auch deren relevante Domain-Daten in Form von Datenprodukten zugänglich. Dies erfolgt häufig über asynchrone Technologien und vorzugsweise mithilfe von definierten Domain-Events. Letztendlich muss aber das Domain-Team entscheiden, wie seine Domain-Daten in seine Datenprodukte aufgenommen werden.

Datenprodukte können auch andere Datenprodukte verwenden, wenn ein vereinbarter Data Contract vorliegt. Diese anderen Datenprodukte können entweder demselben Team oder anderen Teams gehören. Typischerweise ist dies bei Consumer-orientierten oder aggregierten Datenprodukten der Fall. Eine Verknüpfung zwischen quellenorientierten Datenprodukten und anderen Domain-Daten ist aber ebenfalls möglich, falls dies hilfreich ist, z. B. um Masterdaten zu suchen.

Discovery-Port

Data Consumers müssen die für sie relevanten Datenprodukte finden können. Da Daten in der Regel je nach Domain eine spezifische Bedeutung haben, ist eine umfassende Beschreibung der Semantik des Datenmodells erforderlich.

Weitere Metadaten, z. B. Kontaktdetails, Reifegrad, Nutzung des Datenprodukts durch andere, Tests zur Datenqualität oder Service-Level Objectives, sind für Data Consumers von großer Bedeutung, damit sie entscheiden können, ob ein Datenprodukt vertrauenswürdig und für ihren Use Case geeignet ist.

Es hat sich bewährt, zur automatischen Veröffentlichung von Metadaten in einem Datenkatalog und dem Datenproduktbestand auf CI/CD-Pipelines zu setzen, z. B. den Data Mesh Manager.

Ownership

Ein Datenprodukt wird von einem einzelnen Team entwickelt und verwaltet, das den Geschäftsbereich, die Geschäftsprozesse und die Daten inhaltlich versteht. Das Team ist dafür verantwortlich, die zugesicherte Datenqualität bereitzustellen und Service-Level Objectives zu erfüllen. Für ein Datenprodukt wird ein fester Ansprechpartner festgelegt, der Product Owner des Teams, der letztendlich für das Datenprodukt und dessen Qualität verantwortlich ist.

Ein Product Owner trägt die Verantwortung für den Lebenszyklus und die Entwicklung eines Datenprodukts. Dabei bindet er die Anforderungen von (potenziellen) Consumers sowie Domain-interne analytische Anforderungen ein. Außerdem legt er den Preis fest, der für die Nutzung eines Datenprodukts berechnet wird.

Transformationscode

Daten müssen bereinigt, aggregiert, zusammengesetzt und transformiert werden, damit das Output-Port-Schema erfüllt wird oder analytische Fragen beantwortet werden können.

Bei der Implementierung eines Datenprodukts müssen folgende Fragen beantwortet werden: Welche Technologie wird verwendet? Wie wird Code intern organisiert? Die Antworten auf diese Fragen hängen von der Datenplattform ab. Entwicklungsteams sind jedoch dafür verantwortlich, Entscheidungen bezüglich der Implementierungsdetails zu treffen.

In vielen Fällen werden SQL-Queries für einfache Transformationen und Apache Spark für komplexe Pipelines verwendet.

Der Transformationscode wird über ein Planungs- und Orchestrierungstool wie Airflow ausgeführt und gesteuert.

Data Storage

In einem Datenprodukt muss in der Regel eine große Datenmenge gespeichert werden, z. B. in Form von Tabellen oder Dateien in einem Objektspeicher. Entsprechender Storage wird als Self-Service über die Datenplattform bereitgestellt. Ein Datenprodukt verfügt über seinen eigenen privaten Bereich, der von anderen Datenprodukten isoliert ist.

Bei der Implementierung eines Datenprodukts müssen folgende Fragen beantwortet werden: Welche Technologie wird verwendet? Wie werden Daten intern organisiert? Die Antworten auf diese Fragen hängen von der Datenplattform ab. Entwicklungsteams sind jedoch dafür verantwortlich, diesbezügliche Entscheidungen zu treffen. In vielen Fällen werden spaltenbasierte Speichertechnologien verwendet.

Tests

Datenprodukte stellen hochwertige Datensätze bereit, die qualitätsgesichert sein müssen. Deswegen spielen Tests – wie auch bei jeder anderen Software-Engineering-Disziplin – eine entscheidende Rolle. Es gibt unterschiedliche Testtypen:

Bei Unit-Tests wird der Transformationscode selbst getestet. Hier werden feste Eingabedaten verwendet und die erwarteten Ausgabedaten definiert.

Expectation-Tests werden während der Bereitstellung auf den echten Datenmodellen ausgeführt. Im Rahmen dieser Tests wird geprüft, ob die Quelldaten aus den Input-Ports, den Zwischenmodellen und dem Output-Port die definierten Erwartungen erfüllen.

Quality-Tests werden periodisch auf echten Daten ausgeführt, um die Service-Level Objectives zu überwachen.

Documentation

Wenn Domain-Daten für andere Teams freigegeben werden, müssen die Semantik der Daten und der Geschäftskontext beschrieben werden, damit andere Teams verstehen können, wie die Daten entstanden sind, und ob sie für einen Anwendungsfall genutzt werden können.

Neben einer Beschreibung der Attribute des Datenmodells enthält eine aussagekräftige Dokumentation auch eine Einleitung, Angaben dazu, was von den Datensätzen zu erwarten ist, und erste Hinweise darauf, welche Daten von Interesse sein können und wie auf sie zugegriffen werden kann.

Eine gute Möglichkeit zum Implementieren einer Dokumentation ist es, ein interaktives Notebook (Jupyter, Google Collab, Databricks Notebook) mit Beispielabfragen bereitzustellen.

Cost Management

Datentechnologien werden schnell zu einer teuren Angelegenheit, wenn sie im großen Maßstab verwendet werden. Deswegen müssen die Kosten von Datenprodukten stets im Auge behalten werden. Sie können die Grundlage für den Preis bilden, der Data Consumers gemäß Data Contracts berechnet wird.

Policies as Code

Global Policies stellen die Spielregeln im Data Mesh dar und werden durch die Federated-Governance-Gruppe definiert. Dazu zählen Namenskonventionen, Datenklassifikationsvorgaben und Zugriffskontrolle.

Die meisten der Richtlinien sollten zwar auf Datenplattformebene implementiert werden, allerdings ist die Konfiguration für einige Policies möglicherweise auf Datenproduktebene erforderlich. Zu den Beispielen gehören die Vertraulichkeitsklassifikation von Domain-Daten, das Tagging personenbezogener Daten oder Berechtigungen.

CI/CD-Pipeline

Ein Datenprodukt hat seine eigene CI/CD-Pipeline. Die CI/CD-Pipeline wird ausgelöst, wenn sich der Transformationscode oder das Modell ändert, Tests werden ausgeführt und das Datenprodukt in Einklang mit den Global Policies auf der Datenplattform bereitgestellt. Das Datenplattformteam kann Terraform-Module oder Templates bereitstellen, die die Datenproduktteams verwenden sollen.

Beobachtbarkeit

Ein Datenprodukt kann über zusätzliche Ports und Funktionalitäten verfügen, die nicht direkt von Data Consumers verwendet werden, aber dennoch wichtig für das Funktionieren des Datenprodukts sind. Dazu gehören Ports zur Überwachung und Protokollierung sowie Admin-Funktionen.

Spezifikation zum Datenprodukt

Zur Beschreibung der Metadaten eines Datenprodukts nutzt man häufig eine YAML-Datei. Alternativ wird eine solche Beschreibung durch die Datenplattform generiert.

dataProductSpecification: 0.0.1
info:
  id: "shelf_warmers"
  name: "Shelf Warmers"
  description: "Shelf warmers are products that are not selling for 3 months and are taking up space on the shelf."
  status: "active"
  archetype: "source-aligned"
  maturity: "managed"
owner:
  teamId: "fulfillment"
inputPorts:
  - id: "stock-service"
    operationalSystemId: "stock-service"
    type: "Kafka Topic"
    location: "fulfillment.stock.events.v1"
outputPorts:
  - id: "shelf_warmers_v1_sql"
    name: "shelf_warmers_v1_sql"
    description: "All articles that are not selling for 3 months and are taking up space on the shelf."
    type: "SQL"
    location: "fulfillment.shelf_warmers_v1"
    links:
      catalog: "https://datacatalog.example.com/fulfillment/shelf_warmers/shelf_warmers_v1"
      jdbc_endpoint: "jdbc:awsathena://AWSRegion=..."
    containsPii: false
    serviceLevelObjectives: []
    tags:
    - "AWS"
  - id: "shelf_warmers_v1_s3"
    name: "shelf_warmers_v1_s3"
    description: "All articles that are not selling for 3 months and are taking up space on the shelf. Provided as parquet files on s3."
    type: "S3"
    status: "active"
links:
  repository: "https://git.example.com/fulfillment/dataproducts/shelf_warmers"
  dataCatalog: "https://datacatalog.example.com/fulfillment/shelf_warmers"
tags: ["AWS", "S3", "Athena"]

Eine formale Datenproduktspezifikation kann als Grundlage zur Automatisierung dienen oder anderen Systemen Metadaten bereitstellen, z. B. einen Unternehmens- oder Datenproduktkatalog.

Wir nutzen hier die dataproduct-specification.com.

Implementierung des Datenprodukts

Sehen wir uns nun ein Beispiel dafür an, wie ein Datenprodukt mithilfe des AWS S3- und Athena-Tech-Stacks implementiert werden kann. In diesem Beispiel stellt das Datenplattformteam ein Terraform-Modul zur Verfügung, das alle zur Ausführung eines Datenprodukts erforderlichen Services bereitstellt. Diese sind wiederum in Einklang mit den Policies und Vereinbarungen, die in der Governance-Gruppe definiert wurden.

Die Entwickler des Datenprodukts definieren ein Git-Repository pro Datenprodukt. Sie verwenden das bereitgestellte Terraform-Modul und konfigurieren es für ihr Datenprodukt. Im selben Repository definieren sie den Transformationscode als SQL-Abfrage und JSON-Schemadatei mit dem Modell des Output-Ports und einer detaillierten Beschreibung des Datenmodells.

Mit dem Befehl terraform apply, der in der Regel über die CI/CD-Pipeline ausgelöst wird, werden alle erforderlichen Ressourcen bereitgestellt, z. B. S3-Buckets, AWS Athena-Ressourcen und Lambda-Funktionen. Außerdem werden Berechtigungen in AWS IAM erstellt.

Die CI/CD-Pipeline überträgt Metadaten außerdem per Push in den Datenkatalog und den Datenproduktbestand.

Ein Beispiel für die Implementierung eines Terraform-Moduls finden Sie auf GitHub.

Tools

In unseren Data-Mesh-Projekten stellen wir immer wieder fest, dass es an guten Tools fehlt, mit denen Datenprodukte gefunden, verwaltet und überwacht werden können. Wir haben daher den Data Mesh Manager entwickelt: Anhand der Metadaten des Datenprodukts baut er ein umfassendes Data Product Inventory auf. Dieses Inventory ist ein guter Ausgangspunkt für die Navigation durch ein komplexes Data Mesh und hilft bei der Suche nach vertrauenswürdigen Datenprodukten, die für Data Consumer relevant sein könnten. Eine Data Mesh Map visualisiert das Data Mesh und hilft dabei, die Data-Mesh-Topologie zu verstehen und die Nutzung von Daten nachzuverfolgen.

Der Data Mesh Manager unterstützt auch den vollständigen Lebenszyklus von Data Contracts als einen Self-Service: Der Zugriff auf ein Datenprodukt kann von Data Consumern angefordert und vom Data Provider akzeptiert werden, um einen bilateralen Data Contract zu vereinbaren.

Über die REST-API ist der Data Mesh Manager vollständig mit allen Datenplattformen integrierbar. Durch eine Event-API können Aktionen in der Datenplattform automatisiert werden, wie etwa die Einrichtung von Berechtigungen, sobald ein Data Contract vereinbart wurde.