Home Screen
KONTAKT
EN^

Arrow verantwortungsvoll begleiten: Technischer Fortschritt und Resilienz der Community

byAlex Scammon|Jun. 03, 2026

Apache Arrow ist zu einer grundlegenden Infrastruktur für den modernen Data Stack geworden. Viele dieser Workflows (von Finanzsystemen über Machine-Learning-Pipelines bis hin zu GPU-beschleunigten Analysen) bewegen Daten durch Arrows spaltenorientiertes Format, ohne dass die Engineers, die davon abhängen, viel darüber nachdenken, was es stabil hält. Bei so vielen Daten, die so zuverlässig durch Arrow fließen, lag die Annahme nahe, dass diese Infrastruktur einfach verfügbar sein würde, um die Workloads ohne Eingreifen zu unterstützen.

2025 wurde diese Annahme auf die Probe gestellt.

Als Voltron Data den Betrieb einstellte, verschwand damit ein erheblicher Teil der Personen, die in Vollzeit dafür bezahlt wurden, Arrow stabil zu halten. Zu ihren Aufgaben gehörten die Pflege von CI, das Reviewen von PRs, Performance-Benchmarks, die Erstellung von Releases, die Triage von Issues und die unspektakuläre Arbeit, auf die Open-Source-Projekte angewiesen sind. Der Pool aktiver Mitwirkender sank von 94 auf 59. Der Contributor Absence Factor (die Zahl der Personen, deren Abwesenheit die Hälfte aller gemergten PRs wegfallen ließe) sank von 11 auf 5. Die Benchmarking-Infrastruktur, die Performance-Regressionen über jeden Commit hinweg verfolgt, hatte kein Zuhause mehr.

Keine einzelne Kennzahl fasst die Gesundheit einer Community perfekt zusammen, aber die Zahl der pro Monat geschlossenen Issues im Arrow-Projekt zeigte einen beunruhigenden Trend:

Quelle: https://github.com/arrow-maintenance/arrowdash/tree/main/data/cache

Solange Voltron weiterhin Open-Source-Maintainer für Arrow beschäftigte, blieb die Zahl der aktiven Contributors bei etwa 50 pro Monat. Jetzt liegt sie bei etwa 30.

Die Arctos Alliance wurde gegründet, um genau hier anzusetzen. Sie ist eine kleine Gruppe von Mitwirkenden, die meist in Teilzeit und mit begrenzter Finanzierung arbeiten und eingesprungen sind, um die Lage zu stabilisieren. Sie migrieren die Infrastruktur, bauen den Issue-Backlog ab, arbeiten neue Maintainer ein und liefern weiterhin wichtige technische Arbeit für das Ökosystem.

Als kleines Team können wir nicht alle einzelnen Mitwirkenden ersetzen, die früher für Voltron gearbeitet haben. Trotzdem hat unser kleines Team einen überproportionalen Einfluss auf den Issue-Durchsatz im Arrow-Projekt. Ein kleines Beispiel, an dem das deutlich wird:

Quelle: https://github.com/arrow-maintenance/arrowdash/tree/main/data/cache

Dieser Beitrag beschreibt, was die Arctos Alliance getan hat. Er ist auch eine ehrliche Bestandsaufnahme der aktuellen Lage: Die Community ist gesünder als zuvor, aber sie ist fragil und hängt von einer sehr kleinen Zahl von Menschen ab. Wenn Sie auf Arrow aufbauen (und wenn Sie das lesen, ist die Wahrscheinlichkeit recht hoch, dass Sie das tun), sollten Sie das verstehen.

Technischer Fortschritt

Das konkreteste Maß für die Gesundheit eines Projekts ist, ob es mit der Hardware und den Workloads Schritt hält, für die es da ist. Deshalb hilft die Arctos Alliance Arrow dabei, mit einigen extrem wichtigen technischen Verbesserungen Schritt zu halten:

Float16-Unterstützung

Es wird daran gearbeitet, native Unterstützung für float16 (Gleitkomma mit halber Genauigkeit) in der C++-Implementierung hinzuzufügen. Gleitkommazahlen mit halber Genauigkeit sind der De-facto-Standard für Inferenz im großen Maßstab. Sie halbieren den Speicherbedarf gegenüber float32 ungefähr, was enorm wichtig ist, wenn Tensoren durch Pipelines bewegt werden, die an einem Ende oder an beiden Enden mit Arrow arbeiten. Aktuell wird daran gearbeitet, hardwarebeschleunigte float16-Operationen zu ermöglichen und Half-Float-Tensoren in Gleichheitsvergleichen zu unterstützen. Damit lassen sich Modellgewichte und Aktivierungen bewegen, ohne das Arrow-Ökosystem zu verlassen. Das schließt eine Lücke, die alle zu schätzen wissen, die ernsthaft mit ML arbeiten.

Relevante Beispiele:
[1] HalfFloatBuilder akzeptiert Float16
[2] Logischer Typ float16 in Parquet

Vektortypen

Die Arbeit an richtiger Unterstützung für Vektortypen kommt voran. Sie ist noch nicht abgeschlossen, aber die Richtung ist klar. Wer mit GPU-beschleunigten Analysen oder Embedding-lastigen Workloads arbeitet, braucht eine Möglichkeit, hochdimensionale Vektoren nativ in Arrow darzustellen, ohne Workarounds. Diese Arbeit wird Arrow-Nutzer in dieser Welt vollwertig unterstützen.

Relevante Beispiele:
[1] Umbrella-Issue zu Tensoren mit variabler Form
[2] VariableShapeTensor-Implementierung
[3] Apache Arrow Tensor Arrays: ein Ansatz zum Speichern von Tensordaten (FOSDEM 2025)

Parquet-Verschlüsselung

Parquet Modular Encryption — der in der Spezifikation definierte Mechanismus zum Verschlüsseln einzelner Spalten und Footer — fehlte lange in der Rust-Implementierung. Die Arctos Alliance hat einen kontinuierlichen Aufwand vorangetrieben, um dies in arrow-rs Ende zu Ende auszubauen, einschließlich Schreibunterstützung, Umgang mit Plaintext-Footern, mehrthreadigem Schreiben und Schlüsselverwaltung. Arctos-Mitwirkende haben außerdem über mehrere Arrow-Releases hinweg eine Reihe von Verschlüsselungsfixes und Verbesserungen in der C++-Implementierung vorangebracht.

Relevante Beispiele:
[1] PR zu Content-Defined Chunking
[2] Logischer Typ FIXED_SIZE_LIST
[3] Flatbuf-Schema-PR
[4] Verbesserungen an der Verschlüsselung in C++
[5] Unterstützung für Modular Encryption in Rust
[6] Mehrthreadiges Schreiben verschlüsselter Parquet-Dateien in Rust
[7] Stand von Parquet 2025: Struktur, Optimierungen und aktuelle Innovationen (PyData Paris)

Modulare C++-Compute-Kernels

Viele Compute-Kernels wurden aus dem integrierten Compute-Modul in eine separate, optionale C++-Bibliothek verschoben. Das reduziert die Distributionsgröße für Nutzer, die nicht den vollen Compute-Funktionsumfang benötigen, und verbessert die Modularität der C++-Bibliothek insgesamt. Das ist wichtig für alle, die Arrow in eingeschränkten Umgebungen einbetten oder für die Distribution paketieren.

Relevante Beispiele:
[1] [C++] Nicht zum Kern gehörende Compute-Kernels in separate Shared Library verschieben

PyArrow-Typannotationen

Eine umfassende Arbeit an Typannotationen für PyArrow begann bei den EuroPython 2025 Sprints und ist zu einem erheblichen Arbeitsstrang angewachsen, der zentrale Datenstrukturen, das Compute-Modul, Dateisysteme, I/O, IPC, Parquet und Flight abdeckt. Das senkt die Einstiegshürde für Python-Entwickler und verbessert die IDE-Unterstützung auf breiter Front — eine Verbesserung der Alltagstauglichkeit, die mit der Zeit stärker wirkt, wenn mehr Teams Arrow in Python-lastigen Stacks einsetzen.

Relevante Beispiele:
[1] Unterstützung für Type Checking
[2] Ein neues Zuhause für pyarrow-stubs?
[3] Teilen hilft: Effizienter Datenaustausch mit pyarrow (EuroPython 2025)

Die Trendwende bei offenen Issues

Eine der weniger glanzvollen, aber folgenreicheren Aufgaben, die die Arctos Alliance im vergangenen Jahr übernommen hat, war es, einen Trend umzukehren, der still das Vertrauen der Mitwirkenden untergrub: das unkontrollierte Wachstum ungelöster Issues.

10 Jahre ununterbrochenes Wachstum bei offenen Issues
Quelle: https://github.com/arrow-maintenance/arrowdash/tree/main/data/cache

Vor einem Jahr stieg die Zahl der offenen Issues ohne erkennbare Obergrenze. Ungebremst erzeugt so ein Backlog eine schleichende Krise: Nutzer und Mitwirkende melden Bugs und hören nichts, Maintainer werden von Triage überrollt, statt zu entwickeln, und das Projekt bekommt den Ruf, nicht zu reagieren. Nic Crane (thisisnic) leitete eine kontinuierliche Arbeit, um veraltete Issues durchzugehen und solche sichtbar zu machen, die übersehen oder vergessen worden waren:

Der Wendepunkt durch die Arctos Alliance: Höchststand 4,335, jetzt unter 2,400.
Quelle: https://github.com/arrow-maintenance/arrowdash/tree/main/data/cache

Das Arrow Maintainer Dashboard zeigt die Zahl der offenen Issues inzwischen unter 2,400 — eine Reduktion um fast 2000 offene Issues und eine Rückkehr auf das Niveau von 2022. Das ist nicht nur Kosmetik. Es zeigt eine echte Veränderung der Gesundheit des Projekts und der Fähigkeit der Community, bei den tatsächlichen technischen Herausforderungen voranzukommen. Trotz der deutlichen Verbesserung müssen 2,400 Issues weiter bewertet und bearbeitet werden, und nur kontinuierliche Arbeit wird den Backlog abbauen. Genau diese Art von Arbeit ist der Zweck der Arctos Alliance, und genau deshalb ist anhaltende Unterstützung wichtig.

Gute Engineering-Arbeit durch den Übergang bewahren

Als Voltron Data 2025 den Betrieb einstellte, stand die Arrow-Community vor dem realen Risiko, Engineering-Arbeit zu verlieren, für die es kein klares Zuhause gab. Zu den gefährdeten Assets gehörte eine Suite von Benchmarking-Infrastruktur, auf die das Projekt angewiesen ist, um Performance über Commits hinweg zu verfolgen und Regressionen zu markieren, bevor sie ausgeliefert werden.

Rok Mihevc (rok) leitete die Migration dieser Infrastruktur in ein von Arrow verwaltetes AWS-Konto. Die Arctos Alliance hostet jetzt den vollständigen Benchmarking-Stack — einschließlich arrow-benchmarks-ci, arrowbench und des benchmarks-Repositorys — sowie weitere wichtige Entwicklerwerkzeuge wie Crossbow (das Aufgabenautomatisierungssystem für Arrows Release- und CI-Pipeline), Ursabot, substrait-fiddle und GPU-Build-Infrastruktur. Benchmark-Ergebnisse sowie das Live-Crossbow-Dashboard werden jetzt auf conbench.arrow-dev.org veröffentlicht.

Diese Art von Kontinuitätsarbeit wird trotz ihrer Bedeutung selten gewürdigt. Die Alternative hätte die Community spürbar zurückgeworfen, und die Werkzeuge liegen nun stabil in Community-kontrollierten Händen.

Die Rolle der Arctos Alliance in den Zahlen

Die Nachhaltigkeitsanalyse gibt einen detaillierteren Blick darauf, wo der Beitrag von Arctos tatsächlich liegt. Zwei Kennzahlen sollte man gemeinsam verstehen.

  1. Der Contributor Absence Factor (CAF), eine Standardmetrik von CHAOSS, misst die Konzentration der PR-Autorenschaft: genauer gesagt die Mindestzahl von Contributors, deren Abwesenheit 50% aller in einem bestimmten Quartal gemergten PRs wegfallen ließe. Für Apache Arrow liegt diese Zahl derzeit bei 5, nach 11 vor der Auflösung von Voltron Data. Arctos-Mitwirkende stellen je nach Quartal 1-3 dieser 5 Personen.
  2. Auf der Merge-Seite gibt es eine ebenso wichtige und weniger diskutierte Kennzahl. Nennen wir sie den Merger Absence Factor (MAF): die Mindestzahl von Personen, deren Abwesenheit 50% aller Merge-Entscheidungen in einem Quartal wegfallen ließe. Das ist die Gatekeeping-Funktion. Es können tausend Contributors PRs öffnen, aber wenn die Personen fehlen, die mergen, wird nichts veröffentlicht. Arctos-Mitwirkende stellen je nach Quartal 3-5 der Personen, die für die Hälfte aller Merges verantwortlich sind. Dieser Anteil schwankt, ist aber über die Zeit konstant geblieben.

Die Daten zeigen außerdem, dass der CAF nach der Schließung von Voltron Data von 11 auf 5 fiel. Das lag nicht daran, dass das Projekt weniger gesund wurde, sondern daran, dass eine erhebliche Zahl von Contributors, die in Vollzeit an Arrow gearbeitet hatten, diesen Auftrag nicht mehr hatten. Der gesamte Contributor-Pool fiel von 94 (Q2 2024) auf 59 (Q1 2026). Die verbleibenden Personen sind wirklich engagiert, aber stark ausgelastet. Jeder weitere Verlust in der Spitzengruppe hätte unverhältnismäßig große Auswirkungen auf Review-Kapazität und Release-Geschwindigkeit.

Die Analyse kommt zu einem klaren Schluss: Das Projekt würde von zusätzlicher Maintainer-Zeit profitieren, sei es durch Sponsoring oder durch dedizierte Engineering-Unterstützung von Organisationen, die von Arrow abhängen. Genau diese Lücke sollte die Arctos Alliance schließen, und sie macht den Kern des Arguments aus, das wir gegenüber Organisationen vorbringen, deren Infrastruktur jeden Tag auf Arrow läuft.

Was daraus folgt

Die Arctos Alliance ist kein Governance-Gremium im bürokratischen Sinn. Sie ist eine Gruppe von Menschen, denen wichtig ist, dass Arrow ausgezeichnet bleibt, und die sich organisiert haben, um genau das zu ermöglichen: durch wichtige technische Verbesserungen, durch die Pflege der operativen Gesundheit des Projekts und durch den Aufbau einer Community, die Störungen überstehen kann, ohne an Tempo zu verlieren.

Die Nachhaltigkeitsdaten zeigen die Risiken klar, so wie die technische Bilanz zeigt, wie viel bereits erreicht wurde. Beide weisen in dieselbe Richtung: Arrow ist gesund, die Projektpflege funktioniert, und anhaltende Unterstützung — von den Organisationen, die von dieser Infrastruktur abhängen — sorgt dafür, dass es so bleibt.

Wenn Ihre Arbeit auf Apache Arrow aufbaut — und wenn Sie das lesen, ist die Wahrscheinlichkeit recht hoch, dass das der Fall ist — wissen Sie: Die Arctos Alliance sorgt dafür, dass diese Verlässlichkeit erhalten bleibt. Wir sprechen gerne darüber, wie Ihre Organisation Teil davon werden kann: Sie erreichen uns unter info [at] arctosalliance [dot] org. Alternativ können Sie uns hier erreichen bei OpenCollective.

Die Repositories der Arctos Alliance finden Sie unter github.com/arctosalliance.
Die Apache Arrow 2025 Community-Highlights sind im Arrow-Blog veröffentlicht.