- プロジェクト：pure Ruby Apache Arrow実装の開発
- 応募者：株式会社クリアコード
- メンター：村田賢太
本プロジェクトは、Apache Arrow の読み書きに特化した pure Ruby 実装を整備するものである。Apache Arrow は、大きな表形式データを低コストで交換し、高速に処理するための共通フォーマットとして広く利用されており、言語やツールをまたいだデータ連携の基盤として普及している。Ruby でも Apache Arrow を利用できるが、既存の主要な手段は C++ や Rust 実装のバインディングに依存している。これらは高機能かつ高性能である反面、インストールや依存解決の負担が比較的大きいという課題があった。応募者はこの状況を踏まえ、高速なデータ処理機能そのものではなく、Apache Arrow データのシリアライズ・デシリアライズに対象を絞り、pure Ruby による軽量な実装を提供することを本プロジェクトの主眼として設定した。
本プロジェクトが目指すゴールは、Ruby 利用者がネイティブ拡張への依存を強く意識せずに Apache Arrow フォーマットを読み書きできるようにすることである。既存のバインディング方式を置き換えることは目的としていない。高速な分析処理や Arrow C++ が持つ処理系の恩恵を必要とする場面では、引き続き既存実装が有力な選択肢である。他方で、外部システムとのデータ交換、Arrow 対応システムとの連携、あるいは Ruby アプリケーションにおける軽量な入出力機能の提供といった用途では、読み書きに特化した pure Ruby 実装には大きな意義がある。
「Arrow 形式データの入出力に特化した機能を提供するための独立した小型のライブラリ」という点で近い発想のものとして、Apache Arrow コミュニティが開発する nanoarrow がある。nanoarrow は、Arrow データを作成・利用するための小規模で組み込みやすいライブラリ群として位置づけられており、公式ドキュメントでは C/C++、Python、R 向けが案内されている。これに対して本プロジェクトは、Ruby 利用者にとっての導入のしやすさ、依存の軽さ、配布の容易さを優先した点に特徴がある。すなわち、用途を「Arrow データを読む・書く」に絞り込んでいる点は共通しているが、Ruby 利用者から見た扱いやすさという点で大きく異なっている。
本プロジェクトの成果により、Ruby エコシステムには複数の恩恵が期待できる。第一に、Arrow 対応機能を Ruby のアプリケーションやライブラリに組み込みやすくなる。第二に、ネイティブ依存が重い環境では導入しづらかったユースケースにも対応しやすくなる。第三に、Ruby をデータ交換の入口・出口として使い、実際の重い処理は他の Arrow 対応系に任せるといった構成が取りやすくなる。こうした基盤が整うことは、Ruby におけるデータ処理関連ライブラリやアプリケーションの裾野を広げる意義を持つ。
提案時点での計画は次のとおりである。2025 年 11 月末までに FlatBuffers の Ruby 実装における読み込みサポートと Apache Arrow 側の読み込みサポートを整備し、2025 年 12 月末までに FlatBuffers の書き込みサポート、Apache Arrow 側の書き込みサポート、さらにインテグレーションテストへの対応まで完了させ、2026 年 1 月時点で全体を完了させる想定であった。スコープとしては、ストリーミングフォーマットおよびファイルフォーマットの読み書き、使用頻度の高いプリミティブ型・ネスト型・Dictionary 型への対応が中核に据えられていた。
最終的に達成された成果は、この当初計画の中核部分を十分に満たしている。成果物として、FlatBuffers の pure Ruby 実装である Red FlatBuffers と、Apache Arrow の pure Ruby 実装である Red Arrow Format が整備された。さらに、既存の C++ 実装の挙動を期待値として各種機能を検証し、Apache Arrow の既存インテグレーションテストにも組み込むことで、C++ 以外の実装との相互運用性も確認されている。したがって、本プロジェクトの成果は単なる試作にとどまるものではなく、Apache Arrow 実装として一定の品質水準を備えたものになったと評価できる。
なお、性能面については、最終報告書提出後に Apache Arrow 本体へ pure Ruby reader / writer に対するベンチマークが追加され、pure Ruby 実装の現時点での基準値が確認された。応募者の環境では、reader は release build の C++ 実装より約 5〜6 倍遅い一方で debug build の C++ 実装よりやや高速であり、writer は release build の C++ 実装より約 2〜2.5 倍遅い一方で debug build の C++ 実装より約 2〜2.5 倍高速であった。これらの結果は環境依存ではあるものの、本プロジェクトの成果について、性能上の現在地と今後の改善余地を定量的に把握できる段階に入ったことを示している。
もっとも、プロジェクトの進行は当初予定どおりには進まなかった。主たる要因は FlatBuffers 側にあり、当初は Google の FlatBuffers 本体に Ruby サポートとして取り込まれることを想定して実装とプルリクエスト提出を進めていたものの、レビューが進まず、途中で方針転換を余儀なくされた。中間報告の時点で進行上の不確実性として報告されていたこの問題は、提案時には計画されていなかった Red FlatBuffers を開発することで解消された。これは Arrow 実装のための内部部品にとどまらず、FlatBuffers の pure Ruby 実装として独立した価値を持つ成果物になっている。なお、最終的な完了時期は 2026 年 3 月上旬まで後ろ倒しになっており、その要因としては、方針転換に伴う遅延に加え、半月ほど作業できない期間があったことも報告されている。
本プロジェクトを通じて新たに明らかになった課題もある。第一に、pure Ruby 実装を整備しただけでは、継続的なコントリビューター育成までは自動的には進まないという点である。最終報告書では、公開チャットを通じて参加者を募ったことで一部の開発参加は得られたものの、継続的な開発者の育成という副次目標は十分には達成できなかったと率直に総括している。第二に、こうした成果を Ruby エコシステム全体の普及につなげるには、実装の存在だけでなく、利用者向けの説明、導入手順、適切なユースケース提示といった普及面の整備も今後重要になることが示唆された。
第三に、性能改善のための課題がライブラリ内部の工夫だけでは閉じず、Ruby 本体の改善課題として明確になった点も重要である。最終報告書では、Apache Arrow がビットマップを多用することから高速なビット操作 API の整備が読み書き性能に寄与しうること、差分 Dictionary などを視野に入れると配列データの効率的なスライスおよび再構築機構が必要になること、書き込み時の一時的な配列や文字列の生成を避けるためには効率的なデータ変換・シリアライズ機能が求められること、さらに MemoryView と JIT を適切に連携できれば pure Ruby のまま高速な Arrow データ処理系へ進める可能性があることが示されている。これらは Apache Arrow 向けの局所的な要望にとどまらず、Ruby をデータ処理用途へ広げるうえで重要な実装基盤上の課題を具体化したものと評価できる。
本プロジェクトにおいて、メンターとしての私の主たる役割は、データ処理分野に詳しい Ruby コミッターであり、かつ Apache Arrow 開発経験を持つ立場から、プロジェクトの進行状況と成果内容の妥当性を評価することであった。本プロジェクトは、Apache Arrow という特定分野の技術的背景と、Ruby における実装上の制約や価値判断の双方を理解していなければ、適切な評価が難しい性質のものである。そのため、実装の方向性が妥当か、スコープ設定が現実的か、成果物が本当に Ruby エコシステムに価値を持つかを見極めることが、メンターとして重要であった。
もっとも、応募者自身が対象領域に関する深い知見と十分な実装経験を備えていたため、私が技術的なサポートを詳細に行う必要はなかった。そのため本件では、技術的な詳細支援よりも、進捗と成果の評価、ならびに報告内容の妥当性確認に重心を置く関与が適切であったと考える。
具体的な関与としては、応募者からの定期的な進捗報告を確認し、中間報告書および最終報告書の内容をレビューし、また pure Ruby の Arrow reader / writer を提案する文章案の作成過程で簡単な助言を行った。進捗管理は Apache Arrow 側の公開 issue 上で行われており、また応募者はメンターとのやりとりも公開チャット上で進めていたため、私はそれらを通じて進展と成果を確認し、必要に応じて妥当性の観点からコメントする役割を担った。公開性の高い進行管理は、本プロジェクトの透明性を高めると同時に、助成対象としての説明責任にも資するものであった。
本プロジェクトは、FlatBuffers 対応をめぐる方針転換や作業遅延を含みつつも、最終的には pure Ruby による Apache Arrow reader / writer の実装を成立させ、加えてそれを支える pure Ruby FlatBuffers 実装も整備した点で、十分に意義ある成果を上げたと評価できる。中間報告の時点で大きな課題だった FlatBuffers 側の不確実性は、独立実装というかたちで乗り越えられ、最終的には相互運用性の検証まで含めて完了している。したがって、当初計画からの遅延はあったものの、プロジェクトの中核となる目標は達成されたと判断してよい。
また、この成果は単年度の実装成果にとどまらず、Ruby エコシステムにおける Apache Arrow 利用の将来に向けた基盤整備として評価できる。加えて、本プロジェクトは pure Ruby で高性能なデータ交換基盤を実現しようとした結果として、Ruby 本体にどのような改善が求められるかを具体的に示した点でも意義が大きい。高速なビット操作、効率的な配列スライス、無駄な一時オブジェクトを抑えたデータ変換、MemoryView と JIT の連携といった論点は、Apache Arrow に限らず、Ruby を今後より広くデータ処理に使っていくうえで重要な技術課題である。今後、こうした点の改善と、利用しやすさの向上、周辺ライブラリでの採用拡大が進めば、本プロジェクトの成果は Ruby の将来に対してより大きな波及効果を持ちうる。