Von Hadoop zu Databricks auf Google Cloud: Migration mit eigenem Data-Quality-Framework, später Databricks DQX

Ausgangslage

Die Datenlandschaft war über Jahre gewachsen: ein Hadoop-Cluster für große Datenmengen, icCube als OLAP-Schicht für Auswertungen, dazu diverse PostgreSQL-Datenbanken mit operativen und abgeleiteten Daten. Jedes System hatte seine Berechtigung, zusammen waren sie teuer im Betrieb, schwer zu ändern und kaum nachvollziehbar. Ziel war eine Google-Cloud-Umgebung mit Databricks als zentraler Lakehouse-Plattform.

Aufgabe von Fidan Consulting

Fidan Consulting war maßgeblich für die Zielarchitektur der neuen Plattform verantwortlich – technisch und fachlich. Dazu gehörten die Datenmodellierung mit Schichtenmodell, Governance und Strukturierung, die Planung der Arbeitspakete inklusive Aufwandsschätzungen und die enge Abstimmung mit dem Projektmanagement zu Roadmap und Priorisierung. Ergänzend wurden Entwicklungsrichtlinien, ein Data-Governance-Konzept und Dokumentationsstandards aufgebaut.

Zielarchitektur

Die Migration folgte keinem Lift-and-Shift. Statt Hadoop-Jobs eins zu eins zu übertragen, wurde die Datenlandschaft neu geschnitten:

• Speicher: Delta Lake auf Google Cloud Storage als einheitliches Format für alle Schichten – anstelle von HDFS, Datenbank-Tabellen und OLAP-Würfeln nebeneinander.
• Schichtenmodell: Bronze für Rohdaten aus allen Quellen, Silver für harmonisierte und historisierte Daten, Gold für fachliche Modelle und Kennzahlen. Die icCube-Logik wurde in die Gold-Schicht überführt, statt eine weitere OLAP-Schicht zu betreiben.
• Governance: Kataloge, Schemata und Berechtigungen nach einem festen Schema, Dokumentation als Teil der Definition of Done.
• Arbeitspakete: Die Migration wurde quellsystemweise geplant, jedes Paket mit Aufwandsschätzung, Abhängigkeiten und Abnahmekriterien.

Das Data-Quality-Framework

Ein zentrales Element war die Datenqualität. Bei einer Migration ist die entscheidende Frage nicht, ob die Daten angekommen sind, sondern ob sie stimmen. Fidan Consulting hat ein eigenes Framework zur automatisierten Validierung und Überwachung von Datenqualitätsregeln innerhalb der Lakehouse-Architektur konzipiert und implementiert.

Das Framework prüfte an definierten Punkten der Verarbeitung:

• Vollständigkeit: Pflichtfelder, erwartete Zeilenzahlen, Abgleich mit der Quelle.
• Konsistenz: referenzielle Bezüge zwischen Tabellen, Summenabgleiche zwischen Schichten.
• Plausibilität: Wertebereiche, zeitliche Verläufe, Ausreißer gegenüber historischen Mustern.
• Schema-Validierung: Erwartete Spalten, Typen und Nullbarkeit, damit Änderungen an Quellsystemen früh auffallen.

Regeln wurden deklarativ definiert und in die bestehenden ETL- und ELT-Prozesse eingebettet; Ergebnisse flossen in ein Monitoring- und Reporting-Konzept, sodass Verstöße nicht nur geloggt, sondern gesehen wurden. Das Framework wurde über die Projektlaufzeit mit Fokus auf Skalierbarkeit und Wiederverwendbarkeit weiterentwickelt: Eine Regel wird einmal definiert und auf beliebig viele Tabellen angewendet.

Ablösung durch Databricks DQX

Als Databricks mit DQX ein eigenes Framework für Data-Quality-Prüfungen bereitstellte, wurde die Eigenentwicklung bewusst abgelöst. Die Regeln ließen sich übertragen, weil sie bereits deklarativ vorlagen. Der Gewinn: bessere Wartbarkeit, Standardisierung auf ein von Databricks gepflegtes Werkzeug und einfachere Erweiterbarkeit – ohne dass das Team weiter eigene Infrastruktur für Qualitätsprüfungen pflegen muss. Die Erfahrung aus dem eigenen Framework half dabei, DQX schnell und sinnvoll einzusetzen statt bei null zu beginnen.

Befähigung der Teams

Damit die Plattform nach der Migration ohne externe Hilfe weiterläuft, wurden Workshops und Schulungen durchgeführt: zu Architektur und Schichtenmodell, zu den Entwicklungsrichtlinien und zum Umgang mit dem Data-Quality-Framework beziehungsweise DQX.