Was ist ein Data Lake – und wann braucht Ihr Unternehmen einen?

Sensordaten aus der Produktion, PDF-Rechnungen aus dem ERP, Bilder aus der Qualitätskontrolle, Log-Dateien aus IoT-Geräten – moderne Unternehmen produzieren Daten in Formaten, die ein klassisches Data Warehouse nicht speichern kann. Genau hier kommt der Data Lake ins Spiel: ein zentraler Speicherort, der alle Daten im Rohformat aufnimmt – strukturiert, semi-strukturiert und unstrukturiert.

Doch ein Data Lake ist kein Selbstzweck. Ohne klare Struktur wird er schnell zum «Data Swamp» – einem Datensumpf, in dem niemand mehr findet, was er sucht. Dieser Artikel erklärt, was ein Data Lake ist, wie er sich vom Data Warehouse und Lakehouse unterscheidet, und wann welche Architektur die richtige Wahl ist.

Data Lake – Definition und Kernprinzip

Ein Data Lake ist ein zentrales Speichersystem, das grosse Mengen an Rohdaten in ihrem ursprünglichen Format aufbewahrt. Im Gegensatz zum Data Warehouse, das Daten beim Laden transformiert und in ein festes Schema presst (Schema-on-Write), wendet der Data Lake das Schema erst beim Lesen an (Schema-on-Read).

Das bedeutet konkret: Daten werden zunächst «as-is» gespeichert – ohne vordefinierte Tabellenstruktur. Erst wenn jemand die Daten abfragt oder analysiert, wird entschieden, wie sie interpretiert werden. Dieser Ansatz bietet maximale Flexibilität, stellt aber hohe Anforderungen an Data Governance und Katalogisierung.

Die drei Datentypen im Data Lake:

Strukturierte Daten – Tabellen aus ERP, CRM, Buchhaltung. Zeilen und Spalten mit festem Schema. Könnten auch in ein Data Warehouse.

Semi-strukturierte Daten – JSON-Dateien, XML, Log-Files, API-Responses. Haben eine innere Struktur, passen aber nicht in klassische Tabellen.

Unstrukturierte Daten – Bilder, Videos, PDFs, E-Mails, Audiodateien, Sensordaten. Machen den grössten Teil der Unternehmensdaten aus und können nur in einem Data Lake oder Lakehouse sinnvoll gespeichert werden.

Data Lake vs. Data Warehouse vs. Lakehouse

Die Frage «Data Lake oder Data Warehouse?» ist in der Praxis meist falsch gestellt. Moderne Datenarchitekturen kombinieren Elemente beider Ansätze – oft in Form eines Lakehouse. Trotzdem ist es wichtig, die Unterschiede zu kennen.

→ Vergleichstabelle: Data Lake vs. Data Warehouse vs. Lakehouse (siehe HTML-Tabelle unten)

Wann reicht ein Data Warehouse?

Wenn Ihr Unternehmen primär strukturierte Daten aus ERP, CRM und Finanzsystemen analysiert und verlässliche Reports und Dashboards braucht, ist ein klassisches Data Warehouse oft die einfachste und kosteneffektivste Lösung. Typisch für KMU mit überschaubarer Datenlandschaft.

Wann brauchen Sie einen Data Lake?

Sobald Sie mit unstrukturierten Daten arbeiten – etwa Sensorströmen aus der Produktion, Bilddaten für Computer Vision oder Textdaten für NLP und Generative AI – kommen Sie um einen Data Lake nicht herum. Auch für Data-Science-Projekte, bei denen explorative Analysen auf Rohdaten nötig sind, ist ein Data Lake die richtige Grundlage.

Wann ist ein Lakehouse die Antwort?

Wenn Sie beides brauchen: verlässliches Reporting auf strukturierten Daten und gleichzeitig die Flexibilität für Machine Learning, RAG-Systeme oder Generative AI. Plattformen wie Microsoft Fabric oder Databricks implementieren genau dieses Lakehouse-Konzept: ein Data Lake als Speicherschicht, darüber eine Governance- und Query-Schicht, die Warehouse-Performance liefert.

Aufbau eines Data Lake: Die Schichten-Architektur

In der Praxis organisiert man einen Data Lake in Schichten (Layers), die den Reifegrad der Daten widerspiegeln. Diese Architektur wird oft als Bronze – Silber – Gold bezeichnet und ist auch die Grundlage moderner Lakehouse-Plattformen.

Bronze-Schicht (Raw / Landing Zone)

Hier landen alle Rohdaten aus den Quellsystemen – exakt so, wie sie geliefert werden. Keine Transformation, keine Bereinigung. Zweck: vollständige, unveränderliche Kopie der Originaldaten als «Single Source of Truth». Data Pipelines laden die Daten automatisiert in diese Schicht.

Silber-Schicht (Cleaned / Curated)

In der Silber-Schicht werden die Rohdaten bereinigt, dedupliziert, standardisiert und angereichert. Hier entsteht die bereinigte, vertrauenswürdige Datenbasis, auf der sowohl BI-Reports als auch Data-Science-Projekte aufbauen. Transformationen mit dbt sind in dieser Schicht besonders wertvoll.

Gold-Schicht (Business-Ready)

Die Gold-Schicht enthält aggregierte, geschäftsfertige Datensätze: KPI-Tabellen, Feature Stores für Machine Learning, dimensionale Modelle für Business Intelligence. Endnutzer und Dashboards greifen ausschliesslich auf die Gold-Schicht zu.

Diese Schichten-Architektur verhindert das grösste Risiko eines Data Lake: den Data Swamp.

Der Data Swamp – wenn der Data Lake zum Problem wird

Ein Data Lake ohne Governance wird zum Data Swamp. Die Symptome sind immer gleich:

Niemand weiss, welche Daten vorhanden sind. Ohne Datenkatalog und Metadaten wird der Lake zur Blackbox. Teams laden Daten, aber niemand dokumentiert Herkunft, Bedeutung oder Aktualität.

Datenqualität ist unkontrolliert. Duplikate, veraltete Exporte, fehlerhafte Formate – alles landet im Lake, und niemand räumt auf. Ohne Qualitätsregeln in der Silber-Schicht wird jede Analyse unzuverlässig.

Zugriffsrechte fehlen. Wer darf welche Daten sehen? Ohne Data Governance entstehen Compliance-Risiken, besonders bei personenbezogenen Daten in der Verwaltung oder im Gesundheitswesen.

Kosten explodieren. Ein Data Lake auf Cloud-Speicher (Azure Data Lake Storage, AWS S3) ist günstig – aber nur, wenn Daten mit Lifecycle-Policies verwaltet werden. Ohne Archivierungsstrategie wachsen die Speicherkosten unkontrolliert.

Gegenmassnahmen: Datenlandkarte erstellen, Datenkatalog einführen, Bronze-Silber-Gold-Architektur implementieren, Data-Ownership definieren, Lifecycle-Policies automatisieren.

Praxisbeispiele: Data Lake in Industrie, ÖV und Verwaltung

Industrie – Sensordaten zentral speichern und auswerten

Ein Maschinenbauer erfasst pro Anlage Hunderte von Sensorwerten pro Sekunde: Temperatur, Vibration, Drehzahl, Stromverbrauch. Diese Zeitreihendaten sind semi-strukturiert und volumenmässig zu gross für ein klassisches Data Warehouse. Im Data Lake werden sie im Rohformat gespeichert (Bronze), in der Silber-Schicht normalisiert und in der Gold-Schicht als Features für Predictive Maintenance bereitgestellt.

Substring begleitet Industrieunternehmen beim Aufbau solcher Architekturen – von der Sensoranbindung über Data Pipelines bis zur Datenplattform auf Microsoft Fabric.

Öffentlicher Verkehr – heterogene Datenquellen vereinen

Verkehrsbetriebe arbeiten mit Daten aus völlig unterschiedlichen Systemen: Fahrzeitenmessung, Passagierzählung, Wetterdaten, akustische Sensoren für die Schienenkopfkonditionierung. Ein Data Lake nimmt alle diese Formate auf und macht sie für übergreifende Analysen zugänglich – etwa für die Akustikerkennung bei BERNMOBIL oder die Plattformstrategie beim BVB.

Verwaltung – Dokumenten- und Prozessdaten zusammenführen

Verwaltungen verarbeiten grosse Mengen unstrukturierter Daten: eingescannte Anträge, E-Mail-Korrespondenz, Protokolle, Berichte. Ein Data Lake speichert diese Dokumente zentral und macht sie über die Silber-Schicht für automatisierte Textanalyse und Klassifikation zugänglich. Voraussetzung: eine klare Data-Governance-Strategie, die regelt, welche Daten wie lange gespeichert und wer darauf zugreifen darf.

Technologien: Data-Lake-Plattformen im Überblick

Azure Data Lake Storage Gen2 (ADLS) – Microsofts Lösung, integriert in Microsoft Fabric. Basiert auf Azure Blob Storage mit hierarchischem Namespace. Substrings bevorzugte Plattform für Kunden im Microsoft-Ökosystem.

Amazon S3 – AWS-Standard für Data Lakes. Kombiniert mit AWS Glue (Katalog) und Athena (Abfrage). Verbreitet bei Unternehmen mit AWS-Fokus.

Google Cloud Storage – Googles Pendant, oft kombiniert mit BigQuery als Lakehouse-Schicht.

Databricks (Delta Lake) – Open-Source-Lakehouse-Format auf Basis von Apache Spark. Bringt ACID-Transaktionen, Versionierung und Schema-Enforcement in den Data Lake. Beliebt bei Unternehmen mit starkem Data-Science-Fokus.

Snowflake – Ursprünglich Data Warehouse, bietet heute ebenfalls Lakehouse-Funktionen mit Iceberg-Tabellen und externen Stages.

Die Technologiewahl hängt vom bestehenden Ökosystem, den Anforderungen an Data Governance und dem Skill-Set des Teams ab. Substring berät bei der Auswahl im Rahmen einer Datenstrategie.

Data Lake vs. Data Warehouse vs. Lakehouse – Vergleichstabelle

So starten Sie richtig

1. Bestandsaufnahme. Erstellen Sie eine Datenlandkarte: Welche Datenquellen gibt es? Welche Formate? Welche Volumina?
2. Architektur-Entscheid. Brauchen Sie einen reinen Data Lake, ein Data Warehouse oder ein Lakehouse? Die Antwort hängt von Ihren Use Cases ab – nicht von Technologie-Trends. Substring hilft bei dieser Entscheidung im Rahmen einer Datenstrategie.
3. Bronze-Silber-Gold aufsetzen. Starten Sie mit einer klaren Schichten-Architektur, auch wenn Sie zunächst nur wenige Quellen anbinden. Data Pipelines und dbt-Transformationen automatisieren den Datenfluss.
4. Governance von Anfang an. Datenkatalog einführen, Zugriffsrechte definieren, Datenqualitätsregeln implementieren. Sonst wird der Lake zum Swamp.
5. Ersten Use Case umsetzen. Ein konkretes Projekt – etwa ein BI-Dashboard oder ein Data-Science-Modell – das den Wert des Data Lake beweist und das Team motiviert.

Wie Substring Sie unterstützt

Substring baut Datenplattformen, die Data Lake, Data Warehouse und Lakehouse-Konzepte pragmatisch kombinieren – zugeschnitten auf die Bedürfnisse von Industrieunternehmen, Verkehrsbetrieben und Verwaltungen.

• Beratung und Strategie: Datenlandkarte, Datenstrategie, Architektur-Entscheid
• Datenplattform: Microsoft Fabric, Snowflake, Azure – Bronze-Silber-Gold-Architektur
• Data Engineering: Pipelines, dbt-Transformationen, Datenkatalog
• Künstliche Intelligenz: ML auf dem Data Lake, Generative AI, RAG

→ Kontakt aufnehmen – wir zeigen Ihnen, welche Architektur zu Ihrer Datenlage passt.

Weiterführende Glossar-Artikel

• Data Warehouse oder Lakehouse? – die richtige Plattformwahl
• Was ist eine Data Pipeline? – der automatisierte Datenfluss
• Was ist ein Data Catalogue? – Metadaten managen
• dbt und Microsoft Fabric – Transformationen automatisieren
• Data Governance – Spielregeln für den Umgang mit Daten
• Datenlandkarte erstellen – Überblick über das Datenökosystem
• Was ist Data Science? – Daten als Wettbewerbsvorteil
• Was ist MLOps? – Modelle in Produktion bringen

‍