6 Ja, Sie können ein Data Lakehouse auf On-Premises-Objektspeicher betreiben – und immer mehr Banken, Behörden, Versorger, Hersteller und Forschungseinrichtungen tun genau das. Das Lakehouse-Muster verbindet den kostengünstigen, skalierbaren Speicher eines Data Lake mit den Zuverlässigkeits- und Leistungsmerkmalen eines Data Warehouse, indem offene Tabellenformate auf Objektspeicher aufsetzen. Da die Speicherschicht die S3-API spricht, kann dieselbe Architektur, die in Public Clouds läuft, auch in Ihrem eigenen Rechenzentrum laufen – auf Ihrer eigenen Hardware und unter Ihrer eigenen Kontrolle. Dieser Artikel erklärt, wie ein On-Premises-Data-Lakehouse aufgebaut ist, was es vom Objektspeicher verlangt, welche Rolle Query Engines und Kataloge spielen und wann On-Premises sinnvoller ist als die Cloud. Er richtet sich an Architekten von Datenplattformen. Hintergründe finden Sie in den Beiträgen Data Lake vs. Data Warehouse und Objektspeicher für Data Lakes (auf Englisch). Was ein Lakehouse ist Ein Data Lakehouse speichert Daten in offenen Dateiformaten, typischerweise Parquet, auf Objektspeicher und ergänzt eine Schicht mit einem Tabellenformat, die datenbankähnliche Funktionen bietet: ACID-Transaktionen, damit gleichzeitige Schreiber und Leser konsistente Daten sehen. Schema-Evolution, damit sich Tabellen ändern können, ohne alle Daten neu zu schreiben. Partitionierung und Pruning, damit Abfragen nur relevante Dateien lesen. Time Travel, damit Benutzer frühere Versionen einer Tabelle abfragen können. Snapshot-Verwaltung für konsistente Lesevorgänge und Rollback. Verteilte Query- und Processing-Engines lesen und schreiben diese Tabellen direkt auf dem Objektspeicher. Ein Katalog verfolgt die Tabellen und ihre aktuellen Metadaten. Die Schichten eines On-Premises-Lakehouse Speicher S3-kompatibler Objektspeicher hält Datendateien, Tabellenmetadaten und Manifests. Er muss auf Petabytes skalieren, hohen Durchsatz halten und große Objektzahlen bewältigen. Er ist das Fundament; jede andere Schicht hängt davon ab. Tabellenformat Offene Tabellenformate legen fest, wie Tabellen auf dem Speicher abgebildet werden. Die führenden Formate werden von vielen Engines unterstützt und funktionieren gut auf S3-kompatiblem Speicher. Katalog Ein Katalog ordnet Tabellennamen dem aktuellen Speicherort ihrer Metadaten zu und koordiniert Commits. Zu den Optionen gehören aus älteren Datenplattformen übernommene Metastore-Dienste, REST-basierte Katalogdienste und datenbankgestützte Kataloge. Der Katalog muss hochverfügbar sein, da jede Abfrage von ihm abhängt. Query- und Processing-Engines Verteilte SQL-Engines bedienen interaktive Analysen und BI. Verteilte Processing-Frameworks übernehmen umfangreiche Verarbeitung und Data Engineering. Weitere Engines bedienen Streaming, maschinelles Lernen und spezielle Workloads. Da die Daten in offenen Formaten vorliegen, können mehrere Engines dieselben Tabellen nutzen. Governance und Sicherheit Zugriffskontrolle, Auditing, Data Lineage und Verschlüsselung ziehen sich durch alle Schichten. In regulierten Umgebungen sind sie ebenso wichtig wie die Leistung. Was das Lakehouse vom Objektspeicher braucht S3-API-Kompatibilität Engines und Tabellenformate nutzen S3-Operationen intensiv: GET mit Byte-Ranges, PUT und Multipart-Uploads, LIST, HEAD und DELETE. Der Speicher muss diese korrekt und konsistent implementieren. Starke Read-after-Write-Konsistenz ist für Tabellen-Commits und Metadatenoperationen wichtig. Hoher aggregierter Durchsatz Analytische Abfragen scannen große Datenmengen parallel. Der Speicher muss über viele gleichzeitige Verbindungen hohen aggregierten Lesedurchsatz liefern und mit zusätzlichen Knoten skalieren. Leistung bei kleinen Objekten und Metadaten Tabellenmetadaten, Manifests und kleine Datendateien erzeugen viele kleine Anfragen. Der Speicher muss hohe Anfrageraten mit niedriger Latenz bewältigen, nicht nur große sequenzielle Lesevorgänge. Skalierung Lakehouses wachsen schnell, wenn neue Quellen hinzukommen und die Historie aufbewahrt wird. Der Speicher muss ohne disruptive Upgrades auf viele Petabytes und Milliarden von Objekten skalieren. Datenschutz und Resilienz Erasure Coding schützt Daten innerhalb eines Standorts, und Replikation oder Designs über mehrere Standorte schützen vor dem Ausfall eines Standorts. Versionierung und Object Lock können kritische Daten vor versehentlichem oder böswilligem Löschen schützen. Sicherheit Verschlüsselung im Ruhezustand und bei der Übertragung, feingranulare Zugriffsrichtlinien, Integration mit Identitätssystemen und Audit-Logging. S3-Zugriffsrichtlinien behandelt das Design von Richtlinien. Warum ein Lakehouse On-Premises betreiben Datensouveränität und Regulierung Viele Organisationen müssen Daten im eigenen Land oder in eigenen Einrichtungen halten. In Europa unterliegen Finanzinstitute DORA und nationalen Aufsichtserwartungen; öffentliche Stellen und Betreiber kritischer Infrastrukturen unterliegen NIS2 und nationalen Sicherheitsregeln. Behörden und Verteidigungseinrichtungen in den USA, im Vereinigten Königreich, in Frankreich, Deutschland, Japan und andernorts verlangen oft, dass Daten in akkreditierten Einrichtungen bleiben. Ein On-Premises-Lakehouse hält die Daten unter direkter Kontrolle. Planbare Kosten Analytische Workloads lesen Daten intensiv. In Public Clouds wachsen die Gebühren für Speicher, Anfragen und Datentransfer mit der Nutzung. On-Premises sind die Kosten weitgehend fest und planbar, was zu gleichmäßigen, schweren Workloads passt. Nähe zu Datenquellen und Rechenleistung Daten, die On-Premises entstehen – von Handelssystemen, Sensoren, Fertigungslinien oder wissenschaftlichen Geräten –, lassen sich dort analysieren, wo sie anfallen, ohne sie in die Cloud zu verschieben. On-Premises-GPU- und CPU-Cluster können direkt aus lokalem Objektspeicher lesen. Lock-in vermeiden Offene Tabellenformate auf S3-kompatiblem Speicher halten Daten zwischen Engines sowie zwischen On-Premises und Cloud portabel. Wann die Cloud besser passen kann Lakehouses in der Cloud können für Organisationen mit stark schwankenden Workloads, kleinen Teams, Cloud-nativen Datenquellen oder ohne eigene Infrastruktur sinnvoll sein. Viele Organisationen landen bei einem hybriden Modell: sensible oder schwere Workloads On-Premises, andere in der Cloud, verbunden über offene Formate. Migration von Hadoop Viele On-Premises-Datenplattformen begannen mit Hadoop und HDFS. Der Wechsel zu einem Lakehouse auf Objektspeicher trennt Rechenleistung und Speicher, verringert die betriebliche Komplexität und ermöglicht moderne Engines. KI und maschinelles Lernen auf dem Lakehouse Lakehouses versorgen neben BI zunehmend auch KI und maschinelles Lernen. Feature Engineering, Modelltraining und Retrieval-Pipelines lesen große Datenmengen aus denselben Tabellen, die Analysten abfragen. Diese Workloads auf einer einzigen kontrollierten Kopie der Daten zu halten, statt Auszüge in separate Systeme zu exportieren, verringert Duplikate und hält die Lineage klar. Es erhöht allerdings die Anforderungen an den Speicherdurchsatz, da Trainingsjobs Daten in großen parallelen Schüben lesen. Wer die Objektspeicher-Schicht von Anfang an für analytische und KI-Zugriffsmuster plant, vermeidet später eine zweite, getrennte Datenplattform. Ein typisches On-Premises-Referenzdesign Ein gängiges On-Premises-Design sieht so aus: ein S3-kompatibler Objektspeicher-Cluster über mehrere Racks oder zur Resilienz über zwei Standorte; ein hochverfügbarer Katalogdienst auf einer replizierten Datenbank; eine verteilte SQL-Engine für interaktive Abfragen und BI-Tools; ein Processing-Cluster, oft containerbasiert, für Data Engineering; Streaming-Ingestion, die in Tabellen eines offenen Tabellenformats schreibt; und eine Governance-Schicht, die Zugriffsrichtlinien durchsetzt und die Lineage erfasst. Die Rechencluster skalieren unabhängig vom Speicher: Mehr Analysten erfordern keine zusätzliche Kapazität, und zusätzliche Jahre an Historie erfordern keine zusätzliche Rechenleistung. Ein On-Premises-Lakehouse dimensionieren Kapazität: aktuelle Daten, Wachstumsrate, Aufbewahrung und Tabellenhistorie aus Snapshots, zuzüglich Schutz-Overhead. Durchsatz: Spitzenlast aus gleichzeitigen Abfragen und Verarbeitung, gemessen in aggregierten GB pro Sekunde. Anfrageraten: Aktivität bei Metadaten und kleinen Dateien, besonders bei häufig aktualisierten Tabellen. Netzwerk: Bandbreite zwischen Rechenclustern und Speicher; analytische Engines können Verbindungen auslasten. Wachstum: Erweiterungen in kleinen Schritten planen. Das Lakehouse betreiben Lakehouses brauchen regelmäßige Wartung auf Ebene des Tabellenformats: kleine Dateien zusammenfassen, alte Snapshots ablaufen lassen und verwaiste Dateien entfernen. Diese Aufgaben halten die Abfrageleistung hoch und den Speicherverbrauch im Rahmen. Überwachen Sie Durchsatz, Latenz und Kapazität des Speichers zusammen mit der Engine-Leistung, denn langsamer Speicher zeigt sich als langsame Abfragen. Checkliste: On-Premises-Data-Lakehouse Ein offenes Tabellenformat mit breiter Engine-Unterstützung wählen. S3-kompatiblen Objektspeicher mit starker Konsistenz und hohem Durchsatz auswählen. Einen hochverfügbaren Katalog bereitstellen. Speicher nach Kapazität, Durchsatz, Anfrageraten und Wachstum dimensionieren. Netzwerk mit hoher Bandbreite zwischen Rechen- und Speicherebene bereitstellen. Zugriffskontrolle, Verschlüsselung und Audit-Logging umsetzen. Tabellenwartung planen: Compaction und Ablauf von Snapshots. Schutz über mehrere Standorte für kritische Daten auslegen. Die Migration von Altplattformen wie HDFS planen. Zusammenfassung Ein On-Premises-Data-Lakehouse ist nicht nur möglich, sondern zunehmend verbreitet. Offene Tabellenformate, ein zuverlässiger Katalog und moderne Query Engines laufen auf S3-kompatiblem Objektspeicher in Ihrem eigenen Rechenzentrum – mit Cloud-artiger Architektur, On-Premises-Kontrolle, planbaren Kosten und Daten, die dort bleiben, wo die Regulierung es verlangt. Die Speicherschicht muss S3-Kompatibilität, starke Konsistenz, hohen Durchsatz und Skalierbarkeit liefern; stimmt das, kann sich der restliche Stack darauf frei weiterentwickeln. Häufig gestellte Fragen Kann ein Data Lakehouse On-Premises laufen? Ja. Offene Tabellenformate und Query Engines laufen auf S3-kompatiblem Objektspeicher in Ihrem eigenen Rechenzentrum genauso wie in Public Clouds. Welches Tabellenformat eignet sich On-Premises am besten? Wählen Sie ein Format, das von den Engines Ihrer Teams breit unterstützt wird. Aus Sicht des Speichers haben die führenden Formate nahezu identische Anforderungen. Was braucht Objektspeicher für ein Lakehouse? S3-API-Kompatibilität, starke Read-after-Write-Konsistenz, hohen aggregierten Durchsatz, gute Leistung bei kleinen Objekten und Skalierbarkeit. Warum für ein Lakehouse On-Premises statt Cloud wählen? Wegen Datensouveränität, regulatorischer Anforderungen, planbarer Kosten bei schweren Workloads, Nähe zu den Datenquellen und Portabilität. Brauche ich für einen On-Premises-Data-Lake noch Hadoop? Nein. Viele Organisationen wechseln von HDFS auf Objektspeicher mit modernen Engines und trennen so Rechenleistung und Speicher. Weiterführende Lektüre Offene Tabellenformate auf On-Premises-S3 Leistung von SQL-Query-Engines auf Objektspeicher Migration von HDFS auf Objektspeicher Souveräne Data Lakes Objektspeicher für Data Lakes (auf Englisch)
