Data Warehouse

Warum es Warehouses gibt

Transaktionale Datenbanken (Postgres, MySQL) sind für hochfrequente Reads und Writes einzelner Zeilen optimiert, die Art, die Web-Apps brauchen. Sie sind nicht gut darin, eine Milliarde Zeilen zu scannen, um den Umsatz pro Kanal zu aggregieren.

Warehouses drehen die Optimierung um: spaltenbasierte Speicherung, parallele Query-Ausführung, getrennte Compute- und Storage-Ressourcen, nahezu unendliche Skalierung. Eine Query, die auf einer transaktionalen Datenbank 30 Sekunden dauert, kann auf einem Warehouse in 2 Sekunden zurückkommen, und das Warehouse kann Dutzende davon gleichzeitig laufen lassen.

Für Analytics, Attribution, BI und zunehmend KI-Agenten ist das Warehouse der Ort, an dem die Daten leben.

Was ins Warehouse kommt

Typischerweise alles, was für Analytics zählt:

• Web-Event-Daten: Page Views, Klicks, Conversions aus dem Tracking
• Bestelldaten: Käufe, Erstattungen, Produkte, Preise aus der E-Commerce-Plattform
• Kundendaten: Profile, Abos, Lifecycle-Events
• Marketing-Plattform-Daten: Ad Spend, Impressions, Klicks aus den APIs von Meta, Google, TikTok
• CRM-Daten: Leads, Opportunities, Account-Aktivität
• Finanzdaten: Kosten, Margen, GuV-Daten aus Buchhaltungssystemen

Die Pipelines, die Daten aus den Quellsystemen ins Warehouse bewegen, werden meist mit Fivetran, Airbyte, Hightouch Reverse-ETL oder eigenem Python gebaut. Das Warehouse wird zum kanonischen, abfragbaren Record.

Warehouse vs. Lake vs. Lakehouse

Viel überlappende Terminologie in 2026:

• Warehouse: strukturiert, Schema-on-Write, optimiert für SQL-Analytics
• Data Lake: rohe Dateien (JSON, Parquet, CSV) im Object Storage, Schema-on-Read
• Lakehouse: hybrid, Lake-Storage mit warehouse-artiger Query-Semantik (Databricks hat es geprägt, andere zogen nach)

Für die meisten Marketing-Analytics-Use-Cases ist ein Cloud-Warehouse (BigQuery, Snowflake) die richtige Form. Lakes glänzen bei unstrukturierten Daten mit hohem Volumen. Lakehouses bei ML und großangelegtem Data Engineering.

Wo das Warehouse in den modernen Stack passt

Quellsysteme     →   Pipelines   →   Warehouse   →   Semantic Layer   →   Konsumenten
(Shopify, Meta,                                                          (Dashboards,
 GA4, CRM, etc.)                                                          KI-Agenten, CRM)

Jede Ebene hat eine bestimmte Aufgabe. Das Warehouse speichert. Der Semantic Layer interpretiert. Die Konsumenten zeigen an oder handeln.

Warehouse-Performance und -Kosten

Warehouses berechnen nach Storage und Compute. Zwei praktische Sorgen:

• Kosten-Runaway: unoptimierte Queries (Full Table Scans auf Terabyte-Tabellen) können riesige Rechnungen auftürmen. Materialisiere schwere Aggregationen.
• Latenz-Mismatch: eine Warehouse-Query dauert Sekunden. Ein KI-Agent, der 10 Queries in Serie stellt, fühlt sich langsam an. Cache aggressiv auf Ebene des Semantic Layer.

Häufige Fehler

• Das Warehouse direkt aus Produktions-Apps abfragen. Falsches Werkzeug. Warehouses sind nicht für Echtzeit-Reads. Nutze dafür eine transaktionale Datenbank.
• Den Semantic Layer überspringen. Wenn jeder Konsument Metriken neu implementiert, entsteht Inkonsistenz.
• Daten ohne Modellierung laden. Rohe Events sind kein Analytics. Die Transformationen (dbt-Modelle etc.) sind das, was nützliche Warehouse-Tabellen erzeugt.

FAQ zu Data Warehouse

Was ist ein Data Warehouse?

Ein Data Warehouse ist ein zentraler, für Abfragen optimierter Speicher für alle strukturierten Daten eines Business. Gängige Warehouses sind BigQuery, Snowflake, Redshift und Databricks. Es ist das Fundament, aus dem BI Dashboards, Attributionsmodelle und KI-Agenten lesen.

Data Warehouse vs. Datenbank vs. Data Lake, was ist der Unterschied?

Datenbanken sind für hochfrequente Reads einzelner Zeilen optimiert (gut für Apps). Warehouses sind für analytische Abfragen optimiert (große Scans, Aggregationen). Data Lakes speichern rohe Dateien für Schema-on-Read. Lakehouses hybridisieren Lake-Storage mit warehouse-artiger Query-Semantik.

Welches Data Warehouse sollte ich wählen?

Für die meisten Marketing-Analytics-Stacks sind BigQuery (wenn deine Daten bei Google liegen) oder Snowflake (herstellerneutral) die dominierenden Optionen. Beide skalieren nahezu unendlich und haben reiche Ökosystem-Unterstützung für den Rest des modernen Data-Stacks.