Teil A · Das Quell-Datenprodukt
Übung 3 · Datenprodukt beschreiben
Das Datenprodukt hinter den Kontrakten mit ODPS beschreiben.
~20 Min.0 von 4 Schritten erledigt
Deine Datenkontrakte beschreiben die Schnittstelle deiner Daten: Tabellen, Typen, Qualitätsregeln. Consumer wollen mehr wissen: Wofür sind die Daten gedacht? Wem gehören sie? Welche Versionen gibt es, und welche sollte ich nutzen? Das beschreibt das Datenprodukt, mit dem Open Data Product Standard (ODPS).
Das lernst du
- Den Unterschied zwischen Datenprodukt und Datenkontrakt verstehen
- Das Datenprodukt Orders mit ODPS 1.1 beschreiben, inklusive Typ und Output-Ports
- Die Beschreibung mit der Data Product CLI validieren
Das Datenprodukt erstellen
Die Datei anlegen
Die Data Product CLI legt eine Startdatei an:
dataproduct init orders.odps.yaml📄 data product written to orders.odps.yamlÖffne orders.odps.yaml in deiner IDE. Sie enthält Platzhalter und auskommentierte Abschnitte.
Ersetze den oberen Teil durch die Grunddaten deines Orders-Produkts:
YAML
apiVersion: v1.1.0
kind: DataProduct
id: orders
name: Orders
version: 1.0.0 # die Version des Datenprodukts, unabhängig von den Kontraktversionen
status: active
type: sourceAligned
domain: ecommerce
description:
purpose: # wofür ist dieses Datenprodukt gedacht?
limitations: # was sollten Consumer vor der Nutzung wissen?Ersetze die Kommentare bei purpose und limitations durch echten Text: Was muss ein Consumer wissen, bevor er Zugriff beantragt?
Die Output-Ports ergänzen
Ergänze pro Datenkontrakt einen Output-Port. Die contractId muss der id des Kontrakts entsprechen:
YAML
outputPorts:
- name: orders_v1
description: Orders and line items tables in PostgreSQL (v1, superseded by v2)
deprecated: true
version: 1.0.0
contractId: orders_v1
- name: orders_v2
description: # ...
version: 2.0.0
contractId: orders_v2Schreib die Beschreibung für orders_v2 selbst. Entferne den Beispiel-Port von dataproduct init.
deprecated: true (neu in ODPS 1.1) markiert den Port orders_v1 als nicht mehr empfohlen. Er bleibt für bestehende Consumer dokumentiert, neue Consumer wählen orders_v2.
Team und Support ergänzen
Ergänze team und support. Übernimm, was du in deinen Kontrakten definiert hast:
YAML
team:
name: order_data_team
members:
- username: [email protected]
role: Owner
support:
- channel: "#order-data-help"
url: https://example.slack.com/archives/order-data-help
tool: slackValidieren
Das Datenprodukt linten
Validiere gegen das offizielle ODPS-JSON-Schema:
dataproduct lint orders.odps.yaml✅ Data product is valid against ODPS v1.1.0
🟢 Data product is valid.Lass es einmal fehlschlagen: Ändere kind: DataProduct in kind: DataProdukt und linte erneut:
dataproduct lint orders.odps.yaml❌ Check that data product is valid against ODPS v1.1.0: kind: 'DataProdukt' is not one of
['DataProduct']
🔴 Data product is invalid.Die CLI nennt das falsche Feld und endet mit Exit-Code 1. Mach es danach rückgängig.
Kurzer Check
Dein Orders-Produkt veröffentlicht nächstes Jahr orders_v3. Was ändert sich in orders.odps.yaml?
Bonus
orders_v1istretired. Sollte sein als deprecated markierter Output-Port in der Produktbeschreibung bleiben oder entfernt werden? Wäge Transparenz für bestehende Consumer gegen einen aufgeräumten Katalog ab.- ODPS 1.1 kennt wie ODCS 3.2 einen
context-Block für KI-Agenten, auf Produkt- und Output-Port-Ebene. Ergänzeinstructions, die einem Agenten sagen, welchen Port er nutzen soll. - Ergänze
tagsam Datenprodukt, z. B.['orders', 'ecommerce'], und linte erneut.