この記事は公開されてから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 さん）
@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の数を決定する方法が実装され、その後クラスタ全体のリソース状況を考慮するものが実装されるのでは
感想など
TezはDAGらしいという程度の知識しかなかったので、とても勉強させてもらいました。ありがとうございます！おかげさまで雰囲気は理解できた気がします。あと、参加していてSparkは必須の知識になっているんだなーと思いました。
14
