Der Aufstieg des modernen Data Warehouses: Zwanzig Jahre in acht Epochen

Wie können Unternehmen von manuell erstellten Verkaufsberichten zu einer mehrmandantenfähigen PB-Skalenplattform mit Tausenden von Verbrauchern gelangen und wie wird sich die Entwicklung in den nächsten zehn Jahren gestalten?

Vor zwanzig Jahren war ein “Datenwarehouse” fast gleichbedeutend mit der Extraktion, Transformation und Laden (ETL) von Daten in ein Oracle- oder relationales Datenbankmanagementsystem (RDBMS). Der Speicherplatz wurde in GB gemessen. Berichte wurden monatlich oder wöchentlich ausgeliefert. Die meisten Unternehmen hatten weniger als ein Dutzend Dashboards, und Analysten waren oft die Wächter von SQL.

Springen wir in die Gegenwart:

Google BigQuery kann Abfragen an EB-Skalendaten stellen.

Netflix nutzt Apache Iceberg, um täglich Milliarden von Streamingereignissen zu verwalten.

Uber verwaltet mehr als 150 PB an Daten mit Apache Hudi.

Dies ist nicht nur eine technische Frage — es ist die Geschichte davon, wie Daten zum zentralen Produkt moderner Unternehmen geworden sind.

Erste Ära: 2005–2010 · Direkte Tabellen → “Nur Berichte erstellen”

💡  “Daten sind eine Kostenstelle, kein Vermögenswert.”

Anwendungen schrieben direkt in Berichtetabellen (sales_report, customer_report, inventory_report). Berichte waren in der Regel hartcodierte SQL-Skripte, die über cron-Jobs regelmäßig ausgeführt wurden. Tabellenkalkulationen wurden manuell exportiert und per E-Mail als “einzige Quelle der Wahrheit” verschickt. Anwendungen schrieben direkt in Berichtetabellen. Dashboards fragten diese Tabellen direkt ab.

Dieser Ansatz war in Ordnung, bis jemand fragte: 👉  “Wie hoch ist unser Umsatz pro Kundengruppe unter Berücksichtigung der Lagerverfügbarkeit?”

Die Lösung dieses Problems erforderte in der Regel die manuelle Verknüpfung von Daten in Excel — manchmal dauerte dies Wochen.

Der Business-Intelligence-Magischen Quadrant-Bericht von Gartner aus dem Jahr 2008 beschrieb die Nutzung von Datenwarehouses/Business Intelligence als “auf wenige Führungskräfte beschränkt”. Weniger als 10 % der Mitarbeiter in den meisten Unternehmen hatten Zugang zu Daten aus einem Datenwarehouse.

Branchenumbruch: Google's Dremel (2010) bewies, dass SQL in Sekundenschnelle Billionen von Datensätzen verarbeiten kann. Dies führte zur Entstehung von BigQuery und revolutionierte die Erwartungen an die Datenverarbeitung, indem es den Übergang von Batchberichten zur interaktiven Analyse ermöglichte.

Zweite Ära: 2011–2015 · Cloud-Datawarehouses gehen Mainstream

💡  “Elastizität ist die neue Skalierbarkeit.”

Drei bahnbrechende Innovationen:

BigQuery (offiziell 2011)  → Das erste serverlose, nutzungsbasierte Datenwarehouse.

Amazon Redshift (offiziell 2013)  → Das erste kostengünstige PB-Skalen-Datenwarehouse. Bei der Einführung betrug der Preis etwa 1.000 US-Dollar/TB/Jahr, fast 20 Mal weniger als bei Teradata.

Snowflake (2016)  → Ein Datenwarehouse mit mehrclusterfähiger, getrennter Speicher- und Rechenarchitektur.

Die Einführung von Redshift löste eine der größten Migrationen in der Datenhistorie aus — binnen drei Jahren wechselten Tausende von Oracle/Teradata-Kunden zu AWS.

Auswirkungen: Verkaufsdaten, Kundendaten und Lagerdaten konnten erstmals in einem cloudnativen Datenwarehouse zentralisiert werden. Die Skalierung bedeutete nicht mehr, neue Hardware zu kaufen, sondern Cluster binnen Minuten zu starten.

Dritte Ära: 2015–2018 · Spaghetti-Pipelines → Normalisierte Rohdatenbereiche

💡  “Entweder gibt es eine einzige Quelle der Wahrheit, oder es gibt keine Wahrheit.”

Mit zunehmender Verbreitung explodierte die Anzahl der Pipelines:

Die Finanzabteilung benötigte ein finance_sales-Schema.

Die Recruiting-Marketingabteilung benötigte ein campaign_customers-Schema.

Die Recruiting-Operationsabteilung benötigte ein inventory_ops-Schema.

Bald schrieben Anwendungen in mehrere redundante Datenquellen. Die Governance-Mechanismen brachen zusammen.

Lösung: Normalisierte Rohdaten + ausgewählte Datenbereiche.

Rohdaten: sales_raw, customers_raw, inventory_raw.

Ausgewählte Daten: fact_sales, dim_customers, fact_inventory.

Tools wie Presto (Facebook, 2013) unterstützen verteilte Abfragen über mehrere Datenquellen hinweg. Bis 2018 führte Facebook täglich über 30.000 Presto-Abfragen aus, um Produktanalysen und Werbeberichte zu unterstützen.

Fallstudie: In dieser Zeit wechselte Airbnb von MySQL-Dumps zu einem Hive-basierten Datenwarehouse und später zu Minerva, um die Konsistenz von Metriken sicherzustellen.

Technischer Meilenstein: Presto (entwickelt von Facebook) wurde das erste schnelle verteilte SQL-Engine. Es ermöglichte die Abfrage von Daten in Hive, MySQL und Cassandra, ohne die Daten zu migrieren.

Vierte Ära: 2016–2020 · Lakehouse

💡  “Säure ins Sumpfwasser bringen.”

Datenseen (HDFS, S3, GCS) wuchsen explosionsartig an — aber ohne Governance verwandelten sie sich in Daten-Sümpfe.

Lösung: Tabellenformate + ACID-Schicht.

Apache Hudi (2016, Uber)  → Inkrementelle Einfügungen, CDC, Zeitreihenanalyse. Unterstützt die Prognose der Ankunftszeit bei Uber Eats.

Delta Lake (2020, Databricks)  → ACID-Transaktionen, Schema-Evolution.

Apache Iceberg (Netflix)  → Skalierbare Metadaten, versteckte Partitionen. Netflix nutzt es, um täglich Milliarden von Ereignissen zu verarbeiten.

Bis 2019 nahm der Hudi-Pipeline von Uber täglich Billionen von Datensätzen auf und verwaltete über 150 PB an Speicherplatz.

Wichtigkeit: Diese Technologien schufen das Lakehouse. Business-Intelligence-Teams können Dashboards ausführen, während Machine-Learning-Engineer mit demselben konsistenten Datensatz Modelle trainieren können.

Fünfte Ära: 2018–2022 · Echtzeit-Datenwarehouses

💡  “Wenn es nicht in Echtzeit aktualisiert wird, ist es schon veraltet.”

Batch-ETL war für Uber, Netflix und LinkedIn nicht ausreichend:

Uber AthenaX  → Flink-basierte Stream-SQL. Wird für dynamische Preispolitik und Betrugsdetection verwendet.

Apache Pinot (LinkedIn → Uber)  → Subsekundige OLAP. LinkedIn nutzt es, um die Funktion “Wer hat Ihr Profil angesehen” anzuzeigen, und Uber nutzt es für Echtzeit-Betriebsdashboards.

Auswirkungen:

Verfügbarkeitsprobleme im Lager werden in Echtzeit erkannt.

Promotionskampagnen werden dynamisch angepasst.

Kundenschwund wird in Echtzeit markiert.

Netflix' Echtzeit-Infrastruktur (Mantis + Iceberg) verarbeitet täglich Hunderte von Milliarden von Ereignissen, um die Empfehlungen anzupassen.

Sechste Ära: 2018–2024 · Metadaten, Semantik und Governance

💡  “Daten ohne Kontext sind nur Rauschen.”

PB-Skalen-Datenwarehouses bringen neue Herausforderungen mit sich: Datenfindung, Vertrauenswürdigkeit und Governance.

Uber Databook  → Ein Metadatenplattform mit über 10.000 Datensätzen.

LinkedIn DataHub  → Open-Source-Metadaten + Datenherkunft, die jetzt von Unternehmen wie Expedia und Saxo Bank eingesetzt wird.

Airbnb Minerva  → Eine einheitliche Metrikenschicht, die Analysten jeden Quartal Tausende von Arbeitsstunden spart.

Gartner schätzt, dass bis 2023 60–70 % der Unternehmen mehrere widersprüchliche Metrikendefinitionen (“zwei Versionen des Umsatzes”) haben werden und dadurch aufgrund verringerter Entscheidungsqualität Milliarden von Dollar verschwenden werden.

Siebte Ära: 2022–2025 · Cross-Cloud-Architekturen

💡  “Ihre Daten sind überall, also muss es Ihr Datenwarehouse auch sein.”

Unternehmen betreiben jetzt Multi-Cloud- und Hybrid-Cloud-Umgebungen.

Google BigLake (2022)  → Eine einheitliche Governance-/Sicherheitsschicht für BigQuery und offene Tabellen

Microsoft OneLake (2023, Fabric)  → Ein “logischer Datensee” für alle Fabric-Services.

Achte Ära: 2025–2035 · Was kommt als Nächstes?

💡  “Ihr Datenwarehouse denkt für Sie.”

Prognosen auf der Grundlage aktueller Fakten:

1. AI-natives Datenwarehouse

Bereits in Betrieb: BigQuery AI, Snowflake Cortex, Microsoft Fabric Copilot.

Bis 2030 werden mehr als 50 % der Abfragen von AI-Co-Piloten automatisch generiert