Smart Talk Episode 8: Echtzeit-Einblicke mit Data Lakehouses erschließen

Der Data Lakehouse hat sich als flexibles, vielseitiges Repository etabliert. In dieser Smart-Talk-Episode diskutieren Dinesh Chandrasekhar, CEO von Stratola, und sein Gast Justin Borgman, CEO und Chairman von Starburst, wie man die Fähigkeiten eines Data Lakehouse erweitern kann, um Echtzeitdaten und High-Performance-Queries einzuschließen, die fast Echtzeit-Einblicke liefern – ein zunehmend häufiger Anwendungsfall. Zwei Schlüsseltechnologien sind dafür erforderlich: Kafka-Streams und eine leistungsstarke Query-Engine.

Besonders interessant sind ihre Perspektiven auf die Bedeutung von Open-Source-Software und offenen Formaten, die durch die Ankündigung von Snowflake und Databricks bestätigt wurde, Apache Iceberg zu unterstützen. Justin teilt seine Ratschläge für das Benchmarking von Lösungen: Nutzen Sie Ihre Unternehmensdaten, führen Sie Ihre tatsächlichen Queries aus, simulieren Sie Skalierung und berechnen Sie abschließend die Kosten.

Behandelte Themen:

• Kafka für Streaming von Echtzeitdaten in Data Lakehouses (4:22)
• Vorteile offener Formate (5:56)
• SQLs unterstützende Rolle für GenAI (8:53)
• Snowflake, Databricks und Iceberg (11:56)
• Flexible Data-Repository-Strategie (17:21)

Gast

Justin Borgman, CEO und Chairman, Starburst

Justin Borgman ist Experte für Big Data & Analytics. Vor der Gründung von Starburst war er Vice President & GM bei Teradata (NYSE: TDC), verantwortlich für das Hadoop-Produktportfolio. Er kam 2014 über die Akquisition seiner Firma Hadapt zu Teradata, wo er Co-Founder und CEO war. Hadapt schuf „SQL on Hadoop“ und verwandelte Hadoop von einem Dateisystem in eine analytische Datenbank, die von jedem BI-Tool zugänglich ist. 2017 gründete er Starburst, um Analysten die Freiheit zu geben, diverse Datensets zu analysieren, wo immer sie sich befinden, ohne Performance-Einbußen.

Moderator

Dinesh Chandrasekhar ist Technologie-Evangelist, Thought Leader und erfahrener IT-Industrieanalyst. Mit fast 30 Jahren Erfahrung arbeitete er an B2B-Unternehmenssoftware und SaaS-Produkten, die anspruchsvolle Lösungen für Kunden mit komplexen Architekturen liefern. Er definierte und führte hocherfolgreiche GTM-Strategien aus, um mehrere High-Growth-Produkte bei Unternehmen wie LogicMonitor, Cloudera, Hortonworks, CA Technologies, Software AG, IBM usw. auf den Markt zu bringen. Er ist ein produktiver Sprecher, Blogger und Wochenend-Coder. Dinesh hat einen MBA von der Santa Clara University und einen Master in Computer Applications von der University of Madras. Derzeit führt er sein eigenes Unternehmen Stratola, eine kundenorientierte Business-Strategie-Beratung und Full-Stack-Marketing-Services-Firma.

Ressourcen

Smart Talk Episode 7: Cardinality, Control und Kosten in Observability
Smart Talk Episode 6: AIOps und die Zukunft des IT-Monitorings
Smart Talk Episode 5: Disaggregation des Observability Stacks
Smart Talk Episode 4: Echtzeitdaten und Vektordatenbanken
Smart Talk Episode 3: Moderne Data Pipelines und LLMs
Smart Talk Episode 2: Der Aufstieg von GenAI-Anwendungen mit Data-in-Motion
Smart Talk Episode 1: Die Data-in-Motion-Ökosystem-Landschaft
Data-in-Motion-Ökosystem-Map hier ansehen
Mehr über Data-in-Motion auf RTInsights hier erfahren

Transkript

Dinesh Chandrasekhar:
Hallo und willkommen zu dieser Episode von Smart Talk in der Data and Motion Leadership Series. Ich bin Ihr Gastgeber, Dinesh Chandrasekhar, Chief Analyst und Gründer von Stratola. Unser Gast heute ist Justin Borgman, CEO und Chairman von Starburst. Justin hatte eine herausragende Karriere in Sicherheits- und Datenanalyse-Unternehmen und gründete vor der Gründung von Starburst 2017 eine Firma namens Hadapt, die später von Teradata akquiriert wurde, wo er als VP und GM einige Jahre tätig war. Willkommen, Justin. Lassen Sie uns mit Starburst beginnen – viele kennen die Marke, aber es gibt auch viele, die mehr darüber erfahren möchten. Erzählen Sie uns von Starburst, insbesondere seinen Ursprüngen und Ihrer Motivation, das Unternehmen zu gründen.

Justin Borgman:
Gerne. Wie in der Einleitung erwähnt, bin ich seit etwa 15 Jahren im Data-Analytics-Bereich tätig, zurückgehend auf das erste Startup, das von Teradata akquiriert wurde. Teradata war jahrzehntelang der Leader im Data-Warehousing-Analytics. Dieses Modell erforderte, alle Daten in eine proprietäre Datenbank – das Enterprise Data Warehouse – zu verschieben. Von dort aus konnte man schnelle Analysen durchführen und das Geschäft verstehen. Wir sahen die Chance, dieses Modell auf den Kopf zu stellen – in zwei Richtungen: Erstens die Nutzung offener Tabellenformate in einem Data Lake für Data-Warehousing-Performance in einem Data Lake (manchmal Lakehouse-Architektur genannt). Zweitens die Möglichkeit, auf andere Datenquellen zuzugreifen und Tabellen, die in einer anderen Datenbank liegen, mit Tabellen im Data Lake zu joinen.

Beispielsweise haben Sie vielleicht eine Oracle- oder SQL-Server-Datenbank und möchten eine Tabelle dort mit einer Tabelle im Iceberg-Format im Data Lake joinen. Genau das macht unsere Technologie. Die zugrundeliegende Technologie heißt Trino – ein Open-Source-Projekt, ursprünglich aus Facebook entstanden. Viele der größten Internetunternehmen – LinkedIn, Airbnb, Netflix, Apple etc. – nutzen es für ihre Data-Warehousing-Analytik. Wieder in dem Modell, wo der Data Lake das zentrale Repository ist, um Daten sehr kostengünstig in Data Lakes zu speichern und gleichzeitig andere Tabellen zu joinen. Starburst ist im Wesentlichen die Kommerzialisierung dieses Open-Source-Projekts. Wir bieten eine Enterprise-Version von Trino mit zusätzlichen Sicherheitsfeatures, weiteren Connectors, Performance-Vorteilen und vielen weiteren Funktionen.

Dinesh Chandrasekhar:
Danke. Ich möchte tiefer in Trino, Iceberg und all das eintauchen – großartige Themen für heute. Aber kann ich einen Schritt zurücktreten und fragen: Wenn man die Evolution von Datenarchitekturen betrachtet – traditionelle Datenbanken, dann Data Warehouses, dann mit der Datenexplosion und dem Bedarf an Echtzeitverarbeitung Lakehouse-Architekturen und andere – und in Ihrer Welt haben Sie auch das Konzept des „Icehouse“: Wie hat das die Fähigkeit von Organisationen beeinflusst, Echtzeitdaten effektiv zu handhaben?

Justin Borgman:
Gute Frage. Zur Klarstellung für Ihre Zuhörer: Das Icehouse-Konzept ist im Wesentlichen ein Iceberg-basierter Lakehouse. Die Daten werden im Iceberg-Tabellenformat gespeichert und Sie können Data-Warehousing-Analytik darauf ausführen. Das Ergebnis bietet sehr niedrige Total Cost of Ownership sowie die Fähigkeit, Near-Real-Time-Daten zu handhaben. Wir sehen eine enorme Zunahme an Streaming-Datentechnologien wie Kafka, wo Kunden zunehmend Daten in Near-Real-Time in einen Data Lake streamen. Da setzen wir an: Wir haben „Streaming Ingest“ entwickelt, womit Sie sich mit einem Kafka-Stream verbinden können und wir diesen automatisch in Iceberg-Tabellen umwandeln und für Abfragen fast augenblicklich verfügbar machen. Das ermöglicht Unternehmen jetzt viel schnellere, frischere Einblicke in ihre Daten durch diese Architektur.

Dinesh Chandrasekhar:
Danke. Der Lakehouse verspricht definitiv ein einheitlicher Architekturansatz für Batch- und Echtzeit-Analytik zu sein. Könnten wir sagen, wie sehen Sie diesen architektonischen Wandel, der BI und traditionelle Entscheidungsfindung branchenübergreifend transformiert? Wie hat sich das geändert?

Justin Borgman:
Ja, ich sehe das die Dinge ziemlich dramatisch verändern. Einer der Treiber und Vorteile dieser Architektur ist schlicht Ökonomie. Am Ende des Tages konnten traditionelle Data Warehouses sehr teuer werden. Das war wahrscheinlich die Nummer-eins-Beschwerde während meiner Zeit bei Teradata. Niemand sagte je, Teradata sei eine schlechte Datenbank – es ist eigentlich ein großartiges System. Es ist nur extrem teuer und einmal drin, ist man drin und quasi festgelegt.

Der Data Lake bietet größere Flexibilität, weil Sie offene Formate nutzen, was dem Kunden die Wahl lässt, welche Engine die richtige ist, um auf seine Daten zuzugreifen. Das gibt viel Flexibilität, reduziert Vendor Lock-in, aber erlaubt auch, Daten in sehr günstigem Commodity-Speicher zu lagern – im Cloud-Kontext zunehmend S3, Google GCS oder Azure Data Lake Storage. Selbst On-Prem sehen wir S3-kompatiblen Objektspeicher von Firmen wie Dell oder IBM. Das wird zur gemeinsamen Basisschicht für sehr kosteneffizientes Datenspeichern – ein Teil dessen, was diese Transformation antreibt.

Dinesh Chandrasekhar:
Okay, lassen Sie uns nun in Trino einsteigen – eine sehr mächtige Query-Engine im Echtzeitdaten-Bereich. Wie sehen Sie seine Rolle in der modernen Datenökosystem-Evolution? Besonders in Kombination mit anderen Open-Source-Technologien wie Apache Iceberg, die Interoperabilität zwischen verschiedenen Datensystemen bieten?

Justin Borgman:
Ich denke, es wird zum „Postgres des Data Warehousing“. Postgres ist eine weit verbreitete, extrem beliebte Open-Source-Datenbank – ein traditionelles RDBMS Single-Node. Trino ist sozusagen das MPP (Massively Parallel Processing) Data-Warehousing-Analytics-Äquivalent. Für Big Data, für Data-Warehousing-Aktivitäten wird dies zur de-facto Open-Source-Wahl.

Manchmal fragen Leute: Was ist mit Spark? Spark ist eine großartige General-Purpose-Processing-Engine, aber nicht wirklich für SQL-Analytics optimiert. Und zu Ihrem Punkt zu Business Intelligence und Entscheidungsfindung: SQL ist immer noch die Sprache für diese Use Cases – ob BI-Tool-Anbindung, Reporting oder datengetriebene Anwendungen. SQL bleibt eine sehr wichtige Sprache für die Schnittstelle, und Trino ist heute die Nummer-eins-Engine dafür am Markt.

Kombiniert man es mit Iceberg, hat man im Wesentlichen ein komplettes Data Warehouse: Query-Engine, Storage, und nun ein komplettes offenes Data Warehouse. Es kann auch überall laufen – On-Prem, in der Cloud. Man hat also viel Flexibilität mit diesem Stack.

Dinesh Chandrasekhar:
Eine Abzweigung: Sie erwähnten SQL als Go-to für viele Datenspeicher. In den letzten 30-40 Jahren hat nichts das erschüttert. Aber mit GenAI und NLP überall können nun auch Business-Analysten ohne tiefes SQL-Wissen natürliche Sprache nutzen: „Gib mir die letzten drei Monate Umsatz in dieser Region.“ Intern wird das in SQL übersetzt und die Engine abgefragt. Sehen Sie hier einen Wandel? Wird SQL überleben und gedeihen, oder gibt es einen Shift in der Art, wie wir Daten abfragen?

Justin Borgman:
Das ist eine wirklich großartige Frage, und ich denke, Sie sind auf etwas gestoßen. Ich glaube, generative KI als Interface wird nach und nach super populär, weil es – wie Sie sagten – für jedermann „verdummt“. Jetzt ist es eine Google-Experience auf allen Unternehmensdaten – sehr aufregend. Wir haben eine frühe Version davon in unser Produkt integriert, und ich denke, jeder wird das tun – es wird Table Stakes.

Ich denke aber, hinter den Kulissen werden diese Technologien die natürliche Sprache einfach in SQL-Syntax für die Engine konvertieren. Die Sprache bleibt also wichtig, wird aber mehr zum Implementierungsdetail hinter einem GenAI-Natural-Language-Interface. Das erinnert mich an die Erfindung von Taschenrechnern – plötzlich brauchten wir nicht mehr alle Formeln und schriftliche Division, weil der Rechner das übernahm. GenAI wird Ähnliches für uns tun.

Dinesh Chandrasekhar:
Einfacherer Datenzugriff, definitiv. Da geht die Reise hin. Aufregender Bereich. Zurück zu Iceberg – das wird sehr populär. Die großen Player adoptieren Iceberg als natürliche Art zu sagen: „Wir sind interoperabel, wir unterstützen es.“ Wenn Organisationen zunehmend Echtzeit-Analytik adoptieren: Welche Rolle spielt Iceberg für effizienteres und skalierbares Datenmanagement? Ihre Meinung?

Justin Borgman:
Ich denke, es ist ein großes Ding. Ich denke, es ist die größte Story neben KI 2024. Das Format gibt es seit einigen Jahren, aber dieses Jahr hat der Markt die Debatte entschieden, welches Format gewinnt. Es gab eine kurze Phase mit drei populären konkurrierenden Formaten – die Frage war: Wer gewinnt? Unser Tipp war immer Iceberg, und der Markt hat sich diesen Sommer geeinigt, als sowohl Snowflake als auch Databricks ihre Unterstützung ankündigten – das hat die Debatte quasi beendet: Iceberg ist der de-facto-Standard. Und was das für Kunden bedeutet: Kunden sind die echten Gewinner. Sie können Daten jetzt in einem Format speichern, das sie besitzen, kontrollieren, das portabel ist – nicht in den Händen eines Datenbankanbieters, der sie jahrzehntelang gefangen hält. Sie besitzen es und können Engines gegeneinander ausspielen: „Starburst macht diesen Workload mit bestem Cost-Performance, vielleicht Snowflake für jenen, Databricks für einen anderen.“ Wenn Engines konkurrieren, gewinnt der Kunde – und das ist es, was Iceberg ermöglicht.

Dinesh Chandrasekhar:
Eine großartige Zusammenfassung. Das klärt die Bedeutung von Iceberg für die Zukunft, da Unternehmen auf ein Modell standardisieren, wo alle interoperabler sind und der Kunde profitiert, ohne an einen Vendor gebunden zu sein – mehr Offenheit und Flexibilität. Ein großartiger Punkt.

Justin Borgman:
Genau.

Dinesh Chandrasekhar:
Justin, lass uns über ein Kundenbeispiel sprechen. Trino und Iceberg sind heute zentral – erzählen Sie von einem Fall, wo dies praktisch angewendet wurde und welche Vorteile sie durch Adoption von Trino und Iceberg sahen.

Justin Borgman:
Gerne. Es gibt diverse Beispiele – von führenden Internetunternehmen wie DoorDash bis zu traditionellen Unternehmen wie Comcast, die beide Workloads von traditionellen Data-Warehouse-Plattformen migrieren. Comcast: sehr traditionelles On-Prem-Data-Warehouse. DoorDash: sehr traditionelles Cloud-Data-Warehouse. In beiden Fällen geht es letztlich um besseres TCO bei SQL-Analytics und Flexibilität, mit neuesten Technologien über dieses eine gemeinsame Format zu arbeiten. Auch im Hinblick auf KI: Sie legen die Fundamente, ihre Datenarchitektur so aufzubauen, dass sie einfachen Zugriff auf die Daten haben, die sie brauchen, um eigene Modelle zu trainieren oder RAG-Workflows durchzuführen – für ihre eigenen KI-Ambitionen. Viele Unternehmen sind in den frühen Tagen: „Was kann KI für mich tun? Wie verschafft sie mir Wettbewerbsvorteil?“ Aber alle sind sich einig: Ihre eigenen proprietären Daten sind zentral für Wettbewerbsvorteil. Eine Dateninfrastruktur, die Zugriff auf das Brauchbare in Low-Cost-High-Performance bietet, ist ein Kernschritt in diesem Prozess.

Dinesh Chandrasekhar:
Als Vorteils-Nachfrage: Bei Echtzeitdaten gibt es oft Herausforderungen wie Schema-Evolution – Änderungen am Schema, wenn Quellen sich ändern, muss das Ziel adaptieren – und Data Versioning. Wie hilft Apache Iceberg, diese Herausforderungen in modernen Datenplattformen zu adressieren?

Justin Borgman:
Es gibt das Konzept von Versioning und Time Travel – man kann sehen, wie sich Daten innerhalb unserer Plattform entwickelt haben. Wir haben auch Data Lineage und Data Quality Metrics hinzugefügt, die wir erfassen und Nutzern präsentieren können, damit man wirklich versteht: Woher kamen die Daten? Wie haben sie sich entwickelt, iteriert? Und diese Transparenz letztlich dem Endnutzer bieten.

Dinesh Chandrasekhar:
Okay. Mit Trino sprachen Sie über Kombination diverser Datenquellen und Joint Queries. Bewegt sich die Architektur mehr zu einem zentralisierten Datenspeicher, oder behält man sie dort, wo sie sind, aber bietet die Möglichkeit, sie zu kombinieren und Sichtbarkeit für Konsumenten zu geben? Wie sieht die Zielarchitektur aus?

Justin Borgman:
Gute Frage. Es sind Elemente von beidem, und das hat es immer herausfordernd gemacht, unser Value Proposition zu artikulieren, weil Menschen an ein Modell gewöhnt sind: Alles in ein traditionelles Data Warehouse zentralisieren oder man hat keinen Zugriff. Wir sehen die Welt so: Es wird ein zentrales Repository geben – zweifellos ein Data Lake –, das den Großteil der Daten speichert, weil man ökonomische und Performance-Vorteile hat, so viel wie möglich in Iceberg-Formaten im Lake zu speichern. Das ist eine großartige Strategie für viele Daten. Aber es wird immer Use Cases geben, wo man auf andere Datenquellen zugreifen will – z. B. explorative Analytik: Ich habe eine Hypothese, die ich testen will, die groß fürs Geschäft sein könnte, aber ich will nicht alle ETL-Pipelines bauen und den ganzen Prozess durchlaufen, nur für eine Idee. Da ist die Fähigkeit, eine Tabelle, die woanders liegt, mit dem zu joinen, was man hat, ein Game Changer. Man kann die Hypothese in Minuten statt Wochen testen. Beide sind wertvoll, aber wir denken: Mehrheit im Lake, dann darüber hinausreichen.

Dinesh Chandrasekhar:
Wenn ich ein Drittanbieter-Unternehmen bin, das nach moderner Datenplattform sucht – welche kritischen Performance-Kriterien sollte ich auf meiner Checkliste haben, wenn ich Trino mit Alternativen vergleiche? Meine Priorität: Echtzeit-Daten-Queries handhaben, niedrige Latenz sicherstellen. Was sind die Überlegungen?

Justin Borgman:
Die zwei wichtigsten Ratschläge: Erstens, nutzen Sie echte Queries, die Sie tatsächlich verwenden. Industry Benchmarks sind okay als sehr grober erster Schritt, aber sie spiegeln Ihre Workloads nie wider. Jedes Unternehmen hat seine eigenen Ziele. Simulieren Sie Ihren Endzustand so gut wie möglich – mit Ihren eigenen Queries und Daten im Proof of Concept und Benchmarking. Vertrauen Sie nie ausschließlich auf Vendor-Benchmarks – nicht mal auf unsere. Wir haben sie, Sie können sie ansehen, aber testen Sie selbst mit Ihren eigenen Queries und Daten.

Zweitens: Simulieren Sie auch Skalierung. Skalierung ist wichtig, weil wir oft Gelegenheiten bei Kunden finden, einen Vendor zu ersetzen, der im POC-Prozess ihre Bedürfnisse zu erfüllen schien, aber bei echter Produktionsskalierung versagte. Hier ist der Vorteil von Open-Source-Technologien wie Trino, die bei größtmöglicher Skalierung bewiesen sind – Apple nutzt es bei irrer Skalierung, Facebook offensichtlich auch. Das gibt Sicherheit. Aber trotzdem: Simulieren Sie es selbst im Benchmarking, um sicherzustellen, dass die Technologien Ihre Produktionsbedürfnisse erfüllen.

Drittens: Kosten. Cost und Performance sind zwei Seiten derselben Medaille. Sie müssen das in Ihr Benchmarking einbeziehen – Sie wählen nicht nur das Schnellste, sondern das beste Cost-Performance-Verhältnis. Auch ein wichtiger Bestandteil.

Dinesh Chandrasekhar:
Zustimmung. Ein wichtiges Checklisten-Item für viele, die Lösungen evaluieren. Zum Abschluss aus Trend-Perspektive: Im Datenbereich passiert viel – Data Warehouse Vendors, Lakehouse Vendors, Data Lake Vendors, Real-Time Analytics Databases. Die Auswahl ist breit und verwirrend für Käufer. Sehen Sie aus aufkommenden Trends eine Konvergenz bei Echtzeit-Datenverarbeitung, Lakehouse-Architekturen und Open-Source-Ökosystem? Irgendwelche Konvergenz, die es für Käufer in naher Zukunft klarer macht?

Justin Borgman:
Ich denke schon. Wir sehen sehr populäre Patterns entstehen – oft stammen sie von Internet-Hyperscalern und übersetzen sich über Zeit ins Enterprise. Wir sind jetzt an dem Punkt, wo es ins Enterprise kommt. Die Patterns: Kafka für Streaming (mit Choices: Confluent, Amazon-Version etc. – Choice in all diesen Open-Source-Plattformen, was großartig ist). Iceberg sicher für das Format – das scheint die sicherste Wette zu sein. Auf der Engine-Seite: Die richtige Engine für den richtigen Job. Für SQL-Analytics würden wir Trino und Starburst als beste Wette sagen, aber Sie sollten es sich selbst beweisen. Für ML-Modell-Training vermutlich Spark. Diese vier Technologien werden in Open-Source-basierten Datenarchitekturen für Jahre unglaublich populär sein. Und Open Source gibt die Flexibilität, Komponenten über Zeit zu mischen und anzupassen – was Ihre Architektur den Test der Zeit bestehen lässt. Man will kein Technical Debt schaffen, das man in 10 Jahren nur schwer ersetzen kann. Open Source gibt diese Flexibilität.

Dinesh Chandrasekhar:
Liebe diesen Punkt. Danke. Ich denke, wir sollten mit diesem großartigen Punkt abschließen. Justin, vielen Dank fürs Mitmachen. Großartiges Gespräch über Trino, Iceberg und wie Starburst diese fantastische Plattform bietet, die das Beste aus beiden Welten vereint. Danke und schätzen Ihre Teilnahme.

Justin Borgman:
Danke, Dinesh. War mir ein Vergnügen.