Thema
Openlineage
3 Beiträge zu diesem Thema
Snowflake External Lineage behält Adressen, keine Bedeutung
Snowflake nimmt jetzt OpenLineage entgegen. Es behält, woher die Daten kamen, und verwirft, warum sie verarbeitet wurden.
Die Pipeline-Hälfte, Teil 2 — OpenLineage, Great Expectations und der Nachweis, den eine Pipeline emittiert
Teil 1 behandelte, was eine Pipeline liest. Dieser Teil behandelt, was sie emittiert — und warum genau das die ganze Governance-Geschichte ist: OpenLineage als herstellerneutrales Lineage-Rückgrat, der AWS-native Einführungspfad über die PostLineageEvent-API von DataZone, Assertion-Ergebnisse als Data-Quality-Facet, auf dem ein Grant ausgesetzt werden kann, und das Provenance-Facet, das die Prüferfrage „welcher Code hat diese Zahl erzeugt“ beantwortet. Dazu, warum der Scheduler zentral bleibt, während Compute dezentralisiert, und der eine Sprung, den diese Architektur nicht sieht. Durchgehend echte Payloads und echte Emitter-Konfiguration.
Behaviour-first Governance in der Praxis — Artefakte aus Plattform-Ereignissen erzeugen
Der Data-Governance-Grundpfeiler etabliert das Konzept: Artefakte sind Nebenprodukte von Verhalten, keine Lieferergebnisse an sich. Dieser Beitrag geht die vier Mechanismen durch, die es Realität werden lassen — RoPA aus Lineage, RACI aus Katalog-Eigentum, Audit-Bericht aus Subscription-Log und ein Änderungs-Autorisierungs-Workflow, in dem der Commit der Nachweis ist. Echtes Terraform, SQL und YAML durchgehend.