Moderner Data Stack vs. Open Data Infrastructure

Der moderne Datenstack löste vor 10 Jahren ein echtes Problem: Daten an einem Ort sammeln, modellieren und von Analysten abfragen lassen. Das war die Aufgabe und Data Warehouses haben sie gut erfüllt.

Das hat sich geändert. Die meisten Teams, mit denen ich spreche, haben sich noch nicht damit auseinandergesetzt, wie sehr. Wenn Sie KI auf einem Warehouse-zentrierten Stack in die Produktion bringen, zahlen Sie dafür – in Form von Rechenkosten, die keinen Sinn ergeben, in Form von Latenzzeiten, die Sie dem Produktteam nicht erklären können, und in Form einer schleichenden Verschiebung von Datenkopien, für die niemand wirklich verantwortlich ist. Die Architektur ist nicht kaputt, sie erledigt nur eine Aufgabe, für die sie nicht konzipiert wurde.

Hier sind die Argumente für den Wechsel zu Open Data Infrastructure, die sich an den Fragen orientieren, die Skeptiker tatsächlich stellen, und nicht an den einfachen Fragen.

[CTA_MODULE]

„Snowflake und Databricks integrieren KI-Funktionen direkt in ihre Plattformen. Warum sollte ich wechseln?“

Das müssen Sie nicht, und genau das ist der Punkt. Diese Plattformen sind nach wie vor die besten ihrer Kategorie für Datenverarbeitung, Analyse und KI. Cortex, Mosaic, AI Functions – sie sind real und für viele Arbeitslasten genau das, was Sie brauchen. Bei der Umstellung geht es nicht darum, sie zu ersetzen. Es geht darum, den Speicherort Ihrer Daten zu ändern, damit Sie sie effektiver nutzen können.

Die Beschränkung liegt nicht in den Tools, sondern in der Architektur. Wenn Daten eng an eine einzige Plattform gekoppelt sind, führt jeder neue KI-Anwendungsfall, der außerhalb dieser Plattform liegt, zu Reibungsverlusten. In dem Moment, in dem Sie ein anderes Modell, ein anderes Tool oder ein anderes System verwenden müssen, müssen Sie wieder Daten kopieren, Pipelines erstellen und Inkonsistenzen in verschiedenen Umgebungen verwalten. Auf diese Weise steigen die Kosten, es kommt zu Latenzzeiten und der Kontext wird beeinträchtigt.

Open Data Infrastructure löst dieses Problem, indem es die Speicherung von der Datenverarbeitung trennt. Anstatt die Daten in jede Plattform einzuspeisen, speichern Sie sie einmal in einem offenen, verwalteten Data Lake und lassen Snowflake, Databricks und andere Engines aus derselben Datenquelle lesen. Dadurch werden doppelte Pipelines vermieden, die Integrations- und Compute-Kosten gesenkt und die Daten über verschiedenen Teams und Tools hinweg konsistent gehalten.

Das lässt sich in realen Unternehmen deutlich erkennen. Üblicherweise verwenden verschiedene Teams unterschiedliche Compute-Tools – die Finanzabteilung nutzt Snowflake, Data Science arbeitet mit Databricks und vielleicht gibt es ein neues KI-Team, das mit etwas ganz anderem experimentiert. Oder Sie erben nach einer Übernahme ganz andere Technologien. Ohne eine gemeinsame Basis laufen Sie Gefahr, parallele Datenpipelines in jedes System zu betreiben, für die Datenintegration mehrfach zu bezahlen und zu versuchen, leicht voneinander abweichende Versionen derselben Daten miteinander abzugleichen. Bei einem zentralisierten Data Lake entfällt diese Komplexität: Sie pflegen eine einzige „Quelle der Wahrheit“, verwalten sie einmal, und jedes Tool arbeitet mit demselben, aktuellen Kontext.

Die Frage ist also nicht, ob Sie wechseln sollten, sondern ob Sie Ihre Daten an ein System binden oder für alle Systeme zugänglich machen möchten. Die Beibehaltung dieser Plattformen als Compute-Schichten bei gleichzeitiger Umstellung auf eine offene Datengrundlage bietet Ihnen jetzt Flexibilität und Auswahlmöglichkeiten für später – ohne dass Sie zu einem vollständigen Neuaufbau gezwungen sind, wenn sich Ihre Anforderungen unweigerlich ändern.

„Wir haben 2018 einen Data Lake ausprobiert. Es war wie ein Sumpf. Warum ist dies anders?“

Das ist fair, und viele Teams haben diese Altlasten. Der Data Lake 2018 scheiterte aus bestimmten Gründen, die inzwischen behoben wurden.

Die alten Lakes waren reine Dateiablagen ohne Transaktionsgarantien. Die Schemaabweichungen waren allgegenwärtig, Governance spielte nur eine untergeordnete Rolle und die Abfrage-Engines, die diese Dateien auslasen, waren im Vergleich zu einem Data Warehouse langsam und anfällig. Deshalb haben die Teams sie aufgegeben und sind wieder zu Snowflake oder Databricks zurückgekehrt. Das war damals die richtige Entscheidung.

Was jetzt tatsächlich anders ist: Offene Tabellenformate (Iceberg, Delta) bieten ACID-Transaktionen, Schemaentwicklung und Zeitreisen auf Basis von Objektspeicher. Die Katalogstandards sind ausgereifter. Abfrage-Engines, die diese Formate lesen, sind bei vielen Arbeitslasten wettbewerbsfähig, manchmal sogar schneller als die Leistung nativer Data Warehouses.

Aber diese Fähigkeiten allein bringen noch keinen Mehrwert. Dennoch müssen Sie die Daten in diese Formate übertragen, sie ständig auf dem neuesten Stand halten, Schemaänderungen verwalten und Metadaten systemübergreifend pflegen – und genau hier stoßen die meisten Teams auf Schwierigkeiten.

Der Fivetran Managed Data Lake Service übernimmt das für Sie. Sie stellt Daten in offenen Formaten bereit, synchronisiert Ihren Data Lake kontinuierlich mit den Quellsystemen, verwaltet die Schemaentwicklung automatisch und veröffentlicht Metadaten in Ihrem Katalog, so dass jede Engine auf eine konsistente, kontrollierte Ansicht der Daten zugreifen kann. Anstatt diese Teile selbst zusammenzufügen, erhalten Sie die Vorteile eines offenen Data Lake ohne den operativen Aufwand, der traditionell damit verbunden ist.

„Databricks hat Delta Lake entwickelt und ist jetzt Eigentümer von Tabular, das von Iceberg entwickelt wurde. Was bedeutet hier „offen“?

Offenheit hat ein großes Spektrum – es kommt darauf an, welche Dimension Sie meinen. Es besteht Formatoffenheit, das heißt, mehrere Engines können die Daten lesen und schreiben. Iceberg verfügt über funktionierende Implementierungen von Snowflake, AWS, Google, Trino, DuckDB usw. Auch Delta wird umfassend unterstützt. Unabhängig davon, welcher Anbieter die Spezifikation sponsert, befinden sich Ihre Daten in einem Objektspeicher, den Sie kontrollieren, und zwar in einem Format, das mehrere Engines lesen können. Das ist ein deutlich anderer Ansatz als die proprietäre Warehouse-Speicherung.

Governance-Offenheit, wer die Spezifikation kontrolliert, ist komplizierter. Iceberg gehört zur Apache Foundation, aber Tabular ist jetzt im Besitz von Databricks. Delta wird von Databricks geführt und unterliegt der Governance der Linux Foundation. Beide sind nicht völlig neutral. Entscheidend im operativen Betrieb ist, ob Ihr Speicher und Katalog so offen sind, dass Sie Abfrage-Engines austauschen können, ohne Petabytes an Daten neu einzulesen – dann haben Sie einen entscheidenden Vorteil. Das ist die Messlatte. ODI schafft sie. Proprietärer Warehouse-Speicher tut das nicht.

„Tausche ich nicht einfach einen Anbieter gegen fünf? Das kann mein Plattformteam nicht leisten.“

Dies ist der Punkt, an dem viele „Modular Stack“-Angebote in der Praxis scheitern. ODI gibt Ihnen Flexibilität, und Flexibilität verursacht Betriebskosten. Wenn Sie das Ganze selbst aus Einzelkomponenten zusammenstellen – ein Katalog hier, eine Abfrage-Engine dort, dazwischen eine Orchestrierungsschicht – brauchen Sie ein Plattformteam, das alles zusammenhält. Für viele Unternehmen ist das nicht realistisch.

Zwei Dinge machen dies überschaubar. Erstens sind die wichtigsten Ebenen – Speicher und Katalog – zunehmend standardisiert, sodass Sie nicht fünf proprietäre Systeme einfach zusammenfügen, sondern Ebenen konfigurieren, die tatsächlich zusammenarbeiten. Zweitens gibt es jetzt für die meisten Komponenten verwaltete Angebote, sodass Sie die Architektur übernehmen können, ohne jede Komponente selbst zu betreiben.

Die eigentliche Frage ist nicht „modular vs. konsolidiert“, sondern: „Wo möchte ich Wahlfreiheit haben?“ Wenn Sie innerhalb eines Anbieters konsolidieren, tauschen Sie die betriebliche Einfachheit von heute gegen die Umstellungskosten von morgen. Wenn Sie ODI einführen, tauschen Sie eine gewisse betriebliche Komplexität gegen die Möglichkeit, Arbeitslasten weiterzuleiten, wenn sie sich weiterentwickeln. Beides sind gültige Optionen. Es wäre falsch, so zu tun, als gehe es ohne Kompromiss.

„Meine Warehouse-Abrechnung ist in Ordnung. Zeigen Sie mir, wo die KI-Arbeitslast die Rechnung tatsächlich nicht mehr aufgehen lässt.“

Bei frühen Experimenten gibt es noch keine Probleme. Probleme treten erst an dem Punkt auf, den die meisten Teams noch nicht erreicht haben.

Eine einzelne Agentenaufgabe, z. B. das Generieren einer Empfehlung, erscheint als eine Ausgabe. Dahinter verbergen sich eine Abfrage des Nutzerverhaltens, eine Produktsuche, eine Bestandsprüfung, eine Modellinferenz und häufig eine Neueinstufung. Das ist nicht eine Abfrage – sondern ein Dutzend Abfragen, manchmal sogar mehr. Die Ausführung für einen Nutzer ist kein Problem. Wenn man das auf Tausende von gleichzeitigen Agenten anwendet, erscheinen die Kosten pro Aufgabe bei Rechenleistung zum Warehouse-Preis geradezu lächerlich im Vergleich zu den Kosten, die dieselben Vorgänge in einer routingfähigen Umgebung verursachen würden.

Es gibt noch ein weiteres Problem: die Latenzzeit. Warehouses sind auf Durchsatz bei großen Abfragen und nicht auf geringe Latenzzeiten bei kleinen Abfragen ausgelegt. Wenn Agenten verkettete Abrufe durchführen, summiert sich jede Verzögerung von hundert Millisekunden. Einige Arbeitslasten werden im Warehouse ausgeführt, und Sie werden es nicht einmal bemerken. Andere werden nach und nach unbrauchbar, und die Antwort, die das Team findet, ist, „ein anderes System aufzusetzen“. Und so entsteht schließlich das Problem eines Flickwerks.

Wenn Sie sich selbst ein Bild davon machen möchten, implementieren Sie einen echten Agent-Workflow von Anfang bis Ende und sehen Sie sich die Kosten pro Aufgabe sowie die P95-Latenz an. Die Zahlen sind meist überzeugender als die Argumente.

Wir haben das intern festgestellt. Mit der zunehmenden Nutzung von Agenten stiegen das Abfragevolumen und die Kosten viel schneller als erwartet. Die erste Reaktion bestand darin, Leitplanken einzubauen, aber das machte das eigentliche Problem nur noch deutlicher: Wenn jeder neue KI-Workflow von demselben kostenintensiven Pfad abhängt, wird die Skalierung der KI zu einem Kostenproblem und nicht zu einem Problem der Leistungsfähigkeit. Das hat uns dazu veranlasst, auf eine Data Lake-Architektur umzusteigen, bei der Arbeitslasten mit hohem Volumen auf kostengünstigeren Engines ausgeführt werden können, anstatt standardmäßig im Data Warehouse.

„Ist das nicht nur eine als Architekturberatung getarnte Verkaufspräsentation?“

Bei jeder Diskussion um die Architektur gibt es jemanden, der davon profitiert. Die Anbieter von ODI-Komponenten – offene Tabellenformate, Abfrage-Engines, Kataloge und Data Movement-Plattformen – profitieren vom Wachstum dieses Modells. Wichtig ist jedoch, dass auch die Warehouse-Anbieter Teil dieses Ökosystems sind. Bei einem ODI-Ansatz spielen sie weiterhin eine wichtige Rolle als leistungsstarke Compute-Ebenen – nur nicht mehr als einziger Ort, an dem Ihre Daten gespeichert sind.

Was schwerer von der Hand zu weisen ist, ist die Tatsache, dass die zugrundeliegenden Veränderungen – offene Tabellenformate als Speicherstandard, Entkopplung der Datenverarbeitung vom Speicher, Agenten als primäre Datenkonsumenten – unabhängig davon stattfinden, welcher Anbieter den Zuschlag erhält. Snowflake unterstützt Iceberg. Databricks hat Tabular gekauft. AWS, Google und die großen Kataloge konvergieren alle auf diese Ebene. Die Frage ist nicht, ob sich die Architektur in diese Richtung entwickelt. Das tut sie. Die Frage ist, wie aggressiv Sie sich dafür positionieren und wie viel von Ihrem aktuellen Stack Sie bereit sind, auf dem Weg dorthin umzubauen.

Eine naheliegende Schlussfolgerung: Wenn sich gerade die Anbieter, die durch diesen Wandel Nachteile hätten, selbst in diese Richtung bewegen, ist der Wandel wahrscheinlich real.

Modern Data Stack vs. Open Data Infrastructure

Wo man anfangen sollte

Sie müssen das Warehouse nicht komplett ausmustern. Sie müssen nur aufhören, es als Zentrum des Universums zu betrachten. Verlagern Sie die Speicherebene zunächst zu offenen Formaten: Iceberg oder Delta auf einem Objektspeicher, den Sie tatsächlich kontrollieren. Alles andere baut auf dieser Grundlage auf. Die meisten Data Warehouses können diese Formate inzwischen lesen, es handelt sich also nicht um eine Migration von Ihrem bestehenden Stack; es ist eine Neupositionierung der Daten, sodass auch andere Engines darauf zugreifen können.

Ziehen Sie als Nächstes eine Arbeitslast vom Data Warehouse ab. Wählen Sie etwas aus, das das Warehouse schlecht bewältigt: einen häufigen Abruf, eine Feature-Pipeline für einen ML-Anwendungsfall oder einen Agenten-Workflow, der unerwartet hohe Kosten verursacht. Leiten Sie es über eine andere Engine unter Verwendung desselben Speichers. Messen Sie den Unterschied. Das ist Ihr interner Beweis.

Investieren Sie schließlich in die Kontextebene. Metadaten und Semantik wirken wie reine Verwaltungsarbeit, bis man sieht, wie ein Agent aufgrund einer veralteten Definition Aktionen ausführt. Sie sind für KI nicht optional, sondern machen den Unterschied zwischen Agenten, die funktionieren, und solchen, die nicht funktionieren.

[CTA_MODULE]