ja ja ja ja ja ja ja ja ja en ja ja ja ja ja ja ja ja ja ja ja de ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja en pt en en en br en en en pl en ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja en ja en ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja en ja ja ja ja en ja ja ja ja ja en ja ja ja ja ja ja ja ja zh ja ja ja ja zh ja ja ja ja ja ja ja ja ja ja ja ja ja ja zh ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja zh ja en ja ja ja zh zh ja ja ja ja ja ja en ja ja ja ja ja en ja pt ja ja ja ja ja ja ja ja ja en ja ja ja ja ja ja ja ja ja ja ja ja en ja ja ja ja en ja ja ja ja ja en ja ja ja ja en ja ja en ja ja en ja ja ja ja en ja ja ja en pt en en en br en en en pl en ja ja ja ja ja ja en ja ja ja ja ja pt ja ja ja ja ja en ja ja de ja ja es ja ja ja ja ja ja ja en ja ja ja en en en ja ja zh ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja en ja ja ja ja ja ja ja en ja ja ja en ja ja ja en en ja en ja zh ja ja ja ja ja ja ja ja ja ja ja ja zh ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja br ja en en ja en ja ja en ja ja ja ja en ja en ja ja en pl ja ja ja en ja en ja lt ja en ja ja en ja ja zh ja ja ja ja ja ja ja ja ja ja ja ja ja zh ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja en ja ja ja ja ja en ja ja ja ja en ja ja ja ja ja ja en ja ja ja ja ja ja ja ja ja ja ja en ja ja en ja ja vi ja sv eu ja en en hu ja ja en en pl ja ja jbo hbs_lat en ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja
Apache Arrowフォーマットで一番うまみがでるのは、各システムすべてがApache Arrowフォーマットに対応しているときです。Apache Arrowフォーマットに対応していないシステムがあるとそのシステムとのデータ交換時にApache Arrowフォーマットを使えないからです。つまり、そのシステムとのデータ交換コストが高くなります。
Apache ArrowのデータはOLTP(OnLine Transaction Processing)(ECサイトで購買するような処理)よりもOLAP(OnLine Analytical Processing)(データから探索的に知見を探し出すような処理)で性能がでるように設計されています。OLTPとOLAPでは処理の内容が違うので、データの配置の仕方で実現しやすさが変わってきます。RDBMSを知っている人向けな説明をすると、OLTPでは行単位の処理(行の追加・削除など)が多くて、OLAPでは列単位の処理(COUNTやGROUP BYなど)が多いです。OLTPでは行単位でデータが固まっていた方が性能がでやすく、OLAPでは列単位でデータが固まっていた方が性能がでやすいです。Apache ArrowはOLAP向けの設計なので列単位でデータをまとめています。このようなデータの持ち方を「カラムナー」と言います。
[DISCUSS] Contribution of Gandiva to Apache Arrow
Contribute "RowSet" mechanism from Apache Drill?
プログラムから直接効率良く扱える配置にしてあるとそのままデータを扱えます。システムが提供するメモリーマップ機能を使えばゼロコピーでデータを扱えます。しかし、直接扱えるデータでも圧縮すると伸張しなければ使えません。つまり、「直接効率よく扱える配置」ではなくなってしまいます。そのため、新しい領域を用意して伸張したデータを格納する必要があります。コピーのような挙動です。大量データを処理する想定なのでこのような伸張するコストが無視できないことも多いです。ただ、ネットワーク越しにデータ交換する時のようにネットワーク上のデータ送受信コストの方が圧縮・伸張コストよりも高いことがあります。このような場合は圧縮した方が割に合うので、用途によって使い分けます。(まだ圧縮機能はサポートされていまLZ4を扱うための部分は実装済みです。ARROW-300 [Format] Add buffer compression option to IPC file format参照。)
DBMS Musings: Apache Arrow vs. Parquet and ORC: Do we really need a third Apache project for columnar data representation?
続編としてDBMS Musings: An analysis of the strengths and weaknesses of Apache Arrowがあるので↑が面白かった人は読んでみてもよいかも
Some comments to Daniel Abadi's blog about Apache Arrow - Wes McKinney
それでは詳細を説明していきます。
まずはApache Arrowが扱えるデータを説明します。
現在Apache Arrowが扱えるデータは次の通りです。
Apache Arrowはもともと「データフレーム」なデータを扱うために開発が始まりました。「データフレーム」は表形式のデータです。RDBMSのテーブルのようなものです。1つのテーブルには1つ以上のカラムがあり、それぞれのカラムは違う型にできます。
現在、Apache Arrowがサポートしている型は次の通りです。これらの型のデータを扱えるということです。
8bit非負整数(リトルエンディアン)
8bit整数(リトルエンディアン)
16bit非負整数(リトルエンディアン)
16bit整数(リトルエンディアン)
32bit非負整数(リトルエンディアン)
32bit整数(リトルエンディアン)
64bit非負整数(リトルエンディアン)
64bit整数(リトルエンディアン)
16bit浮動小数点数
32bit浮動小数点数
64bit浮動小数点数
小数(精度・スケールを指定)
可変長UTF-8文字列
可変長バイナリーデータ
固定長バイナリーデータ
UNIXエポックからの経過日数(32bit)
UNIXエポックからの経過ミリ秒数(64bit)
タイムスタンプ(64bit整数)
UNIXエポックからの経過秒数
UNIXエポックからの経過ミリ秒数
UNIXエポックからの経過マイクロ秒数
UNIXエポックからの経過ナノ秒数
深夜0時からの経過秒数(32bit整数)
深夜0時からの経過ミリ秒数(32bit整数)
深夜0時からの経過マイクロ秒数(64bit整数)
深夜0時からの経過ナノ秒数(64bit整数)
リスト(0個以上の同じ型の値を持つ型)
構造体(1個以上のフィールドを持つ型で、各フィールドは別の型にできる)
共用体(1個以上のフィールドを持つ型で、各フィールドは別の型にでき、どれか1つのフィールドの値のみが設定されている)
統計っぽい説明:名義尺度なカテゴリーデータ
実装よりの説明:各値に整数でIDを割り当て、数値で値を表現する型
scikit-learnを知っている人向けの説明:sklearn.preprocessing.LabelEncoderのtransform結果を値として使う型
なお、どの型でもnullを設定できます。
Apache Arrowはデータフレームを想定して開発が始まりましたが、多次元配列も扱えるとよさそうというフィードバックがありApache Arrow 0.3.0から多次元配列をサポートしました。
参考:ARROW-550 [Format] Add a TensorMessage type
データフレームと多次元配列の違いは次の通りです。
データフレームは2次元
データフレームはカラム毎に違う型を使える
多次元配列の要素の値はすべて同じ型
Pythonでいうと、pandasが実現しているのがデータフレームで、NumPyが実現しているのが多次元配列です。
多次元配列には密(dense)な多次元配列と疎(sparse)な多次元配列があります。密な多次元配列は要素の値をすべて持っている多次元配列で、疎な多次元配列は0以外の要素の値だけを持っている多次元配列です。
たとえば、[0, 0, 0, 1, 0]という多次元配列(1次元配列)があった場合、5要素全部の値を保持しているのが密な多次元配列で、「4番目の要素の値が1でそれ以外は0」という情報だけ保持しているのが疎な多次元配列です。
Apache Arrowは現在は密な多次元配列のみサポートしています。疎な多次元配列もサポートする予定があります。現在は妥当なデータフォーマットの仕様を検討する人を募集している状態です。疎な多次元配列の知見がある人はぜひ取り組んでみてください。
参考:ARROW-854 [C++] Support sparse tensor
Apache Arrowは各種データ処理ツールが共通で使える高速なデータ処理機能の開発も重視しています。これまでデータフォーマットの方に注力していたためまだあまり進んでいませんが、現時点できることを紹介します。
データ処理部分の実装に着手しているのはC++、JavaScript、Goでの実装だけなので、それぞれの言語での実装ごとに紹介します。
なお、データ処理部分が実装されていない言語あるいは実装が始まっている言語でも未実装の処理はできないかというとそうでもありません。読み込んだApache Arrowフォーマットのデータを他の既存のライブラリーで扱えるように変換することで処理できます。コピーやデータの変換が必要になるので多少非効率ですが、Apache Arrowフォーマットによりデータ交換部分のコストがすごく効率化されるので割に合うことが多いです。
たとえば、Apache Sparkではデータ交換部分でApache Arrowを使うことにより大きく速度向上しています。Apache Sparkには処理の一部をPythonで実装できるPySparkという機能があります。Apache Spark本体はScalaで実装されているので別プロセスで動いているPythonにデータを渡す必要があります。このときにソケット経由でApache Arrowデータを渡しています。従来はPythonに標準で含まれているpickleを使ってデータを転送していました。Apache Arrowフォーマットで受け取ったデータはpandasのオブジェクトに変換し、データ処理はpandasの機能を使います。ちなみに、Apache Arrowのデータからpandasのオブジェクトへの変換は、型によってはゼロコピーで実現できます。この場合はさらに効率的にデータ交換できます。
参考:Speeding up PySpark with Apache Arrow
それでは現時点で実装されているデータ処理機能を各言語毎に紹介します。
C++で実装されている処理は次の通りです。
例:16bit整数を32bit整数へ変換
辞書型への変換も実装済み
要素ごとの排他的論理和
実装が予定されている処理のリストはApache Arrowのプロジェクト管理ツールであるJIRAを「kernel」で検索してみてください。実装してみたい処理があったらぜひ取り組んでみてください。
JavaScriptで実装されている処理は次の通りです。
要素ごとの排他的論理和
値ごとの出現数のカウント
Goで実装されている処理は次の通りです。
まだ1つしか実装されていないんですが、SIMDを活用するために面白い実装になっているので少し説明します。
SIMDを使うためにはCPUがSIMDをサポートしていないと使えません。最近のC/C++コンパイラーはCPUがSIMDをサポートしているかどうかで自動的にSIMDを使ったコードを生成できるくらい賢くなっています。しかし、Goのコンパイラーはまだその最適化はできません。そこで、事前にClangを使ってSIMD対応のアセンブリを出力してそれをGoに組み込んでいます。ただ、この方法だとCPUが対応していないSIMDもGoに組み込まれています。そこで、使えるSIMDを実行時に検出して適切なSIMD実装の処理を呼び出すようにしています。詳細は以下の参考URLを参照してください。Go実装を書いたInfluxDataの人が書いたブログです。
参考:InfluxData Working on Go Implementation of Apache Arrow | InfluxData
ちなみに、InfluxDataは時系列データベースInfluxDBを開発している会社です。InfluxDBはGoで実装されているのでInfluxDBで活用するためにApache Arrowの開発に参加しています。
データ処理部分の実装のまとめ
データ処理部分はあまり実装されていなくてがっかりしたかもしれません。少し将来の話もしておきます。
Apache Arrowでは各要素の処理だけでなく、複雑な条件を高速に処理する実行エンジンの実装も視野に入れています。その実装として使えそうなモジュールが近いうちにApache Arrowに入る予定です。
このモジュールにはGandivaという名前がついています。Gandivaはどのように処理を実行すればよいかを実行時に計算して、LLVMを使って実行時にコンパイルしてから実行します。コンパイルしているので事前にコンパイルしたときと同じくらい高速になりますし、LLVMはSIMD用の最適化機能もあるので、SIMD対応の処理にもなります。詳細はGandivaの開発者が書いた以下のブログを参考にしてください。
参考:Introducing the Gandiva Initiative for Apache Arrow - Dremio
「近いうちにApache Arrowに入る予定」で今はどんなステータスなのかについても触れておきます。
外部のモジュールがApache Arrowに取り込まれるには次のステップを踏む必要があります。
PMC(プロジェクト管理チームみたいなやつ)が承認する
IPクリアランス(知的財産侵害を心配しなくても使えることを確認する)
参考:Intellectual property clearance - Apache Incubator
Gandivaは今は「PMCが承認する」を完了したステータスです。
参考:[RESULT] [VOTE] Accept donation of Gandiva to Apache Arrow
次はIPクリアランスなのですが、そのためにはApache Arrowのリポジトリーにpull requestを作る必要があるのですが、まだそれはできていません。
0.11.0のリリースが今月中の予定なので、それには間に合わなそうですが、数ヶ月以内には入るんじゃないかと私は思っています。
Apache Arrowには同一マシン内でオブジェクトを共有する機能もあります。それがPlasmaという名前のモジュールです。Apache Arrowにはデータフレームなデータを低いシリアライズ・デシリアライズコストで交換するための仕組みがあります。それを活用して実装しています。Plasmaはデータフレームなデータを交換するための機能ではなく、メモリー上の生データを交換するためのもっと低レベルな機能であることに注意してください。
PlasmaはもともとRayの一部として開発していた機能ですが、広く有用そうだということでApache Arrowに移動しました。Rayは大規模な機械学習・強化学習用の高速な分散処理フレームワークです。カリフォルニア大学バークレイ校のRISELabが開発しています。
Plasmaを使うとCPU上のデータもGPU上のデータもゼロコピーで共有できます。Plasmaでデータを共有することで複数プロセスで分散処理できます。
Plasmaを使うためにはサーバープロセスを起動する必要があります。各プロセスがサーバープロセスに接続して、共有したいデータを置いたり、共有されているデータを参照したりして処理を進めます。
参考:Plasma In-Memory Object Store
各言語での実装の完成度
次は各言語での実装の完成度を説明します。
Apache Arrowフォーマットはより多くの環境で使えるほどメリットが大きくなります。そのため、Apache Arrowフォーマットを使える言語を増やすべく開発しています。現在は次の言語で使えます(再掲)が、その完成度は様々です。
特に完成度が高いのがJava、C++、Python、C、Ruby実装です。
最初にJava、C++実装から開発が始まっているのでこれらの言語の実装は完成度が高いのです。Python、C、Ruby実装も完成度が高いのはこれらはC++実装のバインディング(C++実装の機能を他の言語でも使えるようにしている)からです。Lua実装も(間接的に)C++実装のバインディングなのですが、APIの使い勝手という面で少し完成度が落ちます。
MATLAB、R実装もC++実装のバインディングですが、まだ開発が始まったばかりで完成度はそれほどではありません。
Go、JavaScript、Rust実装は1から実装しているのでまだJava、C++実装ほどの完成度にはなっていません。ただ、対応しているデータフレームの型に関してはJavaScript実装の完成度は高いです。
まだApache Arrowのリポジトリーには入っていませんが、Juliaの実装も進んでいます。Julia実装は1から実装しています。
それではアルファベット順に各言語の実装の概要と完成度を紹介します。
C実装はC++実装のバインディングです。これは私が作りはじめたモジュールです。今は主に私と@shiro615が開発しています。
GLibというC言語用の便利ライブラリーを使っているのが特徴です。GLibを使った理由は「各種言語のバインディングを自動生成できる」からです。念のため補足しますが、「C++実装のバインディングを自動生成できる」のではなく、「C++実装のバインディングであるC実装のバインディングを自動生成できる」です。
この機能を使ってRubyとLuaのバインディングが動いています。GLibにはC言語でオブジェクト指向プログラミングをするためのライブラリーGObjectも含まれています。GObjectを使ってオブジェクト指向なAPIを実現しています。そのため、自動生成されたRuby・Lua用のバインディングもオブジェクト指向なAPIになっていて使いやすいです。通常、Cのライブラリーのバインディングを自動生成するアプローチは生のCの関数をそのまま使えるようなAPIになります。そうすると使いやすくするために手動で使いやすいAPIをラップするレイヤーを実装する必要があるのですが、C実装で使っている自動生成機能ではその手間は必要ありません。
なお、C実装で使っている自動生成する仕組みはGObject Introspectionです。
C実装ではPlasma以外のすべてのC++実装の機能を使えます。近いうちにPlasmaも使えるようになる予定です。
C++実装は1から開発しています。主に@wesm、@xhochy、@pitrou、@pcmoritz、@cpcloudが開発しています。
C++実装はC++11を使っています。そのため、CentOS 6に標準で入っている古いg++ではビルドできません。CentOS 6でビルドしたい時はdevtoolset-6あるいはdevtoolset-7パッケージをインストールして新しいg++を用意します。
C++実装はデータフレームのすべての型も多次元配列もサポートしています。
PlasmaのサーバープロセスはC++で実装されています。もちろん、Plasmaクライアント機能も実装されています。
C++実装には他のフォーマットとの相互変換機能がいくつか含まれています。現時点で実装されているフォーマットは次の通りです。
PythonとR間でデータ交換するためのフォーマット。
Apache Arrowで置き換えるため現在は非推奨。
Hadoop用のカラムナーなフォーマット。
現時点では読み込みのみ。簡単な書き込み機能はサポート予定。
Apache Parquet
Hadoop用のカラムナーなフォーマット。
Apache ArrowのC++実装ではなく、Apache ParquetのC++実装の方に実装されている。
メモリー上ではなくGPU上にデータを置く機能もあります。まだあまり活用されていない機能ですが、今後より活用されていくはずです。というのは、Apache ArrowフォーマットのデータをGPU上で処理するライブラリーが開発されているからです。
たとえばlibgdfというライブラリーです。libgdfはC言語用のデータフレームライブラリーです。CUDAを使って実装しています。値の比較処理だけでなくにグループ化機能やジョイン機能といった高度な機能も実装されています。
libgdfはGoAi (GPU Open Analytics Initiative)という団体が開発しています。この団体のミッションは「GPUを活用してデータ分析できるプラットフォームを構築する」です。
他にもMapDというGPU上で動くデータベースがApache Arrowフォーマットに対応しています。MapDではSQLを使ってデータを処理できます。MapDを開発している会社もGoAiに参加しています。
Python連携用のモジュールもC++実装に含まれています。Python連携用のモジュールではC++のApache ArrowオブジェクトとPythonのpandas・NumPyオブジェクトを相互変換する機能を提供しています。Pythonバインディングの方に入れずにC++実装の方に入れているのはいろいろなライブラリーでこの機能を共有したいからです。当初の想定の1つのpandas 2.0ではまだ使っていませんがすでに活用している例があります。それはRed Arrow PyCallという同一プロセス内でRubyとPythonを両方動かしてRubyとPython間でApache Arrowデータを共有するためのライブラリーです。Apache ArrowデータとPythonオブジェクトを変換するためにPython連携用のモジュールを使っています。
参考:ARROW-341 [Python] Making libpyarrow available to third parties
2018年9月にApache ParquetのC++実装がApache Arrowのリポジトリーに移動しました。理由は現時点では両者がすごく密に連携をして開発を進めているので同じリポジトリーにあった方が開発を進めやすいからです。将来的に、APIが安定したらまた分離するかもしれません。
Apache Parquet C++の開発チームでの議論: [VOTE] Moving Apache Parquet C++ development process to a monorepo
Apache Arrowの開発チームでの議論: [DISCUSS] Solutions for improving the Arrow-Parquet C++ development morass
pull request: ARROW-3075: [C++] Merge parquet-cpp codebase into Arrow C++ codebase by wesm · Pull Request #2453 · apache/arrow
Go実装は1から開発しています。InfluxDataの人たちが開発しました。Apache Arrowのリポジトリーに入ってからは@sbinet(InfluxDataの人ではない)が開発しています。
対応しているデータフレームの型は次の通りです。
8bit非負整数(リトルエンディアン)
8bit整数(リトルエンディアン)
16bit非負整数(リトルエンディアン)
16bit整数(リトルエンディアン)
32bit非負整数(リトルエンディアン)
32bit整数(リトルエンディアン)
64bit非負整数(リトルエンディアン)
64bit整数(リトルエンディアン)
32bit浮動小数点数
64bit浮動小数点数
可変長バイナリーデータ
タイムスタンプ(64bit整数)
UNIXエポックからの経過秒数
UNIXエポックからの経過ミリ秒数
UNIXエポックからの経過マイクロ秒数
UNIXエポックからの経過ナノ秒数
リスト(0個以上の同じ型の値を持つ型)
構造体(1個以上のフィールドを持つ型で、各フィールドは別の型にできる)
多次元配列はまだサポートしていません。
Plasmaクライアント機能もまだサポートしていません。
他のフォーマットとの相互変換機能もまだサポートしていません。
Java実装は1から開発しています。主に@julienledem、@BryanCutler、@StevenMPhillips、@siddharthteotia、@elahrvivaz、@icexellossが開発しています。
Java実装はデータフレームの型をほとんどサポートしています。サポートしていないのは次の型だけです。
16bit浮動小数点数
多次元配列はまだサポートしていません。
Plasmaクライアント機能をサポートしています。
JDBCで取得したデータをApache Arrowオブジェクトで返す機能が実装されているので、簡単にRDBMSのデータをApache Arrowオブジェクトとして扱えます。
JavaScript実装は1から開発しています。主に@trxcllntと@TheNeuralBitが開発しています。
TypeScriptで開発しています。Webブラウザー上でもNode.js上でも動きます。
MapDで処理した結果をWebブラウザー上でビジュアライズするために活用できます。MapDはApache Arrowに対応しているのでWebブラウザー上のJavaScriptと低いコストでデータ交換できるのです。
参考:Supercharging Visualization with Apache Arrow
JavaScript実装はデータフレームのすべての型に対応しています。
多次元配列はまだサポートしていません。
Plasmaクライアント機能もまだサポートしていません。node-plasmaというNode.js用モジュールを作ってサポートしたいという構想があります。
参考:Connecting JS to modern GPU and ML frameworks: Update from Nvidia GTC 2018
公式のJulia実装はまだありませんが、@ExpandingManがArrow.jlの実装を進めています。公式実装にするための議論も進んでいます。
参考:collaboration with Apache Arrow org · Issue #28 · ExpandingMan/Arrow.jl
Julia実装が対応しているデータフレームの型は次の通りです。
8bit非負整数(リトルエンディアン)
8bit整数(リトルエンディアン)
16bit非負整数(リトルエンディアン)
16bit整数(リトルエンディアン)
32bit非負整数(リトルエンディアン)
32bit整数(リトルエンディアン)
64bit非負整数(リトルエンディアン)
64bit整数(リトルエンディアン)
32bit浮動小数点数
64bit浮動小数点数
可変長UTF-8文字列
UNIXエポックからの経過日数(32bit)
タイムスタンプ(64bit整数)
UNIXエポックからの経過秒数
UNIXエポックからの経過ミリ秒数
UNIXエポックからの経過マイクロ秒数
UNIXエポックからの経過ナノ秒数
深夜0時からの経過秒数(32bit整数)
深夜0時からの経過ミリ秒数(32bit整数)
深夜0時からの経過マイクロ秒数(64bit整数)
深夜0時からの経過ナノ秒数(64bit整数)
リスト(0個以上の同じ型の値を持つ型)
統計っぽい説明:名義尺度なカテゴリーデータ
実装よりの説明:各値に整数でIDを割り当て、数値で値を表現する型
scikit-learnを知っている人向けの説明:sklearn.preprocessing.LabelEncoderのtransform結果を値として使う型
多次元配列はまだサポートしていません。
Plasmaクライアント機能もまだサポートしていません。
Lua実装はC実装とlgiを使って自動生成しています。特にパッケージにはしていなくて、以下のようにすれば使えるという状態です。
local lgi = require 'lgi' local Arrow = lgi.Arrow
参考:arrow/c_glib/example/lua at master · apache/arrow
C実装で使える機能はすべて使えます。
MATLAB実装はC++実装のバインディングです。2018年9月10日現在ではまだ1コミットだけですが、主に開発をしている人は@kevingurneyです。MATLABを開発しているMathWorksの人です。
現在はFeatherフォーマットのデータを読み込む機能だけがあります。Apache Arrow形式のデータはまだ読めません。
Python実装はC++実装のバインディングです。主に開発をしている人たちはC++実装を開発している人たちとだいたい同じです。
C++実装で使える機能はすべて使えます。単に使えるだけではなく、Pythonからより便利に使えるようにAPIが整備されています。
Cythonを使って実装されています。
pandas・NumPyのオブジェクトに簡単に相互変換できる機能も実装されていて、既存のライブラリーとシームレスに使えるようになっています。
R実装はC++実装のバインディングです。2018年9月10日現在ではまだ1コミットだけですが、主に開発をしている人は@romainfrancoisです。↓の最初のpull requestにR関係の人が何人かコメントしたりJIRAに新しくissueを作っている人もいるので、今後開発に参加する人は増えていきそうな気配がします。
参考:ARROW-1325: [R] Initial R package that builds against the arrow C++ library by romainfrancois · Pull Request #2489 · apache/arrow
現在はC++実装の簡単に機能を使えるだけでApache Arrowフォーマットのデータを読めたりはしません。ただ、開発環境の整備は進んでいます。すでにTravis CIでテストできるようになっています。
R実装の進め方はGoogle Docsで議論しています。ある程度まとまったらJIRAのチケットにブレイクダウンされる予定です。
参考:Apache Arrow for R - Initial Roadmap - Google Docs
Ruby実装はC実装とgobject-introspection gemを使って自動生成しています。主に開発している人たちはC実装を開発している人たちです。
C実装で使える機能はすべて使えます。単にバインディングを自動生成しているだけではなく、Python実装のように、より便利に使うためのAPIも整備してあります。
既存のライブラリーとシームレスに使えるようにするための機能もあります。依存関係を増やしたくないのでRuby実装自体には入っていないのですが、関連ライブラリーとして次のライブラリーがあります。
Red Arrow GSL
Ruby/GSLと相互変換用のライブラリー。
Red Arrow NMatrix
NMatrixと相互変換用のライブラリー。
Red Arrow Numo::NArray
Numo::NArrayと相互変換用のライブラリー。
Red Arrow PyCall
PyCall経由でPython実装のオブジェクトと相互変換するライブラリー。
また、Apache Parquetフォーマットのデータを読み込むためのRed Parquetもあります。
Rust実装は1から開発しています。主に@andygroveが開発しています。
Rust実装が対応しているデータフレームの型は次の通りです。
8bit非負整数(リトルエンディアン)
8bit整数(リトルエンディアン)
16bit非負整数(リトルエンディアン)
16bit整数(リトルエンディアン)
32bit非負整数(リトルエンディアン)
32bit整数(リトルエンディアン)
64bit非負整数(リトルエンディアン)
64bit整数(リトルエンディアン)
16bit浮動小数点数
32bit浮動小数点数
64bit浮動小数点数
可変長UTF-8文字列
リスト(0個以上の同じ型の値を持つ型)
構造体(1個以上のフィールドを持つ型で、各フィールドは別の型にできる)
多次元配列はまだサポートしていません。
Plasmaクライアント機能もまだサポートしていません。
各言語での実装の完成度のまとめ
Apache Arrowの各言語での実装をそれぞれ説明しました。
サポートしている型という観点では、数値型と真偽値型はどの言語の実装でもカバーしています。時間関連の型はGo、Rust実装以外はカバーしています。複合型は共用体以外ならどの言語の実装でもカバーしています。C++、Java、JavaScript実装およびC++実装のバインディングはすべての型に対応しています。
他のフォーマットとの相互変換はC++実装ファミリーが進んでいます。Apache ParquetやApache ORC、Featherフォーマットと相互変換できます。
GPUサポートもC++実装ファミリーが進んでいます。
Plasmaを使いたい場合はC++、Java、Python実装を使うことになります。近いうちにC実装ファミリーでも使えるようになる予定です。
Apache Arrowデータを高速に処理するという観点ではどの実装もまだカバー範囲は狭いです。
Apache Arrowの今後
ここまででApache Arrowの概要、現状を説明しました。最後に今後のことを説明します。
実行エンジンGandivaの取り込み
現状ではApache Arrowデータを高速に処理するところがまだ弱いです。そのあたりをカバーするモジュールがGandivaです。このGandivaが近いうちに取り込まれ、Apache Arrowデータを高速処理できる基盤となるでしょう。
GandivaはC++で実装されているので、C++実装ではすぐにGandivaを使えるようになります。
Gandivaを開発しているDremioは自社で開発しているサービスでApache Arrowを利用しています。このサービスはJavaで実装しているので、C++で実装したGandivaをJavaから使うためのバインディングも開発しています。そのため、Java実装でもすぐにGandivaを使えるようになります。
C++実装ベースのPython実装、C実装ファミリーもすぐに使えるようになるでしょう。
世の中では今でもCSVがよく使われています。そのため、CSVをパースしてApache Arrowオブジェクトを作成するパーサーの開発を進めています。
参考:Building a fast Arrow-native delimited file reader (e.g. for CSVs) - Apache Mail Archives
これはC++実装での話です。実装されたらC++実装ファミリーでもすぐに使えるようになるでしょう。
Apache Arrow対応クライアントの追加
Java実装にはJDBCで取得したデータをApache Arrowオブジェクトで返す機能があります。それと同様な機能がC++実装にも入る予定です。
まずは、Apache Hive・Apache Impalaからデータを取得してApache Arrowオブジェクトで返す機能が入りました。
他にもPostgreSQLからデータを取得してApache Arrow形式で返す機能の実装も計画しています。
参考:Developing native Arrow interfaces to database protocols - Apache Mail Archives
同様のことをしているPythonライブラリーがあります。それがturbodbcです。これはODBCで取得したデータをApache Arrowオブジェクトで返すことができます。もしかしたら、今後、この機能がApache Arrowの方に移動して、turobdbcはそれを使うという関係になるかもしれません。
Apache Arrowの概要、2018年9月時点での現状、今後のことについて説明しました。Apache Arrowは数年後にはデータ処理界隈で重要なコンポーネントになっているだろうプロジェクトです。日本でもApache Arrowのことを知っている人が増えるといいと思うので日本語でまとめました。Apache Arrowを使う人が増えるといいなぁと思います。さらに言えば開発に参加する人も増えるといいなぁと思います。
この説明では省略しましたが、Apache Arrowの生い立ちについて面白い読み物があります。PMC(プロジェクト管理チームみたいな感じ)のチェアー(1番偉い人)が書いたものです。興味がある人はこちらも読んでみてください。
The Origin & History of Apache Arrow - Dremio
「Arrow」という名前の由来についての話もある。
私が知っていることはまとめたつもりですが、もしかしたらカバーできていない話があるかもしれません。もし、「○○についても知りたい!」という方がいたらRed Data Toolsのチャットで声をかけてください。この記事に追加します。
Apache Arrowについて講演して欲しいという方はお問い合わせフォームからご連絡ください。
私はデータ処理ツールの開発という仕事をしたいと思っています。その中にはもちろんApache Arrowの開発も含まれています。一緒に仕事をしたい!(自社サービスをApache Arrow対応したいとか)という方はお問い合わせフォームからご連絡ください。
Apache Arrow
現在クリアコードではソフトウェア開発者を募集しています! フリーソフトウェア開発での開発の仕方をベースに、成果や知識を公開し共有しながら業務に携われます。
RubyKaigi 2022 after event - 「Fast data processing with Ruby and Apache Arrow」のスピーカーに質問しよう! RubyKaigi 2022で須藤が発表した内容をより深堀するイベントをYouTube Liveで開催しました!アーカイブ公開中です。
2022年6月Apache Arrowの最新情報が一堂に集うデジタルカンファレンス『The Data Thread』に須藤が「Why Apache Arrow is important for Ruby」と題しビデオ登壇しました。動画はチャンネルからご覧いただけます。
2021-11-17 db tech showcase 2021で Apache Arrow Flight について講演しました!
YoctoのWeston上で日本語入力
fcitx-mozcの入力モードを外部プロセスから制御する
Apache Arrow
milter manager
ククログの記事はCC BY-SA 4.0とGFDLのデュアルライセンスで自由に利用できます。
クリアコードはプログラミングが楽しいソフトウェア開発者を1名募集しています。
クリアコードは「クリアコードをいい感じにする人」を1名募集しています。
クリアコードはフリーソフトウェア開発で培った技術力を提供しています。特にMozilla製品(Mozilla FirefoxとMozilla Thunderbird)とRubyとGroonga(全文検索)に関連した開発を得意としています。