Den meisten Unternehmen, die heute KI-Initiativen betreiben, fehlt es nicht an Daten. Ihnen fehlt ein Ort, an dem diese Daten gleichzeitig für Analytics, Machine Learning und generative KI nutzbar sind, ohne drei separate Kopien und drei separate Pipelines zu benötigen. IBM watsonx.data ist IBMs Antwort auf dieses Problem: ein offenes Lakehouse, das strukturierte, halbstrukturierte und unstrukturierte Daten an einem Ort vorhält, von mehreren Engines abfragbar macht und so gut regelt, dass KI-Teams und Analytics-Teams aus derselben Quelle arbeiten können, ohne sich gegenseitig in die Quere zu kommen. Für Teams, die bereits Kafka für Echtzeitdaten einsetzen, stellt sich die interessantere Frage, wie diese Streaming-Daten tatsächlich in einem so aufgebauten Lakehouse landen.
IBM watsonx.data ist ein Lakehouse mit offener Architektur, das Compute, Metadaten und Storage in unabhängige Schichten trennt, sodass verschiedene Query Engines auf dieselben zugrunde liegenden Daten zugreifen können, ohne sie zu duplizieren. Als primäres offenes Tabellenformat nutzt es Apache Iceberg, unterstützt daneben aber auch Avro, Parquet und ORC, und macht diese Daten für mehrere Query Engines zugänglich, darunter Presto (sowohl die Java- als auch die C++-Variante) und Spark. Die Governance läuft über IBM Knowledge Catalog, der die Schema-Konsistenz durchsetzt und die Metadaten der gesamten Plattform verwaltet. Zusätzlich wird die Vektordatenbank Milvus mitgeliefert, für die Speicherung von Embeddings und die Ähnlichkeitssuche. Das verbindet die Plattform mit KI-Workloads und Workloads für generative KI, statt nur mit klassischem Analytics.
Die Plattform unterstützt zudem den No-Copy-Zugriff auf Daten, die bereits in bestehenden Systemen liegen, darunter Db2 Warehouse und Netezza Performance Server. Eine Migration muss also nicht abgeschlossen sein, bevor ein Team diese Daten über watsonx.data abfragen kann. Als Deployment-Optionen stehen AWS, Azure, IBM Cloud und On-Premises über Red Hat OpenShift zur Verfügung. Eine Developer Edition bündelt vorkonfigurierte Engines für die lokale Installation unter macOS, Windows oder Linux, was typischerweise der Weg ist, auf dem Teams die Plattform evaluieren, bevor sie sich für ein Produktions-Deployment entscheiden.
Ein Data Lakehouse ist eine Architektur, die den günstigen, flexiblen Storage eines Data Lake mit den Datenmanagement-Funktionen eines Data Warehouse verbindet: ACID-Transaktionen, Schema-Durchsetzung und Abfrageperformance. Die Idee dahinter: Man muss sich nicht zwischen „günstig und flexibel" und „strukturiert und schnell" entscheiden. Daten landen einmal, in einem offenen Format, und sowohl explorative Analysen als auch governance-konformes Reporting laufen gegen dieselbe Kopie.
| Aspekt | Data Warehouse | Data Lake | Data Lakehouse |
|---|---|---|---|
| Datenstruktur | Hochstrukturiert, Schema-on-Write | Roh, strukturiert oder unstrukturiert | Strukturiert und unstrukturiert, offene Tabellenformate |
| Kosten | Höhere Storage-Kosten | Kostengünstiger Object Storage | Kostengünstiger Object Storage |
| Governance | Stark, integriert | Oft schwach ohne zusätzliches Tooling | Integriert durch Metadaten und Schema-Durchsetzung |
| Flexibilität bei heterogenen Daten | Begrenzt | Hoch | Hoch |
| Typisches Fehlerbild | Teure Skalierung für Rohdaten | Wird zum unregulierten Datensumpf | Erfordert bewusste Entscheidungen zu Tabellenformat und Governance |
| Am besten geeignet für | SQL-basiertes Reporting | Speicherung von Rohdaten, Exploration | Einheitliche Analytics-, ML- und KI-Workloads |
Das Muster, das zu dieser Situation führt, kennen die meisten Datenteams. Zuerst entsteht ein Data Warehouse fürs Reporting, weil Reporting Struktur und Geschwindigkeit braucht. Wenn sich Roh- und halbstrukturierte Daten ansammeln, meist schneller, als das Warehouse sie aufnehmen kann, kommt ein Data Lake für günstigen Storage und Flexibilität hinzu. Nach ein paar Jahren betreibt die Organisation zwei Systeme, zahlt dafür, sie einigermassen synchron zu halten, und lässt Data Scientists aus dem jeweiligen System ziehen, das gerade die benötigten Daten enthält. Das Lakehouse ist der Versuch, diesen Aufwand nicht länger zu zahlen, indem ein einziges System beide Aufgaben gut erfüllt.
KI- und Machine-Learning-Workloads benötigen für das Training grosse Mengen an Roh- und halbstrukturierten Daten, und zwar ohne einen langwierigen Extract-Transform-Load-Prozess in einen separaten strukturierten Speicher. Ein Lakehouse hält diese Daten in einem offenen Format vor, das sowohl der Spark-Job eines Data Scientists als auch die SQL-Abfrage eines Business-Analysten direkt lesen kann. Bei watsonx.data sorgt die Integration von Milvus konkret dafür, dass Embeddings und Vektorsuche neben denselben governance-konformen Daten liegen, statt in einem losgelösten Vektorspeicher, der separat synchronisiert werden muss.
Das ist besonders relevant für Retrieval-Augmented Generation (RAG), bei der die Ausgabe eines Modells nur so gut ist wie der Kontext, den es abruft. Wenn der Vektorspeicher mit den Embeddings ein anderes System ist als das Lakehouse mit den strukturierten Datensätzen, die diese Embeddings beschreiben, wird das Konsistenthalten beider Systeme zu einem eigenen, dauerhaften Engineering-Problem. Werden beide in watsonx.data untergebracht, entfällt dieser Synchronisierungsschritt, weil Vektorsuche und die zugrunde liegenden governance-konformen Daten aus derselben Plattform abgefragt werden, statt sie nachträglich abzugleichen.
watsonx.data selbst ist eine Query- und Storage-Schicht, kein Stream-Prozessor, weshalb Kafka-Topics nicht direkt darin landen. In der Praxis erreichen Streaming-Daten das Lakehouse über eine Ingestion-Schicht, typischerweise einen Change-Data-Capture- oder Stream-Processing-Job, der Kafka-Events konsumiert und sie bei ihrer Ankunft in Iceberg-Tabellen schreibt. Sobald die Daten in Tabellenform vorliegen, unterscheiden sie sich nicht von anderen Datensätzen in watsonx.data: abfragbar über Presto oder Spark, verwaltet durch IBM Knowledge Catalog und verfügbar für dieselben Analytics- und KI-Workloads wie batchgeladene Daten. Der praktische Vorteil: Ein Team, das bereits Kafka für Echtzeitereignisse betreibt, braucht keine separate Echtzeit-Serving-Schicht neben seinem analytischen Speicher. Die Streaming-Pipeline speist eine einzige governance-konforme Tabelle, und jeder nachgelagerte Konsument, ob Dashboard, Batch-Report oder Modelltraining, liest aus derselben Quelle statt aus einer separaten, nur für Echtzeit gedachten Kopie.
Das bringt einen Kompromiss mit sich, den man offen benennen sollte: Die Daten sind nur so aktuell wie der Ingestion-Job, der sie einspeist, nicht in Echtzeit aktuell wie bei einem nativen Stream-Prozessor. Für die meisten Analytics- und KI-Anwendungsfälle reicht eine Aktualität der Tabellen im Sekunden- bis Minutenbereich völlig aus und ist gegenüber einem nächtlichen Batch-Load bereits eine deutliche Verbesserung. Bei Anwendungsfällen, die tatsächlich eine Verarbeitung im Sub-Sekunden-Bereich benötigen, etwa Betrugserkennung auf Basis einzelner Transaktionen, gehört diese Logik weiterhin in die Stream-Processing-Schicht selbst und nicht in das Lakehouse.
Teams setzen watsonx.data meist aus drei Gründen ein: um Analytics über Systeme hinweg zu konsolidieren, in denen sich über die Zeit separate Data Marts angesammelt haben, um eine einzige governance-konforme Quelle sowohl für BI-Reporting als auch für Trainingsdaten im Machine Learning aufzubauen, und um Retrieval-Augmented-Generation-Workloads zu unterstützen, bei denen die Milvus-gestützte Vektorsuche direkt neben den strukturierten Daten liegen muss, aus denen sie Kontext abruft. Ein vierter, zunehmend häufiger Fall ist Near-Realtime-Analytics, bei dem Kafka-gespeiste Iceberg-Tabellen Dashboards und Modelle mit Daten arbeiten lassen, die nur wenige Minuten alt sind, statt mit einem nächtlichen Batch-Load.
Ein fünfter Fall zeigt sich speziell in regulierten Branchen: No-Copy-Zugriff wird genutzt, um Daten abzufragen, die weiterhin in einem bestehenden Db2 Warehouse- oder Netezza-System liegen, sodass eine Governance- und Zugriffskontrollschicht eingeführt werden kann, ohne zuvor eine vollständige Datenmigration abzuschliessen. So lassen sich Compliance- und Audit-Anforderungen nach ihrem eigenen Zeitplan angehen, unabhängig vom grösseren und langsameren Projekt, den Storage zu konsolidieren.
Das Wort „offen" in einem offenen Lakehouse ist kein Marketing-Detail. Es entscheidet darüber, was in fünf Jahren mit den Daten passiert, nicht nur heute.
Weil watsonx.data Daten in Iceberg, Parquet, Avro und ORC speichert statt in einem proprietären Format, bleiben die zugrunde liegenden Daten für jede Engine lesbar, die diese Formate unterstützt, nicht nur für die von IBM. Eine Query Engine später zu wechseln oder zu ergänzen, erfordert keinen erneuten Export oder eine Neuformatierung der bereits vorhandenen Daten.
Offene Formate bedeuten, dass dieselben Tabellen von Presto, Spark oder anderen Iceberg-kompatiblen Engines abgefragt werden können, die ein Team möglicherweise bereits anderswo betreibt, ohne die Daten für jedes Tool zu duplizieren. Das ist besonders relevant für Organisationen, die im Lauf der Zeit mehrere Analytics- und Data-Science-Tools angesammelt haben und sich realistischerweise nicht auf eine einzige Engine festlegen können.
Daten überdauern die Tools, die um sie herum gebaut werden. Ein offenes Tabellenformat bedeutet: Auch wenn sich Query Engines, KI-Frameworks und Governance-Tooling in den nächsten Jahren verändern, müssen die zugrunde liegenden Daten nicht migriert oder neu geschrieben werden, um mitzuhalten. Die Investition steckt in der Datenschicht, nicht in der Engine eines einzelnen Anbieters.
Die Einführung von watsonx.data ist kein direkter Ersatz für ein bestehendes Warehouse oder Lake. Man muss entscheiden, welche Datenquellen zuerst umziehen, üblicherweise diejenigen, die bereits die meiste Duplizierung oder die grössten Governance-Probleme verursachen, und die Ingestion-Pfade aufbauen, batch- oder streamingbasiert, die die Iceberg-Tabellen aktuell halten. Teams müssen auch entscheiden, wie bestehende BI-Tools und Machine-Learning-Pipelines mit den neuen Query Engines verbunden werden, da das meist bedeutet, Connection Strings und Zugriffsrichtlinien zu aktualisieren, statt die Tools selbst neu zu schreiben. Nichts davon ist ein Rip-and-Replace-Projekt. Es kommt eher einer Konsolidierung des Zugriffs auf bereits vorhandene Daten gleich, Quelle für Quelle.
Drei Entscheidungen bestimmen meist, ob der Rollout reibungslos verläuft. Erstens, welche Query Engine, Presto oder Spark, welchen Workload übernimmt, denn jede Abfrage unabhängig von ihrer Form durch dieselbe Engine zu leiten, führt in der Regel zu schlechterer Performance, als die Engine passend zur Aufgabe zu wählen. Zweitens, wie sich die Governance-Richtlinien von IBM Knowledge Catalog auf die Zugriffskontrollen abbilden lassen, die in den Quellsystemen bereits gelten, damit die Konsolidierung des Zugriffs diesen nicht versehentlich lockert. Drittens, wer die Ingestion-Jobs verantwortet, die Iceberg-Tabellen aus Streaming- oder Batch-Quellen speisen, denn eine Ingestion-Pipeline ohne klaren Verantwortlichen ist meist das Erste, was stillschweigend ausfällt, wenn sich stromaufwärts ein Quellschema ändert.
Mimacom entwirft Lakehouse- und Streaming-Architekturen für Kunden, die governance-konforme Analytics- und KI-Workloads auf denselben Daten benötigen, statt separater Kopien, die von separaten Teams gepflegt werden. Dazu gehören die Ingestion-Schicht, die Kafka oder andere Event-Streams mit Iceberg-Tabellen verbindet, das Governance-Modell, das verhindert, dass ein Lakehouse zu einem unregulierten Datensumpf wird, sowie der Migrationspfad von einem bestehenden Warehouse oder Lake in eine offene Architektur wie watsonx.data.
Die Plattformentscheidung ist weniger wichtig, als die meisten Teams zu Beginn annehmen. Was tatsächlich darüber entscheidet, ob ein Lakehouse-Projekt gelingt, ist, ob die Ingestion-Pfade, batch- und streamingbasiert, die zugrunde liegenden Tabellen zuverlässig aktuell und governance-konform halten. Stimmt das, wird die Wahl der Query Engine oder des KI-Frameworks darüber zu einer viel kleineren Entscheidung, die sich später leicht revidieren lässt.
Nicht zwingend, und nicht sofort. watsonx.data kann Daten direkt dort abfragen, wo sie liegen, etwa in Db2 Warehouse und Netezza, ohne dass eine Migration nötig ist. So können Teams den Zugriff konsolidieren, bevor sie entscheiden, ob ein bestehendes Warehouse vollständig abgeschaltet wird.
Kafka-Topics werden nicht direkt von den Query Engines von watsonx.data gelesen. Eine Streaming- oder Change-Data-Capture-Schicht konsumiert die Kafka-Events und schreibt sie in Iceberg-Tabellen. Die Presto- und Spark-Engines von watsonx.data fragen diese Tabellen anschliessend ab wie jeden anderen Datensatz im Lakehouse.
Weil das Format bestimmt, was mit den Daten passiert, wenn sich die Plattform ändert. Iceberg, Parquet, Avro und ORC sind von vielen Engines lesbar, nicht nur von IBMs eigenen, sodass die Daten nutzbar bleiben, selbst wenn sich die Query Engine oder die Anbieterbeziehung später ändert. Die Plattform ist austauschbar. Ein proprietäres Datenformat ist es nicht.
Ob Sie bestehende Data Marts konsolidieren oder einen governance-konformen Pfad von Kafka-Streams zu KI-Workloads aufbauen: Mimacom entwirft und implementiert die Lakehouse-Architektur, die zu Ihren bestehenden Systemen passt.