„Materialized Views oder Tabellen? Strategien für effizientes Datenmanagement in der Google Cloud“

Ihr stolpert bei der Wahl der Architektur eines Anwendungsfalles in der Google Cloud mit BigQuery über den Begriff 'Materialized View' und seid euch unsicher, ob das etwas für euch ist und worin eigentlich der Unterschied zur Tabelle und einer herkömmlichen View liegt? Wann ist welche Technologie die bessere Wahl? In diesem Blogbeitrag zeigen wir euch aus den Erfahrungen eines Kundenprojektes, wie wir diese Entscheidung getroffen haben und wie ihr davon profitieren könnt. 

Ganz schön wolkig hier

In diesem Kundenprojekt beraten wir eine deutsche Großbank bei der Verfolgung ihrer Cloud-First-Strategie und sind maßgeblich an der Migration der Anwendungsfälle eines Bereichs in die Google Cloud beteiligt. Basis hierfür, ist die seit längerem nicht mehr unterstützte Hortonworks Data Platform (HDP), die bereits 2019 mit der nun existierenden Cloudera Data Platform (CDP) verschmolzen wurde. Anwendungsfälle, die aufgrund regulatorischer oder anderer Anforderungen nicht in die Cloud migriert werden können, werden auf die neue CDP migriert. Für alle anderen ist der Weg klar: Ziel ist die Google Cloud Platform (GCP) mit BigQuery als Basis.

Wir bekamen die Anforderung, auf Datenduplizierung in Form von weiteren Tabellen zu verzichten und stattdessen auf Materialized Views zu setzen, um einer erneuten Silobildung der Daten vorzubeugen.

Aber was sind die Unterschiede und was die Vor- und Nachteile einer Materialized View gegenüber Tabellen? Das klären wir jetzt. 

Über Materialized Views und Tabellen

Einer der Hauptunterschiede zwischen Materialized Views und Tabellen ist die Speicherung der Daten bzw. des Inhalts. Während bei einer Tabelle die Daten dauerhaft in der Struktur gespeichert und flexibel verändert und abgefragt werden, ist der Ansatz bei Materialized Views ein anderer. Hier werden die Ergebnisse einer Abfrage in einer persistenten Sicht (View) gespeichert. Im Gegensatz zu herkömmlichen Views trägt die Speicherung der vorab berechneten Ergebnisse in der Regel zu einer erheblichen Verbesserung der Abfrageperformance bei. Da es sich um eine View handelt, können die Quelldaten nicht verändert werden. Wenn also die Anforderung besteht, einzelne Datensätze zu ergänzen, zu ändern oder zu löschen, sind Materialized Views nicht zu empfehlen. Für unseren Use Case spricht theoretisch alles für den Einsatz von Materialized Views: Es werden kurze Antwortzeiten erwartet, die Änderung der Quelldaten ist irrelevant und die Datenabfragen sind stets ähnlich.

Nachfolgend könnt ihr euch einen Überblick über die gesammelten Eigenschaften von Materialized Views vs. Tabellen verschaffen und damit schnell ein Gefühl dafür bekommen, welche Basis bei euch sinnvoll eingesetzt werden kann: 

Wohin denn nun mit den Daten?

Der Anwendungsfall unseres Kunden erfordert eine interaktive Benutzeroberfläche zur Abfrage von Zahlungsverkehrsdaten für einen Bankkunden. Daher sind kurze Antwortzeiten notwendig, selbst bei einer großen Datenmenge im einstelligen Milliardenbereich, die partitioniert und geclustert vorliegt. Die Rohdaten aus dem Data-Landing-Prozess sind bereits in den entsprechenden Projekten in der Google Cloud verfügbar.

In der Architektur des früheren Anwendungsfalls auf der HDP-Plattform gab es neben den Rohdaten auch speziell angereicherte Daten in eigenen Tabellen, die für das Projekt vorgehalten wurden. Um eine erneute Silobildung der Daten zu vermeiden, entschieden wir uns diesmal gegen eine Datenverdopplung und setzten stattdessen auf Materialized Views.

Nach den ersten Tests in der GCP folgte jedoch eine Enttäuschung: Die Antwortzeiten lagen bei 20–40 Sekunden, was die Interaktivität der Anwendung massiv beeinträchtigt. Zum Vergleich: In der vorherigen Lösung lagen die Abfragezeiten zwischen wenigen hundert Millisekunden und einer Sekunde. Da die Abfragelogik und -komplexität nicht weiter vereinfacht werden konnten, musste eine alternative Lösung gefunden werden.

Die Lösung bestand darin, erneut auf eigene Tabellen zurückzugreifen und damit die Daten zu duplizieren, was die erwarteten schnellen Antwortzeiten wiederherstellte. Die Abfrage selbst ist sehr komplex, mit mehreren temporären Tabellen, die durch UNION ALL-Befehle und verschachtelte Aggregationen sowie Sortierungen kombiniert werden. BigQuery hat bei solch verschachtelten Abfragen auf großen Datensätzen von Natur aus Performanceprobleme und stößt dabei auch an Ressourcengrenzen.

Für diesen Anwendungsfall und die aktuelle GCP-Konfiguration war die Verwendung eigener Tabellen somit die performantere Wahl, auch wenn dies eine Datenverdopplung von mehreren Terabytes bedeutete.

Hinterher ist man immer schlauer

Durch die Verwendung von Tabellen konnte die Abfrageperformance des Anwendungsfalls wieder in den gewünschten Bereich gebracht werden. Auch wenn dies zu einer Duplizierung der Daten und zur Entstehung eines weiteren Datensilos führte, war es in diesem Fall notwendig.

Für andere Szenarien bieten Materialized Views jedoch eine vielversprechende Alternative, insbesondere dann, wenn Speicherbedarf und Kosten im Vordergrund stehen und häufig wiederkehrende Abfragen genutzt werden.

Unabhängig von der gewählten Lösung ist die Kategorisierung und Eintragung der Daten in einen Data Catalog (beispielsweise Dataplex in der Google Cloud) empfehlenswert. Dies ermöglicht anderen Fachabteilungen bei Bedarf einfachen Zugriff und unterstützt eine Data-Management-Kultur im Sinne von Data Mesh. Eine solche Vorgehensweise minimiert nicht nur die Bildung von Datensilos, sondern fördert auch die Transparenz und Beschleunigung bei der Bereitstellung neuer Datenprodukte – und das bei insgesamt höherer Qualität.

Falls weitere Fragen aufkommen oder Bedarf an einer individuellen Beratungsleistung besteht, zögert nicht, uns direkt zu kontaktieren – wir stehen gerne zur Verfügung, um gemeinsam maßgeschneiderte Lösungen für eure Anforderungen zu entwickeln. 

Seminarempfehlungen