Das On-Premise Data Lakehouse für eine souveräne Datenstrategie

Ein Data Lakehouse vereint die Flexibilität und kostengünstige Speicherung eines Data Lakes (einem grossen «Datensee» für Rohdaten) mit der Struktur, Zuverlässigkeit und Analysefähigkeit eines Data Warehouses (einem organisierten «Datenlager»). So verbindet es also das Beste aus beiden Welten.

Bei Überlegungen zur digitalen Souveränität kann ein Unternehmen zum Schluss kommen, dass Teile oder sogar die gesamte analytische Landschaft On-Premises betrieben werden sollen. Wird ein Lakehouse On-Premises betrieben, verwaltet das Unternehmen die gesamte Infrastruktur – von Servern und Speichersystemen bis hin zur Software – im eigenen oder gemieteten Rechenzentrum. 

Dies ermöglicht maximale Kontrolle über Daten und Technologie, bringt jedoch auch spezifische Herausforderungen mit sich. Diese beleuchten wir in diesem Beitrag.

Warum brauchen Unternehmen ein On-Premise Lakehouse?

Das Hauptziel eines Data Lakehouse ist es, eine einzige, zentrale Plattform für alle Unternehmensdaten zu schaffen. Diese kann in der Cloud, On-Premises oder als hybride Lösung betrieben werden. 

Entscheidet sich ein Unternehmen für ein On-Premises Lakehouse, sind in der Regel folgende Beweggründe ausschlaggebend:

Das Lakehouse schafft die Grundlage, um Geschäftswert aus sensitiven und geschäftskritischen Daten zu generieren. Es ermöglicht die Bereitstellung verlässlicher KPIs für das Management, unterstützt datenbasierte Entscheidungsfindung und bildet eine stabile Datengrundlage für AI-Use-Cases, auch dort, wo höchste Anforderungen an Datenschutz, Sicherheit und Qualität gelten.

Gleichzeitig behalten Unternehmen die volle Kontrolle über ihre Daten. Sämtliche sensiblen Informationen verbleiben unter eigener Hoheit, während strikte regulatorische und Compliance-Vorgaben zuverlässig eingehalten werden können.

Der konsequente Einsatz offener Standards und etablierter Open-Source-Technologien sorgt für Transparenz und reduziert die Abhängigkeit von einzelnen Anbietern. Dadurch bleiben sowohl Daten als auch analytische Lösungen langfristig nutzbar und können flexibel an neue fachliche, regulatorische oder technologische Anforderungen angepasst werden.

Dank standardisierter Datenformate und einer klar abstrahierten Plattformarchitektur ist das Lakehouse zudem portabel und zukunftssicher. Es unterstützt hybride und Cloud-basierte Betriebsmodelle, ohne dass bestehende Investitionen in Daten, Prozesse oder Know-how verloren gehen, und schafft damit eine nachhaltige Basis für die kontinuierliche Weiterentwicklung der Datenplattform.

Komponenten der Architektur eines Data Lakehouses

Die Architektur lässt sich in vier Hauptbereiche unterteilen, die den Weg der Daten von der Quelle bis zur Analyse und Nutzung abbilden.

Dateneingang: Wie kommen die Daten ins Lakehouse

Die Systems of Records, also die Quellsysteme, bilden die Ursprungsorte der Daten. Dazu zählen beispielsweise Kundendatenbanken, interne Geschäftsanwendungen oder auch externe Partner-Systeme.

Auf diese Quellsysteme aufbauend kommen die Systems of Integration, die Integrationssysteme, zum Einsatz. Sie sind dafür verantwortlich, die Daten sicher zu transportieren. Dabei kommen unterschiedliche Technologien zum Einsatz, wie Schnittstellen über APIs, Dateiübertragungen oder ETL-Prozesse (Extrahieren, Transformieren, Laden), die sicherstellen, dass die Rohdaten zuverlässig aus den Quellsystemen übertragen werden.

Analytics Platform: Das Herzstück der Datenverarbeitung im Lakehouse

Die Fundamente (Data Store)

• Basis: Der Data Store (Speicher), oft realisiert als S3 File Storage (kostengünstiger Objektspeicher).
• Dateiformate (Parquet, Delta, Iceberg): Daten werden nicht nur als lose Dateien gespeichert, sondern in speziellen Formaten wie Parquet und mit einer zusätzlichen intelligenten Schicht (z. B. Delta oder Iceberg). Diese bietet Funktionen, die man sonst nur aus Datenbanken kennt:
  • Reliability: Stellt sicher, dass Daten nur vollständig oder gar nicht gespeichert werden (ACID-Prinzip).
  • Struktur: Ermöglicht nachträglich eine klare Struktur (Schema) der Daten.
  • Time Travel (Historisierung): Ermöglicht den Zugriff auf ältere Versionen der Daten.

Die Daten-Fabrik (ETL Process)

• Container-Plattform: Häufig auf Kubernetes basierend, stellt sie die technische Umgebung für die Datenverarbeitungsprozesse bereit. 

Entwicklung: Prozesse werden typischerweise mit Programmiersprachen wie Python erstellt und orchestriert.
 

Kernkomponenten

• Orchestration (Airflow/NiFi): Der Dirigent des Datenflusses. Plant und steuert komplexe Verarbeitungsschritte, sodass alles in der richtigen Reihenfolge und zum richtigen Zeitpunkt abläuft.
• Processing Engine (Spark/Trino): Der Hochleistungsrechner für Datenbereinigung, Anreicherung und Umstrukturierung (ETL). Er verwandelt rohe, unstrukturierte Daten in wertvolle, analysefertige Informationen.

Platform Services: Die Hilfsmittel für einen reibungslosen Betrieb des Lakehouses

Ein zentrales Element der Plattform ist ein durchgängiges Secret Management, das Passwörter, Tokens und Zugangsschlüssel zuverlässig schützt und deren sichere Nutzung in automatisierten Prozessen ermöglicht, beispielsweise mit Lösungen wie HashiCorp Vault.

Ergänzt wird dies durch eine konsequente Prozessautomatisierung mittels CI/CD- und GitOps-Pipelines, die sicherstellt, dass neue Funktionen, Konfigurationsänderungen und Updates schnell, reproduzierbar und fehlerfrei in die Plattform integriert werden können. Werkzeuge wie Bitbucket oder GitHub bilden dabei die Grundlage für eine sichere und effiziente Bereitstellung.

Die Identitäts- und Zugriffsverwaltung (Identity and Access Management, IAM) regelt klar, wer zu welchem Zeitpunkt auf welche Daten, Services oder Plattformkomponenten zugreifen darf. Lösungen wie Microsoft Entra ID oder Okta stellen sicher, dass Zugriffsrechte zentral verwaltet, nachvollziehbar und compliance-konform umgesetzt werden.

Abgerundet wird die Plattform durch eine umfassende Überwachung und Protokollierung. Monitoring-, Alerting- und Log-Collection-Mechanismen überwachen kontinuierlich den Zustand, die Verfügbarkeit und die Performance der Plattform und ermöglichen ein frühzeitiges Erkennen sowie schnelles Reagieren auf Störungen, beispielsweise durch den Einsatz von Lösungen wie Splunk.

Systems of Engagement: Die Abrufung und Nutzung der Daten im Lakehouse

Der Data Sharing Endpoint bildet die zentrale Zugriffsschicht der Plattform. Über diese Schnittstelle erhalten Business-Teams, Entwicklerinnen und Entwickler sowie Analyse- und BI-Tools wie Power BI, Tableau oder Looker direkten Zugriff auf kuratierte, einsatzbereite Datenprodukte. 

An dieser Stelle entsteht der eigentliche Mehrwert der Datenarbeit, da Daten effizient genutzt, analysiert und in Entscheidungen oder neue Anwendungen überführt werden können.

Die Nutzer:innen der Plattform – darunter Entwickler:innen, Fachanwender:innen und interdisziplinäre Teams – greifen über den Data Sharing Endpoint auf die Daten zu, erstellen Reports und Dashboards oder entwickeln neue datengetriebene Anwendungen. Die Plattform stellt sicher, dass diese unterschiedlichen Nutzergruppen sicher, performant und bedarfsgerecht mit Daten versorgt werden.

Vergleich: On-Premises mit Open Source vs. Managed Service

Im On-Premises-Umfeld stellt sich die strategische Frage, ob die Plattform selbst mit Open-Source-Software (z. B. Apache Spark, Airflow, Iceberg) aufgebaut wird oder ein Managed Service eines Anbieters genutzt wird, der die Software im eigenen Rechenzentrum bereitstellt.

Hierzu ein paar Beispiele:

1. Beispiele für die Technologie:

On-Premise mit Open Source Produkten: 

• Apache Spark, Apache Airflow, Apache Iceberg/Delta Lake, Kubernetes (DIY-Ansatz)*

On-Premise mit einem Managed Service: 

• Cloudera Data Platform (CDP) Private Cloud: Eine integrierte Plattform mit konsistentem Governance-Layer (SDX).* Anbieter von Data Lakehouse-Lösungen, die ihre Produkte (z.B. Databricks-ähnliche Umgebungen, Openshift AI, etc.) als Managed Service für das Kundenrechenzentrum anbieten.

2. Kostenstruktur:

On-Premise mit Open Source Produkten: 

• Geringere Lizenzkosten, aber höhere Entwicklungskosten für Aufbau, Wartung und Betrieb durch Experten.

On-Premise mit einem Managed Service: 

• Höhere Lizenzgebühren oder Abo-Kosten, aber geringere interne Personalkosten für den Betrieb.

3. Kontrolle & Flexibilität:

On-Premise mit Open Source Produkten: 

• Maximale Kontrolle und Anpassbarkeit an spezifische interne Anforderungen. Kein Vendor Lock-in (Abhängigkeit von einem Anbieter).

On-Premise mit einem Managed Service: 

• Eingeschränkte Kontrolle und Anpassbarkeit, da der Anbieter die Architektur vorgibt. Hohes Risiko eines Vendor-Lock In, weil der Markt für on-premises Managed Lakehouse Lösungen immer kleiner wird (Abwanderung in die Cloud) und einen immer kleineren Standardisierungsgrad aufweist (wenig Investition in Weiterentwicklung).

4. Aufwand & Geschwindigkeit:

On-Premise mit Open Source Produkten: 

• Hoher initialer Aufwand und längere Implementierungszeit (Monate), da verschiedene Plattform Elemente aufgebaut werden müssen. Der Integrationsaufwand ist gleich gross.

On-Premise mit einem Managed Service: 

• Schnellerer Start möglich, da die Komponenten bereits aufeinander abgestimmt sind und als fertige Lösung bereitgestellt werden. Der Integrationsaufwand bleibt bestehen und ist gleich hoch.

5. Betrieb & Support:

On-Premise mit Open Source Produkten: 

• Volle Verantwortung für Betrieb, Updates, Sicherheit. Support erfolgt über die Community oder über eingekauften Profi-Support für Open Source.

On-Premise mit einem Managed Service: 

• Der Anbieter übernimmt die Wartung und bietet dedizierten Support für die gesamte Plattform. Die fachlichen Lösungen auf der Plattform müssen separat betrieben werden.

6. Strategische Empfehlung:

On-Premise mit Open Source Produkten: 

• Ideal für Unternehmen mit grossen, spezialisierten Tech-Teams, die die Fähigkeiten für einen spezialisierten Plattformaufbau haben. Ausserdem ist diese Lösung angezeigt, wenn hohe Anforderungen an Flexibilität, Compliance und Kontrolle bestehen.

On-Premise mit einem Managed Service: 

• Ideal für Unternehmen, die schnell starten möchten, ihre Techniker-Teams entlasten und sich auf die Datenanalyse konzentrieren wollen.

Herausforderungen von On-Premise Data Lakehouses

Der Betrieb eines On-Premise Data Lakehouse ist technisch anspruchsvoll und erfordert eine sorgfältige strategische Planung. Eine zentrale Herausforderung liegt im komplexen Lebenszyklus-Management: Sämtliche Software- und Hardware-Komponenten müssen kontinuierlich betrieben, aktualisiert und aufeinander abgestimmt werden. Dieser laufende Aufwand ist erheblich und wird häufig unterschätzt.

Hinzu kommt der hohe Bedarf an spezialisierter Expertise und Know-how. Für den stabilen und effizienten Betrieb ist ein erfahrenes Team notwendig, das alle Ebenen der Plattform beherrscht – von Hardware und Netzwerkinfrastruktur über Sicherheitsmechanismen bis hin zu Technologien für die Datenverarbeitung wie Spark oder Iceberg.

Auch Netzwerk und Sicherheit stellen kritische Faktoren dar. Eine schnelle, sichere und zuverlässige Kommunikation zwischen allen internen Komponenten ist essenziell, wird jedoch oft durch komplexe Netzwerkarchitekturen, Proxies und Firewalls erschwert, die zusätzliche Hürden für Anwendungen und Datenflüsse schaffen.

Darüber hinaus sind Hochverfügbarkeit und Notfallwiederherstellung mit hohem Aufwand verbunden. Der Aufbau redundanter Systeme für einen unterbrechungsfreien Betrieb (High Availability) sowie die Planung und Umsetzung von Disaster-Recovery-Szenarien sind technisch komplex und mit erheblichen Kosten verbunden.

Schliesslich stellt auch Skalierbarkeit und Performance eine Herausforderung dar. Wachsende Datenmengen oder steigende Nutzer:innenzahlen erfordern manuelle Erweiterungen von Rechenleistung und Speicher. Im Vergleich zu Cloud-Umgebungen ist eine flexible, automatische Skalierung nur eingeschränkt möglich, wodurch Kosten und Betriebsaufwand schnell ansteigen können.

Fazit zu On-Premises Data Lakehouses

Ein On-Premises Data Lakehouse kann in Szenarien mit hohen Anforderungen an Datenschutz, Compliance und technologische Souveränität eine sinnvolle und nachhaltige Lösung sein. Der zusätzliche Aufwand für Aufbau und Betrieb wird durch maximale Kontrolle über Daten, Architektur und Betriebsmodelle ausgeglichen.

Da moderne On-Premises- und Cloud-Lakehouse-Architekturen technisch stark ähneln, ermöglicht der Einsatz offener und portabler Standards eine zukunftssichere Ausrichtung. Investitionen in Datenmodelle, Pipelines und Know-how bleiben so auch bei einer späteren Hybrid- oder Cloud-Strategie erhalten.

ipt unterstützt Unternehmen ganzheitlich bei der Definition ihrer Datenstrategie. Von der Entscheidung zwischen On-Premises, Hybrid oder Public Cloud über die Architektur- und Technologieauswahl bis hin zum Aufbau und Betrieb der Lakehouse-Plattform sowie der darauf basierenden fachlichen Datenprodukte.