Data Warehouse & Lakehouse

Warum Daten in Warehouse/Lakehouse zentralisieren¶

Ein typisches Unternehmen hat Daten verstreut ueber Dutzende Systeme — ERP, CRM, E-Commerce, HR-System, Excel-Dateien, Google Sheets, Drittanbieter-APIs. Jedes System hat sein eigenes Format, eigene Definitionen und eigene Historie. Das Ergebnis:

• Management bekommt keine Antworten auf einfache Fragen — „Wie hoch war der Umsatz diesen Monat?” erfordert 3 Tage Analysten-Arbeit
• Zahlen stimmen nicht ueberein — Vertrieb berichtet anders als Finanzen, niemand weiss was stimmt
• Historische Daten fehlen — Quellsysteme loeschen oder ueberschreiben, kein Audit Trail
• KI/ML hat keine Daten — Modelle brauchen konsolidierte, saubere Daten an einem Ort

Warehouse vs. Lakehouse vs. Lake¶

Data Warehouse (Snowflake, BigQuery, Redshift)¶

Fuer wen: Unternehmen mit strukturierten Daten, primaerer Bedarf ist BI und Reporting.

• Schema vorab definiert (Schema-on-Write)
• Optimiert fuer SQL-Abfragen und Aggregationen
• ACID-Transaktionen, Time Travel, Zero-Copy Cloning
• Managed Service — keine Infrastruktur zu warten
• Hoechste Leistung fuer analytische Abfragen

Data Lakehouse (Databricks, Delta Lake, Apache Iceberg)¶

Fuer wen: Unternehmen mit Mix aus strukturierten und unstrukturierten Daten, ML/KI-Workloads.

• Offene Formate (Delta, Iceberg, Hudi) — kein Vendor Lock-in
• Schema-on-Read und Schema-on-Write
• Unified Processing — SQL, Python, Spark, ML in einer Umgebung
• Kosteneffektiver Speicher (Object Storage = S3/ADLS)
• ACID-Transaktionen ueber Data Lake dank Delta/Iceberg

Data Lake (S3/ADLS raw)¶

Fuer wen: Landing Zone fuer Rohdaten, Archivierung, spezifische ML-Pipelines.

• Guenstigster Speicher
• Keine Struktur — alles ablegen
• Ohne Delta/Iceberg = kein ACID, kein Time Travel
• Typischerweise Bronze-Schicht in der Medallion-Architektur

Wie wir Technologie auswaehlen¶

Wir verkaufen keine einzelne Technologie. Wir waehlen basierend auf Ihren Anforderungen:

Snowflake wenn: primaerer Use Case ist BI/Reporting, Team kennt SQL, Sie brauchen Multi-Cloud, Data Sharing zwischen Organisationen, Trennung von Compute und Storage ist entscheidend.

Databricks wenn: Sie ML/KI-Workloads neben Analytics brauchen, grosse Volumen unstrukturierter Daten haben, Team kennt Python/Spark, Sie Open-Source-Formate wollen (Delta Lake).

BigQuery wenn: Sie auf Google Cloud sind, Serverless wollen (kein Cluster-Management), Pay-per-Query-Modell fuer Ihre Abfragemuster Sinn macht, GIS/ML-Integration benoetigen.

PostgreSQL + dbt wenn: Datenvolumen < 100 GB, Budget begrenzt, Team kennt PostgreSQL, Compute muss nicht unabhaengig von Storage skaliert werden.

Implementierungsansatz¶

1. Discovery und Datenmodellierung (2-3 Wochen)¶

• Inventarisierung von Quellen und Datenentitaeten
• Dimensional Modeling (Kimball) oder Data Vault 2.0
• Source of Truth-Definition fuer Schluesselentitaeten
• Namenskonventionen, Datentypen, Standards

2. Infrastruktur und Ingestion (2-3 Wochen)¶

• Provisioning Warehouse/Lakehouse (IaC — Terraform)
• Ingestion-Pipeline fuer Schluesselquellen
• Bronze Layer — Rohdaten, unveraenderlich, partitioniert
• Monitoring und Alerting ab dem ersten Tag

3. Transformation und Business Layer (3-4 Wochen)¶

• dbt-Projekt-Setup mit CI/CD
• Silver Layer — Bereinigung, Validierung, Harmonisierung
• Gold Layer — Business-ready Views, KPIs, Metriken
• Semantic Layer fuer konsistente Definitionen

4. Optimierung und Hardening (fortlaufend)¶

• Query-Performance-Tuning (Clustering, Materialized Views)
• Kostenoptimierung (Warehouse-Sizing, Auto-Suspend, Resource Monitors)
• Partitionierungs- und Pruning-Strategien
• Backup, DR, Aufbewahrungsrichtlinien

Kostenoptimierung¶

Cloud Warehouse ohne Governance erzeugt schnell unerwartete Kosten. Wir implementieren:

• Resource Monitors — Automatisches Herunterfahren bei Erreichen des Budgetlimits
• Auto-Suspend/Resume — Warehouse laeuft nicht, wenn niemand es nutzt
• Query Profiling — Identifikation teurer Abfragen, Optimierung
• Storage Tiering — Hot/Warm/Cold-Daten auf verschiedenen Speicherebenen
• Reservation vs. On-Demand — Fuer vorhersehbare Workloads spart reservierte Kapazitaet 30-60%

Verwandt mit