6 Offene Tabellenformate auf On-Premises-S3-Speicher sind heute eine gängige Grundlage für Data Lakehouses, die in den eigenen Rechenzentren der Organisation bleiben. Ein offenes Tabellenformat ergänzt Sammlungen von Dateien im Objektspeicher um datenbankähnliche Funktionen: Schemata, Transaktionen, Snapshots und effiziente Abfrageplanung. Die führenden Formate sind Open Source und so ausgelegt, dass sie mit jedem Speicher arbeiten, der die S3-API bereitstellt – sie sind also nicht an eine Public Cloud gebunden. Die kurze Antwort auf die Frage, ob offene Tabellenformate auf S3-kompatiblem On-Premises-Speicher funktionieren, lautet Ja – sofern der Speicher einige Anforderungen erfüllt. Dieser Artikel erklärt, wie Tabellenformate Objektspeicher nutzen, was der Speicher unterstützen muss, welche Rolle Kataloge spielen, welche Wartungsaufgaben wichtig sind und wie eine Bereitstellung getestet wird. Die übergreifende Architektur beschreibt unsere Übersicht zum Betrieb eines Data Lakehouse auf On-Premises-Objektspeicher. Was ein offenes Tabellenformat leistet Rohdateien im Objektspeicher, etwa Parquet oder ORC, kennen kein Konzept einer Tabelle. Frühe Data Lakes definierten Tabellen über Verzeichnisstrukturen und Dateilisten, was Änderungen riskant und Abfragen im großen Maßstab langsam machte. Offene Tabellenformate lösen das mit einer Metadatenschicht: Tabellenmetadaten halten Schema, Partitionierung und aktuellen Snapshot fest. Manifests listen die Datendateien jedes Snapshots auf, mit Statistiken wie Zeilenzahlen sowie Minimal- und Maximalwerten der Spalten. Snapshots halten den Zustand der Tabelle bei jedem Commit fest und ermöglichen Time Travel und Rollback. Atomare Commits stellen sicher, dass Leser entweder die alte oder die neue Tabelle sehen, nie einen halben Schreibvorgang. Query Engines nutzen diese Metadaten, um Abfragen ohne Verzeichnislisten zu planen und Dateien zu überspringen, die einem Filter nicht entsprechen können. Wie Tabellenformate Objektspeicher nutzen Alle Daten und Metadaten liegen als Objekte vor. Ein typischer Schreibvorgang: Schreibt neue Datendateien in den Objektspeicher. Schreibt neue Manifest-Dateien, die sie beschreiben. Schreibt eine neue Metadatendatei der Tabelle, die auf den neuen Snapshot verweist. Aktualisiert den Katalog atomar, sodass die Tabelle auf die neue Metadatendatei zeigt. Lesevorgänge folgen dem Verweis vom Katalog zur Metadatendatei, dann zu den Manifests und dann zu den benötigten Datendateien. Da der Austausch im Katalog der Commit-Punkt ist, muss der Objektspeicher selbst keine Transaktionen unterstützen. Er muss Objekte zuverlässig und konsistent speichern und bereitstellen. Was On-Premises-S3-Speicher unterstützen muss Starke Read-after-Write-Konsistenz Wenn ein Writer einen Snapshot committet, müssen Leser die neuen Metadaten- und Datendateien sofort sehen können. Speicher mit Eventual Consistency kann dazu führen, dass Leser Dateien übersehen oder Abfragen fehlschlagen. Vergewissern Sie sich, dass der Speicher starke Konsistenz für neue Objekte, Überschreibungen und Listen bietet. Abdeckung der zentralen S3-API Tabellenformate und Engines stützen sich auf Standardoperationen: PUT, GET mit Byte-Ranges, HEAD, DELETE, Löschen mehrerer Objekte, Multipart-Upload und Listen. Range-GETs sind besonders wichtig, weil spaltenorientierte Leser bestimmte Spalten-Chunks abrufen. Testen Sie auch die Fehlerbehandlung, da Clients anhand bestimmter Fehlercodes wiederholen. Leistung bei kleinen und großen Objekten Metadaten- und Manifest-Dateien sind klein und werden oft gelesen; Datendateien sind größer und werden in parallelen Range-Anfragen gelesen. Der Speicher sollte hohe Anfrageraten mit niedriger Latenz ebenso bewältigen wie hohen aggregierten Durchsatz. Skalierung bei der Objektzahl Große Tabellen sammeln mit der Zeit Millionen von Datendateien und viele Metadatendateien an. Der Speicher muss große Objektzahlen pro Bucket bewältigen, ohne dass Listen oder Abfragen langsamer werden. Sicherheit und Zugriffskontrolle Buckets für Analytik enthalten oft sensible Daten. Achten Sie auf feingranulare Bucket-Richtlinien, Identitätsintegration, Verschlüsselung im Ruhezustand und bei der Übertragung sowie Audit-Logging. Die Rolle des Katalogs Jedes offene Tabellenformat braucht einen Katalog, der für jede Tabelle den aktuellen Speicherort der Metadaten verfolgt und beim Commit den atomaren Austausch durchführt. Zu den Optionen gehören REST-basierte Katalogdienste, aus älteren Data-Lake-Plattformen übernommene Metastore-Dienste und datenbankgestützte Kataloge. On-Premises läuft der Katalog als Dienst neben den Query Engines, typischerweise auf einer Datenbank, die selbst hochverfügbar und gesichert sein muss. Der Katalog ist klein, aber kritisch: Geht er verloren, lassen sich Tabellen nicht mehr finden, obwohl alle Daten im Objektspeicher intakt sind. Wartungsaufgaben mit Auswirkung auf den Speicher Offene Tabellenformate erzeugen mit der Zeit Dateien. Regelmäßige Wartung hält Leistung und Kapazität im Rahmen: Compaction führt kleine Datendateien zu größeren zusammen, verringert die Zahl der Anfragen und beschleunigt Scans. Ablauf von Snapshots entfernt alte Snapshots jenseits der für Time Travel und Audit benötigten Aufbewahrung. Bereinigung verwaister Dateien löscht Dateien, auf die kein Snapshot mehr verweist, etwa Überreste fehlgeschlagener Schreibvorgänge. Neuschreiben von Manifests konsolidiert Metadaten für eine schnellere Planung. Die Aufbewahrung für Time Travel sollte bewusst festgelegt werden. Jeden Snapshot für immer zu behalten verbraucht Kapazität; zu aggressives Ablaufen nimmt die Möglichkeit, zu prüfen oder zurückzusetzen. Die Versionierung von Buckets im Objektspeicher bietet eine weitere Schutzebene, erhöht aber auch den Kapazitätsbedarf. Häufige Probleme On-Premises und wie man sie vermeidet Path-Style- vs. Virtual-Hosted-Style-Adressierung: Konfigurieren Sie die Clients passend zum Speicherendpunkt, bei On-Premises-Endpunkten oft mit Path-Style-Zugriff. TLS und Zertifikate: Interne Zertifizierungsstellen müssen von jeder Engine und jedem Katalog-Client als vertrauenswürdig eingestuft werden. Endpunkt- und Regionseinstellungen: Clients erwarten oft auch On-Premises einen Regionswert; legen Sie ihn einheitlich fest. Timeouts und Wiederholungen: Stimmen Sie Verbindungspools und Wiederholungseinstellungen der Clients auf Workloads mit hoher Parallelität ab. Zeitabweichungen: Das Signieren von Anfragen schlägt fehl, wenn Uhren auseinanderlaufen. Halten Sie die Zeit auf Rechen- und Speicherseite synchron. Ein Tabellenformat wählen Die wichtigsten offenen Tabellenformate teilen dieselben Grundideen, unterscheiden sich aber in der Unterstützung durch das Ökosystem, im Umgang mit Updates und Löschungen und in der Reife ihrer Tools für bestimmte Engines. Aus Sicht des Speichers sind die Anforderungen nahezu identisch, sodass die Wahl meist davon abhängt, welche Engines Ihre Teams nutzen, wie oft Daten an Ort und Stelle aktualisiert werden und welchen Katalog Sie betreiben wollen. Viele Organisationen standardisieren für neue Tabellen auf ein Format und behalten die Möglichkeit, andere zu lesen. Da die Daten in jedem Fall in offenen Dateiformaten auf S3-kompatiblem Speicher liegen, ist ein späterer Formatwechsel ein Datenkonvertierungsprojekt und keine Speichermigration. Umstieg von älteren Tabellenlayouts Viele Organisationen haben bereits Daten im Objektspeicher oder in einem älteren Data Lake mit verzeichnisbasierten Tabellen. Diese lassen sich meist an Ort und Stelle umwandeln oder schrittweise migrieren: Registrierung an Ort und Stelle ergänzt vorhandene Parquet- oder ORC-Dateien um Metadaten des Tabellenformats, ohne sie neu zu schreiben, sofern das Dateilayout es erlaubt. Neuschreiben bei der Migration kopiert Daten in neue Tabellen mit besseren Dateigrößen, besserer Partitionierung und Sortierung, was die Leistung oft verbessert. Paralleler Betrieb hält alte und neue Tabellen nebeneinander, während Abfragen und Pipelines umgestellt und die Ergebnisse verglichen werden. Planen Sie zuerst den Katalog, damit neue Tabellen in dem System registriert werden, das die Engines künftig nutzen. Eine Bereitstellung testen Führen Sie vor dem Umzug produktiver Tabellen einen strukturierten Test durch: Tabellen mit realistischen Schemata, realistischer Partitionierung und realistischen Dateigrößen anlegen. Gleichzeitige Schreib- und Lesevorgänge ausführen, um Konsistenz und Commit-Verhalten zu bestätigen. Repräsentative Abfragen ausführen und Planungszeit sowie Scan-Durchsatz messen. Wartungsjobs ausführen und bestätigen, dass Löschungen, Compaction und Ablauf von Snapshots wie erwartet funktionieren. Ausfälle simulieren, etwa den Verlust eines Speicherknotens oder einen Neustart des Katalogs, und die Wiederherstellung bestätigen. Souveränität und Kontrolle Da offene Tabellenformate offen und speicherunabhängig sind, können Organisationen Analysedaten auf Infrastruktur halten, die sie kontrollieren, ohne auf moderne Lakehouse-Funktionen zu verzichten. Das ist wichtig für regulierte Branchen und öffentliche Stellen mit Anforderungen an die Datenresidenz. Zudem verringert es den Lock-in, da mehrere Engines dieselben Tabellen lesen können. Checkliste: offene Tabellenformate auf On-Premises-S3 Starke Read-after-Write-Konsistenz, auch bei Listen. Vollständige Abdeckung der zentralen S3-Operationen, einschließlich Range-GETs und Multipart-Uploads. Hohe Anfrageraten und niedrige Latenz für kleine Metadatenobjekte. Hoher aggregierter Durchsatz für parallele Datenlesevorgänge. Skalierung auf Millionen von Objekten pro Bucket. Ein hochverfügbarer, gesicherter Katalogdienst. Geplante Compaction, Ablauf von Snapshots und Bereinigung verwaister Dateien. Korrekte Client-Einstellungen für Adressierungsstil, TLS, Region und Timeouts. Feingranulare Zugriffskontrolle, Verschlüsselung und Audit-Logging. Zusammenfassung Offene Tabellenformate funktionieren gut auf S3-kompatiblem On-Premises-Objektspeicher. Der Speicher muss konsistent sein, mit den von Tabellenformaten genutzten S3-Operationen kompatibel sein und sowohl kleine Metadatenzugriffe als auch große parallele Scans schnell bedienen. Ergänzt um einen zuverlässigen Katalog und regelmäßige Wartung entsteht ein Lakehouse mit modernen Funktionen, das unter Ihrer Kontrolle bleibt. Das vollständige Bild finden Sie unter Betrieb eines Data Lakehouse auf On-Premises-Objektspeicher. Häufig gestellte Fragen Brauchen offene Tabellenformate Objektspeicher in der Public Cloud? Nein. Sie funktionieren mit jedem Speicher, der die S3-API mit starker Konsistenz implementiert, einschließlich On-Premises-Objektspeicher. Welche S3-Funktionen brauchen offene Tabellenformate? Starke Konsistenz, Standard-Objektoperationen, Range-GETs, Multipart-Uploads, Löschen mehrerer Objekte und effiziente Listen. Muss der Objektspeicher Transaktionen unterstützen? Nein. Commits werden durch den Katalog atomar, der einen Verweis auf neue Metadaten austauscht. Der Objektspeicher muss Objekte zuverlässig und konsistent speichern und bereitstellen. Welche Wartung brauchen offene Tabellenformate? Compaction, Ablauf von Snapshots, Bereinigung verwaister Dateien und regelmäßiges Neuschreiben von Manifests. Ist ein Katalog erforderlich? Ja. Der Katalog verfolgt die aktuellen Metadaten jeder Tabelle und führt den atomaren Commit durch.
