Bestandsaufnahme & Zieldefinition
Anforderungsanalyse: Die instabile Bereitstellung und fehlerhafte Daten führen zu einem spürbaren Verlust des Vertrauens der Stakeholder und des Managements in das Reporting und die Datenbasis. Daher wurden im intensiven Austausch mit Stakeholdern klare Schwellenwerte für maximale Datenabweichungen gegenüber den Quellsystemen, sowie Richtlinien für die Aktualität der Daten werden festgelegt.
Analyse der bestehenden Struktur: Parallel zur Aufnahme der Anforderungen und dem Austausch mit Stakeholdern wurde die bestehende Architektur analysiert. Ziel dabei war eine schnelle Identifikation der Fehlerursachen und Performance-Bottlenecks, sowie die Evaluation möglicher Lösungsansätze.
Datenquellen und Formate: Eine große Menge an Rohdaten in unterschiedlichen Formaten - primär Web- und App-Analysedaten (Google Analytics, Google Play Store, App Store Connect, Crashlytics, etc.) soll automatisiert gespeichert und verarbeitet werden. Das datenmodell Datenmodell soll als zuverlässige Basis für tiefe Analysen und Reporting dienen und bei hohem Detailgrad möglichst verständlich und skalierbar bleiben.
Komplexität & Datenqualität: Die existierende Datenstruktur führt in bestehenden Dashboards bei bestimmten Filteroperationen, insbesondere bei userbasierten Metriken, zu methodischen Fehlern wie unbeabsichtigten Ausschließungen oder Doppelzählungen. Außerdem wurde die Kapazitätsgrenze der Datasets wichtiger Reports durch steigende Datenmengen errreicht, weshalb die Reports nicht mehr aktualisiert werden können.
Konzeption & technische Architektur
Neugestaltung des Datenmodells: Zunächst wurde die bestehende Datenlandschaft in eine einheitliche Medallion-Architektur nach Databricks-Standard überführt. Die Daten wurden mithilfe automatisierter Jobs über mehrere Layer hinweg aufbereitet und in ein einheitliches Datenmodell im Star-Schema überführt. Eine besondere Herausforderung stellt dabei die Verarbeitung der wachsenden Menge an Google Analytics-Rohdaten im Terabyte-Bereich dar. Sie verursachte die Ladefehler und Ausfälle der Power BI Datasets. Ansätze zur Aggregation der Daten hatten wiederum zu fehlerhaften User Metriken auf den Dashboards geführt.
Optimierung der Datenmenge: Um die Probleme zu beheben wurde zunächst ein Mapping für die gezielte Ingestion und Strukturierung relevanter Daten entworfen. Anschließend wurde eine maßgeschneiderte Aggregationsebene mit definierten Subsets entwickelt, die die Größe des Datasets um über 90% reduzierte, aber nicht zu den zuvor beschriebenen Datenqualitätsproblemen führte.
Migration, Qualitätssicherung & Enablement
Zero-Downtime-Migration: Nach der Fertigstellung des neuen Datenmodells und umfassenden Datenqualitätstests wird die Power BI Reports and die neuen Tabellen angebunden, ohne das laufende Reporting zu unterbrechen.
Testing & Monitoring: Ein weiterer entscheidender Erfolgsfaktor war die Entwicklung und Dokumentation umfassender Testing-Strategien zur dauerhaften Sicherung der Datenqualität. Außerdem wurde ein Monitoring-Dashboards mit automatischen Benachrichtigungen bei Pipeline-Ausfällen oder Datenverzögerungen aufgebaut.
Team-Enablement: Abschließend wurde das neu entwickelte Dataset dokumentiert und die Plattform an das interne Team übergeben. Die implementierte Struktur ist auf eine unkomplizierte Erweiterung mithilfe zentraler Mappings ausgelegt.
