広告配信サービス「UZOU」

現在、畑中氏は株式会社Speeeに在籍し、「UZOU」という広告配信サービスを配信を行う事業部に所属されています。
畑中氏はその中で、アルゴリズム部分の実装やGoによるバッチ処理の実装に携わる部分を担当されています。

PHP等からRubyへ移行、エンジニアのほとんどがRubyを使用

株式会社Speeeは、2007年に創業し、当時はPHP等を使用していたそうですが、約2年前に会社の使用言語をPHP等からRubyに徐々に移行して行き、システムやサービスの約８割をRubyに切り替え、今では、社内のエンジニアのほとんどがRubyを使用しているということでした。
ただ、一部では適材適所で他の言語を使用することはあるようです。

このイベントに参加されている方は軽量Rubyの活用を検討していたり、実際に活用している方が多いと思いますが、そもそも、軽量Rubyで大量のデータをどう活用・分析されているのでしょうか？

最近ではビックデータという言葉がよく聞かれるようになりましたが、定義が曖昧ではないでしょうか？畑中氏による定義はこちらです。

1. データ量が多い

みなさんが持っているイメージそのもの、大きなデータ。

2. 急速に増える

例えば、広告配信でお客様のサイトに広告を出すと、そのアクセスログはサーバに返ってきて日々急速に増えていっている

3.元となるデータの種類が様々

JSONやエクセルなど様々なデータフォーマットを取り扱う

スライドより

では、それぞれのシステム間のデータ連携をどう実現するか？

現状では、それぞれのシステムでは独自のメモリ構造をもっているので、実際に連携しようという時には、一度、CSVやJSONのようなファイルに出力し、連携するシステムの方に持って行き、それにアクセスし読み込めるような形にするという方法が一つ目の方法です。

もう一つの方法としては、Parquet（https://parquet.apache.org/）と呼ばれるディスク上で列指向でデータを扱うフォーマットを使うなどしてシステム間の連携行う方法があります。

現状はこういった例がよく見かけられます。
畑中氏のチームでは、TSVで出力したものを、別のシステムに持って行き連携し読み込み直す、というようなアプローチを取られています。
しかし、この場合、数MBくらいのデータであれば問題ないのですが、数TBなどといった大きなデータになってくると、データ交換コストは無視のできないものになってきます。

スライドより

スライドより

ロー型

カラム型と対になって、行指向やロー型といった、行単位でデータを管理する方法です。

カラム型

列でデータを管理する方法。
縦にデータを格納しているため、格納されたデータは同じ型なので圧縮効率が良くなります。
例えば、価格などを集計する際は、列でデータを扱えるため、ロー型のように他の列を参照しないで、ロー型より早く集計することができます。

1. Fast

● 最新のプロセッサに含まれるSIMD (Single Instruction/Multiple Data)を使用することが出来ます。

● カラム型のデータを扱えることでCPUキャッシュを効率よく使用することが出来ます。

● コピーなしでデータを読み込むZeroCopyをサポートできます。

2. Flexible

● Java, C, C++, Pythonなど各種言語から扱うことが出来るのでArrowに対応したシステムを柔軟に扱うことが出来ます。

● 他の言語に関しても対応は進められています。

3. Standard

● Calcite, Cassandra, Drill, Hadoop, HBase,Ibis, Impala, Kudu, Pandas, Parquet, Phoenix, Spark, Stormの13のビックデータ関連プロジェクトの開発者が参加

● Apache Incubator が省略されたApache Software Foundationのトップレベルプロジェクト

例えば、PandasとCassandraを連携しようとする場合、まずPandasでコピーしてConvertしてCassandraの方で読み込み直す対応を行わなければなりません。 一つならまだいいですが、３つ４つ…と増えていくと複数に関連し合うことになります。 そうなってくるとシステムが複雑になり、CPUが無駄に使われてしまいます。

共通のメモリフォーマットと呼ばれる「Apache Arrow」を使うことで、複雑さが解消され、真ん中の共通のArrow Memoryを介してデータを連携することができるようになるので、CPUも無駄に使われることなく、非常に効率良くデータを連携できるようになります。

● Rubyで集めたデータをArrowに対応しているPandasやSpark 　に連携し分析した結果をRubyで受け取って、Railsを使った 　webアプリで可視化、ということができるようになる

● PandasやSpark部分を徐々にRubyへ移行することも出来る

これが共通データフォーマットを使用する強みと言えます。

例えば、図のようにmruby、Rubyで出たデータをApache Arrowを介して、Pandasなどと連携していって解析を行います。その結果を受け取って、Railsのアプリ上でグラフや図などのわかりやすい形で表示することができます。

スライドより

スライドより

Apache Arrowって、よさそうなプロジェクトだけど、そもそもRubyからApache Arrowを使うことができるのでしょうか？

もちろん、RubyからApache Arrowを使うことは可能です。

Red Arrowというgemによって、RubyはApache Arrowに対応できるようになったということです。

 

red-data-tools/red-arrow

検証内容

● Pythonで約2GのデータをCSV, Apache Arrowで書き込みRubyでそれぞれを読み込む

● 各フォーマットにおける書き込みと読み込みの時間を計測して比較を行う

検証環境

● AWSのEC2インスタンスのt2.large

• vCPU: 2, メモリ: 8G
• Ubuntu: 16.04.2 LTS

● Python: 3.6.2

● Ruby: 2.4.1

● Apache Arrow: 0.6.0

スライドより

Python側のCSVの書き込みです。

スライドより

Ruby側のCSVの読み込みです。

スライドより

Python側のApache Arrow形式の書き込みです。

スライドより

Ruby側でRed Arrowというgemを使ってのApache Arrow形式の読み込みです。

CSV

まずはCSVの方から。
トータルで51秒の時間がかかっています。
Rubyで5秒くらいの読み込み時間でした。
４万行くらいのデータです。

Apache Arrow

Apache Arrow形式では、
書き込みに3.4秒くらい
Rubyでの読み込み時間は約2秒くらいで終わりました。

1. Red Arrow

● Apache ArrowのRubyバインディング

● Rubyバインディングの開発だけでなくApache Arrow本体の開発も行っている

2. 既存のgemのArrow化

● SciRuby

• 科学技術計算、データ可視化用途のGem群の総称
• Pythonでいうpandasにあたるdaruやnumpyにあたるnmatrixなどがある
• Gem間が独立していて連携が難しい

● PyCall

• @mrknさんが作成されているRubyとPythonのブリッジライブラリ
• Pythonで作成された既存の資産を使うことが出来るのでRubyでPythonのオブジェクトを使用することが出来る

3. 新しいツールを提供

● red-data-tools/xtensor-arrow-glib

• xtensorと呼ばれるC++で実装された多次元配列を扱うライブラリのApace Arrow対応
• Pythonでいうpandasにあたるdaruやnumpyにあたるnumo-narryなどがある

● red-data-tools/red-chainer

• • Python製の深層学習フレームワークのChainerをRubyへポーティングしたもの