Composable Data Systems

Einführung

• Was sind Composable Data Systems? [1, 2]
• Vorteile von Composable Data Systems [2-9]
• Der Weg zu Composable Data Systems [10-12]

Offene Standards über Silos

• Die Bedeutung von offenen Standards [8, 13-18]
• Arrow als Beispiel für einen offenen Standard [19-22]
• Das Arrow-Ökosystem [23-25]
• Composable Data Systems mit Substrait, ADBC und Arrow [26, 27]

Sprachinteroperabilität

• Herausforderungen der Sprachinteroperabilität [6, 28-34]
• Die Rolle von Intermediate Representations (IR) [35-43]
• Substrait als IR-Standard [43-45]
• Composable User Interfaces [46-58]

Von Datenwildwuchs zu Datenkonnektivität

• Die Herausforderungen des Datenwildwuchses [7, 59-65]
• Die Bedeutung der Datenkonnektivität [66-73]
• Wesentliche Komplexitäten der Datenkonnektivität [74-82]
• Datenkonnektivitätsstandards [83-89]
• Arrow Database Connectivity (ADBC) [90-93]
• Arrow Flight SQL [94-96]
• Composable Datenkonnektivität [97-105]

Beschleunigte Hardware

• Die Herausforderungen der Engine-Optimierung [9, 106-110]
• Die "Wall" der CPU-basierten Systeme [111, 112]
• Der Aufstieg von GPUs und beschleunigter Hardware [113-118]
• Die "Machine" für beschleunigte Systeme [119-131]
• Die Rolle von Standards in beschleunigten Systemen [132-139]

Zusammenfassung und Ausblick

• Composable Data Systems sind die Zukunft [140, 141]
• Wie Sie sich über Composable Data Systems informieren können [1, 8, 16, 28, 59, 106, 142-146]
• Wie Sie sich an der Entwicklung von Composable Data Systems beteiligen können [140]

Referenzen

• Voltron Data. 2023. The Composable Codex. https://voltrondata.com/codex [147-150]
• Pedreira et al. 2023. The Composable Data Management System Manifesto. [127, 151]
• Chattopadhyay et al. 2023. Shared Foundations: Modernizing Meta’s Data Lakehouse. [121, 151]
• Li et al. Mainlining Databases: Supporting Fast Transactional Workloads on Universal Columnar Data File Formats. [78]
• Raasveldt & Muhleisen. Don’t hold my data hostage. [79]
• Jindal et al 2021, Magpie: Python at Speed and Scale using Cloud Backends. [152]
• Ahmad et al. Benchmarking Apache Arrow Flight - A wire-speed protocol for data transfer, querying and microservices. [96]

Composable Data Systems

Einführung

Daten-Systeme zu bauen ist schwierig: es ist teuer, verbraucht Ressourcen und nur wenige Experten sind in der Lage, sie zu entwerfen und zu implementieren. Doch das Blatt wendet sich. Anstatt von Grund auf neu zu programmieren, sind jetzt die Voraussetzungen dafür geschaffen, Systeme durch Komposition zu erstellen. [1]

• Was sind Composable Data Systems?
• Vorteile von Composable Data Systems
• Der Weg zu Composable Data Systems

Der Weg zu composable Data Systems

Im Jahr 2010 begann eine Bewegung ohne Namen. Man kann sie als "Build Your Own Database" (BYODB)-Bewegung bezeichnen. Oder die "Build Your Own Data System"-Bewegung. [2]

Meta baut sein eigenes Datensystem. Walmart baut sein eigenes Datensystem. Ebenso Microsoft, GE, Netflix, Airbnb, Apple, Two Sigma, Twitter, Man Group, Goldman Sachs und die Liste geht weiter. Diese Unternehmen haben effektiv damit begonnen, ihre eigenen Datensysteme intern zu entwickeln. [3]

Warum Composable Data Systems?

• Der Traum ist, dass das System einfach nahtlos funktioniert: Es gibt unendlich skalierbaren Speicherplatz, die Ausführung ist schnell und Daten können abgefragt werden, ohne dass es Vorbehalte gibt, welche Programmiersprachen oder APIs unterstützt werden. [4]
• Unternehmen, die es sich leisten konnten, begannen, alle oder einen erheblichen Teil der Softwarekomponenten von Grund auf neu zu entwickeln und so maßgeschneiderte Datensysteme zu entwickeln, die ihren speziellen Bedürfnissen entsprechen. [4]

Herausforderungen und Trends

Die Entscheidung, Millionen von Dollar und jahrelange Entwicklung in ein Moonshot-Dateninfrastrukturprojekt zu investieren, kann für kein Unternehmen einfach sein. Was würde ein Unternehmen dazu bringen, sich für den Bau eines eigenen Datensystems zu entscheiden? Wahrscheinlich ist es eine Kombination aus zwei Trends, die sich im Universum abzeichnen: [5]

• Mikrotrends ("Trends im kleinen Maßstab, die sie von ihrem aktuellen System wegdrängten") und
• Makrotrends ("Trends im großen Maßstab der Branche, die sie zu einer Veränderung drängten"). [5]

Mikrotrends

• Lock-in: Niemand wird gerne in seinem Stack eingesperrt. Vor allem, wenn sie wissen, dass jede Änderung am System bedeutet, dass sie alle Daten in das neue System migrieren, alle Datenteams für die Verwendung des neuen Systems umschulen und alle vorhandenen Daten-Workloads in einer neuen Benutzeroberfläche neu schreiben müssen. [6]
• Skalierbarkeit: Niemand mag es, wenn die Ressourcen ausgehen. Vor allem, wenn sie Abfragen neu schreiben müssen, um eine Workload zu skalieren. [6]
• Leistung: Niemand mag ein langsames System. Geschwindigkeit ist wichtig. Rechenzeit ist wichtig. Datentransportzeit ist wichtig. [6]

Makrotrends

• Der KI-Wettrüsten: Schon vor dem Aufstieg der LLMs gab es einen echten Bedarf an "schnellerem, skalierbarerem und kostengünstigerem maschinellem Lernen". In den frühen Tagen der BYODB-Bewegung waren viele Unternehmen vielleicht nicht in der Lage, genau zu bestimmen, wie und warum sie KI oder ML einsetzen müssten. Aber sicher wollte niemand im "KI-Wettrüsten" auf dem falschen Fuß erwischt werden. Die FOMO (*Fear of Missing Out*) war real. [7]
• Der Aufstieg von GPUs und anderer beschleunigter Hardware: Die Hardware hat sich seit dem Beginn der BYODB-Bewegung sowohl in vorhersehbarer als auch in unvorhersehbarer Weise verändert. Was einst ein Bereich war, in dem CPUs herrschten, ist heute ein "Wilder Westen der Hardware", in dem sich Chips wie GPUs, FPGAs, ASICs, TPUs und andere spezialisierte Hardware rasant weiterentwickelt haben. Aber wie auf der JupyterCon 2018 festgestellt wurde, "haben sich die Werkzeuge, die wir verwenden, nicht so elegant skaliert, um die Vorteile moderner Hardware zu nutzen". Die Entwickler, die die BYODB-Bewegung anführten, erkannten, dass Software zwar ein Gatekeeper für beschleunigte Hardware war, dies aber nur vorübergehend war. In Zukunft würde Software ein Gateway zu beschleunigter Hardware bieten, aber nur für diejenigen, deren Systeme so aufgestellt waren, dass sie die Hardware-Lotterie gewinnen konnten. Genau wie bei der KI wollte niemand die Frage hören "GPUs sind da - sind wir bereit?" und mit "Nein" antworten. Die FUD (*Fear, Uncertainty, and Doubt*) war real. [8]

Eine neue composable Grenze

Wie sieht diese neue Grenze der Datensysteme aus? Sie sieht eigentlich sehr ähnlich aus wie Ihr traditionelles Datensystem. [9]

Auch wenn moderne, spezialisierte Datensysteme auf den ersten Blick unterschiedlich erscheinen mögen, so bestehen sie im Kern doch alle aus einem ähnlichen Satz logischer Komponenten. [9]

Ein minimal lebensfähiges Datensystem kann in drei Hauptschichten unterteilt werden: [10]

• Eine Benutzeroberfläche
• Eine Ausführungsmaschine
• Datenspeicherung [10]

Open Source und Standards

Glücklicherweise begannen die Teams in diesen Pionierunternehmen, als sie mit dem Aufbau ihrer eigenen Datensysteme begannen, die Macht zweier sich ergänzender Kräfte zu erkennen: [11]

1. Open Source bietet mehr Auswahlmöglichkeiten
2. Standards helfen, bessere Entscheidungen zu treffen [11]

Composable Systeme

Viele leitende Entwickler in Unternehmen, die ihre eigenen Systeme aufgebaut haben, plädieren nun für einen Paradigmenwechsel im Design von Datensystemen. Der Paradigmenwechsel würde nicht nur den Unternehmen zugute kommen, die es sich leisten können, ihre eigenen Systeme zu bauen, sondern auch jeder Organisation, die ein bestehendes Datensystem modernisieren möchte. Die Umstellung besteht darin, sich von der Entwicklung von Systemen durch "Coding First" zu entfernen und stattdessen mit "Composing First" zu beginnen. [12]

Ein composable Datensystem ist eines, das durch die Wiederverwendung verfügbarer Komponenten entworfen wird. Aber man baut ein Datensystem nicht einfach aus Komponenten zusammen, die einfach herumliegen. Aus den Lehren der BYODB-Bewegung heraus balanciert ein gesundes composable Datensystem die sich ergänzenden Kräfte von: [13]

• Open-Source-Komponenten zur Förderung von Innovationen
• Standards für Dateninteroperabilität [14]

Struktur eines composable Datensystems

Ein composable Datensystem hat die gleichen drei Kernschichten wie ein traditionelles Datensystem: [15]

1. Eine Benutzeroberfläche
2. Eine Ausführungsmaschine
3. Datenspeicherung [15]

Sie können sich diese Schichten als die "Macher" eines Systems vorstellen. Das sind die Werkzeuge, die wir kennen und lieben, die Logos, die Sie wiedererkennen, und die Dokumente, die die Leute stundenlang durchkämmen. [15]

Aber in einem composable System sind die "Kleber" genauso wichtig oder sogar noch wichtiger. Die Kleber sind die Kernstandards, die die Schichten zusammenhalten: [15]

• Dateninteroperabilität
• Abfrageinteroperabilität
• Systeminteroperabilität [16]

Zusammenfassung und Ausblick

Composable Data Systems sind die Zukunft. [17]

Wegen der BYODB-Bewegung können die Menschen jetzt bessere, schnellere und leistungsfähigere Datensysteme aufbauen, deren Aufbau in der Vergangenheit Jahre gedauert hätte. Dank der BYODB-Bewegung sind composable Systeme nun das, was der Wissenschaftler Stuart Kauffman als "das angrenzende Mögliche" bezeichnet hat. [18]

Composable Data Systems: Sprachinteroperabilität

Die Herausforderung der Sprachwahl

In der Welt der Datenanalyse gibt es viele verschiedene Programmiersprachen und Benutzeroberflächen (UIs). Datenexperten haben oft ihre bevorzugten Sprachen und Tools, die sie für ihre Arbeit verwenden. Diese Vielfalt an Sprachen und UIs kann jedoch zu Problemen führen, wenn verschiedene Teams in einem Unternehmen unterschiedliche Tools verwenden. [1, 2]

• Unterschiedliche Teams verwenden unterschiedliche Tools und Infrastrukturen, um auf unterschiedliche Daten zuzugreifen und unterschiedliche Workloads auszuführen. [1]
• Dies führt zu Silos, in denen die Teams ihre Arbeit duplizieren, um ihr eigenes Silo am Laufen zu halten. [1]
• Die Sprachwahl kann zu großen Gräben führen, insbesondere zwischen den "Datenmenschen", die das System nutzen, und den "Systemmenschen", die es entwerfen und warten. [1]

Der Wunsch nach einer einheitlichen Benutzeroberfläche

Jeder wünscht sich eine einheitliche Benutzeroberfläche, aber jeder möchte sie auch in seiner Sprache, auf seine Weise. [3] Wie können wir also die Kluft zwischen den Programmiersprachen überbrücken? [3]

Anstatt mit Abfragesprachen, SQL-Dialekten und einem Netzwerk von Verbindungen zwischen Benutzeroberflächen und Engines zu jonglieren, bieten Composable Data Systems Standards, um die Kluft zwischen Programmiersprachen zu überbrücken. [3]

Die Rolle von Intermediate Representations (IR)

Composable Data Systems nutzen Intermediate Representations (IRs), um die Sprachinteroperabilität zu ermöglichen. [4]

• Eine IR ist eine spezielle Sprache, die von Maschinen gelesen und geschrieben werden kann, aber nicht von Menschen. [4, 5]
• Die IR fungiert als Übersetzer zwischen den UIs und den Ausführungs-Engines. [4]
• Eine UI wandelt die Abfrage eines Benutzers in eine IR um. [4]
• Eine Ausführungs-Engine wandelt diese IR in den spezifischen Code um, den sie ausführen kann. [4]

Dadurch entfällt die Notwendigkeit, Gewinner (und Verlierer) bei der Sprachauswahl zu bestimmen, und es eröffnet sich die Möglichkeit, Data Engineering anders zu betreiben. [4]

Substrait als IR-Standard

Substrait ist ein offener IR-Standard für UIs und Engines zur Darstellung von Analyseplänen. [6]

• Substrait ist eine sprachübergreifende Spezifikation für Datenberechnungsoperationen, auch bekannt als IR für relationale Algebra. [6]
• Substrait-Pläne konzentrieren sich auf die Definition und Standardisierung von Datenmanipulationsoperationen. [6]

Anstatt ein Netzwerk von Verbindungen zwischen Schnittstellen und Engines zu verwalten, muss ein Composable Data System nur Folgendes festlegen: [7]

• UIs erzeugen letztendlich einen Substrait-Plan. [7]
• Engines können arbeiten, indem sie einen Substrait-Plan akzeptieren. [7]

Vorteile von Composable Data Systems

Composable Data Systems bieten eine Reihe von Vorteilen, darunter: [8, 9]

• Flexibilität: Benutzer können die Programmiersprachen und Tools verwenden, die ihren Bedürfnissen am besten entsprechen. [9]
• Interoperabilität: Verschiedene Komponenten des Systems können nahtlos zusammenarbeiten. [9]
• Skalierbarkeit: Systeme können leicht skaliert werden, um wachsende Datenmengen und Workloads zu bewältigen. [9]
• Kosteneffizienz: Durch die Wiederverwendung von Komponenten und die Vermeidung von Silos können Unternehmen Kosten sparen. [8]

Composable Data Systems: Datenkonnektivität

Von Datenwildwuchs zu Datenkonnektivität

Wenn Sie jemals gefragt wurden: "Wie bekomme ich diese Daten, die ich jetzt brauche?" und Sie mit "Es ist kompliziert und es kommt darauf an" geantwortet haben, dann sind Sie am schlechten Datenort angekommen. Sobald Sie mehr als einen Ort haben, an dem Daten gespeichert sind, können die Komplexität und die Kosten Ihres Systems nur in eine Richtung gehen: nach oben (vorerst). [1] Datenwildwuchs erfordert Lösungen, die über Speicherebenen und Datenbanken hinweg greifen können. Anstatt sich mit kostspieligen Migrationen, langwierigen Umschreibungen und Labyrinthen von Glue-Code herumzuschlagen, verlassen sich Composable Data Systems auf Standards, um den Datenwildwuchs klein erscheinen zu lassen. [1]

Warum ist Datenkonnektivität wichtig?

Die meisten Datenteams tragen dieses Wissen über ihre Daten an verschiedenen Orten mit sich herum. Im besten Fall ist das gesamte Wissen irgendwo festgehalten. Doch selbst wenn es Dokumentationen gibt, fehlen oft die praktischen Anmerkungen wie "funktioniert, aber nur, wenn dies passiert" oder "funktioniert mehr oder weniger, abhängig von der Mondphase". [2] Dokumentation ist oft ein Flickwerk für einen Prozess, der eigentlich einfacher zu benutzen sein sollte. [3] Daher behalten viele Menschen das Wissen einfach im Kopf oder in ihrem persönlichen Datentagebuch, damit ihr jetziges Ich ihrem zukünftigen Ich Zeit und Leid ersparen kann. [3] Es gibt selten eine klare oder einfache Antwort auf die Frage "Wie komme ich jetzt an diese Daten, die ich brauche?" ohne eine mündliche Überlieferung, die mit vielen Sternchen und Entschuldigungen gespickt ist. [3]

Die Kosten des Datenwildwuchses

Auf Systemebene können die Komplexität und die Kosten Ihres Systems nur in eine Richtung gehen: nach *oben* (vorerst), sobald Sie mehr als einen Ort haben, an dem Daten gespeichert sind. [4] Wie summieren sich diese Kosten? [5]

• Viele Datenkopien: Um den Systemwildwuchs zu umgehen, werden die gleichen Daten viele, viele Male kopiert - einige an legitimen Orten und einige an nicht so legitimen Orten. Dies führt zu veralteten, nicht aktuellen Datenkopien mit unterschiedlichem Grad an Legitimität und zu Analysen, die nie die neuesten oder vollständigsten Daten erreichen (ganz zu schweigen von Sicherheits- und Datenschutzrisiken). [5]
• Kostspielige Datenkopien: Wenn man über Daten in Terabyte- oder Petabyte-Größe spricht, die immer wieder kopiert werden, können die Kosten für die Speicherung der Originaldaten plus ihrer Nachkommen sehr teuer werden. [5]
• Kostspielige Komplexität: Mehr Datenquellen bedeuten mehr Wartung, was mehr Personal, Zeit und Ressourcen bedeutet: [5]
  • Mehr Personal wird benötigt, um die gleiche Arbeit zu erledigen, weil die Systeme zu komplex sind. [5]
  • Mehr Zeit wird benötigt, um neue Arbeiten zu erledigen, weil die Anzahl der Werkzeuge und Schritte so groß ist. [5]
  • Mehr Ressourcen werden benötigt, um Dinge zu reparieren: um zu bemerken, wenn Dinge kaputt gehen, herauszufinden, was schief gelaufen ist, und sie zu reparieren. [5]

Den Wildwuchs annehmen

Die kurze Antwort, die viele unserer Teammitglieder auf die harte Tour gelernt haben, ist, dass man den Wildwuchs nicht *beseitigt* - man *nimmt* ihn an, mit all der knorrigen Komplexität, die damit einhergeht. [6] Den Datenwildwuchs anzunehmen bedeutet, dass man die Daten in Ruhe lässt: Man muss seine Daten nicht verschieben, man muss nicht seine gesamte Organisation dazu bringen, eine weitere groß angelegte Datenmigration zu einem neuen System zu versuchen, und man muss definitiv keine "große Zentralisierungs"-Initiative durchführen, um sich auf ein einziges Datensystem zu einigen, das den Zugriff auf alle wichtigen Daten des Unternehmens beinhaltet. [6]

Composable Data Systems

Wie kann man also den Wildwuchs annehmen und trotzdem alle Züge pünktlich fahren lassen, so dass die Datenleute auf die Daten zugreifen können, die sie brauchen, wenn sie sie brauchen? Wir denken, die Antwort ist ein Composable Data System, das auf drei wesentlichen Konnektivitätsstandards aufgebaut ist: [7]

1. Datenformate: Standard-Datenformate können viele der Sternchen rund um die Datenkonnektivität in einem System für Endbenutzer und für die Datensysteme, die diese Benutzer unterstützen, entfernen. [7]
2. Datenzugriff: Konnektivitätsstandards können eine reibungslosere und konsistentere Datenzugriffsschicht für Menschen in allen Bereichen des Unternehmens schaffen, die das Datensystem nutzen, unabhängig von der/den zugrunde liegenden Datenbank(en). [7]
3. Datentransport: Standard-Wire-Protokolle und eine Standardmethode zur Darstellung von Daten auf der Leitung schaffen eine reibungslosere und vorhersehbarere Entwicklererfahrung beim Entwurf von Datensystemen, die skalierbar sind. [7]

Allein oder zusammen lassen diese Konnektivitätsstandards den Wildwuchs für die Endbenutzer kleiner erscheinen und bieten Wege (falls der Geist Sie bewegt), um schließlich Schritte zur Bändigung des Datenwildwuchses in einem Composable System zu unternehmen. [8]

Drei wesentliche Standards für die Datenkonnektivität

Ein Composable Data System kann die Anzahl der verwendeten Datenbanken nicht verringern. Aber es kann die Kompatibilität der verwendeten Datenbanken erhöhen. Kurz gesagt, ein Composable Data System kann den Datenwildwuchs kleiner erscheinen lassen, weil die Leute sich mit Daten verbinden können, egal wo genau sie gespeichert sind. [9] Was bedeutet es, den Wildwuchs kleiner erscheinen zu lassen? Es bedeutet, dass ein Composable System: [9]

• es den Benutzern leichter machen kann, über Datensysteme hinweg zu greifen, um Daten aus verschiedenen Quellen zu kombinieren, größere Fragen mit vollständigeren und aktuelleren Datensätzen zu beantworten und sicher zu sein, dass sie sich mit den benötigten Daten verbinden können - mit weniger Überraschungen, Sternchen und "es kommt darauf an". [9]
• die Anzahl der Oberflächen und Knöpfe reduzieren kann, die Datenleute berühren müssen, um auf Daten zuzugreifen. [9]
• Verschwendung im System reduzieren kann, wie z. B. das Konfetti aus Datenkopien, Glue-Infrastruktur und Notlösungen für die Konnektivität. [9]
• die Wartezeit auf Ergebnisse reduzieren kann, um schneller iterieren zu können. [9]

Standards reduzieren die Datenkonnektivität auf drei wesentliche Komplexitäten: [10]

1. Format des Ergebnissatzes - Datenleute mögen Spaltendaten für die meisten Analyseanwendungsfälle [10]
2. Datenzugriff - Datenleute wollen nahtlosen und schnellen Zugriff [10]
3. Datentransport - Entwickler wollen (a) das Datenformat während der gesamten Datenpipeline gleich halten und (b) das Spaltenformat als Standarddatenformat verwenden (um Himmels willen) [10]

Composable Data Systems: Offene Standards über Silos

Die stille Macht offener Standards

Es kann schwierig sein, ein Verfechter von Standards zu sein. Standards haben kein Marketingbudget. Standards sind auch nicht die Art von Technologie, die die meisten Leute begeistert: Die Begeisterung kommt oft später, wenn man Software sieht, die auf den Standards aufgebaut ist. [1]

Aber genau das macht vielleicht den Reiz von Standards aus. Und in der Geschichte der revolutionären Technologie, die unsere Welt verändert hat, haben Standards tatsächlich eine stille Hauptrolle gespielt. [2]

Beispiel: Das World Wide Web

Offene Standards waren der Schlüssel zum frühen Erfolg des World Wide Web: [2]

• Die Standardisierung rund um HTML ermöglichte es dem Web, sich zu entwickeln. Es war nicht nur die Tatsache, dass es sich um einen Standard handelte, sondern auch die Tatsache, dass er offen und lizenzfrei war. [2]
• Wenn HTML nicht frei gewesen wäre, wenn es eine proprietäre Technologie gewesen wäre, dann hätte es das Geschäft mit dem tatsächlichen Verkauf von HTML und den konkurrierenden Produkten JTML, LTML, MTML gegeben… [2]

Zitat von Tim Berners-Lee, dem Erfinder des World Wide Web: "Ja, wir brauchen Standards, denn das Geld, die Aufregung liegt nicht im Wettbewerb um die Technologie auf dieser Ebene. Die Aufregung liegt in den Unternehmen und den Anwendungen, die man darauf aufbaut." [2]

Standards in Datensystemen

Standards sind auch für die Funktionsweise von Datensystemen entscheidend, aber sie erhalten nicht immer die Anerkennung, die sie im "modernen Datenstapel" verdienen. [3]

Für Ingenieure mag sich die Begeisterung über die Einführung eines neuen Standards wie etwas anfühlen, das man in eine interne Slack-Nachricht schreibt, anstatt es mit dem Rest der Welt zu teilen. Es ist schwer zu vermitteln, wie gut es sich anfühlt, Tausende von Zeilen Klebecode zu entfernen und durch ein paar API-Aufrufe an eine Standardbibliothek zu ersetzen. [3]

Erfolgsgeschichten von Standards

Hier sind zwei Erfolgsgeschichten von Standards, die von Entwicklern geteilt werden: [3]

• Streamlit-Entwicklungsteam (2021) wechselte zu Arrow: "In unserem alten Serialisierungsformat stieg mit zunehmender DataFrame-Größe auch die Serialisierungszeit deutlich an… Vergleichen Sie einfach die Leistung unseres alten Formats mit Arrow. Es ist nicht einmal lustig!" [4]
• Ingenieurteam bei Meta (2023) schrieb in ihrem Artikel "Shared Foundations: Modernizing Meta’s Data Lakehouse": "In den letzten drei Jahren haben wir mit dem Shared Foundations-Projekt einen Generationssprung in der Dateninfrastrukturlandschaft bei Meta vollzogen. Das Ergebnis war: ein modernerer, zusammensetzbarer und konsistenterer Stack, mit weniger Komponenten, reicheren Funktionen, konsistenten Schnittstellen und besserer Leistung für die Benutzer unseres Stacks, insbesondere für maschinelles Lernen und Analytik. Wir haben mehrere große Systeme stillgelegt und Hunderttausende von Codezeilen entfernt, was die Entwicklungsgeschwindigkeit verbessert und den Betriebsaufwand reduziert hat." [5]

Wann sollte man nach Standards suchen?

Zitat der Internationalen Organisation für Normung (ISO): "Wenn die Dinge nicht so funktionieren, wie sie sollten, bedeutet das oft, dass Standards fehlen." [6]

Vorteile von offenen Standards

Im "Composable Data Management System Manifesto" (2023) skizzierte eine Gruppe von Ingenieuren bei Meta, Voltron Data, Databricks und Sundeck die folgenden Vorteile der Entwicklung auf der Grundlage eines Ökosystems offener Standards: [7]

• Schnellere und produktivere Engineering-Teams – Weniger Doppelarbeit bedeutet mehr Zeit für Innovation. [7]
• Engere Innovationszyklen – Gezielte Feature-Entwicklung auf einer kleineren Codebasis bedeutet schnellere Releases. [7]
• Koevolution von Datenbanksoftware und -hardware – Die Vereinheitlichung der Kernschichten bedeutet bessere Leistung und Skalierbarkeit. [7]
• Bessere Benutzererfahrung – Konsistentere Schnittstellen und Semantik bedeuten eine reibungslosere Benutzererfahrung. [7]

Warum fliegen Standards unter dem Radar?

Es wird vermutet, dass diese Vorteile unsichtbar eintreten - kein neuer Algorithmus, kein glänzendes neues Produkt, keine Pressemitteilung, nur Tausende von Zeilen Klebecode gelöscht und Entwickler, die nachts ruhig schlafen können. Aus diesem Grund kann es schwierig sein, einen guten Standard zu finden. [7]

Die Mauer und die Maschine: Beschleunigte Hardware

Die Herausforderung: Die Mauer

Die zunehmende Nutzung von KI/ML-Modellen in Produktionssystemen führt zu einem Engpass in der Datenverarbeitung. Während KI/ML-Engines wie PyTorch und TensorFlow auf GPUs für schnelle Trainingszeiten ausgelegt sind, werden Datenverarbeitungspipelines oft noch auf CPUs ausgeführt, die deutlich langsamer sind. [1]

Dieser Leistungsunterschied zwischen KI/ML-Systemen und Datenverarbeitungssystemen wird als "Die Mauer" bezeichnet. Sie stellt eine wachsende Kluft dar und begrenzt die Effizienz von Datensystemen. [1, 2]

• GPUs bleiben ungenutzt, während sie auf Daten warten. [3, 4]
• Die Optimierung der Systemleistung wird zu einem komplexen Problem, da Engpässe an verschiedenen Stellen auftreten. [5]
• Der Stromverbrauch für Speicher und Datenvorverarbeitung übersteigt den der eigentlichen GPU-Trainer. [6, 7]

Die Lösung: Die Maschine

Um "Die Mauer" zu überwinden, wird ein ganzheitlicher Ansatz benötigt, der die gesamte Systemarchitektur beschleunigt - von der Berechnung über den Speicher bis hin zur Netzwerkverbindung. [8, 9]

Komponenten der Maschine:

• **Ein zusammensetzbarer Motor:** Dieser Motor kann verschiedene Berechnungsbibliotheken verwenden, um mit unterschiedlicher Hardware zu kommunizieren. [9, 10]
• **Beschleunigte Software und Hardware:** Hierbei handelt es sich um Berechnungsbibliotheken, die den Motor auf beschleunigter Hardware ausführen. [9, 11]
• **Ein beschleunigernatives System:** Dieses System ist so konzipiert, dass es die Beschleunigung auf Systemebene von der Berechnung über den Speicher bis hin zur Netzwerkverbindung und zum Speicher unterstützt. [9, 12]

Prinzipien der Maschine

Die Maschine basiert auf drei Kernprinzipien, um eine effiziente Datenverarbeitung zu ermöglichen: [13]

• **Intelligenter arbeiten:** Einsatz von heterogener Berechnung, d.h. die Verwendung unterschiedlicher Hardware für verschiedene Aufgaben. [13, 14]
• **Weniger bewegen:** Gemeinsamer Speicher für alle Komponenten, um Datenkopien zu vermeiden. [13, 15]
• **Schneller bewegen:** Schnelle Datenübertragung durch hohe Speicherbandbreite und beschleunigte Netzwerkverbindungen. [13, 16]

Standards für eine sichere Zukunft

Offene Standards wie Arrow und Substrait spielen eine wichtige Rolle bei der Entwicklung von beschleunigten Datensystemen. [17-19]

• **Arrow** bietet ein standardisiertes In-Memory-Datenformat, das den Datenaustausch zwischen verschiedenen Komponenten vereinfacht. [19]
• **Substrait** definiert eine standardisierte Abfragesprache, die die Portabilität von Abfragen zwischen verschiedenen Engines ermöglicht. [19, 20]

Durch die Verwendung dieser Standards können neue Hardwareplattformen leichter in bestehende Softwaresysteme integriert werden, was die Innovation und Weiterentwicklung von Datensystemen fördert. [20, 21]

Fazit

Die "Mauer" stellt eine Herausforderung für moderne Datensysteme dar, aber die "Maschine", die auf offenen Standards, beschleunigter Hardware und einem ganzheitlichen Systemansatz basiert, bietet eine vielversprechende Lösung. Durch die Überwindung dieser Herausforderungen können wir die Leistungsfähigkeit von KI/ML-Modellen voll ausschöpfen und die Effizienz von Datensystemen steigern. [22]