Erfahrungsbericht: Einführung einer modernen BI-Architektur – ETL vs. ELT

Januar 2017, da stand sie vor mir, „die grüne Wiese“, der Traum jedes „Black Belt Data Ninjas“. Nun konnte ich endlich Business Intelligence-mäßig loslegen inklusive ETL Prozesse, Data Warehouse, Reports, Dashboards & Co. Zu diesem Zeitpunkt war das Hauptziel ein Marketing Reporting aufzubauen. Ein Google Analytics nahes, klassiches „ETL Werkzeug“ zum Extrahieren, Transformieren und Laden der Daten ins Data Warehouse schien erstmal die richtige Wahl zu sein, wir kamen jedenfalls sehr schnell ans Ziel. Doch das war erst der Anfang und so sind einige ETL Prozesse von Zeit zu Zeit dazu gekommen: Sales Reporting, Produktfeeds, Partner Reports, CSV Exports und und und….

Outdated ETL vs. Modern ELT
„Outdated ETL vs. Modern ELT“
Quelle: https://fivetran.com/blog/elt_vs_etl

Nachteile des klassischen ETL Ansatzes

Der klassiche ETL Prozess ist so alt wie Business Intelligence selbst. Seit den 80er Jahre werden die Daten mit Tools der üblichen Verdächtigen wie IBM, SAS, Talend, Pentaho, Oracle & Co. aus den Quellsystemen extrahiert, transformiert und in das Data Warehouse gebracht. Oftmals mit einer Visualisierung des Datenflusses, Drag & Drop Transformationsblöcken und nützlichen Werkzeugen wie einer Datenvorschau. Warum ist dieser altbewährte ETL Ansatz aus meiner Sicht nicht mehr optimal:

  1. Vor der Cloud Ära war es unfassbar teuer ein Data Warehouse zu betreiben. Datenbank-Lizenzen für 6-stellige Euro Beträge waren keine Seltenheit. Da hat sich jede Firma natürlich gut überlegt, welche (finale) Daten überhaupt in das Data Warehouse gespeichert werden müssen. Mittlerweile kann jede(!) Firma mit Technologien wie Google BigQuery, Amazon Redshift, Snowflake oder Microsoft Azure ein Data Warehous betreiben. Die Total Cost of Ownership für ein Datawarehouse sind drastisch gesunken. Damit spielt es nahezu keine Rolle mehr welche Daten und wie viele Daten im Data Warehouse gespeichert werden.
  2. Besonders Startups benötigen Agilität im Reporting. Relevante Dimensionen und Metriken können sich mit jedem neuen Business Modell schnell ändern. In der alten ETL Welt bedeuten Änderungen am Datenmodell (z.B. neue Dimensionen) oftmals einen vollständigen Datenload (evtl. die Daten mehrerer Jahre), damit alle Daten dem aktuellen Logiken folgen. Viele BI Teams sind mit den ständigen Änderungen überfordert und hängen im Maintenance-Teufelskreis fest. Anforderungen ändern sich einfach mit der Zeit, d.h. man kann sich zum Zeitpunkt X nie sicher sein, welche Daten in der Zukunft zum Zeitpunkt Y relevant für das Reporting werden.
  3. ETL Software ist in der Regel proprietär. Das heißt die kompletten Datenverarbeitungsprozesse (und damit Business-Logiken) liegen meistens in einem Hersteller-eignen Format vor. Ein schneller Wechsel des Anbieters ist nicht möglich und würde „Abreißen und neu bauen“ bedeutet, daher herrscht eine komplette Abhängigkeit zu dem Software Anbieter.
  4. Kein ETL Anbieter kann alle Datenquellen integrieren, die es in der Online Welt gibt. Besonders Marketing Datenquellen können durch die Vielzahl der Hunderten Werbenetzwerke eine Herausforderung für klassische ETL Tools darstellen. Bei der Integration der Kostendaten spielt aber die vollständige Abdeckung aller Kostendatenquellen eine enorm wichtige Rolle.
  5. Drag & Drop wirkt auf dem ersten Blick einfacher, ist es in der Regel auch, wenn es darum geht Prozesse „from scratch“ aufzubauen. Doch das Duplizieren, Anpassen oder Modularisieren solcher Prozesse ist deutlich eingeschränkter als es mit Quellcode jemals sein wird.
  6. Werden die prozessierten Datenmengen größer (> 10 GB) kommen die eigenen ETL Server schnell an Ihre physikalischen Grenzen oder benötigen sehr viel Zeit zur Verarbeitung, denn die Rechenleistung der ETL Prozesse liegt auf dem ETL Server, nicht im Data Warehouse Cluster.
  7. ETL bedeutet, die Rohdaten werden nicht zentral im Data Warehouse gespeichert. Damit hat man meistens keinen direkten Zugriff auf die Rohdaten, was einige Nachteile mit sich zieht wie z.B. für die Data Governance und Nachvollziehbarkeit insbesondere bei unstrukturierten Daten wie Video und Audio Material.

Ja,es geht auch ohne ETL aber…..

wie so oft hat auch die Gegenseite in der Praxis ihre Nachteile.

  1. ELT Prozesse bringen die Business-Logik Schicht in das Data Warehouse. Oftmals ist es daher notwendig sehr gute SQL Skills oder Ähnliches für die Datenmodellierung im DWH zu besitzen
  2. Für die Datenmodellierung fehlen die nützlichen Werkzeuge der klassischen ETL Softwarelösungen z.B. Datenvorschau, Daten QA, Errorhandling oder Job Monitoring
  3. ELT bedeudet nicht, dass die Datenintegration ein Kinderspiel wird. Auch hier muss man eine Vielzahl von verschiedenen Datenquellen in das Data Warehouse bringen…. mehr dazu später
  4. In der Realität kann, darf und sollte man keine Datensätze 1:1 in das Cloud Data Warehouse speichern insbesondere sensible Kundendaten. D.h. ein wenig Transformation ist auch vor dem DWH Datenload notwendig

Was verspreche ich mir von einer ELT Architektur

Ich persönlich sehe die Zukunft von Business Intelligence ganz klar in einer ELT Architektur. Ich habe selber erfahren, wie mühselig es sein kann, die „schnell gebauten“ ETL Flows über die Jahre zu warten. Daher konnte ich glücklicherweise die Vorteile der neuen Welt direkt erfahren:

  • Agilität im Reporting: schnelle Änderung des Datenmodells
  • Weniger Aufwand für Wartung / Anpassungen
  • Mehr Transparenz der Prozesse durch Standard Sprachen wie SQL
  • Chancen auf neue Mitarbeiter durch Tool-unabhängiges Wissen
  • „Ownen“ der Business Logiken und somit komplette Unabhängigkeit von Herstellern
  • Schnellere Datenupdatezyklen u.a. auch durch Real Time / Streaming Architekturen
  • Weniger Kosten durch Tooleinsparungen
  • Bessere Ausgangsarchitektur für Data Science Team

Beispielstack für eine ELT Architektur

Exemplarischer Technologie-Stack für eine ELT Architektur. Die verwendeten Anbieter sind Beispiele und müssen nicht zu den individuellen Requirements deines Unternehmens passen

10 Best Practices für eine Umsetzung mit Google BigQuery

Ich persönlich bin ein sehr großer Fan von Google BigQuery als Data Storage Lösung. Folgend findet Ihr 10 meiner Best Practices, die sich während der ELT Projekte mit Google BigQuery herauskristallisiert haben.

  1. Je nach verfügbaren Ressourcen, Budget und Datenquellsystemen machen Datenintegrationslösungen oftmals mehr Sinn als Eigenentwicklung. Lösungen wie Funnel.io und Fivetran können die „Time to Reporting“ deutlich verringern. Mit den passenden gemanaged Datenkonnektoren können die Daten mit Google BigQuery (oder anderen Datenbanktechnologien) synchronisiert werden. Man erschafft sich natürlich wieder ein Stück mehr Abhängigkeit zu Toolanbietern, da diese aber nur Rohdaten aus Fremdsystem transformieren, bleiben geschäftskritische Business-Logiken ein Asset der Firma und die Anbieter können relativ schmerzlos ausgetauscht werden. Bei einer geringerem Anzahl von Quellsystemen reichen eventuell auch eigene Python Skripte etc., beide Varianten konnte ich erfolgreich und produktiv umsetzen.
  2. Wenn möglich, solltest du immer eine native Integration der Quellsysteme bevorzugen. Insbesondere Google bietet mit den Google Transfer Services bereits eine Vielzahl von Standardschnittstellen zwischen Google Ads, Google Spreadsheet, Google Gdrive etc. und Google BigQuery an. Diese Schnittstellen sind immer aktuell, da die Daten im „Google Universum“ bleiben.
  3. Nicht alle Daten sollten zwangläufig im Data Warehouse landen, insbesondere sensible Kundendaten müssen von einem automatischen Synchronisation ausgeschlossen werden. Arbeite daher immer mit White oder Blacklisten für deine Tabellen und Felder, egal ob die Daten mit oder ohne Tools ins Data Warehouse integriert werden. Zu Recht könnte man sagen, „reines ELT“ existiert meistens gar nicht, es ist eher „ETLT“ 🙂 P.S. achte auch darauf wo die Daten in Google BigQuery gespeichert werden (Location: EU).
  4. Betrachte Business-Logiken z.B. SQL Modelle als Unternehmensasset. Die Datenmodelle solltest Dir gehören, nicht den Toolanbietern.
  5. Benutze ein Code Repository wie GitHub für deine Datenmodelle um alle Änderungen nachvollziehbar zu machen. Die kostenlose Version wird dafür in der Regel ausreichen.
  6. Aus meiner Erfahrung ist der schnellste Weg eine Vielzahl von Daten in Google BigQuery reinzuladen, der Weg über CSV / JSON Files in Google Cloud Storage. Was sich wie ein Workaround anhört, ist bei großen Datenmengen deutlich performanter als der Weg über die API
  7. Versuche die Quelldaten automatisiert gemäß der Anforderungen von Google BigQuery anzupassen z.B. keine Underscores „_“ als erstes Zeichen der Feldnamen oder die richtige Auswahl der Feldtypen
  8. Arbeite für die verschiedenen Zwischenschichten der SQL Modellierung mit BigQuery Views (Datenansichten), nicht nur mit reinen Tabellen
  9. Für das finale Reporting kannst du deine Views dann mit Hilfe von „Schedulded Queries“ in regelmäßigen Abständen materialisieren, (z.B. alle 3 Stunden) so dass die Views im Reporting nicht in Real Time dauernd neu berechnet werden müssen.
  10. Vergiss das Star Schema, eine konsolidierte große Tabelle mit allen relevanten Reporting Feldern führt in Google BigQuery zu bis zu 50 % mehr Performance als das klassische Star Schema mit verteilten Tabellen, auch wenn es zu einer höheren Datenmenge führt.

Weiterführende Ressourcen

Hast du Anmerkungen, Fragen oder Kritik? Dann freue ich mich sehr auf dein Kommentar. Ich hoffe du konntest etwas aus den Blog Post mitnehmen!