Empfiehlt ein KI-Agent auf Basis von Mustern einer schleichenden Leistungsverschlechterung den Austausch kritischer Netzinfrastrukturen, stehen menschliche Operatoren vor einer Trust-Challenge. Sollen sie aufgrund der Ratschläge des ‚digitalen Kollegen‘ Budget und Ressourcen zuweisen? Was ist, wenn mit den Empfehlungen erhebliche Investitionen in Zeit, den Austausch von Geräten oder die Modernisierung von Systemen verbunden sind?

Wie Microsoft-CEO Satya Nadella kürzlich feststellte, "können sich klassische Geschäfts- oder SaaS-Anwendungen im Zeitalter von Agenten dramatisch verändern. Hinter diesen Anwendungen verbergen sich im Wesentlichen CRUD-Datenbanken (Erstellen, Lesen, Aktualisieren und Löschen) mit Geschäftslogik. Aber in Zukunft wird diese Logik zu KI-Agenten migrieren"^[1]. Dieser Wandel bedeutet, dass KI bald direkt mit Unternehmensdaten arbeiten wird, um operative Empfehlungen auszusprechen. Daher kommt der Qualität und dem Umfang dieser Daten entscheidende Bedeutung zu.

Der Schlüssel, um Vertrauen zwischen menschlichen Operatoren und ‚KI-Fachkräften‘ zu schaffen, liegt in der Sicherung einer ausgereiften Data-Engineering-Infrastruktur. Wenn KI-Agenten Lösungen anbieten, müssen diese durch umfassende Daten validiert werden. Dabei handelt es sich nicht um einzelne Momentaufnahmen, sondern um eine Längsschnittanalyse, die sich über Wochen, Monate oder sogar Jahre erstreckt.

Anwendungsfall: Vorausschauende Wartung im Netzbetrieb

Betrachten Sie diesen realen Dialog zwischen einem KI-Agenten und einem Netzwerkadministrator:

Für deratig anspruchsvolle Analysen sind Betriebsdaten erforderlich, die über Jahre erfasst wurden. Diese Daten müssen in einem System gespeichert werden, das komplexe Abfragen, Zeitreihenanalysen und Mustererkennung über verschiedene, heterogene Datenquellen hinweg unterstützt. Die Investition von 15.000 US-Dollar für optische High-End-Module in einem Core-Switch ist gerechtfertigt, wenn man sie den potenziellen Kosten für Ausfallzeiten gegenüberstellt. Hier wird die moderne Dateninfrastruktur zu einem entscheidenden Faktor.

Die Lakehouse-Lösung – einheitliche Datenarchitektur für KI-gesteuerten Betrieb

Die Lakehouse-Architektur. © Belden

Bevor wir tiefer in die Materie eintauchen, ist es wichtig zu definieren, was die Data Lakehouse-Architektur ist und wie sie sich von anderen Modellen unterscheidet. Die Lakehouse-Architektur vereinheitlicht den Datenzugriff durch drei grundlegende Komponenten: die Storage Engine, die die Datenpersistenz verwaltet, die Compute Engine, die Abfragen ver- arbeitet, und der Katalog, der Metadaten verwaltet. Diese Kernelemente greifen ineinander, um Informationen vor der endgültigen Speicherung in standardisierte Tabellen- und Dateiformate umzuwandeln. Dadurch wird ein einheitliches Datenflussmuster geschaffen. Der integrierte Ansatz hebt die übliche Trennung zwischen Warehouses und Lakes auf, so dass Analyse- und KI-Workloads auf derselben zuverlässigen Datenbasis ausgeführt werden. Im Kern kennzeichnet sich das Lakehouse-Paradigma durch vier Hauptmerkmale aus:

1. Kosteneffiziente Speicherung riesiger Datenmengen: Cloud-Objektspeicher (S3, Azure Data Lake Storage, Google Cloud Storage) sind das Fundament, auf dem Lakehouse-Architekturen basieren. Sie verursachen Speicherkosten von etwa 20 bis 23 US-Dollar pro Terabyte und Monat, was drastisch unter den Kosten herkömmlicher Lösungen liegt. Dieser wirtschaftliche Vorteil ermöglicht es Unternehmen, historische Daten aufzubewahren, die für die KI-Mustererkennung und -Validierung erforderlich sind.
   In unserem Beispiel der Netzüberwachung wird die Speicherung detaillierter Telemetriedaten von Tausenden von Switches, Routern und optischen Komponenten wirtschaftlich machbar. Ein einziges Unternehmensnetz kann pro Jahr Terabyte an Leistungsdaten erzeugen. Dank der niedrigen Lakehouse-Kosten zahlt sich eine langjährige Speicherung jedoch durch eine langfristige Erfolgsquote aus.
2. Schema-Entwicklung: Im Gegensatz zu starren Datenbanken sind Lakehouses flexibel. Diese Systeme basieren auf offenen Tabellenformaten wie Delta Lake, Apache Iceberg und Apache Hudi. Neue Metriken oder Sensordaten können hinzufügt werden, ohne die bestehenden Abläufe zu stören. Darüber hinaus können sie Datenstrukturen weiterentwickeln, während Geräte und Überwachungsfunktionen aktualisiert werden, und die Abwärtskompatibilität für historische Analysen gewährleisten.
   Diese Flexibilität ist für die künftige Entwicklung der Netze unerlässlich. Werden neue optische Überwachungsparameter verfügbar oder KI-Modelle benötigen zusätzliche kontextbezogene Daten, lässt sich das Lakehouse ohne aufwendige Migrationen oder Systemausfallzeiten anpassen.
   Diese Flexibilität ist entscheidend: Wenn neue Überwachungsdaten verfügbar werden oder KI-Tools zusätzlichen Kontext benötigen, kann eine Lakehouse-Architektur all dies pro-blemlos umsetzen – ohne Migration oder Ausfallzeiten. Es funktioniert einfach, ohne dass die historischen Daten des Unternehmens beeinträchtigt werden.
3. Herstellerneutrale offene Standards: Das Lakehouse-Ökosystem basiert auf offenen Standards. Eine Abhängigkeit von einem bestimmten Anbieter, die den langfristigen Datenzugriff erschweren könnte, stellt somit kein Problem dar. Unternehmen können ihre Daten in offenen Formaten wie Parquet oder ORC speichern, die von vielen Tools gelesen werden können. Je nach ihren spezifischen Anforderungen haben sie die Möglichkeit, zwischen verschiedenen Compute Engines wie Spark, Trino oder DuckDB zu wählen. Die Nutzung von Standards wie S3-API für die Datenspeicherung vereinfacht die Migration zwischen Cloud-Anbietern oder lokaler Infrastruktur, wenn sich die Anforderungen ändern.
4. Einheitliche Zugriffsmuster: Einer der wichtigsten Aspekte für KI-Anwendungen ist vielleicht, dass Lakehouses dank Standardschnittstellen einen einheitlichen Zugriff auf eine breite Palette von Datentypen ermöglichen. Die Infrastruktur macht es einfach, mit allen Arten von Daten zu arbeiten. Die Benutzer können Zeitreihen-Telemetriedaten von Netzwerkgeräten abfragen, unstrukturierte Eingaben wie Wartungsprotokolle und Notizen von Technikern speichern und analysieren. Zudem können sie halbstrukturierte und strukturierte Daten wie Konfigura- tionsdateien und Netzwerktopologiekarten abrufen. Mit integrierter Time-Travel-Funktion ist es auch möglich, historische Leistungs-Baselines oder frühere Anomalien zu überprüfen. KI-Agenten können auf all diese Informationen über standardmäßige SQL- oder Python-DataFrames zugreifen.

Vertrauen schaffen durch umfassende Daten

Die Lakehouse-Architektur geht die Vertrauensproblematik in der Beziehung zwischen KI und Mensch mit verschiedenen Mechanismen an:

Analyse von Längsschnittdaten

Die wirtschaftliche Speicherung jahrelanger Betriebsdaten im Lakehouse ermöglicht es der KI, subtile Muster zu erkennen, die dem menschlichen Auge entgehen könnten. In unserem Beispiel eines optischen Empfängers erkannte die KI ein frühes Stadium der Degradation, indem sie mehrere Datenströme in einer kohärenten Analyse verband.

Das System verfolgte die täglichen Messungen der Signalstärke über Monate hinweg und stellte eine allmähliche Verschlechterung fest, die von Standardwarnsystemen nicht erkannt wurde. Gleichzeitig wurden diese Messwerte mit Umgebungsfaktoren wie Temperatur und Luftfeuchtigkeit korreliert, um anlagenbedingte Ursachen auszuschließen.

Die Glaubwürdigkeit dieser Analyse wurde durch einen automatischen Vergleich mit historischen Ausfallmustern ähnlicher Geräte bestätigt. Dabei identifizierte das System eine charakteristische Degradationskurve, die vor den vergangenen Ausfällen auftrat.

Das Fehlen von Wartungsereignissen in den Systemprotokollen (Reinigung oder Neuverbindung der Fasern) bestätigte ebenfalls, dass der Signalverlust auf eine echte Verschlechterung der Komponenten und nicht auf vorübergehende Bedingungen zurückzuführen war.

Begründbare Empfehlungen

Wenn KI-Agenten Zugang zu umfangreichen historischen Daten haben, können sie ihre Vorhersagen begründen. Anstatt vage Ergebnisse zu liefern, schlüsseln sie ihre Empfehlungen mit klaren, datengestützten Argumenten auf. Wenn ein KI-Agent beispielsweise vorschlägt, ein Gerät auszutauschen, beruht dies nicht auf einer Vermutung, sondern auf Mustern wie der Degradation von Signalen oder sinkenden Leistungskennzahlen, die in ähnlichen Fällen in der Vergangenheit beobachtet wurden. Es ist das KI-Äquivalent zu der Aussage: "Das haben wir früher schon einmal festgestellt, und das ist als Nächstes passiert".

Das auf realen operativen Daten basierende Konfidenzniveau sorgt für noch mehr Transparenz. Entscheidungsträger erhalten ein klareres Bild davon, wie viel Vertrauen sie in jede der Empfehlungen setzen können.

Am wichtigsten ist vielleicht, dass die KI das technische Risiko mit den Geschäftsergebnissen verknüpft. Sie beschreibt die Kosten proaktiver Maßnahmen im Vergleich zu den potenziellen Kosten von Ausfallzeiten anhand realer Daten. Dadurch wird die Rolle des KI-Agenten von einer Blackbox zu einem aktiven Berater, dessen Denkweise nachvollziehbar ist, der hinterfragt werden kann und dem man vertraut.

Kontinuierliches Lernen und Validierung

Die Lakehouse-Architektur bietet einen wichtigen Vorteil für die KI-Entwicklung: Sie speichert eine vollständige Historie der Daten und Entscheidungen. Das bedeutet, dass Unternehmen messen können, wie gut die KI-Vor- hersagen im Vergleich zu den tatsächlichen Ergebnissen sind. Diese Art der Transparenz ermöglicht es Teams, Modelle anzupassen, wenn neue Muster oder Edge Cases auftreten, ohne den Live-Betrieb unterbrechen zu müssen. Es ist ein sich selbst verbesserndes System, das mit jedem Zyklus intelligenter wird.

Da jede Empfehlung und Maßnahme nachvollziehbar ist, trägt das System auch zur Einhaltung von Compliance- Anforderungen bei und unterstützt damit das organisatorische Lernen. Ingenieure können eine Ursachenanalyse durchführen, wenn es Probleme gibt oder wenn die KI außergewöhnlich gut liegt.

Am wichtigsten ist jedoch, dass dieses Modell eine kontinuierliche Validierung über ein breites Spektrum von Betriebsbedingungen hinweg ermöglicht, von Routineabläufen bis hin zu seltenen Anomalien. Im Gegensatz zu statischen Blackbox-Systemen, die regelmäßig aktualisiert werden müssen, entwickelt sich die Lakehouse-KI kontinuierlich weiter. Sie wird zuverlässiger, erklärbarer und wertvoller.

Erfahrung mit Lakehouse-Architektur

Die in diesem Artikel beschriebenen Fakten und Ideen wurden bereits in der Praxis erprobt. In diesem Abschnitt werden wir die Vor- und Nachteile der Lakehouse-Architektur auf der Grundlage der praktischen Erfahrungen erläutern, die unser Unternehmen im Rahmen der Implementierung gemacht hat.

Die Herausforderungen

Ein Lakehouse vor Ort zu betreiben ist nicht so einfach wie die Bereitstellung einer ‚einzigen ausführbaren Datenbank‘, die alles als Blackbox handhabt. Herkömmliche RDBMS (Relational Database Management System) bündeln Speicherung, Katalogisierung und Abfrage in einem System, während die Lakehouse-Architektur diese Komponenten bewusst dis-aggregiert. In der Praxis bedeutet dies den Betrieb separater Systeme: einen S3-kompatiblen Objektspeicher-Cluster, einen Katalogserver mit relationalem Datenbank-Backend und eine Abfrage-Engine Ihrer Wahl. Diese Disaggregation macht den Betrieb in Nicht-Cloud-Umgebungen komplexer. In Cloud-Umgebungen abstrahieren die Anbieter einen Großteil dieser Komplexität, aber Implementierungen vor Ort erfordern zusätzliche Fachkenntnisse und Ressourcen.

Eine weitere große Herausforderung ist das erforderliche neue Denken. RDBMS haben den Markt in den letzten 50 Jahren dominiert und genau definierte Begriffe für Indizes und klar definierte Kompromisse zwischen Ingress- und Egress-Geschwindigkeit (OTPA – Online Transaction Processing – versus OLAP – Online Analytical Processing) geschaffen. Die Lakehouse-Architektur ändert diese Regeln, indem sie Lese- und Schreibvorgänge voneinander trennt. Unternehmen können gleichzeitig hohe Ingress- und Egress-Leistungen erzielen, allerdings nur, wenn sie Partitionierung, Verdichtung und Dateischema-Designs korrekt implementieren. Entwickler müssen neue Optimierungsansätze verstehen, die sich deutlich von denen der RDBMS-Welt unterscheiden. Die operativen Herausforderungen und das erforderliche Umdenken waren die größten Hürden bei der Implementierung.

Der Nutzen

Bei den Vorteilen sticht besonders die Kosteneffizienz hervor. Wir haben festgestellt, dass die Entkopplung von Rechenleistung und Speicher im Lakehouse-Modell in Kombination mit der Nutzung von S3-Speicher die Kosten um ein Vielfaches senkt. Dabei handelt es sich nicht um theoretische Prognosen, sondern um tatsächliche Kostensenkungen, die wir in Staging-Umgebungen gemessen haben.

Neben den Kostenverbesserungen konnten wir bei einer ordnungsgemäßen Implementierung der Lakehouse-Architektur auch eine erhebliche Verbesserung der Abfrage-Performance feststellen. Es ist jedoch wichtig anzumerken, dass die Leistungsbewertung eine End-to-End-Perspektive erfordert – von der Datenquelle bis zum nachgelagerten Verbraucher. Während nachgelagerte Anwendungen Daten aus dem Lakehouse schnell abfragen können, kann die Geschwindigkeit der Datenaufnahme, -verdichtung und -sortierung bei neu eingegangenen Daten zu Verzögerungen von wenigen Sekunden führen. Das Lakehouse ist kein Allheilmittel für alle Anwendungsfälle, aber es eignet sich hervorragend als Ziel für Streaming-Pipelines, bei denen diese Kompromisse akzeptabel sind.

Der Autor: Dr. Andrii Melashchenko ist System Architect Cloud bei Belden Europe. © Belden

Ein weiterer wesentlicher Vorteil, den wir beobachtet haben, ist die native Time-Travel-Funktion. Das Lakehouse bietet diese Funktion von Haus aus und ermöglicht es uns, das Verhalten der Netzwerkinfrastruktur zu bestimmten Zeitpunkten besser zu verstehen, ohne dass wir dazu komplexe SQL-Abfragen erstellen müssen. Diese Funktion hat sich sowohl bei der Fehlersuche als auch hinsichtlich Compliance-Anforderungen als unschätzbar wertvoll erwiesen.

Unser Unternehmen hat sowohl die Vorteile als auch die Herausforderungen der Lakehouse-Architektur kennengelernt. Unternehmen sollten diese Faktoren entsprechend ihrer spezifischen Anwendungsfälle sorgfältig abwägen. Dennoch sind die Leistungsverbesserungen und die Kosteneffizienz klare Anreize, um eine tiefere Integration zu verfolgen und schrittweise auf dieses Modell zuzusteuern. Wie bei jeder architektonischen Veränderung liegt der Schlüssel darin, die Zugeständnisse zu verstehen und sie mit den geschäftlichen Prioritäten in Einklang zu bringen.