ハクソク

世界を動かす技術を、日本語で。

Apache Arrowは10周年を迎えました

102日前原文(arrow.apache.org)

概要

Apache Arrowプロジェクトは2016年に開始され、2026年で10周年を迎えた記念記事。 この10年間で、Arrowは多様な方法で発展し、カラムナーデータ交換の標準を確立。 バージョン0.1.0から1.0.0までの進化と、ほぼ後方互換性を維持した設計。 エコシステムの広がりとサブプロジェクト、サードパーティの採用事例の紹介。 今後も安定性を維持しつつ、新しいユースケースへの対応とコミュニティ主導の発展を継続。

Apache Arrow 10周年の歩み

  • Apache Arrowプロジェクト、2016年2月5日に設立・初コミット
  • 10年間 で、予想外の発展とカラムナーデータ交換標準の実現
  • 多様な分野の実務者 による共同開発
  • Parquet 開発者も初期設計に参加、Arrowはインメモリ形式、Parquetは永続化形式として補完関係
  • 最初のリリース0.1.0 （2016年10月7日）、主要データ型の実装
    • Null, Int, FloatingPoint, Binary, Utf8, Bool, Decimal, Date, Time, Timestamp, Interval, List, Struct_, Unionなど
  • 後方互換性重視、主な変更は新しいデータ型の追加
  • 唯一の破壊的変更 ：Union型のトップレベルvalidity bitmap廃止（2020年）

クロスランゲージ統合テストと互換性

  • 0.1.0時点 ではC++・Java実装、PythonはC++バインディング
  • 初期は統合テストなし、2016年11月に設計、12月に自動CI導入
  • 統合テストの進化、古いデータも新実装で読めることを保証
  • Union型の破壊的変更 （2020年6月提案・実施）、ユーザーへの影響は限定的
  • それ以降は破壊的変更ゼロ、安定したカラムナ・IPCフォーマット

Arrow 1.0.0への進化と現在

  • バージョン1.0.0 は2020年7月、正式な互換性保証開始
  • エコシステムの拡大、"powered by"ページや公式ドキュメントで紹介
    • In-process zero-copy共有 やデータベースクエリの効率的な返却
    • C, C++, C#, Go, Java, JavaScript, Julia, MATLAB, Python, R, Ruby, Rust の公式実装
    • 非公式・サードパーティ実装 も多数存在
  • 公式サブプロジェクト ：ADBC、nanoarrowなど
    • DataFusion はArrowサブプロジェクトから独立、Apacheトップレベルプロジェクトに昇格
  • GeoArrow など、Arrowフォーマットを活用した第三者プロジェクトの成功例
  • Parquet実装 も現在はArrowリポジトリ内で開発（C++, Rust, Go）

Arrowの未来

  • コミュニティ主導・合意形成 で運営、公式ロードマップなし
  • 仕様は安定 しつつも、新ユースケースに応じた拡張を受け入れ
  • 実装は積極的に保守・機能追加・性能向上
  • 貢献者・参加者を常時歓迎
  • サードパーティのツール・ライブラリの発展 が今後の成長の中心
  • 10年前に築かれた安定基盤 の上で、さらなる発展を期待

Hackerたちの意見

Arrowが実際に何をするのか調べてみたんだけど、sqliteとのパフォーマンス比較もやってみる必要がありそう。メモリ内で列が連続しているのは、特定のデータタイプにはすごく便利だよね。

└

確か、Arrowはカラムデータのメモリ内での標準化された表現みたいなもんだよね。直接使われることはあまりないと思うけど、Polarsみたいな高レベルのライブラリの基盤として使われることが多いかな。とはいえ、専門家じゃないから、詳しい情報は持ってないかも。

└

そうそう、計算だけじゃないよ（カーネルはあるけどね）！実際には、IPCプロトコルやワイヤプロトコル、データベース接続仕様なんかも含まれてる。要するに、言語やエンジン間でゼロコピー操作を可能にするメモリ内のタブular（カラム）表現についてなんだよね。個人的には、すべてはカラムのための標準データ型に帰結すると思う！

└

sqliteとのパフォーマンス比較。実際の目的はそこじゃないよ；これは言語に依存しないフォーマットだから、データフレームやR用に変更する必要がないんだ。分析用にカラム形式になってるのは、集計やフィルタリングをたくさんするから、パフォーマンスが全然違うからね。データは意図的にターゲットカラムが連続して保存されるようになってる。もう知ってるかもしれないけど、SQLiteの分析用の相当物はDuckDBだよ。Arrowは、異なる消費者やツール、操作が同じメモリ表現をそのまま使えるから、データを共有する際にシリアライズ/デシリアライズの必要をなくすこともできるんだ。

└

parquetをチェックしてみて。Arrowをディスクに保存することもできるけど、主にメモリ内の表現として使われることが多いよ。

2015年にフェザーライブラリを見つけて、パワーポイントのスライド用のトピックモデリングに使ってた自分に教えてあげたいな。フェザーが（Arrowになって）どんな影響をデータエコシステムに与えるのかを説明したら、2026年の自分を狂った人みたいに見ただろうな。でも今は、2016年のデータ愛好者が狂ってるのかもね（笑）。

└

確かに。フェザーはRとpandasのデータフレーム間でデータを交換するためのライブラリだったよね。人々はpandasを批判しがちだけど、その創始者（ウェス・マッキニー）はpandasから得た知見でデータエコシステムを良くしてくれたんだよね。

有用で影響力のあるインターチェンジフォーマットが注目されて、必要なリソースを得るのを見るのは嬉しいね。そして、それらの周りにエコシステムが集まってくるのもいい。シリアライズ/デシリアライズの最適化は最初は「些細な」作業に見えるかもしれないけど、ペタバイトのデータを移動させるとすぐにボトルネックになっちゃうんだよね。共通のインターチェンジフォーマットがあれば、これらの最適化の恩恵がスタック全体に共有されるから、ほんと素晴らしいよ。

└

こういう「つまらない基本」がデフォルトのボトルネックだって直感的に理解できるのは、シニア以上のエンジニアの能力の証だよね。

うちの会社でもApache Arrow使ってるけど、めっちゃいいよ。パフォーマンスがすごく良くて、テラバイト単位の時系列金融データを保存して処理するのに使ってるんだ。

└

最近、parquetの書き込みを最適化してる時に偶然見つけたんだけど、完璧に動いて、スループットが10〜20倍になったよ。

└

うちの会社でもApache Arrow使ってるけど、古い社内フォーマットからの移行の一環なんだ。うまく動くときはいいけど、Arrowにはバグが多すぎる。例えば、文字列の基本的なArrow計算がセグメンテーションフォルトを起こすんだ。結果がArrowの文字列型に収まらなくて、大きな文字列型にしか収まらないから。キャストするかユーザーにキャストさせる代わりに、ただセグメンテーションフォルトになるんだ。もう一つの例として、別の基本操作が可変長バイナリ型を使うときに負のバッファサイズについて文句を言う例外を引き起こすことがある。

featherとparquetの使い方の違いって何なの？デザイン哲学は分かるけど、具体的にどう使い分けるの？

└

https://stackoverflow.com/questions/48083405/what-are-the-di...

└

parquetはストレージに最適化されてて、圧縮もよくて（=> ファイルが小さくなる）、featherは高速読み込みに最適化されてるんだ。

Arrowの型システムが好きなんだ。効率的で、完全だし、「無限精度の小数点」もないしね。Postgresの小数点エンコーディングを考えると、i256をバックタイプに使うのはずっと理にかなってると思う。

そのページ全部読んだけど、Apache Arrowが何か、何をするのか全然分からなかったよ。

└

ロゴをクリックするだけでホームページに行けたんだよね。

└

この投稿はApache Arrowの10周年を祝ってるから、もう何なのか、何をするのかは知ってる前提だと思う。そうじゃなければ、ドキュメントを見ればいいし。

「Apache ArrowフォーマットはJSONより効率的です。そう、フォーマットの名前は『Apache Arrow』です。」って説明するたびに笑っちゃう。

ちょっとした疑問だけど、なんでApache ArrowがJSONを完全に置き換えないの？

└

バイナリフォーマットだから？