Fabric, Databricks, Snowflake, BigQuery oder Cloudera — Den Governance-Einstieg auswählen

Begriffe vor dem Lesen

• Governance — Gemeinsame Regeln, Rollen und Nachweise, damit Daten verantwortbar genutzt werden.
• verantwortliche Person — Fachlich verantwortliche Person oder Rolle, die Zweck, Bedeutung und Freigabe klärt.
• technischer Betreiber — Technische Rolle, die Plattform, Zugriff, Betrieb oder Umsetzung betreut.
• Nachweis — Nachvollziehbarer Nachweis zu Entscheidung, Prüfung, Umsetzung oder Ausnahme.

Ausgangslage

Wähle den Governance-Einstieg anhand der bestehenden Landschaft, des ersten governeden Use Cases, des Operating Models und verpflichtender Controls statt über einen Feature-Vergleich.

Was diese Serie klärt

• Orientierung: Fabric, Databricks, Snowflake, BigQuery oder Cloudera — Den Governance-Einstieg auswählen
• Vertiefung: Governance über mehrere Datenplattformen
• Abschluss mit betreibbaren Next Steps über die Dienstleister-Start-Nachbarserie

Begriffe und Kürzel vor dem Lesen

• dbt — data build tool: SQL-nahe Transformationsschicht; Modelle brauchen verantwortliche Person, Tests und Verträge wie jedes Datenprodukt.
• verantwortliche Person — Person oder Rolle mit der Pflicht, Bedeutung, Nutzung, Risiko und Freigabe für ein Datenprodukt oder eine Kennzahl zu entscheiden.
• Metadata — Daten über Daten: Definition, verantwortliche Person, Quelle, Aktualität, Qualität, Klassifikation, Lineage, Status.
• Data Catalog — Auffindbarkeitsschicht für Assets, Begriffe, Owner und Richtlinien — eine Anwendung von Metadata, nicht Metadata selbst.
• Nachweis — Nachweis, dass Kontrolle, Entscheidung oder Test stattfand — Zeitstempel, verantwortliche Person, prüfbare Artefakte.
• Data Vereinbarung — Vereinbarung zwischen Anbieter und Nutzer: Felder, Bedeutung, Qualität, Aktualität, Änderungsvorlauf, Kontakte.

Lesepfad

1. Den Governance-Einstieg auswählen
2. Governance über mehrere Datenplattformen

Vendor-Starts (Nachbarserie): Governance-Plattform Vendor-Starts

Die Beispiele sind Lehrfälle (keine Kundendaten). Ersetzt Tabellen-, Report-, Pfad- und Toolnamen durch eure Catalog-, BI-, Ticket- und Prozessquellen.

Herausforderung

KMU/SMB — ein governed Use Case auf dem aktuell betreibbaren Stack (neue Plattform nur mit Nachweis). Mid-Market — 1–2 Hypothesen mit derselben Control-Evidenz vergleichen. Enterprise — Authority-Matrix über Plattformen vor Standardisierung.

Die Lenkungsrunde fragt: „Fabric, Databricks oder Snowflake?“ — bevor Verantwortung, erster Use Case und Pflichtkontrollen klar sind. Sechs Wochen später gibt es Lizenzen und Workshops, aber keinen Bericht, den Fachseite und Audit gemeinsam als gesteuert anerkennen.

Eine Plattformentscheidung wird unzuverlässig, wenn sie mit Produktnamen beginnt. Fabric, Databricks, Snowflake, BigQuery und Cloudera CDP können governed Data Delivery unterstützen, starten jedoch aus unterschiedlichen Architekturannahmen. Die eigentliche Frage lautet nicht „welche Plattform hat die längste Governance-Liste?“, sondern: Welcher Einstieg liefert das erste wertvolle Data Product mit Owner, Zugriff und Nachweis bei erträglicher Reibung — oder bewusst keine neue Plattform?

Diese Unterscheidung ist entscheidend. Der technisch stärkste Kandidat kann trotzdem der falsche Einstieg sein. Fabric, Databricks, Snowflake, BigQuery und Cloudera sind Beispiele für Start-Hypothesen, keine gerankten Gewinner. Eine Plattform kann Änderungen an Identity, neue Skills, einen weiteren Katalog, zusätzliche Lizenzen, regionale Ausnahmen, Netzwerkanpassungen oder Betriebsverantwortung erfordern, die die Organisation noch nicht tragen kann. Umgekehrt kann der bestehende Stack die verpflichtenden Controls bereits erfüllen und lediglich klarere Verantwortung-, Metadaten- und Qualitätsprozesse benötigen.

Der Vergleich muss daher sechs Kandidaten enthalten:

• Microsoft Fabric
• Databricks
• Snowflake
• BigQuery
• Cloudera CDP
• keine neue Plattform

Der sechste Kandidat ist kein Ausweg aus einer Entscheidung. Er ist ein gültiges Ergebnis, wenn die bestehende Landschaft die erforderlichen Controls erfüllt, der erste governed Use Case keine Migration rechtfertigt oder die Evidenz für einen Plattformwechsel noch unvollständig ist.

Decision-/Intelligence-Plattformen wie Palantir oder Argonos ersetzen diese Kandidatenliste nicht. Sie nutzen denselben Evidenz-Rahmen (Operating Model, Residenz, Exit, Pillars) — siehe Palantir und Argonos. Steht die Hypothese, folgen die Starts in dieser Serie: Palantir · Argonos.

Der Ausgangskontext muss dokumentiert werden, bevor ein Produkt bewertet wird:

• bestehende Cloud- und Plattformlandschaft
• dominante BI- und Consumption-Schicht
• Bedarf für Engineering, Warehouse, Streaming und Machine Learning
• Reifegrad von Verantwortung und Stewardship
• Identity- und Access-Modell
• Betriebsmodell für Katalog und Metadaten
• personenbezogene Daten-, Residency- und Netzwerkvorgaben
• Delivery- und Betriebskapazität
• Kostentransparenz und Kostenverantwortung

Produktnamen dürfen erst einfließen, nachdem verpflichtende Controls, organisatorische Passung und erforderliche Evidenz definiert wurden.

Ansatz

Wähle den Plattform-Einstieg, der für den ersten governeden Use Case verantwortliche Verantwortung, Auffindbarkeit, den Schutz sensibler Daten, kontrollierten Zugriff, Lineage, Qualitätsnachweise und vertrauenswürdige Nutzung etablieren kann. Behandle das Ergebnis als validierten Startpunkt und nicht als dauerhafte unternehmensweite Standardisierung.

1. Den minimalen Governance-Vertrag definieren

Vor dem Plattformvergleich muss feststehen, was das erste governed Data Product nachweisen soll.

Der Vertrag sollte mindestens enthalten:

• den verantwortlichen Data Owner und den operativen Steward
• die Business-Frage und die freigegebene Definition
• die autoritative Quelle und den Ziel-Körnung
• die zulässigen Konsumenten und Verwendungszwecke
• die Identity-Gruppen und die Zugriffsentscheidung
• die personenbezogene Daten- oder Sensitivitätsklassifizierung
• erforderliches Masking, Row Filtering oder andere Schutzmaßnahmen
• Lineage-Evidenz von der Quelle bis zur Nutzung
• Qualitätsregeln, Schwellenwerte und Incident verantwortliche Person
• den Publikations-, Zertifizierungs- und Deprecation-Prozess
• das nach der Umsetzung verantwortliche Betriebsteam

Dieser Vertrag trennt eine reale Governance-Anforderung von dem allgemeinen Wunsch nach einer neuen Plattform.

2. Einen ersten governeden Use Case auswählen

Eine mehrjährige Plattformvision ist kein geeigneter erster Test. Wähle ein abgegrenztes Data Product, das wertvoll genug ist, um Governance-Lücken sichtbar zu machen, aber klein genug für einen kontrollierten Proof of Value bleibt.

Ein geeigneter erster Use Case besitzt:

• eine benannte Entscheidung oder einen benannten Konsumenten
• einen klaren verantwortliche Person
• bekannte Quellsysteme
• einen stabilen initialen fachliche Ebene
• mindestens ein sensibles oder kontrolliertes Attribut
• messbare Qualitätserwartungen
• einen sichtbaren Consumption-Pfad
• einen realistischen operativen verantwortliche Person

Der Proof of Value muss die vollständige Control-Kette prüfen, nicht nur Ingestion oder Query Performance.

3. Plattformsignale als Hypothesen verwenden

Die folgenden Signale grenzen die Untersuchung ein. Sie wählen keinen Gewinner automatisch aus.

Fabric

Fabric ist eine plausible Starthypothese, wenn die Landschaft bereits Microsoft-zentriert ist, Power BI oder Semantic-Model Delivery dominiert, Entra-basierte Identity etabliert ist und das erste governed Data Product von einem eng integrierten Analytics- und Consumption-Pfad profitieren kann.

Relevante Evidenz:

• Zuordnung von Fabric Items, Workspaces und Domains zu verantwortlicher Verantwortung
• Unterstützung von Discovery, Lineage und Information Protection durch die Microsoft-Purview-Integration
• Einbindung von Sensitivity Labels, Endorsements und Certification in den Publikationsprozess
• Lizenzierung und regionale Verfügbarkeit der benötigten Fabric- und Purview-Funktionen
• Fähigkeit der Organisation, Capacity, Tenant Settings, Workspaces und Domain Delegation konsistent zu betreiben

Die Hypothese wird schwächer, wenn primär Cross-Cloud Engineering, umfangreiche Nicht-Microsoft-Verarbeitung oder ein Operating Model benötigt wird, das Fabric- und Purview-Verantwortung nicht koordinieren kann.

Databricks

Databricks ist eine plausible Starthypothese, wenn der erste Use Case Engineering-lastig, Lakehouse-orientiert, Streaming-intensiv oder eng mit Machine Learning und AI verbunden ist. Unity Catalog bildet den Governance Control Plane für governed Data- und AI-Assets innerhalb des Databricks Operating Models.

Relevante Evidenz:

• Architektur von Unity-Catalog-Metastore und Workspaces
• Verantwortung und Privilege Inheritance
• Identity Federation und Gruppenmanagement
• Abdeckung von Tabellen, Volumes, Modellen und weiteren securable Objects
• Betrieb Lineage und Audit-Evidenz
• erforderliche Klassifizierung, Tags, Richtlinien und Quality Monitoring
• Cloud-spezifische Netzwerk-, Storage- und regionale Vorgaben
• Engineering-Kapazität für den gemeinsamen Betrieb von Pipelines, Compute und Governance

Die Hypothese wird schwächer, wenn die Organisation hauptsächlich ein governed SQL Warehouse und einen Semantic-Delivery-Pfad benötigt, aber nicht über die Kapazität zum Betrieb einer breiteren Lakehouse-Umgebung verfügt.

Snowflake

Snowflake ist eine plausible Starthypothese, wenn der erste governed Use Case auf SQL Analytics, governeder Warehouse-Nutzung, Data Sharing oder einem Cross-Cloud Data Service basiert. Snowflake Horizon Catalog und native Policy Objects können Discovery, Lineage, Klassifizierung und Schutz innerhalb der Snowflake-Landschaft unterstützen.

Relevante Evidenz:

• Account-, Database-, Schema- und Role-Design
• Verantwortung und Rollenhierarchie
• Tags, Klassifizierung und Richtlinie-Zuordnung
• Masking, Row Access und weitere Data-Protection-Anforderungen
• Lineage- und Access-History-Evidenz
• Secure Sharing und Nutzer Boundaries
• editionsabhängige Governance-Funktionen
• Kostenverantwortung für Warehouses, Storage und Consumption

Die Hypothese wird schwächer, wenn das erste Data Product überwiegend komplexes Streaming, Notebook-zentriertes Engineering oder ML Operations außerhalb des vorgesehenen Snowflake Delivery Models benötigt.

BigQuery

BigQuery ist eine plausible Starthypothese, wenn die Landschaft GCP-nativ ist und der erste Use Case von serverlosen SQL Analytics, Google Cloud IAM und einem Managed-Analytics-Betriebsmodell profitiert. Knowledge Catalog, ehemals Dataplex Universal Catalog, stellt Katalog-, Glossar-, Metadaten-, Lineage- und Data-Quality-Funktionen für die Google-Cloud-Datenlandschaft bereit.

Relevante Evidenz:

• Verantwortung von Projects, Datasets und Tabellen
• Zugriffsverwaltung- und Gruppendesign
• Row-Level Access Richtlinien
• Schutz auf Spaltenebene über Richtlinie Tags oder aktuelle Data-Governance-Tags
• Anforderungen an Data Masking
• Abdeckung von Metadaten, Glossar und Lineage im Knowledge Catalog
• Deployment automatischer Data-Quality-Prüfungen und Alert Verantwortung
• regionale Kompatibilität von BigQuery-, Richtlinie- und Katalogressourcen
• Kostenverantwortung für Slots, Reservations oder On-Demand-Nutzung

Die Hypothese wird schwächer, wenn die Organisation GCP Identity, Projects, Networking und regionale Ressourcenabhängigkeiten nicht als Teil des governeden Data Products betreiben kann.

Cloudera CDP

Cloudera CDP ist eine plausible Starthypothese, wenn On-Prem- oder Hybrid-Lakehouse, feingranulares Policy-Durchsetzung und bestehende Hadoop-/CDP-Skills den ersten governed Use Case tragen. SDX (Ranger, Atlas, Hive Metastore) bildet die technische Governance-Oberfläche; fachliche Authority bleibt außerhalb der Admin-Konsole.

Relevante Evidenz:

• Cluster- und Umgebungsgrenzen (Produktion/Non-Produktion, Accounts)
• SDX-Umfang: Ranger, Atlas, Hive Metastore
• Identity: Kerberos, LDAP/AD-Gruppen vs. Service Accounts
• Resource- vs. tag-basierte Ranger-Richtlinien inkl. wirksamer Tests
• NiFi-/Spark-/Hive-/Kafka-Pfad mit stabilem Produkt-Identifier
• Atlas-Klassifikation und Lineage-Vollständigkeit
• Nachweispaket: Richtlinie-Version, Audit, Effective-Access-Tests
• Betriebsverantwortung in Cloudera Manager vs. fachliche verantwortliche Person

Die Hypothese wird schwächer, wenn der Use Case primär SaaS-Analytics ohne Cluster-Betrieb ist oder Verantwortung nicht von Ranger-Administration getrennt werden kann.

Bestehender Stack

Der bestehende Stack ist der bevorzugte Einstiegspunkt, wenn er dieselben verpflichtenden Controls ohne neue Plattform nachweisen kann. Dafür können Prozess- und Metadatenverbesserungen statt einer Migration erforderlich sein.

Erforderliche Evidenz:

• benannte Owner und Stewards
• freigegebene Business-Definition und fachliche Ebene
• durchsuchbare Metadaten oder kontrolliertes Inventory
• durchsetzbarer Zugriff und Schutz
• Lineage oder reproduzierbare Source-to-Nutzer-Evidenz
• ausführbare Qualitätsprüfungen und Incident Verantwortung
• Regeln für vertrauenswürdige Publikation und Deprecation
• vertretbare Betriebs- und Supportkosten

Eine Entscheidung gegen eine neue Plattform ist nur gültig, wenn diese Controls nachgewiesen sind. Sie ist keine Erlaubnis, Governance implizit zu lassen.

4. Einstiegspunkt und Standardisierung trennen

Die Entscheidung muss festhalten:

• wo das erste governed Data Product startet
• welche Kontrollregeln nachgewiesen wurden
• welche Lücken bestehen bleiben
• welche Koexistenz akzeptiert wird
• was eine breitere Standardisierung auslösen würde
• wodurch die Entscheidung ungültig würde

So wird verhindert, dass ein Proof of Value ohne erneute Prüfung zu einem Enterprise-Mandat wird.

Checkliste

Nutze für jeden Kandidaten dieselben Evidenzkategorien.

Verantwortung und Stewardship

• Ist jedes governed Data Product einem verantwortlichen Data Owner zugeordnet?
• Können operative Stewardship-Aufgaben zugewiesen und gemessen werden?
• Bleiben Plattformadministration und fachliche Verantwortung getrennt?
• Ist eine Eskalation definiert, wenn Verantwortung fehlt oder umstritten ist?

Katalog und Business-Metadaten

• Können Konsumenten das Data Product über freigegebene Business-Sprache finden?
• Sind Definition, fachliche Ebene, verantwortliche Person, Klassifizierung, Freshness und erlaubte Nutzung sichtbar?
• Können Metadaten über einen Betriebsworkflow statt durch einmalige Dokumentation gepflegt werden?
• Kann der Katalog bei Bedarf Assets außerhalb der Kandidatenplattform abbilden?

Identity und Access

• Integriert sich der Kandidat mit dem autoritativen Identity Provider?
• Sind Verantwortung und Lifecycle der Gruppen kontrolliert?
• Kann Zugriff auf der erforderlichen Objekt-, Zeilen- und Spaltenebene ausgedrückt werden?
• Sind privilegierte Administration, Break-Glass Access und Audit-Evidenz abgedeckt?

PII-Klassifizierung und Schutz

• Können sensible Attribute konsistent klassifiziert werden?
• Können Masking, Filtering oder andere Richtlinien zur Query-Zeit durchgesetzt werden?
• Bleibt der Schutz in Extracts, Partnerfreigaben, semantisches Modells und Downstream Tools wirksam?
• Welche Funktionen erfordern eine höhere Edition, ein Zusatzprodukt oder einen regionalen Service?

Lineage und Source Evidence

• Wird Lineage für die benötigten Verarbeitungspfade automatisch erfasst?
• Umfasst sie relevante Tabellen, Spalten, Jobs, Notebooks, semantisches Modells und Reports?
• Können Ausnahmen oder nicht unterstützte Transformationen dokumentiert werden?
• Reicht die Evidenz für Impact Analysis und Incident Investigation aus?

Qualität und Incident Verantwortung

• Können Qualitätsregeln versioniert und ausgeführt werden?
• Werden Fehler als Evidenz gespeichert und nicht nur visualisiert?
• Wird ein Incident an einen benannten verantwortliche Person geroutet?
• Können Konsumenten erkennen, ob ein Data Product gesund, eingeschränkt oder deprecated ist?

Consumption- und Workload-Fit

• Passt die Plattform zur dominanten BI- und semantisches Modell-Schicht?
• Unterstützt sie die erforderlichen SQL-, Engineering-, Streaming- und ML-Workloads?
• Sind governed Sharing und externe Konsumenten abgedeckt?
• Erfordert der Use Case ein weiteres Tool, das Metadaten oder Kontrollregel Verantwortung aufteilt?

Cloud-, Residency- und Netzwerk-Fit

• Sind alle benötigten Services in der Zielregion verfügbar?
• Können Data Residency und Network Isolation erfüllt werden?
• Sind Cross-Region-Abhängigkeiten für Metadaten, Richtlinien, Replikation oder Egress verstanden?
• Passt das Zieldesign zur bestehenden Cloud Landing Zone?

Betriebskapazität

• Wer betreibt Plattform, Katalog, Identity, Richtlinien, Qualität und Incidents?
• Sind die benötigten Skills intern verfügbar?
• Ist das Supportmodell klar?
• Kann die Organisation die Kontrollregeln nach dem Projekt weiter betreiben?

Kostenverantwortung

• Sind Kosten für Plattform, Capacity, Compute, Storage, Katalog, Governance und Netzwerk sichtbar?
• Sind Editionen und Add-ons berücksichtigt?
• Ist ein Cost verantwortliche Person benannt?
• Können Koexistenz- und Migrationskosten mit dem bestehenden Stack verglichen werden?

Ein Kandidat muss eine offene Frage bleiben, solange Evidenz fehlt. Annahmen dürfen nicht in Scores umgewandelt werden.

Artefakt

Dokumentiere das Ergebnis in einer Platform-Starting-Point-Entscheidung. Das Artefakt muss durch fachliche Verantwortung, Architektur, Security, Platform Operations und Delivery reviewbar sein.

Dokumentiere die Entscheidung mit dem Tool Governance Starting-Point Decision.

Pflichtfelder

Erforderliche Outputs

• bevorzugter Einstiegspunkt
• bedingte Alternative
• ungelöste Blocker
• Validierungsplan
• explizite Non-Goals
• Review-Datum

Entscheidungsregel

Lehne einen Feature Beauty Contest ab. Genehmige einen Kandidaten nur, wenn er für den definierten Kontext und den ersten governeden Use Case einen besseren Governance-Fit nachweist.

Eine belastbare Entscheidung kann deshalb lauten:

Wir starten in der bestehenden Microsoft-Landschaft und validieren Fabric für das erste governed Semantic Data Product. Databricks bleibt die bedingte Alternative, wenn Engineering- und Streaming-Anforderungen das validierte Fabric Operating Model überschreiten. Keine der beiden Plattformen wird standardisiert, bevor Verantwortung, PII-Schutz, Lineage, Qualitätsnachweise, Support und Kostenverantwortung nachgewiesen sind.

Dasselbe Muster kann jeden der sechs Kandidaten auswählen. Der Wert liegt in der Evidenz und den Bedingungen, nicht im Produktnamen.

Tools

Tools dienen der Sammlung von Evidenz und nicht der Erzeugung eines universellen Scores.

Entscheidungs- und Operating-Model-Tools

• Canvas für den ersten governeden Use Case
• Verantwortung- und Stewardship-RACI
• Checkliste verpflichtender Kontrollregeln
• Plattform-Evidenzmatrix
• personenbezogene Daten- und Access-Entscheidungsprotokoll
• Lineage Coverage Map
• Quality-Rule- und Incident-Register
• Skill- und Betriebskapazitätsbewertung
• Lizenz- und Regionalvalidierungslog
• Proof-of-Value-Acceptance-Record
• Platform-Starting-Point-Entscheidung

Zu validierende Control Surfaces

• Fabric: Fabric Governance, Domains, Workspaces, Endorsements, Sensitivity Labels und Microsoft-Purview-Integration
• Databricks: Unity Catalog, Account- und Workspace-Administration, Privileges, Lineage, Audit und governed Data-/KI-Assets
• Snowflake: Horizon Catalog, Rollenhierarchie, Tags, Classification, Masking Richtlinien, Row Access Richtlinien, Lineage und Access History
• BigQuery: Zugriffsverwaltung, Datasets, Row-Level Access Richtlinien, Column-Level Kontrollregeln, Data Masking und Knowledge Catalog
• Cloudera CDP: SDX, Ranger, Atlas, Hive Metastore, Kerberos/LDAP, NiFi/Spark/Kafka-Durchsetzung und Audit-Evidenz
• Bestehender Stack: vorhandene Katalog-, Zugriffsverwaltung-, Metadaten-, Quality-, Lineage- und Publication-Kontrollregeln

Die Verfügbarkeit eines Tools ist kein Implementierungsnachweis. Jeder Control muss im Zielkontext konfiguriert, betrieben und getestet werden.

Ressourcen

Die aktuelle Produktdokumentation muss zum Implementierungszeitpunkt erneut geprüft werden, da sich Bezeichnungen, Lizenzierung, APIs, Previews, regionale Verfügbarkeit und Einschränkungen ändern können.

• Microsoft-Fabric-Governance-Dokumentation
• Microsoft Purview zur Governance von Microsoft Fabric verwenden
• Governance und Compliance in Microsoft Fabric
• Databricks: Data and KI Governance mit Unity Catalog
• Databricks: Was ist Unity Catalog?
• Snowflake Horizon Catalog
• Data Governance in Snowflake
• Google Cloud Knowledge Catalog
• Automatische Datenqualität im Knowledge Catalog
• BigQuery-Sicherheit auf Zeilenebene
• BigQuery-Zugriffssteuerung auf Spaltenebene
• Cloudera CDP Ranger Start
• Cloudera Security / Ranger Docs
• Lernpfad Cloudera CDP Governance