Unternehmens-KI-Tools verändern sich deutlich schneller als die meisten Datenarchitekturen. Ein Lakehouse, das für die heutigen Analytics- und Machine-Learning-Projekte gut funktioniert, kann schwieriger anzupassen sein, wenn seine Tabellen, Kataloge, Governance oder Rechenoptionen zu eng an eine einzelne Plattform gebunden sind.
Niemand kann wissen, welche Modelle, Agenten, Analytics-Engines oder Cloud-Dienste in einigen Jahren relevant sein werden. Unternehmen können jedoch die Datengrundlage kontrollieren, von der diese Tools abhängen. Offene Tabellenformate, interoperable Metadaten, einheitliche Governance und flexible Bereitstellungsmodelle können es erleichtern, neue Analytics- und KI-Tools einzuführen, ohne die zugrunde liegenden Daten wiederholt zu verschieben oder neu aufzubauen.
Offene Formate halten die Datenebene portabel
Das Tabellenformat eines Lakehouse beeinflusst mehr als nur die Organisation von Dateien. Es bestimmt auch, wie verschiedene Engines Datenänderungen interpretieren, Transaktionen verwalten und die für eine Abfrage benötigten Informationen finden.
Apache Iceberg bietet eine offene Möglichkeit zur Verwaltung großer analytischer Tabellen – mit Unterstützung für ACID-Transaktionen, die Weiterentwicklung von Schema und Partitionen, Snapshots und Time Travel. Clouderas Leitfaden zur Iceberg-Migration beschrieb außerdem die Unterstützung von Spark, Hive, Flink, Impala, Trino und Presto. Verschiedene Engines können daher mit denselben zugrunde liegenden Tabellen arbeiten, statt für jeden Workload eine eigene Kopie zu benötigen.
Gartners Market Guide for Data Lakehouse Platforms identifizierte offene Tabellenformate, Objektspeicher, getrennte Rechen- und Speicherressourcen sowie einheitliche Metadaten und Governance als zentrale Merkmale eines Lakehouse. Das Unternehmen empfahl zu prüfen, ob der Großteil der Lakehouse-Daten in einem offenen, gemeinsam nutzbaren Format statt überwiegend in proprietärem Speicher abgelegt wird.
Data Lakehouses verbinden die Flexibilität und Skalierbarkeit eines Data Lake mit Funktionen, die traditionell mit Data Warehouses verbunden werden. Ein offenes Tabellenformat kann dafür sorgen, dass diese gemeinsam genutzten Daten weniger von der jeweils aktuell verwendeten Processing-Engine abhängen.
Interoperabilität hängt von mehr als Iceberg ab
Die Unterstützung von Iceberg macht nicht automatisch jeden Teil eines Lakehouse portabel. Kataloge, Metadatendienste, Sicherheitskontrollen, APIs und operative Tools können eigene Abhängigkeiten schaffen.
Der Iceberg REST Catalog kann eine weitere Reibungsquelle reduzieren, indem er standardisiert, wie Engines eine Verbindung zu einem Katalog herstellen. Über eine gemeinsame Schnittstelle können verschiedene Tools dieselben Tabellen finden und mit ihnen arbeiten, ohne für jede Plattform eine eigene Kataloganbindung zu benötigen.
Gemeinsam genutzte Dateien garantieren nicht, dass verschiedene Engines konsistent mit den Daten arbeiten. Jede Engine benötigt außerdem eine einheitliche Sicht auf Tabellensnapshots und Metadaten, geeignete Sicherheitskontrollen und eine zuverlässige Möglichkeit, Änderungen zu koordinieren, wenn mehrere Workloads dieselben Tabellen verwenden.
Gartner empfahl Käufern ebenfalls zu prüfen, ob die Schnittstellen des Lakehouse offenen Standards folgen, damit Daten toolübergreifend gemeinsam genutzt werden können.
Eine Plattform kann Iceberg unterstützen und dennoch an anderer Stelle im Stack Abhängigkeiten schaffen. Wenn das Hinzufügen einer weiteren Engine eine neue Datenkopie, eine benutzerdefinierte Pipeline oder ein separates Governance-Modell erfordert, kann ein späterer Toolwechsel weiterhin schwierig werden.
Interoperabilität hängt auch von einer Governance ab, die über Tools und Umgebungen hinweg konsistent bleibt. Metadaten, Datenherkunft, Richtlinien und Zugriffskontrollen müssen weiterhin nützlich bleiben, wenn neue Engines und KI-Workloads hinzukommen, statt für jede Plattform einen weiteren Satz voneinander getrennter Regeln zu schaffen.
KI-Flexibilität beginnt bei den Daten
Wenn Unternehmen neue KI-Workloads hinzufügen, können unterschiedliche Anwendungsfälle verschiedene Modelle, Retrieval-Tools, Vektorsysteme, Agenten-Frameworks und Processing-Engines erfordern. Ein Lakehouse, das diese Auswahl ermöglicht, ohne die Datenebene neu aufzubauen, gibt Teams mehr Spielraum, ihre Tools an veränderte Anforderungen anzupassen.
Forresters Q3 2026 Data Lakehouses Wave identifizierte offene Tabellenformate, interoperable Metadatenstandards, Zero-Copy-Datenaustausch und erweiterbare APIs als zentrale Funktionen von Lakehouses, die agentische KI unterstützen. Der Bericht stellte fest, dass sich Modelle, Tools und Workflows kontinuierlich weiterentwickeln, wodurch der Wert einer Architektur steigt, die sich mit verschiedenen Technologien verbinden kann.
Die KI-Bereitschaft hängt außerdem von der Qualität, dem Kontext und der Governance der zugrunde liegenden Daten ab. In der von Cloudera gesponserten IDC-Studie wählten 51,6 % von 353 Unternehmen, die der KI-Datenbereitschaft Priorität einräumen, Data Intelligence – einschließlich Datenqualität, Katalogisierung, Datenherkunft, Metadaten und Stammdaten – als einen ihrer beiden wichtigsten Schwerpunktbereiche aus. Weitere 37,9 % nannten die Modernisierung von Daten in hybriden oder Cloud-Data-Lakes, Lakehouses, Warehouses und Datenbanken.
Clouderas agent-ready data series betonte, dass KI-Anwendungen mehr als nur Zugriff auf Daten benötigen. Eine effektive Nutzung hängt auch von aktuellen Daten, Transparenz über ihre Herkunft und Verwendung sowie dem richtigen Kontext und geeigneten Schutzmaßnahmen ab.
Wenn verwaltete Daten bereits über interoperable Systeme verfügbar sind, muss das Hinzufügen eines KI-Workloads nicht mit einer weiteren isolierten Kopie des Datensatzes beginnen. Teams haben mehr Spielraum, unterschiedliche Tools zu den Daten zu bringen, wenn sich die Anforderungen ändern.
Hybride Umgebungen machen die Platzierung von Workloads zu einer Designentscheidung
Die Flexibilität eines Lakehouse hängt auch davon ab, wo Daten und Workloads ausgeführt werden müssen. Regulatorische Anforderungen, Datensouveränität, bestehende Infrastruktur, Leistungsanforderungen und Cloud-Kosten können dazu führen, dass Teile des Datenbestands in unterschiedlichen Umgebungen verbleiben.
IDC berichtete, dass 53 % der analytischen Daten-Repositories in Public-Cloud-, Hybrid-Cloud- oder Multicloud-Umgebungen gespeichert waren, während 47 % ausschließlich On-Premises oder in Private Clouds verblieben. Als Gründe für diese Verteilung nannte der Bericht unter anderem Regulierung, Souveränität, Kostenoptimierung und Rechenanforderungen.
Ein Design, das davon ausgeht, dass jeder Datensatz irgendwann in eine einzige Umgebung verschoben wird, kann sich in einem großen Unternehmen nur schwer umsetzen lassen. Daten lediglich wegen eines weiteren Processing-Tools zu verschieben, kann außerdem eine zusätzliche zu verwaltende Pipeline und eine weitere zu governende Kopie schaffen.
Die Trennung von Rechen- und Speicherressourcen und die Nutzung offener Formate geben Teams mehr Freiheit bei der Entscheidung, wo ein Workload ausgeführt wird, während sie weiterhin verwaltete Daten nutzen. Sensible Daten könnten beispielsweise On-Premises oder in einer privaten Umgebung verbleiben, während andere Workloads dort Public-Cloud-Ressourcen verwenden, wo dies sinnvoller ist.
Cloudera verfolgt diesen Ansatz in hybriden Umgebungen. Forresters Lakehouse-Evaluierung von 2026 beschrieb die Plattform als Unterstützung für On-Premises-, Private-Cloud- und Public-Cloud-Bereitstellungen mit Multiengine-Zugriff auf Spark, Hive, Impala und Trino sowie Governance, Datenherkunft, Sicherheit und Metadatenverwaltung.
Der Bericht hob außerdem Clouderas offene Architektur und die Interoperabilität mit Nicht-Cloudera-Engines hervor. So können Unternehmen bestehende Plattformen dort beibehalten, wo sie sinnvoll sind, statt jeden Workload auf einen einzigen Stack zu migrieren.
Operative Entscheidungen können die Flexibilität dennoch begrenzen
Offene Standards beseitigen nicht den Aufwand, der mit dem Betrieb eines Lakehouse in großem Maßstab verbunden ist. Teams müssen weiterhin Nebenläufigkeit, Tabellenwartung, das Wachstum von Metadaten, Workload-Performance, Sicherheit und Zuverlässigkeit berücksichtigen.
Clouderas Leitfaden für den Produktivbetrieb von Iceberg stellte fest, dass Partitionierungsstrategien, Job-Scheduling, Aufbewahrungsrichtlinien und die Commit-Frequenz das Verhalten von Tabellen bei Nebenläufigkeit und kontinuierlichen Änderungen beeinflussen. Wenn Ingestion, Wartung und Abfragen auf denselben Tabellen ausgeführt werden, ist diese Koordination besonders wichtig.
Gartner empfahl ebenfalls, Performance, Zuverlässigkeit, Kapazität, Wartbarkeit, Workload-Management und den gesamten Datenlebenszyklus zu bewerten, statt ein Lakehouse allein anhand von Funktionen auszuwählen. Das Unternehmen merkte außerdem an, dass dedizierte Data Warehouses bei einigen optimierten Warehouse-Workloads weiterhin eine bessere Leistung erbringen können.
Vendor-Lock-in zu vermeiden erfordert daher mehr als die Wahl eines Open-Source-Tabellenformats. Architekten müssen berücksichtigen, wie Tabellenformat, Katalog, Governance-Schicht, Processing-Engines, Schnittstellen und Bereitstellungsmodell zusammenspielen – und was geändert werden müsste, wenn eine dieser Komponenten ersetzt würde.
Künftige KI-Projekte werden neue Anforderungen mit sich bringen, doch die Kosten ihrer Umsetzung hängen stark von der zugrunde liegenden Datenarchitektur ab. Offene Formate, interoperable Schnittstellen, einheitliche Governance und eine flexible Platzierung von Workloads können die Einführung neuer Tools erleichtern, ohne dass jede technologische Änderung zu einer weiteren Datenmigration wird.
Suchen Sie nach der richtigen Plattform für KI-Governance? Sehen Sie sich eWeeks Leitfaden zu den besten Tools für KI-Governance an, um führende Optionen und ihre Stärken zu vergleichen.