Der Pandas-Gründer über die Zukunft von KI, Apache Arrow und Software Engineering [YouTube]

• Aus seiner Erfahrung beim Aufbau von Pandas und Apache Arrow heraus sieht er Fachwissen, Urteilsvermögen und Geschmack auch im KI-Zeitalter als entscheidend für den Entwurf leistungsfähiger Datensysteme und Software
• Apache Arrow ist eine universelle In-Memory-Basisschicht für tabellarische Daten, die Übertragung und Verarbeitung zwischen Systemen standardisiert; je mehr Systeme sie übernehmen, desto größer wird auch der Wert der Interoperabilität
• Ausgereifte Systeme wie DuckDB und DataFusion lassen sich nur schwer durch durchschnittlich von LLMs erzeugten Code ersetzen; zur Wettbewerbsfähigkeit von Open Source gehören nicht nur Code, sondern auch über lange Zeit aufgebautes Vertrauen und ein Qualitätsnachweis
• KI-Tools steigern die Produktivität von Entwicklern mit hoher Eigeninitiative stark, aber wenn unklar ist, was gebaut werden soll, häufen sich durchschnittliche Lösungen und Code an, sodass selbst Agenten nur schwer wieder herausfinden — es entsteht ein agentic tarpit
• Künftig werden statt Sprachsyntax und Hand-Coding eher Architektur, Problemdefinition, Kommunikation und die Fähigkeit zur Bewertung von Ergebnissen wichtig, und Organisationen müssen auch die gestiegene Entscheidungslast und Token-Kosten steuern

---

Von Pandas zu KI-Entwicklertools

• Wes McKinney entwickelte vor etwa 18 Jahren Python Pandas und veröffentlichte es 2010 als Open-Source-Projekt
• Sein Buch Python for Data Analysis wurde im Python-Data-Science-Ökosystem breit genutzt; anschließend arbeitete er daran, Unternehmen und Geschäftsmodelle aufzubauen, die eine kontinuierliche Open-Source-Entwicklung tragen können
• Bei Cloudera startete er gemeinsam mit mehreren Open-Source-Entwicklern Apache Arrow und war auch am Arrow-Ökosystem sowie an der Entwicklung von Parquet beteiligt
• Aus Ursa Computing wurde später Voltron Data, und auch nach der Neuordnung von Voltron Data blieb die Verbindung zu Posit bestehen
• Derzeit hat er ein neues Unternehmen gegründet, das sich statt auf Data-Science-Bibliotheken auf KI-Entwicklertools und Infrastruktur konzentriert und untersucht, wie sich mit KI die Produktivität im Software Engineering steigern lässt

Wie sich Apache Arrow verbreitete

• Arrow ist eine universelle In-Memory-Datenschicht für tabellarische Daten, die Verarbeitung im Speicher und Datentransfer zwischen Systemen beschleunigt und die Interoperabilität erhöht
• Anfangs gab es nur wenige Nutzer und konsumierende Systeme, daher war der Anreiz zur Einführung gering, und es gab Skepsis, ob sich mehrere Open-Source-Communities überhaupt auf ein gemeinsames Format einigen würden
  • Wer einen neuen Integrationsstandard schafft, landet leicht beim XKCD-Problem, dass aus 13 Standards plötzlich 14 werden
  • Arrow wuchs, indem es in einer Situation ohne viele glaubwürdige Alternativen für dasselbe Problem eine stabile Implementierung bereitstellte und auf Adoption wartete
• Die Technologie selbst hat sich in den letzten 5 bis 6 Jahren nicht stark verändert, doch mit der Übernahme durch mehr Systeme zeigt sich ein Wertzuwachs, der Netzwerkeffekten nahekommt
• DataFusion erlaubt es, eine Query Engine nicht von Grund auf neu zu bauen, sondern passend zum Produkt zu erweitern; schätzungsweise 30 bis 40 Unternehmen nutzen es als interne Komponente
  • Arroyo, das eine Streaming-Data-Engine entwickelte, wurde von Cloudflare übernommen; danach wurden Arrow und DataFusion Teil von Cloudflares Streaming-Dateninfrastruktur
  • DataFusion Comet wird zur Beschleunigung von Spark eingesetzt

Systemsoftware, die sich nicht leicht durch KI ersetzen lässt

• DataFusion und DuckDB sind Projekte der Art, für die sich ein Ersatz nicht schnell per Vibe Coding bauen lässt
• LLMs neigen stark dazu, vorhandenen Code und bestehende Ansätze zu mitteln, weshalb sie in absehbarer Zeit kaum Systeme hervorbringen, die so fein abgestimmt sind wie moderne Query Engines
• Solche Projekte ähneln eher einer von Hand montierten präzisen Schweizer Uhr als einem spritzgegossenen Plastikspielzeug
  • Das heißt nicht, dass KI so etwas niemals bauen kann, aber derzeit ist die Ersetzbarkeit gering
• Der Wert eines Open-Source-Projekts entsteht nicht nur aus der Implementierung, sondern auch aus dem über lange Zeit aufgebauten Vertrauen der Community
  • dem Vertrauen, dass Maintainer die Interessen der Gemeinschaft berücksichtigen
  • der Erwartung, Supply-Chain-Angriffe abzuwehren und schwerwiegende Bugs zu beheben
  • einer Historie, konsistent gut entworfene und verlässliche Software geliefert zu haben
• McKinney ist seit 2013 nicht mehr tief in die Entwicklung von Pandas eingebunden; heute wird das Projekt von einer großen Gruppe von Entwicklern gepflegt
  • Deshalb sollten Dank und Unterstützung seiner Ansicht nach den tatsächlichen Maintainern zugutekommen
• Auch wenn KI pro Tag 10.000 Zeilen Code erzeugen kann, lassen sich Ergebnisse, die den früher aufgebauten Qualitätsmaßstäben nicht genügen, nicht einfach veröffentlichen; wichtiger als die Generierungsmenge werden daher Review und Qualitätssicherung

Von Spielen und Mathematik zum Programmieren

• Ende der 1990er verfiel er GoldenEye 007 auf dem Nintendo 64 und beteiligte sich ab Ende 1997 oder Anfang 1998 mit einer Fan-Website auf GeoCities an der Speedrun-Community
• Damals pflegte er die Website noch von Hand, sah aber bei Kisman, der mit einem C++-Programm die Aktualisierung der Seite automatisierte, erstmals die Wirkung von Automatisierung, die exzellente Programmierer schaffen
• In der Highschool interessierte er sich für Mathematikwettbewerbe und den Computereinsatz; am MIT spürte er unter Kommilitonen, die schon seit ihrer Kindheit programmierten, einen großen Fähigkeitsunterschied
• Während seines Studiums der reinen Mathematik befasste er sich teilweise mit theoretischer Informatik wie Komplexität und Algorithmen, empfand aber wegen negativer Erfahrungen mit Java zunächst wenig Interesse am Programmieren selbst
• Erst als er Programmierung als Werkzeug zur Problemlösung und zur Steigerung der persönlichen Produktivität begriff, begann er sich ernsthaft darauf einzulassen

Pandas entstand aus Finanzforschung

• 2007 trat er mit 22 Jahren in einen quantitativen Hedgefonds ein und stellte fest, dass sich entgegen seiner Erwartung einer formelzentrierten Forschung vieles auf Excel-Tabellen und Handarbeit stützte
• MATLAB und R wurden ebenfalls genutzt, waren aber eher Hilfsmittel; um MATLAB-Code auf Servern bereitzustellen, waren pro Server teure Lizenzen nötig
• Für Arbeitsabläufe von der Forschung bis zur Produktion hielt er daher eine Open-Source-Sprache für nötig, die sich zum Aufbau von Systemen eignet
• Auf Empfehlung eines Kollegen begann er Anfang 2008 mit Python und wissenschaftlichen Rechenbibliotheken; beim Neuaufbau bestehender Forschungstools in Python entstand die frühe Form von Pandas
• Das Entwickeln produktivitätssteigernder Werkzeuge und das Beobachten, wie andere damit effizienter arbeiten, fühlte sich für ihn ähnlich fesselnd an wie Speedrunning in Spielen

Einfache User Experience und interne technische Schulden

• McKinney legt mehr Wert auf einfache und konsistente Tools, die auch andere verstehen und verwenden können, als auf komplexe KI-Werkzeuge, die nur auf eine einzelne Person zugeschnitten sind
• Ein übermäßig personalisierter Werkzeugkasten kann strukturell so komplex werden, dass außer seinem Erbauer niemand ihn mehr navigieren kann — wie ein Winchester Mystery House
• Die frühe Implementierung von Pandas konzentrierte sich weniger auf die interne Architektur als auf eine API und Nutzbarkeit, die Menschen leicht verstehen und schreiben konnten
• Die Unordnung der internen Struktur hinterließ lange Wartungslasten, doch der Erfolg von Pandas zeigt, dass Software auch ohne perfekte Architektur sehr erfolgreich sein kann

Die Rolle und Grenzen von NumPy

• NumPy entstand, als Travis Oliphant etwa 2005 bis 2006 Numeric, die von Jim Hugunin Mitte der 1990er begonnene Bibliothek für mehrdimensionale Arrays, mit der Numarray-Linie zusammenführte, die Funktionen für große Arrays wie Memory Mapping ergänzte
• Da Matplotlib, SciPy sowie Statistik- und lineare Regressionswerkzeuge damals um NumPy-Arrays herum aufgebaut waren, war NumPy-Kompatibilität Pflicht, wenn ein neues Datentool am Ökosystem teilnehmen wollte
• NumPy war auf große mehrdimensionale Arrays aus Fließkomma- und Ganzzahlen fokussiert und nicht als Grundlage für Datenbanken oder nichtnumerische Daten entworfen
• Frühes Pandas baute auf NumPy auf und umging die Einschränkungen bei nichtnumerischen Daten
  • Werte, die keine Zahlen oder Booleans waren, wurden als Python-Objekte in NumPy-Arrays gespeichert
  • Bei String-Daten führte das zu Objekt-Overhead und indirekten Referenzen und war daher ineffizient
• Diese Grenzen wurden später zu einer Motivation, mit Arrow eine alternative In-Memory-Basis für Systeme wie Pandas zu schaffen

Das Wachstum des Python-Data-Science-Ökosystems

• Mehrere venturefinanzierte Unternehmen warben damit, dass jedes Unternehmen eine Dateninfrastruktur wie Google aufbauen müsse, wodurch enorme Investitionen in Big-Data-Open-Source-Projekte flossen
• Nicht jedes Unternehmen brauchte Infrastruktur in diesem Maßstab, aber ohne dieses Geld wäre es vermutlich deutlich schwieriger gewesen, die für Arrow nötigen Entwickler zu versammeln
• Die Branche konkurrierte damals darum, was Data Science und Data Scientists eigentlich bedeuten und wo man Menschen findet, die Business-, Statistik- und Softwarefähigkeiten zugleich mitbringen
• Python machte Data Science auch für Menschen zugänglich, die wenig Programmiererfahrung, aber Statistikkenntnisse hatten
  • Wer Python for Data Analysis und Werkzeuge wie scikit-learn lernte, konnte innerhalb von 2 bis 3 Wochen mit nützlichen Analysen für die Arbeit beginnen
  • Hätte man zuerst eine Sprache wie Scala lernen müssen, wären Einstiegshürde und Lernzeit wohl deutlich höher gewesen

Veröffentlichung von Pandas und der Aufbau der Arrow-Organisation

• Die Entscheidung, Pandas zu veröffentlichen, fiel an Silvester 2009; mit dem ersten PyCon-Vortrag im Februar 2010 entstand die eigentliche Verbindung zur Python-Community
• 2010 begann McKinney in Duke ein Promotionsstudium in Statistik, legte es aber auf Eis, als er das Interesse von Finanzfirmen an Python-Datentools und das Wachstumspotenzial von Pandas sah
• Pandas 0.1 hatte damals nur eingeschränkte Funktionalität und unterstützte nicht einmal alle Join-Arten; um sich auf das Wachstum des Projekts zu konzentrieren, verließ er die Graduiertenschule
• Nach Überlegungen zu einem Fintech-Geschäft folgten das Schreiben von Python for Data Analysis und die Gründung eines BI-Startups; 2013 kam er zu Cloudera, weil er den Wettbewerb mit Looker im BI-Markt für schwer gewinnbar hielt
• Bei Cloudera knüpfte er Kontakte zu den Entwicklern von Impala und später zu vielen Ingenieuren, die danach bei Iceberg, Databricks und anderen aktiv waren; diese Erfahrung wurde zur Grundlage seiner späteren Laufbahn
• Das Arrow-Projekt begann Anfang 2016 bei Cloudera, doch im Enterprise-Software-Markt war es damals schwer, Budget für ein dediziertes Team für experimentelle Technologie zu bekommen
• Von 2016 bis 2018 setzte er Arrow in Finanzunternehmen in realen Systemen ein, beschleunigte Datenverarbeitungs-Workloads und verbesserte Parquet
• 2018 wollten mehrere Unternehmen Geld für die Arrow-Entwicklung bereitstellen, doch aufgrund der Regeln des Finanzunternehmens war externes Funding schwer zu verwalten; deshalb gründete er im April eine unabhängige Organisation, die Unternehmenssponsoring annehmen konnte
  • Etwa sechs Sponsoren beteiligten sich, darunter Hardware-Unternehmen wie Nvidia und Finanzfirmen
  • Es wurde ein Entwicklerteam von rund acht Personen aufgebaut
• Nachdem sich die kommerzielle Chance bestätigt hatte, erfolgte während der COVID-19-Zeit 2020 der Übergang zu Ursa Computing

Weiterhin offene Probleme im Data Engineering

• Auch heute löst der Datenbereich immer wieder dieselben Probleme: Daten von A nach B bewegen, Formate umwandeln, in den Speicher laden und Queries sowie Transformationen effizient ausführen
• Pandas ist zu einer Grundlage geworden, die weit mehr Datenflüsse in Unternehmen trägt als erwartet; möglicherweise erzeugen LLMs heute mehr Pandas-Code als Menschen früher geschrieben haben
• DuckDB ist ein so leistungsfähiges Werkzeug, dass es sich Entwickler vor 20 Jahren kaum hätten vorstellen können
  • Es lässt sich kostenlos installieren und in verschiedensten Umgebungen ausführen
  • Es kann auch auf Telefonen und im Webbrowser laufen
  • Es bietet leistungsfähige Analytik auf einer einzelnen Maschine ohne komplizierte Installation
• Durch langjährige Reibungsverluste und Versuch-und-Irrtum wurde die Notwendigkeit von Technologien wie DuckDB und Arrow deutlich; viele Lösungen einschließlich Parquet wurden von Techniken beeinflusst, die große Internetunternehmen wie Google zur Senkung von Kosten und Zeit entwickelt haben
• Parquet ist nicht das bestmögliche Format, aber im Vergleich zur Vergangenheit stark verbessert und wird von fast allen Systemen unterstützt
  • Auch wenn es spezialisierte Alternativen wie Vortex und Lance gibt, wird es dank hinreichend guter Kompatibilität weiter genutzt
• Während KI die Aufmerksamkeit der Branche auf sich zieht, ist Data Engineering weniger im Fokus; selbst wenn Databricks eine neue Data Engine ankündigt, erhält das weniger Aufmerksamkeit als früher
• Umgekehrt haben Entwickler von Datentools dadurch mehr Spielraum, sich ohne Hype auf technische Reife zu konzentrieren, und können KI für repetitive, unangenehme Aufgaben wie das Schreiben von Tests einsetzen

Konvergenz hin zur Datenbanktechnik

• Die wichtigste Lehre aus der Big-Data-Ära lautet, dass man Ergebnisse aus Forschung und Konferenzen der Datenbankwelt früher hätte nutzen sollen
• Wichtig ist ein Ansatz, bei dem man Datenbankforschung aus Institutionen wie TU Munich, CWI, MIT, CMU und Berkeley liest, implementiert und gemeinsam weiterentwickelt
• In der Zeit von NoSQL und nichtrelationalen Speichersystemen erzeugten skalierbare Systeme oft so viel Overhead, dass sie langsamer waren als gut gebaute Implementierungen auf einer einzelnen Maschine mit einem einzelnen Thread
• Die Studie Scalability! But at what COST? mit Beteiligung von Frank McSherry, Michael Isard und anderen behandelt genau diese Kosten der Skalierbarkeit
• Der moderne Data Stack konvergiert wieder auf Datenbanktechnik und spaltenorientierte Verarbeitung
  • Polars, Daft und DataFusion nutzen Arrow
  • Die neue Engine von dbt verwendet ADBC
  • Databricks Photon setzt unabhängig von der Nutzung von Arrow auf eine spaltenorientierte Struktur
• Da wichtige Systeme bei ähnlichen Architekturen und Ansätzen zusammenlaufen, wird inzwischen weniger die Kernverarbeitungsmethode zum entscheidenden Thema als vielmehr die Frage, wie einfach sich Software in der Praxis tatsächlich nutzen lässt

Von Hadoop zu DuckDB: bessere Usability

• In der Hadoop-Ära konnte es vorkommen, dass man wegen Java, XML-Konfigurationsdateien und zahlloser Tuning-Parameter fast zwei Tage mit dem Setup verbrachte, bevor man überhaupt mit der eigentlichen Arbeit begann
• Spark war ein großer Fortschritt, weil sich ein Word Count in einer Zeile schreiben ließ, aber man musste immer noch Infrastruktur und Konfigurationsdateien vorbereiten
• Die Art, wie DuckDB installiert und ausgeführt wird, ist ein Usability-Modell dafür, wie einfach Datensysteme werden können
• Auch verteilte Systeme sollten vernünftige Defaults und sofort lauffähige Einstellungen liefern, um die operative Komplexität zu senken
• DuckDB erweitert sich zudem in den Client-Server-Bereich und arbeitet eng mit MotherDuck zusammen

Eine multimodale Datenschicht für generative KI

• Bestehende Lakehouses sind auf tabellarische Daten und Parquet ausgerichtet, doch für generative KI sowie Training und Fine-Tuning großer Modelle werden Bilder, Videos, Texte, Dokumente und Logs gemeinsam benötigt
• Das von LanceDB adressierte multimodale Data Lakehouse ist ein reales Enterprise-Problem
• Wenn aus großen Mengen unstrukturierter Daten Embeddings erzeugt werden, verbraucht das Strom und GPU-Zeit; dadurch erhalten schon die erzeugten Embeddings selbst einen ökonomischen Wert entsprechend den Rechenkosten
• In Produktionsumgebungen braucht man Datenspeicher, die Rohdaten und generierte Ergebnisse stabil speichern, verwalten und verarbeiten können
• Wenn jedes Unternehmen einen eigenen multimodalen Speicher baut, wiederholen sich Bugs, Datenverluste und Performance-Probleme; effizienter ist es, wenn spezialisierte Softwareanbieter gemeinsame Lösungen bereitstellen
• Auch wenn man Iceberg-Tabellen selbst betreiben kann, reduziert es die operative Komplexität, das Management Anbietern wie Databricks, Snowflake oder AWS zu überlassen; dieselbe Logik gilt für multimodale Daten in der generativen KI
• Im Markt für generative KI-Daten bleibt Raum für unterschiedliche Schichten — von Dokumenten-Vektorsuche und hoher QPS-Verarbeitung bis hin zum Management des Datenlebenszyklus

Wettbewerbsfähigkeit von Entwicklern im KI-Zeitalter

• McKinney fragte sich zeitweise selbst, ob er als Software Engineer noch Zukunft habe, kam aber zu dem Schluss, dass KI Menschen künftig deutlicher nach ihrem Maß an Eigeninitiative trennt
• Menschen mit hoher Eigeninitiative können durch KI enorme Produktivitätshebel gewinnen, weil sie sorgfältig überlegen, was sie bauen wollen, und auf Basis von Geschmack und Urteilsvermögen gute Ergebnisse erkennen
• LLMs liefern für die meisten Probleme einen durchschnittlichen und soliden B+-Ansatz, erzeugen aber nicht stellvertretend für den Nutzer Erfahrung, Geschmack oder Urteilsvermögen
• Wenn ohne gutes Urteilsvermögen immer mehr generierter Code hinzugefügt wird, entsteht ein komplizierter Sumpf, in dem selbst Agenten unter Kontext und Struktur zusammenbrechen und kaum weiterarbeiten können
• Früher wurden technische Fähigkeiten und Urteilsvermögen oft durch direkte Implementierung gemeinsam aufgebaut; wenn die Zeit für Hand-Coding sinkt, muss das Verständnis für Systeme und Design künftig gezielt separat entwickelt werden

Was man im KI-Zeitalter lernen sollte

• Neue Entwickler sollten nicht nur Python- oder Java-Syntax lernen, sondern Software Design und Architektur sowie den Aufbau von Datensystemen studieren
• Im Data Engineering sollte man verstehen, wie unterschiedliche Systeme wie Lambda-Architektur und Kappa-Architektur funktionieren und für welche Probleme sie geeignet sind
• Man muss Agenten das gewünschte Ergebnis präzise vermitteln und erkennen können, wenn sie in die falsche Richtung laufen
• Wenn ein Nutzer nicht beurteilen kann, ob A oder B besser ist, kann auch ein Agent die richtige Wahl nicht zuverlässig stellvertretend garantieren
• Software Engineers, Data Engineers und Data Scientists werden wahrscheinlich mehr Zeit für Problemdefinition und Kommunikation als für das Schreiben von Code aufwenden
• Wer nicht erklären kann, was er will, wird auch mit KI nicht das gewünschte Ergebnis erhalten; allein das Hinzufügen von KI in einer Organisation steigert Produktivität und wirtschaftliche Resultate nicht automatisch
• Wer wenig Erfahrung und Urteilsvermögen hat, kann mit KI eher zur slop cannon werden, die massenhaft technische Schulden produziert, die andere später beseitigen müssen

Mehr Entscheidungen und KI-Investitionen in Organisationen

• In den kommenden 2 bis 5 Jahren könnten Entwicklerrekrutierung, technische Interviews und Rollenabgrenzungen verwirrend und schnelllebig werden
• Früher erzeugten Teams über Meetings, Sprint-Planung und Planning Poker ein gemeinsames Vertrauen in die Arbeit und verteilten dann die Umsetzung
• Heute wird dieser bisherige agile Planungsprozess in den Planungsmodus von Claude komprimiert, sodass ein einzelner Entwickler allein eine große Zahl von Entscheidungen treffen muss
• Wer pro Tag zehnmal so viele Entscheidungen wie früher treffen muss, kann an Entscheidungserschöpfung und Mehrdeutigkeit scheitern
• Wer schnell urteilt und einen effizienten Weg festlegt, kann die Produktivität von KI nutzen; wer aber nicht weiß, was zu tun ist, bekommt dieses Problem von KI nicht abgenommen
• Unternehmen zahlen womöglich viel Geld an Anthropic und OpenAI und können den Return on Investment ihrer KI-Ausgaben trotzdem nur schwer nachweisen
  • Neben einigen positiven Ergebnissen entstehen auch Verschwendung, minderwertige Artefakte und die Kosten, diese wieder aufzuräumen
  • Anbieter von KI-Modellen verdienen, solange der Verkauf von Tokens weiterläuft; Kundenunternehmen könnten deshalb strengere Token-Budgets einführen

Open-Weight-Modelle und die Ökonomie von Tokens

• McKinney hat das Open-Weight-Modell aus China, GLM 5.2, auf physischer Infrastruktur betrieben und die Ergebnisse positiv bewertet
• GLM 5.2 ist kein kleines Modell; für einen ordentlichen Betrieb werden etwa acht B200-GPUs benötigt
  • Der Preis einer einzelnen B200 wird auf etwa 30.000 bis 50.000 US-Dollar geschätzt
  • Die gesamten Hardwarekosten könnten damit bei etwa 250.000 bis 400.000 US-Dollar liegen
• Langfristig hofft er, dass Open-Weight-Modelle qualitativ besser werden und Hardware günstiger wird, sodass man nicht fortlaufend externe KI-Unternehmen bezahlen muss, sondern nur noch die Stromkosten eines eigenen Servers trägt
• Rechnet man die in den letzten 30 Tagen verbrauchten Tokens zum API-Listenpreis, käme man auf rund 37.000 US-Dollar, tatsächlich zahlte er dem Modellanbieter aber deutlich weniger
• In den aktuellen Token-Preisen könnten erhebliche Subventionen stecken, und welche Kostenstruktur langfristig tragfähig ist, bleibt unklar
• Auch die Einführungsrate von KI ist nicht so gleichmäßig, wie es die Aufmerksamkeit der Branche vermuten lässt; einige Unternehmen befinden sich noch in einem langen Nachlauf, in dem das Thema nur auf Ebene von Vorstand und CTO diskutiert wird, ohne dass die praktische Einführung begonnen hat