Hadoopソースコードリーディング第17回に参加してきました

Satoshi Noto

2014.09.10

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

Hadoopソースコードリーディング第17回に参加してきました。今回のテーマは7月にApacheのTop-Level Project入りしたばかりのApache Tezについてでした。なお、全体的にApache Sparkと比較する形での説明が多かったので、Sparkについてご存じない方は前回のHadoopソースコードリーディング第16回に参加してきましたをご参照下さい。

NTTデータ濱野さんの冒頭の挨拶

今日は別のイベントも多いためいつもの半分ぐらいの参加者だが、その分Deepにやれれば
いつもの会場だと途中からピザとお酒だが、今回の会場は飲食禁止なので最後までシラフで
Tezに関する勉強会は初回なのにいきなりタイトルがInternalsとかになってますねｗ

Tez Internals （@oza_x86 さん）

@oza_x86 さんからはTez Internalsということで、Sparkと対比しながらのTezの概要の説明、WordCountを例にAPIの解説がありました。

本日の資料はApache Tez Source code reading
TezとSparkの比較
- 参考資料Apache Tez: Accelerating Hadoop Query Processing
- 皆さんSparkは知ってますよね？昨日のやつ参加してますよねｗ
- TezはYARN前提
- ソフトウェアスタックとしてはSparkと衝突する
- Sparkとの比較はバージョンによって性能が大きく変わるので一概にいえない
- Tezはディスクベースに最適化している。一方Sparkはインメモリから始まっているので、そこが大きな違い
- Tezはレイヤーが1つ低い。上位Hive、Pigなどのアプリケーションが追従しない場合は自分たちにコミッターがいるのでパッチをあてて対応させている。Sparkは単体Spark DSLが存在して利用できる
- 一番の違いはRDDの有無
- Dynamic reconfiguration APIsでReduceの数を自動で決めてくれる。DryadのOptimusみたいなもの。統計情報からDAGを書き換えるようなもの。Tezはそこまではやっていないが
- Q. Apache Flinkとの違いは？ -> A. こちらはコンパイラでがんばる感じ
ソースはHadoopよりも読みやすい
動作させるにはHDFSにjarを置いて、ちょっと設定を変えるだけ。MapReduceはエミュレータの実装があり、Hiveは処理系をTezに変える
処理モデル
- Vertex
- Tezはタスク間のデータの受け渡しをユーザーが定義できる
  - One-To-One
  - Broadcast
  - Scatter-Gather
API
- Vertex毎にVertexManagerがいる。例えばOne-To-Oneに対応するshuffleしない実装のVertexManagerが存在する
WordCount
- https://github.com/apache/tez/blob/release-0.5.0/tez-examples/src/main/java/org/apache/tez/examples/WordCount.java
- 263行あって、Spark好きが見たら。。。
- TokenProcessor
  - MapReduceにおけるWordCountのMapperに相当する
  - kvReaderはHadoopのソースを読んだことがある人はわかるがMapReduce内部のソースでも同じように書かれている。Tezはより低レイヤーなのでこれをAPIとして露出している
- SumProcessor
  - MapReduceにおけるWordCountのReducerに相当する
  - Q. 識別子（vertexName？）の単位は？　→　A. Vertex単位？
  - APIを見ていて思うが、一般のユーザーが使うものではないのでは。あくまでHiveやPig経由で使うことを想定しており、これはそういうものを作る人向けのサンプルなのでは
ShuffleVertexManager#TEZ_SHUFFLE_VERTEX_MANAGER_ENABLE_AUTO_PARALLELをtrueにすることでDynamic reconfigurationが有効になる。

アプリケーションエンジニアから見たTez （@marblejenka さん）

Hadoop Source Code Reading #17 from Shingo Furuyama

@marblejenka さんからはTezの周辺、Sparkとの比較、そして改めてWordCountとの比較についての説明がありました。なお、詳細はスライドをご覧ください。以下は主に口頭のみでスライドに書かれていない点になります。

@oza_x86 さんとネタが丸かぶり。。
Twitterなどでよくつぶやいている「この豚野郎！」はPig使って欲しいという意味でつぶやいていた
Tezは本格的に触っているわけではない。仕事でも今のところ使っていない
Tezが出てきた背景はProposalにもあるようにHiveやPigにMapReduceは向いていないから
Tezの系譜としてはNephele/PACTsとHyracksに影響を受けているらしい
Dryadは論文を4回読んで4回挫折した。何がすごいか分からなかったが、難しいということは分かった。実装が公開されているので、何がすごいのか教えてください
FlinkはNephele/PACTsの実装。RoadmapにTez上で動作させるとあるので、将来的にTez上でSparkっぽいAPIを使いながらScalaで書けるようになるはず
TezとSparkの比較
- Tezに動的最適化があったり、SparkにのみRDDがある点。あと、Tezは既存のMapReduce実装を使いまわせる
- Sparkは機械学習で、それ以外はTezがいいのでは
Tezを作っている人は元MSとか元Yahoo!なので期待できますね！
アプリケーションの作り方
- ProcessorがMapper/Reducer的なもの。Processorを組み合わせてDAGを作る
- 忘れているかもしれないので改めてWordCountの説明
- テストは書きやすくなさそう
- デプロイはjarを置くだけなのでとても簡単。複数バージョンもインストール可能なのがいい
- Swimlanesmで処理結果を後で可視化してチューニングできるのが嬉しい
- DAGがTopologyになったら本気出そうと思っていたらDAGのままとなった　←　0.5でAPIがstableとなったので名前はもう変わらないのでは？（@oza_x86 さん）
Processorを生で書くのは時期尚早感があるのでまずはPigやHive経由で
MapReduceはなくならないのでは。耐障害性の部分が異なるので。MapReduceであればその直前のReduceの結果は保証される（と言うといろいろ刺されますが。。）
QA
- Q. HDP以外でもTezは使える？ -> A. 使える
- Q. Hive on Tez
  - Costベースのオプティマイザは実装されてなくてOracleから来た人がOptimusとセットで実装している
  - KVReaderがハングするというバグがある　←　もともとMRの頃からあったものでは。修正中のはず

おまけ

Tezの動的最適化がよく分からなかったので個人的に@oza_x86 さんに質問しました。かなりイメージがわくようになりました。ありがとうございました！

Q. Tezが最適化出来る範囲はどこなのか？ -> A. Reducerの数。なお、Scatter-Gatherの場合のみ。One-To-Oneであれば1:1になるし、Broadcastの場合も全体に配るだけなので
Q. どうやってReducerの数を変えるのか？ -> A. 出力したデータを一時的に貯めておいて、そこで探索するとか？まだ分かっていないので調べる予定
Q. Reducerの数を最適化したい理由は？ -> A.Hadoopクラスタの有効活用。単一のジョブでリソースを専有できるならReduce slotを使いきればよいが、複数のジョブが実行される場合は全体の利用状況を考えてReducerの数を決める必要がある。
Q. ということは、クラスタの情報をInputとして渡すことになるのか？ -> A. 将来的にはそうなるのでは。まずはクラスタ全体は考えずに単純な方法でReducerの数を決定する方法が実装され、その後クラスタ全体のリソース状況を考慮するものが実装されるのでは