Thema
Great Expectations
2 Beiträge zu diesem Thema
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.
Die Pipeline-Hälfte, Teil 1 — eine Pipeline ist ein Deskriptor, kein Programm
Metadata-first wird meist als Emissions-Geschichte gelesen — Lineage- und Qualitäts-Ereignisse, die aus einer Pipeline herauskommen. Das ist die halbe Miete. Dieser Beitrag geht die andere Hälfte durch: die Schemata, Deskriptoren, Verträge, Expectation Suites und Policy-Metadaten, die eine Pipeline auf dem Weg hinein liest, und den einen generischen Executor, der sie interpretiert — statt einer DAG pro Pipeline. Echtes Deskriptor-YAML, ein vollständiger Python-Executor, die sechs Regeln für die Definition eines Deskriptor-Schemas und ehrliche Grenzen, wo die Abstraktion aufhört zu tragen.