AMP Campをひと通りさらってみる：第3回 Explore In-Memory Data Store Tachyon
Explore In-Memory Data Store Tachyonのメモ
- Tachyonはworking setのファイルをメモリ上に保持し、異なるジョブ、クエリやフレームワークからキャッシュされたファイルにメモリのスピードでアクセスすることを可能にする
- 頻繁に読まれるデータセットのディスクへのロードを避けることができる
- TachyonはSparkやMapReduceのプログラムをコード上の変更なしに動作させられる互換性がある
- オフヒープ領域を使うので、つまりRDDは自動的にTachyon内にデータを保持することができ、Sparkにより強い耐障害性とGCのオーバーヘッドを避ける事ができる
Configurations
conf/tachyon-env.shに変更を加えるTACHYON_WORKER_MEMORY_SIZEがworkerのメモリサイズ
Format the strage
- ということで例に従ってやってみるもtachyonが起動せず。。。
- が、ここでは本論ではないので時間を使いすぎずにさっと眺めてみることに
- SparkContextにtachyonの設定を追加するだけで普通のSparkと同じように使えます。
- それなのにGCのコストが低減したり、executorがクラッシュした際にもデータは保たれていて素敵、というシロモノのようです。
動画のメモ
AMP Camp 5: Tachyon - Haoyuan Li - YouTube
- メモリはthroughputが指数関数的に伸びている
- 一方で、ディスクにはもう伸びの限界が来ている
- もっとメモリをうまく使うべし
- メモリをうまく使うアプローチは色々ある
- Spark, Impala, HANA, DBM2, etc...
- 問題1：データ処理をパイプラインで繋げる時、データの受け渡しがボトルネックになる
- すなわち、処理と処理との間のデータの受け渡し
- Sparkだと単一のタスクではデータはメモリ上にあるが、別のタスクに渡す際に、一度HDFSやS3を経由するので遅くなる
- 問題2：プロセスがクラッシュするとキャッシュしていたデータが無駄になる
- 問題3：異なるSparkのタスクが同一のデータを使おうとしていた場合、データの重複が起こる
- 問題を解決するために、メモリのスピードでクラスタ上のフレームワーク間でデータを共有するファイルシステムとしてTachyonを作った
余談
oxdataにはH2Oという機械学習ライブラリをオープンソースで公開しています。H2OはSpark対応が行われたSparkling Waterというのがあって、これまでイマイチ理解できていませんでしたが、ここまで学んできたことでようやく全貌を理解出来た気がします。
- RDDを拡張したH2ORDDを提供
- 処理自体はH2O本体のものを利用（この例ではH2OのDeepLearningを利用）
- データ取得部分などはSparkSQL等に任せ、その結果をTachyonに載っけておいて、H2OからはTachyon上のデータを参照する。（Sparkling WaterのスライドのP23-P31）
みたいな感じですね。H2Oはかなり早くからTachyonを利用することを念頭において開発が進められていたということで、なるほどな、と。
