Kategorie: Einblicke

Du hast einen KI-Agenten programmiert. Er kann reasoning, Daten aus Millionen Dokumenten suchen, Schritte planen. Aber im Unternehmen tritt er auf der Stelle. Kein Fortschritt. Frustration. Kommt dir bekannt vor?

Es liegt nicht an den Modellen. Die sind heute gut genug. Das Problem ist die Infrastruktur, auf der sie laufen. Das sagten drei Infrastruktur-Chefs auf der VB Transform 2026: Animesh Singh von LinkedIn, Desiree Gosby von Walmart und Sami Ghoche von Zendesk. Alle drei waren beim Skalieren von KI-Agenten auf Probleme gestoßen. Ihr Fazit: Die Probleme lagen nicht an den Modellen, sondern an der Infrastruktur.

Stell dir die klassische Unternehmens-IT wie ein altes Straßennetz vor. Gebaut für langsame Fußgänger, die an jeder Kreuzung anhalten. KI-Agenten sind wie autonom fahrende Sportwagen, die keine Zeit für Ampeln haben – es knallt. Genau das passierte.

LinkedIn: Kubernetes war der Flaschenhals

Bei LinkedIn stieß Singh auf zwei Hindernisse. Der erste war Kubernetes. Der Container-Orchestrator startet Container auf Anfrage – das dauert Sekunden. Für Menschen ist das okay, aber KI-Agenten arbeiten in Millisekunden. Singhs Team änderte den Ansatz: Statt Container bei Bedarf zu starten, legen sie jetzt vorgefertigte Container-Pools an, in die agentische Workloads in Echtzeit ein- und ausgeswappt werden. Das löste das erste Problem.

Der zweite war schwieriger. LinkedIn erlaubte Agenten, ihre eigene Orchestrierung zu steuern – sie sollten selbst entscheiden, welche Schritte als Nächstes kommen. Ein fünfteiliges Evaluierungssystem sollte Halluzinationen unterbinden. Trotzdem traten sie auf. Singh erkannte das strukturelle Problem: Ein LLM, das die Ausgabe eines anderen LLMs bewertet, hat denselben Denkfehler wie das, was es bewertet. LinkedIn baute das System um: 80 Prozent des Workflows sind jetzt deterministischer Code, skriptgesteuert. LLMs kommen nur dort zum Einsatz, wo Reasoning nötig ist. Jeder Schritt protokolliert seine Ergebnisse, bevor es weitergeht.

Walmart: Der Erfolg wurde zum Problem

Bei Walmart sah die Hürde anders aus. Desiree Gosby ließ ein Agent-Harness direkt an die Mitarbeiter ausrollen – ein Werkzeug, mit dem selbst Citizen Developer eigene Agenten bauen können. Es ging viral. Plötzlich entstanden Dutzende Agenten für dieselben Probleme. Keine Koordination, keine Governance. Die Lösung war nicht, das Harness zurückzuholen, sondern eine Governance-Struktur aufzubauen, die Duplikate erkennt, die beste Version eines Agenten auswählt und in Produktion bringt – ohne dass Engineering den Prozess verlangsamt.

Gosby sagte: Engineering soll nie wieder der Engpass sein. Stattdessen sollen die Mitarbeiter innovativ sein können, während die Infrastruktur die Qualität sichert.

Zendesk: Die Datenflut zähmen

Sami Ghoche von Zendesk hatte es mit einer anderen Art von Infrastruktur zu tun: den Datenpipelinen. Zendesk sitzt auf rund 20 Milliarden Kundengesprächen – ein großer Bestand. Der naive Ansatz wäre, alles in ein großes Kontextfenster zu stopfen und ein LLM daraus Agenten generieren zu lassen. „Das funktioniert nicht“, sagte Ghoche. Stattdessen investierte Zendesk massiv in Datenpipelines, die die relevanten Informationen filtern und strukturieren, bevor ein Agent sie sieht.

Große Kontextfenster sind verlockend, aber sie ersetzen keine saubere Dateninfrastruktur. Ohne sie verlieren Agenten den Überblick oder liefern falsche Ergebnisse.

Open Source als Strategie

Alle drei Unternehmen verfolgen eine ähnliche Strategie: Unabhängigkeit von einzelnen Modellanbietern. Ghoche sagte, die meisten Unternehmen besitzen lieber eigene Modelle und Infrastruktur, wenn möglich. Nur für reine Frontier-Reasoning-Aufgaben greifen sie auf die führenden Labs zurück. Dieser Anteil sinkt, je mehr normale Enterprise-Anwendungen hinzukommen.

LinkedIn hat dafür zwei Bausteine entwickelt: ein AI Gateway, durch das jeder ausgehende Aufruf an ein Modell läuft, egal ob öffentliche Cloud oder eigenes Rechenzentrum. Und ein Memory-Subsystem, das Kontext unabhängig vom Modellanbieter speichert. So kann das Unternehmen schnell zwischen verschiedenen Anbietern wechseln.

Walmart hat sein eigenes internes Gateway gebaut, das drei Workload-Typen unterstützt: vollständig deterministische Abläufe, Planer-und-Validierer-Workflows für offene Aufgaben und eine Mischung aus beidem. Governance, Sicherheit und Evaluation laufen immer durch dieses Gateway – egal welches Modell gerade am anderen Ende sitzt.

Für alle gilt: Die Wahl zwischen einem Frontier-Modell und einem Open-Weight-Modell erfolgt nach Effektivität für die Aufgabe, nicht nach ideologischen Gründen.

Drei Ratschläge

Aus den Erfahrungen ergeben sich drei Empfehlungen:

Erstens: Investiere früh in Evaluierung. Ghoche nannte Evals die Basis jedes Use Cases. „Ein robustes Set von Evals hilft dir, das Problem zu zerlegen, danach kannst du viel schneller vorankommen.“ Ohne klare Metriken weißt du nicht, ob dein Agent besser wird oder nur anders funktioniert.

Zweitens: Gib Mitarbeitern früh ein Agent-Harness in die Hand. Gosbys Erfahrung zeigt: Das schafft enorme Innovation. Aber baue parallel die Infrastruktur auf, die entstandene Agenten überwachen und koordinieren kann. Sonst entsteht Chaos.

Drittens: Setze auf Modell- und Kontextunabhängigkeit. Singhs Rat: „Sorge für Unabhängigkeit – egal ob Frontier-Modell heute oder Open-Source-Modell morgen. Behalte den Kontext in deinem Unternehmen, damit du ihn wiederverwenden kannst, wenn du nächstes Jahr ein anderes Modell oder Harness einsetzt.“

Konsequenzen für dein Unternehmen

Wenn du KI-Agenten in deinem Unternehmen einsetzen willst, wirf zuerst einen genauen Blick auf deine Infrastruktur. Die Modelle sind bereit, aber deine Systeme sind es meistens nicht. Kubernetes, Datenpipelines, Governance – das sind die wichtigen Komponenten. Nicht das nächste große Sprachmodell, sondern grundlegende Arbeit. Die drei Unternehmen auf der VB Transform haben gezeigt: zuerst die Infrastruktur aufbauen, dann die Agenten einsetzen. Erst dann funktionieren sie zuverlässig.

Quelle: venturebeat.com

Wenn du eine Software entwickelst und Dutzende Ansätze ausprobierst, hast du nach Stunden die beste Lösung – aber die Zwischenschritte sind nur in deinem Kopf oder in verstreuten Notizen. Experience Graphs speichern diese Erfahrungsstruktur in einer durchsuchbaren, wiederherstellbaren und gemeinsam nutzbaren Form. Sie sind das Datenfundament für KI-Agenten, die iterativ nach besseren Lösungen suchen.

Gang Liao und Kollegen von der University of Maryland und Meta schlagen mit Trellis eine Datenbank-Architektur vor, die diesen Experience Graph speichert. Bisher behandeln Agenten-Frameworks diese Daten als flüchtigen Zustand: JSON-Checkpoints und Sitzungslogs, die nach einem Absturz verloren sind. Trellis lagert den Experience Graph in eine Datenbank aus und macht frühere Probleme zu Abfragen.

Jeder Schritt wird zum Knoten

Agenten für Codegenerierung, wissenschaftliche Entdeckungen oder Hardware-Optimierung arbeiten nicht mit einem Durchlauf. Sie explorieren: Sie erzeugen Artefakte, führen Werkzeuge aus, beobachten Fehler, verzweigen, reparieren und vergleichen Alternativen. Jeder Schritt erzeugt einen Knoten im Experience Graph: das Prompt, das Artefakt, die Tool-Ausgaben, eine Bewertung, die Verbindung zum Elternknoten und zu Geschwistern. Dieser Graph ist ein kausaler Baum von Versuchen, kein bloßes Wissen.

Die Autoren kritisieren die übliche Einteilung in deklaratives, prozedurales und episodisches Gedächtnis. Sie erfasst nicht den Experience Graph, der entsteht, wenn ein Agent über viele Sessions sucht. Produktionssysteme wie Metas KernelEvolve haben die Schmerzgrenze erreicht: Fortschritt ging bei Abstürzen verloren, parallele Arbeiter brauchten ad-hoc-Koordination, frühere Entdeckungen ließen sich nicht wiederverwenden. Die Lösung: die Datenbasis ändern.

Eine Architektur aus zwei Schleifen

Die Autoren schlagen eine Zwei-Schleifen-Architektur vor. In der inneren Schleife arbeiten Agenten als zustandslose, serverlose Funktionen – sie erhalten eine Aufgabe, generieren einen Knoten, evaluieren und terminieren. Die äußere Schleife entscheidet anhand einer Suchstrategie (gierig, MCTS, evolutionär), welcher Knoten als nächstes expandiert wird. Der Graph liegt persistent in Trellis, einer Datenbank für diese Zugriffsmuster: Anhängen von Knoten, Aktualisieren von Pfaden, Vektor-Ähnlichkeitssuche für Wiederverwendung und Zeitreise-Abfragen.

Die Vorteile: Crash Recovery wird trivial, da der Graph in der Datenbank gespeichert ist. Zweitens: Wiederverwendung über Sessions hinweg – ein Agent kann den Graph ähnlicher Suchen durchsuchen, per Vektor-Embedding vielversprechende Teilbäume identifizieren und als Startpunkt nutzen. Drittens: Datenextraktion für Training – der Graph liefert alle Knoten mit hohem Reward per Datenbank-Abfrage. Viertens: Horizontale Skalierung – zustandslose Agenten lassen sich parallel laufen lassen, die Datenbank übernimmt die Konsistenz.

Messbare Vorteile und Grenzen

In einer kontrollierten Studie mit KernelEvolve erreichten die Agenten mit Trellis eine Zielbeschleunigung etwa 10-mal schneller, bei 52 % niedrigeren Token-Kosten pro gültiger Lösung. Allerdings zeigte sich ein Exploration-Anker-Effekt: zu starker Fokus auf bisherige Lösungen kann die Exploration neuer Regionen beeinträchtigen. Der Trade-off muss bewusst gesteuert werden.

Die Autoren argumentieren, dass Experience Graphs eine ähnliche Transformation auslösen könnten wie Logs für Datenbanken. Früher waren Logs flüchtige Dateien – heute sind sie zuverlässig, durchsuchbar und wiederherstellbar. Genauso könnten Experience Graphs zu einem dauerhaften Vermögenswert werden. Wenn jeder KI-Agent seine Sucherfahrungen in einer gemeinsamen Datenbank ablegt, entsteht ein kumulativer Wissensschatz.

Offene Fragen für die Forschung

Trellis ist kein ausgereiftes Produkt, sondern eine Systemarchitektur, die viele Forschungsfragen aufwirft: Wie plant man Abfragen über multimodale Daten? Wie hält man Konsistenz bei parallelen Suchstrategien? Wie gestaltet man das physische Layout für typische Zugriffsmuster? Wie bildet man bi-temporale Aspekte ab? Das sind offene Probleme – sie zeigen, dass die Datenbank-Community hier eine entscheidende Rolle spielen kann.

Die nächste Generation von KI-Werkzeugen braucht nicht nur bessere Modelle, sondern auch klügere Datenhaltung. Statt jeden Agenten wie eine Einweg-Applikation zu behandeln, versteht man die Suche als Datenbank-Problem. Experience Graphs sind kein akademisches Konzept – sie ermöglichen selbstverbessernde Agenten. Wie ein Spalier das Wachstum einer Pflanze lenkt, ohne selbst zu wachsen, gibt diese Datenbasis den Agenten Halt, weiterzukommen.

Quelle: arxiv.org

Früher trainierte man für jede Fachdomäne ein eigenes Sprachmodell. Man baute einen Tokenizer für Fachbegriffe, feinjustierte die Gewichte auf domänenspezifische Texte. Das Ergebnis war ein massgeschneidertes Modell. In der Praxis hob dieser Ansatz nie richtig ab. Der Trade‑off war zu gross: spezialisieren auf eine Nische heisst Allgemeinheit verlieren. Die meisten Unternehmen brauchen ein Modell, das Fachsprache und allgemeine Anfragen beherrscht. Alan Yahya, ein erfahrener KI‑Infrastrukturentwickler, erklärt, warum dieser Weg scheiterte und welche Richtung sich abzeichnet.

Die Spezialisierung verlagert sich aus den Modellgewichten in die Umgebung des Modells – in sogenannte Harnesses. Ein Harness ist die Softwarearchitektur, die das Modell umgibt und steuert. Er verwaltet Gedächtnis, Informationsabruf, Planung und Werkzeuge. Das Modell selbst ist stateless. Der Harness liefert Anweisungen, Kontext, Werkzeuge, Fehlerbehandlung. So wird die Anpassung an eine Domäne zur Konfigurationsfrage, nicht zum Neutrainieren. Yahya betont: Diese Verlagerung erhält die Allgemeinheit des Modells und erlaubt gleichzeitig tiefe Spezialisierung.

Gedächtnis und Werkzeuge im Harness

Ein zentrales Element eines Harness ist das Gedächtnis (Memory). Informationen in einer Fachdomäne lassen sich als Graph oder Ontologie abbilden. Ein juristischer Harness behält rohe Dateiverweise, damit das Modell jederzeit den Originaltext nachschlagen kann. In einem Forschungsumfeld, wo konzeptuelle Zusammenfassungen wichtiger sind, darf der Agent verdichten und abstrahieren. Die Compaction – die Strategie, wie der Harness den Arbeitskontext verwaltet – entscheidet, was bewahrt, wie es repräsentiert und was verworfen wird. Im Recht wäre es fahrlässig, Quellverweise zu löschen; in der kreativen Textarbeit reicht eine Zusammenfassung. Dieser Unterschied macht den Harness zu einem mächtigen Hebel für Domänenanpassung, ohne die Modellgewichte zu berühren.

Werkzeuge (Tools) sind der zweite Baustein. Sie geben dem Modell die Fähigkeit, die Aussenwelt zu beobachten oder zu verändern: Suchen, Dateizugriff, Code‑Ausführung, API‑Aufrufe, Datenbankabfragen. Ein Harness kann domänenspezifische Ein‑ und Ausgaben erzwingen, Validierungsschleifen einbauen und sicherstellen, dass der Agent vor einer Änderung eine bestimmte Datenbank konsultiert. Yahya beschreibt dies als Möglichkeit, die korrekte Verwendung domänenspezifischer Daten zu erzwingen. Die Entscheidungslogik wird in den Harness verlagert – reproduzierbar, testbar, anpassbar. Das ist ein entscheidender Vorteil gegenüber dem Fine‑Tuning, bei dem man kaum Kontrolle über einzelne Verhaltensweisen hat.

Schwindender Vorteil des Fine-Tunings

Einwurf: Die grossen Frontier‑Modelle werden bereits auf ihre eigenen Harnesses nachtrainiert. OpenAI, Anthropic, Google post‑trainieren ihre Modelle auf die Werkzeuge, Aufrufkonventionen, Fehlermeldungen und Speicherstrategien ihrer Umgebung. Hat dieser Hebel noch Bedeutung? Yahya räumt ein, dass eine Anpassung der Modellgewichte an die Umgebung einen gewissen Vorteil bringt. Aber dieser Vorteil schwindet rapide. Bei der heutigen allgemeinen Leistungsfähigkeit reicht meist ein Retry‑Loop mit einer umfassenden Fehlermeldung, damit das Modell einen Werkzeugaufruf beim zweiten Mal richtig macht. Die Differenz zwischen einem Modell, das auf seinen Harness optimiert ist, und einem allgemeinen Modell mit klarem Harness wird zunehmend vernachlässigbar.

Für Entwickler und Unternehmen heisst das: Statt Monate und hohe Kosten in Training oder Fine‑Tuning eines spezialisierten Modells zu investieren, können sie auf modulare, quelloffene Harness‑Systeme zurückgreifen. Yahya verweist auf Beispiele wie Project Pi, Codex, Qwen Code, OpenCode, Gemini CLI und Grok Build. Diese Systeme sind open source oder öffentlich verfügbar. Die Bausteine sind da – sie müssen nur auf die eigene Domäne zugeschnitten werden. Die Kunst besteht darin, Gedächtnis, Werkzeuge, Validierung und Kompaktierungsstrategie zu definieren. Einmal konfiguriert, kann der Harness mit jedem leistungsfähigen Basismodell kombiniert werden. Das eröffnet Freiheitsgrade, die das alte Modell der Spezialisierung nie bieten konnte.

Basismodell plus konfigurierter Harness

Harnesses trennen die Verantwortlichkeiten sauber: Gedächtnis ist ein austauschbares Modul, Werkzeuge sind steckbar, die Planungskomponente kann ausgetauscht werden. Yahya stellt sich eine Zukunft vor, in der Unternehmen nicht mehr ein „Juristen‑Modell“ oder „Medizin‑Modell“ kaufen, sondern ein Basis‑Modell plus einen konfigurierten Harness, der alle domänenspezifischen Regeln, Ontologien und Workflows enthält. Das reduziert Kosten und Abhängigkeit von einzelnen Modellanbietern. Der Harness ist unabhängig vom Modell – er kann mit Llama, GPT, Claude oder Gemini arbeiten, solange die Schnittstellen passen.

Yahya räumt Grenzen ein: Für extrem sicherheitskritische Anwendungen in Medizintechnik oder Luftfahrt kann ein speziell trainiertes Modell mit deterministischeren Eigenschaften sinnvoll sein. Für die allermeisten Use Cases – legale Dokumentenanalyse, Softwareentwicklung, wissenschaftliche Recherche – reicht die Kombination aus leistungsfähigem Basismodell und massgeschneidertem Harness. Entscheidend ist die Bereitschaft, die Anpassung dorthin zu verlagern, wo sie am meisten Wirkung zeigt: in die Infrastruktur, nicht in die neuronalen Gewichte.

Vom Modell zur Umgebung

Domänenspezifische Harnesses verändern, wie wir KI in Fachgebieten einsetzen. Statt „Welches Modell trainieren wir?“ fragen wir „Welche Umgebung bauen wir?“. Die Allgemeinheit der Modelle bleibt erhalten, die Flexibilität steigt, die Kosten sinken. Wer heute in domänenspezifische KI investiert, sollte die Hebel im Harness suchen, nicht in den Gewichten. Das erleichtert die Suche nach echten Problemlösungen.

Quelle: alanyahya.com

Stell dir vor, du betrittst einen Laden und wirst sofort nach deinem Geld gefragt, bevor du weißt, was du kaufen willst. Unangenehm. Genau das erlebten Besucher der Website eines globalen Dokumentenediting-Dienstes. Die Conversion Rate Experts testeten das – mit einem überraschenden Ergebnis.

Der Fall zeigt: Nutzer brauchen den richtigen Moment für eine Entscheidung. Es geht nicht darum, möglichst früh einen Call-to-Action zu platzieren, sondern die Reise des Besuchers zu verstehen. Die Agentur beschreibt in ihrem Win Report, wie sie für einen Kunden – einen der größten akademischen und professionellen Editierdienste – den prominenten „Get Quote“-Button in der Kopfzeile entfernte. Das klingt kontraintuitiv. Normalerweise gilt: Je sichtbarer der Button, desto mehr Conversions. Hier führte der Schritt zu einer Steigerung der Conversion-Rate um 39 %.

Warum ein Formular Besucher vertrieb

Die Analyse der Nutzerpfade zeigte ein klares Muster: Viele Besucher kamen auf die Startseite, klickten sofort auf „Get Quote“ und landeten auf einem Formular, das sie mit Fragen überforderte. Der Dienst unterschied zwischen „Substantive Editing“ und „Copy Editing“. Für einen Erstbesucher war das kaum zu unterscheiden. Sie mussten Angaben zu Wortanzahl, Lieferzeit und Servicelevel machen – Dinge, die nur jemand beantworten kann, der den Service bereits kennt. Die Folge: Die meisten verließen frustriert die Seite. Das war die Hypothese der Agentur: Der Button war ein zu früher Schritt, der Besucher ohne ausreichende Information in die Entscheidung trieb.

Um das zu testen, wählten die Experten eine einfache, aber mutige Variante: Sie entfernten den „Get Quote“-Button komplett aus der Kopfzeile. Kein kleiner Textlink, kein anderer Button – einfach nichts. Die Besucher mussten selbst durch die Seite navigieren. Dabei entdeckten sie die detailreichen Beschreibungen der Dienstleistungen, Referenzen und Vertrauenssignale großer Kunden. Auf jeder Serviceseite gab es einen kontextrelevanten CTA, der sich natürlich in den Lesefluss einfügte. Der Unterschied war gewaltig: Statt sofort zum Formular zu springen, informierten sich die Besucher erst und trafen dann eine fundierte Entscheidung.

Das Prinzip der sicheren Schritte

Die Conversion Rate Experts nennen das das „Safe Step Principle“: Besucher gehen den nächsten Schritt eher, wenn er sich sicher und angemessen anfühlt – proportional zu dem, was sie bereits wissen. In diesem Fall war der große Button ein unsicherer Sprung ins Ungewisse. Die Entdeckungsreise durch die Inhalte gab ein Gefühl der Kontrolle. Die Zahlen: 39 % mehr Conversions, nur durch Weglassen eines Elements.

Bedeutet das, man sollte nie einen prominenten CTA verwenden? Nein. Es heißt: Der Kontext ist entscheidend. Für bestehende Kunden wäre der Button vielleicht hilfreich gewesen. Aber für Neubesucher war er eine Hürde. Die Agentur betont, dass sie den Button nicht für immer entfernt haben, sondern erst die zugrunde liegenden Probleme im Formular beheben müssen, bevor sie ihn wieder einblenden.

Übertragbar auf jedes Interface

Diese Lektion lässt sich auf viele Bereiche übertragen – Websites, digitale Produkte, KI-gestützte Interfaces. Entwickler neigen dazu, viele Optionen und direkte Aktionsmöglichkeiten anzubieten, in der Hoffnung, User schnell zu einer Handlung zu bewegen. Die Realität ist komplexer. Menschen brauchen Zeit, Vertrauen und Kontext, bevor sie eine Transaktion durchführen. Beste Technologie nützt nichts, wenn sie den Nutzer überfordert.

Ein weiterer Punkt: Der Test war radikal. Die Agentur zitiert ihr eigenes Buch „Making Websites Win“: Kleine Verbesserungen brauchen ewig, um messbare Effekte zu zeigen. Große, mutige Änderungen sind schneller und liefern mehr Gewinn. Das klingt logisch. In der Praxis scheuen viele Unternehmen davor zurück, etablierte Elemente wie einen Header-Button zu entfernen. Dieser Test zeigte, dass genau solche Entscheidungen den Durchbruch bringen können.

Conversion ist Nutzerpsychologie

Für Tech-Experten ist das eine Erinnerung: Conversion-Optimierung ist kein Spiel mit Farben und Schriftgrößen. Es geht um Nutzerpsychologie. Nimm die Perspektive des Besuchers ein und verstehe seine Unsicherheiten. Wer den Menschen in den Mittelpunkt stellt, wird belohnt – auch wenn es bedeutet, auf den ersten Blick Wichtiges wegzulassen.

Die Einordnung: Dieser Fall ist kein Plädoyer dafür, alle CTAs zu entfernen. Er ist ein Beispiel dafür, dass mutiges Testen und gründliche Nutzeranalyse zu Ergebnissen führen, die auf den ersten Blick widersprüchlich erscheinen. Genau das macht die Arbeit von Conversion-Spezialisten aus: Sie stellen Annahmen infrage und zeigen, dass manchmal weniger wirklich mehr ist. In einer digitalen Welt voller Ablenkung und Entscheidungsdruck kann Reduktion auf das Wesentliche die stärkste Waffe sein.

Quelle: conversion-rate-experts.com

Wenn der Daten-Tacho plötzlich grün wird

Du sitzt vor einem Dashboard, das die Umsätze der letzten Stunde anzeigen soll. Du drückst auf „Aktualisieren“, und nichts passiert. Sekunden vergehen, der Ladebalken kriecht. Ist die Abfrage doch komplexer als gedacht? Dieses Warten gehört im Datenalltag dazu, besonders wenn Apache Spark im Hintergrund arbeitet. Spark verarbeitet große Datenmengen, hat aber eine Schwäche: Overhead. Jede Query muss geplant, optimiert, serialisiert und an die Executors verteilt werden. Das kostet Zeit, vor allem bei vielen kleinen Aufgaben. Ein neues Projekt, Apache DataFusion Comet, zielt genau darauf ab.

Warum Spark manchmal ins Stocken gerät

Apache Spark ist ein verteiltes Framework für große Datenmengen. Es liefert bei großen, parallelen Aufgaben gute Ergebnisse. Bei vielen kleinen Operationen – Filtern, Aggregationen, Joins auf Partitionen – wird der JVM-Overhead spürbar. Jeder Task startet in der Java Virtual Machine, Daten werden serialisiert und deserialisiert, der Scheduler verteilt die Arbeit. Die CPU ist oft nicht ausgelastet, viel Zeit geht für Organisation drauf statt fürs Rechnen.

Apache DataFusion ist eine in Rust geschriebene Query-Engine. Rust bietet Performance ohne Garbage-Collection-Pausen. DataFusion führt SQL-Abfragen nativ aus, ohne JVM-Umweg. Das Comet-Projekt nutzt das: Es ersetzt den Spark-Execution-Plan durch eine native DataFusion-Ausführung. Der Anwender merkt kaum etwas davon. Du schreibst weiterhin Spark-SQL-Abfragen, aber unter der Haube läuft ein anderer Motor.

Wie Comet den Turbo zündet

Apache DataFusion Comet ist kein eigenständiges System, sondern ein Plugin für Spark. Es fängt logische Pläne ab, die Spark generiert, und wandelt sie in physische Pläne für DataFusion um. DataFusion ist in Rust geschrieben und nutzt moderne CPU-Features wie SIMD und optimierte Speicherzugriffe. Dadurch werden Berechnungen schneller und effizienter. Tests zeigen, dass Comet die Ausführungszeit je nach Query-Typ um den Faktor zwei bis fünf reduzieren kann. Und das ohne Code-Änderungen – ein Drop-in-Beschleuniger.

Stell dir vor, du hast eine Profi-Küche mit vielen Köchen – das sind deine Spark-Executors. Bisher holte jeder Koch seine Zutaten aus dem Lager. Mit Comet stehen alle Zutaten bereit, die Kochstation ist vorgeheizt, ein Koch erledigt mehrere Schritte in einem Durchgang. Das Ergebnis: Das Essen ist schneller fertig, die Küche läuft ruhiger.

Die Verbindung zu Iceberg und Rust

Das Comet-Projekt ist eng mit der Entwicklung von Iceberg Rust verknüpft. Apache Iceberg ist ein offenes Tabellenformat für Data Lakes. Es bringt ACID-Transaktionen, Schema-Evolution und Zeitreise-Funktionen. Die offizielle Iceberg-Referenz ist in Java geschrieben, aber es gibt eine wachsende Rust-Implementierung, die Iceberg Rust Library. Rust ist schnell und ideal für DataFusion, da beide dieselbe Sprache verwenden. Wenn Iceberg Rust in DataFusion integriert wird, können Spark-Queries direkt auf Iceberg-Tabellen in Rust ausgeführt werden – ohne Java-Umweg. Das beschleunigt Queries und vereinfacht die Entwicklung.

Die Entwickler von Iceberg Rust arbeiten mit dem DataFusion-Team zusammen, um alle Iceberg-Features zu unterstützen, wie Partition Pruning, Manifest-Lesevorgänge oder Upgrades. Das ist kein theoretisches Projekt: Iceberg-Tabellen lassen sich bereits mit Spark und Comet ausführen und nutzen die Performance von Rust. Da Rust keinen Garbage Collector hat, bleiben Antwortzeiten konstant niedrig – kein ruckelnder Ladebalken.

Was das für dich bedeutet

Wenn du bereits Spark für Data-Lake-Analysen einsetzt, bekommst du mit Comet eine einfache Möglichkeit, Queries zu beschleunigen, ohne Code umzuschreiben. Du aktivierst das Plugin, konfigurierst es einmal und profitierst von der nativen Ausführung. Das spart Zeit und Rechenkosten: Schnellere Queries bedeuten entweder mehr Anfragen oder kleinere Cluster. Besonders bei wiederkehrenden ETL-Jobs oder Ad-hoc-Analysen macht sich der Unterschied bemerkbar.

Für alle, die sich mit Rust und Iceberg beschäftigen, eröffnet Comet eine neue Perspektive: eine vollständig native Pipeline von der Speicherung in Iceberg bis zur Ausführung mit DataFusion und Spark. Das reduziert die Abhängigkeit von der JVM und ermöglicht weitere Performance-Optimierungen, die nur in Rust möglich sind. Die Community arbeitet daran, auch andere Spark-Komponenten wie den Optimizer oder den Shuffle-Prozess durch native Alternativen zu ersetzen. Das ist ein Schritt zu einem „Cloud Native Spark“, das die einfache API von Spark mit der Rechenleistung von Rust vereint.

Eine realistische Einordnung

Apache DataFusion Comet ist kein Allheilmittel. Es löst vor allem Probleme bei rechenintensiven Queries, die viel CPU-Zeit in der Ausführung verbrauchen. Liegen Flaschenhälse im Netzwerk, Speicher oder I/O, bringt Comet wenig. Auch die Kompatibilität mit allen Spark-Features ist noch nicht vollständig. Einige UDFs oder spezielle Funktionalitäten müssen nachgerüstet werden. Aber die Entwicklung ist schnell, und erste Produktionseinsätze zeigen vielversprechende Ergebnisse.

Für Iceberg-Nutzer: Comet ersetzt die Iceberg-Integration nicht automatisch. Du brauchst weiterhin den Iceberg-Katalog und die Tabellenmetadaten – diese werden über die Iceberg Rust Library gelesen, die mit DataFusion spricht. Das Zusammenspiel wird kontinuierlich verbessert, sodass du am Ende einen schlanken, performanten Stack bekommst.

Fazit

Die Kombination aus Apache Spark, Apache DataFusion Comet und Iceberg Rust ist ein Beispiel dafür, wie moderne Software alte Probleme löst. Wir sehen einen Trend weg von monolithischen, JVM-lastigen Systemen hin zu modularen, nativen Komponenten. Du musst deine Gewohnheiten kaum ändern. Die Abstraktion bleibt dieselbe – Spark und SQL –, die Performance steigt. Wenn du das nächste Mal auf ein Dashboard wartest: Vielleicht liegt es nicht an der Datenmenge, sondern daran, dass der Koch noch in der Speisekammer steht. Mit Comet hat er die Zutaten schon in der Hand.

Quelle: iceberg.apache.org