Von Andrew Tan
Das Audit, das nie das eigentliche Problem findet
Hier ist eine Szene, die sich in regulierten Branchen jedes Quartal wiederholt:
Das Compliance-Team führt seinen Governance-Scan durch. Der Datenkatalog zeigt Klassifizierungs-Tags für jede Warehouse-Tabelle. Das Lakehouse verfügt über Sicherheitsrichtlinien auf Spaltenebene. Das BI-Tool erzwingt zeilengesteuerten Zugriff. Alle unterschreiben. Die Prüfer gehen zufrieden.
Inzwischen repliziert ein CDC-Feed Kunden-PII aus einer transaktionalen Datenbank in einen Analytics-Cluster. Niemand hat den Stream selbst klassifiziert – sie haben die Zieltabelle klassifiziert, was in Ordnung ist, außer dass der Stream durch ein Staging-Topic läuft, auf das drei verschiedene Services subscriben. Einer davon ist ein KI-Anreicherungsjob, der Fragmente der Daten an eine externe LLM-API sendet. Der API-Aufruf erscheint nicht im Datenkatalog, weil der Katalog nur erfasst, was ankommt, nicht was sich bewegt.
Das Governance-Programm ist im Ruhezustand makellos. In Bewegung ist es nahezu blind.
Das ist kein Tooling-Fehler. Es ist ein Kategorienfehler. Wir haben Governance auf der Annahme aufgebaut, dass Daten in Tabellen und Dateien leben und dass wir, wenn wir die Endpunkte kontrollieren, die Geschichte kontrollieren. Aber moderne Pipelines funktionieren nicht so. Daten sind ständig in Bewegung – über Broker, durch Transformationen, in Model-Training-Sets, hinaus zu Partner-APIs – und die meisten Governance-Frameworks haben das nicht aufgeholt.
Warum Governance für ruhende Daten die schwierigen Fälle verpasst
Governance im Batch-Zeitalter ergab Sinn für Batch-Architekturen. Daten bewegten sich in geplanten Ladevorgängen. Sie wussten, wann sie ankamen. Sie konnten sie scannen, klassifizieren und Richtlinien anwenden, bevor jemand sie abfragte. Die Pipeline war im Grunde ein Lieferwagen, und Governance passierte am Ladedock.
Streaming und CDC haben dieses Modell gebrochen. Daten bewegen sich kontinuierlich. Sie werden im Flug gejoint. Sie werden durch externe Services angereichert. Sie werden gefiltert, aufgeteilt und an mehrere Consumer geroutet, bevor sie jemals ein gouverniertes Ziel erreichen. Bis sie ankommen, können die sensiblen Teile bereits geleakt, kopiert oder an einen Ort gesendet worden sein, den der Katalog nicht sehen kann.
Diese Lücke zeigt sich auf spezifische, schmerzhafte Weisen:
Klassifizierung nach dem Eintreffen ist oft zu spät. Wenn ein CDC-Stream unmaskierte Kreditkartennummern durch drei Intermediate Topics transportiert, bevor sie das Warehouse erreichen, ist die Warehouse-Richtlinie auf Spaltenebene ein Pflaster auf einer Blutung, die weiter oben passiert ist.
Batch-Governance-Tools verstehen keine Streaming-Semantik. Ein Datenkatalog kann Ihnen sagen, was in einer Tabelle ist. Er kann Ihnen nicht sagen, dass ein Streaming-Join PII aus einem Topic mit Verhaltensdaten aus einem anderen korreliert und dabei einen neuen Composite-Datensatz erzeugt, den niemand geprüft hat.
Lineage bricht an den Nähten. Die meisten Lineage-Tools verfolgen Table-to-Table-Beziehungen. Sie verfolgen nicht den API-Aufruf, der einen Datensatz mitten in der Pipeline anreichert, oder das Modell, das auf einem Snapshot des Streams trainiert, oder den Reverse-ETL-Job, der abgeleitete Daten zurück in ein CRM schiebt. Die Karte sieht vollständig aus, bis man einem Datensatz durch seinen tatsächlichen Lebenszyklus folgt.
Retention-Richtlinien ignorieren Kopien während der Bewegung. Sie setzen eine 90-Tage-Retention auf das Warehouse. Großartig. Aber der Stream-Consumer, der eine Materialized View in Elasticsearch erstellt hat? Der S3-Bucket, in den die Pipeline zum Replay schreibt? Die Partner-API, die eine Kopie erhalten hat? Retention ist nur so stark wie ihre schwächste Replik, und die meisten Governance-Programme wissen nicht, wo die Repliken sind.
Was Governance-in-Motion tatsächlich bedeutet
Governance in die Pipeline zu verlagern, bedeutet nicht, den Datenkatalog oder das Lakehouse-Sicherheitsmodell zu ersetzen. Es bedeutet, die Durchsetzung von Richtlinien auf die Orte auszudehnen, an denen Daten sich tatsächlich bewegen.
Hier sind die vier Fähigkeiten, die zählen:
Richtlinien an der Grenze
Anstatt Daten nach dem Eintreffen zu klassifizieren, klassifizieren Sie sie, wenn sie in die Pipeline eintreten. Ein CDC-Feed aus einer Kundendatenbank sollte seine Klassifizierungs-Tags mit sich führen – PII, Finanzdaten, Gesundheitsdaten – und diese Tags sollten durch jede Umwandlung, jeden Join und jede Routing-Entscheidung hindurch bestehen bleiben. Wenn ein Downstream-Consumer versucht, getaggte Daten an ein nicht genehmigtes Ziel zu senden, sollte die Pipeline ihn blockieren, nicht protokollieren und weitermachen.
Das klingt offensichtlich, aber die meisten Pipelines machen es nicht. Die Metadaten, die für Governance wichtig sind – Klassifizierung, Consent-Flags, Retention-Anforderungen – werden normalerweise während der Normalisierung entfernt oder in einem separaten Katalog gespeichert, den der Runtime nicht konsultiert.
Freigabepunkte für Hochrisiko-Datenflüsse
Manche Datenbewegungen sollten nicht ohne eine zweite Prüfung stattfinden. Eine Pipeline, die beginnt, eine neue Tabelle in ein externes Analytics-Tool zu replizieren. Ein Stream, der beginnt, eine neu hinzugefügte Spalte mit Geolokalisierungsdaten zu enthalten. Ein KI-Workflow, der Kundentranskripte an ein Dritt-Modell senden möchte.
Das sind keine Fehler. Das sind normale Operationen. Aber es sind auch die Momente, in denen sich Governance-Risiken konzentrieren. Das richtige Modell ist nicht, alles zu blockieren und auf ein Ticket zu warten. Es ist, risikoarme Flüsse automatisch laufen zu lassen und Hochrisiko-Flüsse zur Freigabe zu kennzeichnen – wobei der Freigabepunkt in die Pipeline selbst eingebettet ist, nicht in ein separates Workflow-Tool, das der Ingenieur möglicherweise verwendet oder auch nicht.
Retention und Löschung, die den Daten folgen
Wenn ein Kunde sein Recht auf Vergessenwerden ausübt oder wenn eine Aufbewahrungsfrist abläuft, muss die Anfrage jede Kopie der Daten erreichen – nicht nur die Warehouse-Tabelle. Dazu gehören Stream-Replays, Materialized Views, Model-Training-Snapshots und Partner-API-Caches.
In der Praxis bedeutet das, dass die Pipeline-Runtime verfolgen muss, wohin Daten gesendet wurden, und die Zuordnung zwischen der Identität eines Datensatzes und seinen Repliken pflegen muss. Die meisten Streaming-Plattformen tun das nicht. Sie behandeln jede Nachricht als unabhängig, ohne Erinnerung daran, woher sie kam oder wohin sie ging. Governance in Motion erfordert ein anderes Modell: Nachrichten tragen Identität, und der Runtime pflegt Herkunftsinformationen.
Lineage, das Transformationen umfasst, nicht nur Tabellen
Table-to-Table-Lineage ist für Batch-Pipelines nützlich. Für Streaming und CDC ist es unvollständig. Sie müssen wissen, dass ein bestimmter Anreicherungsschritt Drittdaten hinzugefügt hat, dass ein Join zwei Datensätze korreliert hat, die getrennt bleiben sollten, oder dass ein Filter Datensätze stillschweigend verworfen hat, die aus Compliance-Gründen hätten aufbewahrt werden müssen.
Das bedeutet, dass Lineage kein nachträglicher Scan von Query-Logs sein kann. Es muss in den Runtime eingebaut sein und erfassen, was jeder Schritt mit den Daten tut, während es passiert.
Der Rollout-Pfad: Beginnen Sie mit den Schnittstellen
Niemand baut sein Governance-Modell in einem einzigen Projekt um. Die Teams, die erfolgreich sind, fangen klein an und erweitern sich.
Der richtige Ort, um zu beginnen, ist die Pipeline-Grenze – die Punkte, an denen Daten Ihr System betreten oder verlassen. CDC-Feeds aus Produktionsdatenbanken. API-Aufrufe an externe Services. Reverse-ETL-Jobs, die Daten zurück in operative Tools schieben. Das sind die hochriskantesten und sichtbarsten Schnittstellen, und hier zeigen sich Governance-Fehler zuerst.
Wählen Sie eine Schnittstelle. Fügen Sie Klassifizierungs-Tags an der Quelle hinzu. Fügen Sie eine Richtlinienprüfung hinzu, bevor die Daten austreten. Fügen Sie Lineage-Tracking für diesen einen Fluss hinzu. Beweisen Sie, dass es funktioniert. Dann erweitern Sie auf die nächste Schnittstelle.
Die Teams, bei denen ich das gut gelöst sehe, haben eine Gemeinsamkeit: Sie betrachten Governance als Runtime-Angelegenheit, nicht als Dokumentationsangelegenheit. Die Richtlinie steht nicht in einem Wiki und wird erhofft. Sie wird von der Pipeline durchgesetzt, in CI getestet und mit dem Code versioniert. Wenn sich die Richtlinie ändert, ändert sich die Pipeline. Wenn sich die Pipeline ändert, wird die Richtlinie neu validiert.
Wo das schwieriger ist, als es klingt
Ich möchte ehrlich über die Hindernisse sein, denn „Governance einfach in die Pipeline verlagern“ ist leicht gesagt und schwer getan.
Bestehende Tools sind nicht dafür gebaut. Die meisten Datenkataloge, Sicherheitsscanner und Lineage-Tools wurden für Batch-Warehouses entworfen. Sie erwarten geplante Scans, keine kontinuierlichen Streams. Sie erwarten Tabellen, nicht Topics. Ihre Erweiterung auf Bewegung bedeutet in der Regel benutzerdefinierte Integrationsarbeit, die der Hersteller nicht unterstützt.
Performance zählt. Das Hinzufügen von Klassifizierungsprüfungen, Richtlinien-Lookups und Lineage-Logging zu einer Streaming-Pipeline erhöht die Latency. Bei Hochdurchsatz-Flüssen muss der Overhead vernachlässigbar sein – was bedeutet, dass Richtlinienentscheidungen gecacht, asynchron ausgewertet oder an den Rand der Pipeline geschoben werden müssen, wo sie den kritischen Pfad nicht blockieren.
Die organisatorische Verantwortung ist unklar. Data Governance wird oft von einem Compliance-Team verantwortet, das keinen Pipeline-Code schreibt. Das Plattform-Engineering-Team besitzt den Runtime, setzt aber keine Richtlinien. Diese Teams dazu zu bringen, sich darauf zu einigen, was „Governance in Motion“ bedeutet, wer sie pflegt und wer gerufen wird, wenn sie ausfällt, ist oft schwieriger als die technische Implementierung.
Die Standards entstehen noch. Es gibt kein universelles Protokoll, um Governance-Metadaten an Streaming-Records anzuhängen. Keine Standard-API für die Durchsetzung von Pipeline-Richtlinien. Die Hersteller bauen ihre eigenen Modelle, und diese interoperieren nicht gut. Wenn Sie auf einen bestimmten Ansatz setzen, setzen Sie teilweise darauf, welches Herstellermodell gewinnt.
Wo layline.io passt
Ich werde nicht so tun, als würden wir jeden Teil davon lösen. Bei layline.io haben wir uns auf die Runtime-Ebene konzentriert: eine Processing Engine für Batch und Streaming, die Metadaten durch Transformationen tragen, Richtlinien an Pipeline-Grenzen durchsetzen und Lineage über den gesamten Fluss pflegen kann.
Die Wette ist, dass Governance kein separates System sein sollte, das neben Ihrer Pipeline sitzt, Logs parst und hofft, alles zu erwischen. Sie sollte Teil der Pipeline selbst sein – eingebettet in denselben Runtime, der die Daten bewegt, durchgesetzt von denselben Code-Pfaden, die sie transformieren, sichtbar in derselben Observability-Ebene, die Ihnen sagt, ob die Pipeline gesund ist.
Das ist wichtig, weil die Alternative Fragmentierung ist. Ein Tool für das Katalogisieren, ein anderes für Streaming, ein anderes für Batch, ein anderes für Lineage, ein anderes für Policy Management. Jeder Integrationspunkt ist eine Naht, an der Governance lecken kann. Die Teams, mit denen ich spreche, sind diese Nähte leid.
Wir sind nicht die Einzigen, die in diese Richtung bauen. Confluent treibt Stream Governance voran. Airbyte rahmt Souveränität als architektonisches Problem ein. Der gesamte Markt bewegt sich in Richtung derselben Schlussfolgerung: Daten in Bewegung brauchen dieselben Kontrollen wie ruhende Daten. Wir bauen unseren Teil dieses Stacks.
Die Frage, die Sie Ihrem Governance-Team stellen sollten
Wenn Ihr Compliance-Team das nächste Mal ein sauberes Audit abzeichnet, fragen Sie sie:
„Können Sie mir zeigen, wohin Kunden-PII zwischen der Produktionsdatenbank und dem Warehouse geht? Nicht die Endpunkte – den Weg. Jedes Topic, jeder Anreicherungsaufruf, jede Replik.“
Wenn die Antwort ein Diagramm mit zwei Kästchen und einem Pfeil ist, haben Sie keine Governance. Sie haben Hoffnung.
Die gute Nachricht ist, dass die Behebung nicht erfordert, alles herauszureißen. Sie erfordert, den Kontrollpunkt vom Zielort auf die Reise zu verlagern. Beginnen Sie an den Grenzen. Fügen Sie der Pipeline Richtlinien hinzu. Machen Sie Lineage zum Teil des Runtime. Die Tools werden besser, die Muster klarer, und die Teams, die das als Erstes herausfinden, werden einen echten operativen Vorteil haben – nicht nur sauberere Audits, sondern weniger Vorfälle, schnellere Wiederherstellung und Dateninfrastruktur, der sie tatsächlich vertrauen können.
Wenn Sie über Governance für Streaming- oder CDC-Pipelines nachdenken, kontaktieren Sie uns. Wir arbeiten mit Teams an genau diesem Problem – und die Lösungen sind pragmatischer, als sie auf den ersten Blick erscheinen.
Andrew Tan ist ein Serienunternehmer und Gründer von layline.io, der Unternehmensdatenverarbeitungsinfrastruktur aufbaut, die sowohl Batch- als auch Echtzeit-Workloads im großen Maßstab bewältigt.
