この数年、インメモリでデータを処理するシステムが大きな流行となっている。顧客や業界ウォッチャーたちは、「SAP HANA」や「Apache Spark」などをはじめとする、遅いディスクアクセスやファイルシステムのシーケンシャル読み込みを回避し、メモリ内でデータを直接操作できるシステムに魅力を感じている。インメモリのシステムが常に最善の選択肢かどうかはともかく、人気があることは確かだ。
実際、最新のBIシステムは、ほとんどの場合カラム型の方式でもデータをストアする独自のインメモリエンジンを使っている。同一カラムに保存されているデータの値は同じであったり、似ていることが多いため、このやり方を用いることでデータの圧縮率も高まる。これは、より多くのデータをメモリに保存できることにもつながる。
アプローチは共通でも、実装はまちまち
多くのビッグデータ関連プロジェクトでは、カラム型のインメモリアプローチを用いるという点では共通しているにも関わらず、皮肉にもこのことが非効率性の原因になっている。これは、商用かオープンソースかを問わず、アナリティクス製品のほとんどが、カラム型のインメモリデータの表現に独自の方式を採用しているためだ。このため、特に製品間やサブシステム間でデータを移動する際に、データを一方のインメモリでの表現方式から、一般的な表現に変換し、それをもう一度別の製品の表現独自の方式に変換し直すというオーバーヘッドが生じている。データが不正規であったり、階層構造であったりすると、状況はさらに悪くなる。
ソフトウェアの世界では、共通の課題と、それを軽減する解決策が見つかれば、それは標準を確立し、その標準を普及させることで、努力の重複を大きく減らすためのチャンスだと言える。これこそ、ビッグデータのインメモリ表現の問題に対して「Apache Arrow」プロジェクトが目指していることだ。
共通点の体系化
Apache Arrowはエンジンではなく、ストレージシステムでさえない。Apache Arrowは、階層的なインメモリのカラム型データを取り扱うための一連のフォーマットとアルゴリズム、およびそれらを取り扱うプログラミング言語バインディングだ。言語バインディングの数は増えつつある。
このプロジェクトを協力して進めているのは、「Calcite」「Cassandra」「Drill」「Hadoop」「HBase」「Ibis」「Impala」「Kudu」「Pandas」「Parquet」「Phoenix」「Spark」「Storm」という13のビッグデータ関連オープンソースプロジェクトの中心的な開発者（プログラム管理委員会委員長、共同委員長、コミッター）だ。Apache Arrowプロジェクトは、これらの協力プロジェクトのコミュニティや専門家集団の存在を理由として、通常は必要とされるプロジェクトの有効性を検証するためのインキュベーターフェーズを省略し、直接Apache Software Foundationのトップレベルプロジェクトに位置づけられることになる。
