Hadoop ソースコードリーディング #16
- 日 時： 2014年5月29日（木） 19:00～21:00 （受付開始 18:45）
- 場 所： 豊洲センタービル （NTTデータ） ← いつもの隣のビル！
- 地 図： http://www.nttdata.com/jp/ja/corporate/profile/guide/map.html （有楽町線豊洲駅3番出口を出て、左手奥の建物。エスカレータを上がった1Fに受付を設営します）
- 定 員： 120名
- Spark 、個人的にはまだ触ったことがないのだけれど、久々に Hadoop ソースコードリーディングが開催されるということで、参加してきました。
- 今回は、 Hadoop ソースコードリーディングというより、 Spark ソースコードリーディングだったというのはおいておいて、、
- 飲み食いなし！
- 本当にソースを読んだ！！
- スピーカーなお三方のプレゼンは堂々としてネ申！！！
なまさにザッツ・ストイックなすばらしい勉強会でした。
- では、一応ブログかくまでが勉強会ということで、とれた範囲でわたしがとってきたメモをいつもどおり公開しておこうと思います。
冒頭挨拶
- 125 人が受付、実際に席は 110 席くらいしかない。詰めて座ってね
- 飲食禁止だけど、ペットボトルはおk
- Spark 1.0 まだでてないけどやるよ
- Databricks 社さんによると、今週から来週出るよ、といってるらしい
- 今日は大きく二部構成
- 猿田さん、土橋さん @NTT data のお二方から、
- Apache Spark のご紹介（前・後編）
- @taroleo さん @TREASUREDATA から、
- Spark Internals
- 猿田さん、土橋さん @NTT data のお二方から、
Apache Spark のご紹介（前編） by 土橋さん
- Hadoop 歴 6 年
- Storm やったり Spark やったり
- ここ一年くらいは Ansible (日本でも Ansible 勉強会)
- Spark やったことない人には進出キーワードがごっそりでてくるはずだよ
- 今回の資料で紹介する内容は基本的に机上調査＋ソースコード調査 (Scala) をもとにしています
Spark の背景
- Spark とはオンメモリデータ処理の分散処理基盤
- 大規模データの分散処理をオンラインで
- データ処理して HDD に都度書くより高速
- Hadoop とは異なるアイデア・方法でデータ処理を実現する
- UCBerkley, Resilient distributed dtasets (RDD) が基になっている
- Hadoop はスキップします
- 繰り返し処理では、 IO コストの課題に対処が必要
- そして業務処理・データ分析の中には繰り返し処理が現れる
- HDFS に毎回データを保存できるコストが無視できない
- DWH にデータを転送するコストも無視できない
- Hadoop はパワフルだけど・・・
- もうすこし繰り返し計算を効率よくできないか？
- 業務処理が煩雑でジョブが 200 段くらいになていたりする
- インタラクティブなドリルダウン分析につかえないか？
- 速さと使い勝手のよい REPL がほしい
- もうすこし繰り返し計算を効率よくできないか？
- そんなわけで Spark ですよ
- Spark は繰り返し処理を高速に実現
- データがメモリ上におかれるためレスポンスに優れる
- 小規模をつづけて大規模を実現
- データがメモリ上におかれるためレスポンスに優れる
- Spark は大量データを次々に変換する処理が得意
- Java や Scala のコレクション操作のようなメソッドやフレームワークを利用できるため
- Spark は Hadoop の仕組みも利用する
- 得意
- Hadoop で加工したあとのドリルダウン分析
- TB 級までのデータを扱うシステム
- サンプリングが有効でないロングテールのデータ分析
- 数秒〜数分級の Hadoop よりも短いレスポンスが必要な処理
- 得意
- Hadoop などを含むエコシステムでなりたつ（互いの得意分野が少しづつ異なる）
- PostgreSQL 厳密性
- Spark インタラクティブなデータ処理
- Storm
- Hadoop とにかくパワーが必要なもの (ETL)
Spark Summit 2013 の様子とホットトピック
- 2013/12/02-03
- San Francisco
- 450 attendee
- 2days
- 会場は満員御礼
- Databricks CEO: Spark がすべての基盤になるところを目指している
- Hadoop とは共存する
- Cloudera との提携の背景もある
- Y! 事例と Spark の特徴紹介が多かった
- 開発母体である OSS Community が成長してくると、機能拡充や不具合への対応が加速する
- Code のコミット量多し
- UCBerkley 学生の活動活発
- 実は 2012 から Conference への露出はあった Spark
- Hadoop の機能を利用しやすくなっている
- Shark : Hive で培われた SQL による分散処理を利用
- HDFS : Spark の入出力やデータの永続化に利用
- YARN : 高度なリソースマネジメント
- Y! 台湾でパーソナライズに利用されている
- Hadoop から Spark へ置き換え
- 数人程度、数ヶ月で置き換えたという
- 低レスポンスが求められる繰り返し処理を
- スループット重視 Hadoop
- レスポンス重視 Spark という使い分け
- コンテンツ配信でユーザエクスペリエンス向上を狙う
- CONVIVA 社 (Databricks 関連会社)、身内賛辞
- 以下に素早く Feedback するか
- 良かった点
- 分析の高速化、ビットレート向上にたしかに貢献
- スケールさせやすかった
- 苦労した点
- 故障対処と運用
- Spark の基盤に関する独自の知識 (特にデータモデル)
- デバッグにも特殊の知識
- Spark
- Scala, Python の IF を持っている
- Hive 互換
- Java
- Spark エコシステム
- Shark
- SQL で記述できる分散処理フレームワーク
- クエリや UDF は Hive 互換
- Spark Streaming
- MLlib
- Spark で使える機械学習ライブラリ
- Scala, Java, Python
- Mahout 、 Hadoop やめて Spark に？
- Shark
Apache Spark のご紹介（後編） by 猿田さん
(参考) Spark の技術トピック
Spark での典型的な処理のイメージ
- Spark では RDD と呼ばれる抽象データセットの変換を繰り返して目的の結果を得る
- この一連の処理をジョブと呼ぶ
- Spark 版のワードカウントの例 (資料参照)
- もう少し複雑な処理のイメージ
- これも資料をみたい
- Spark のデータ処理をざっくりというと
- RDD という抽象データセットを繰り返し変換し結果を得る
- ユーザが定義した RDD の系譜 (Lineage) にしたがって処理を実施する
- 図解がとてもわかりやすい
Spark が扱う基本的な抽象データセット「RDD」の概要
- RDD とは？
- コレクションのようなデータ構造、内部の要素をイテレートできる
- パーティションに分割され、サーバ上で分散配置
- インメモリ
- 遅延計算される (計算を行うタイミングをスケジューリングされたあと、実際に計算される)
- イミュータブル (フォールトトレラント性を確保)
- 欠損に備えつつ、ネットワーク転送をできるだけ避けたい
- 得たいデータが失われていたら、前のデータを再生成するというアプローチをとっている
- 途中の RDD が欠損しても生きてる RDD から復元できる
- そのための制約
- RDD はイミュータブルであること
- 元データのデータソースは信頼性が高くイミュータブルであること
- コレクションのようなデータ構造、内部の要素をイテレートできる
- RDD の依存関係
- 狭い依存関係
- 親パーティションが単一の子パーティションの生成に関わっている依存関係
- 図解がわかりやすい
- 広い依存関係
- 親パーティションが、複数の子パーティションの生成に関わっている依存関係
- これも図解がわかりやすい
- 狭い依存関係
クラスタ上での処理やノード間の通信イメージ
- RDD の変換がクラスタ上でどのように動作するのか？
- クラスタを構成するノード
- Client ジョブのキック
- Master クラスタ全体のリソース管理
- Worker 計算資源の提供、管理
- ノード以外の主要な要素
- Driver ユーザが RDD の変換を記述したプログラム
- Executer ワーカ上で動作、実際の計算
- Task ジョブをエグゼキュータが処理可能な粒度に分解
- Scheduler ジョブをタスクに分解したり、タスクのエグゼキュータへの割り当てを担当
- クラスタを構成するノード
- RDD の変換がクラスタ上でどのように動作するか
- 図解がわかりやすい
- 処理順、担当ノードなどがわかりやすく図解されている
- 系譜をもとにタスクを生成したり、エグゼキュータへの割り当てをコントロールするのはスケジューラの役割
- タスク生成までの流れ
- 系譜をステージに分割
- ステージの実行要否
- タスク生成
- タスクの実行場所を決定
- タスクの実行順序をスケジューリング
- 系譜をステージに分割する
- DAGScheduler が系譜をステージに分割
- ステージは系譜中で狭い依存関係が連続して・・・ (missed)
- ステージ分割のステップ
- かなり詳細な図解
- なぜステージに分割するのか？
- パーテションごとにエグゼキュータ１つがまとめて計算できる変換の範囲を決めるため
- 広い依存関係・・・ (missed)
- ステージの実行要否を判定する
- Spark では同一スケジューラで制御される複数のジョブで RDD を共有することができる
- 共有する RDD がすでに計算済み、メモリやディスクが実態を保つ場合、当該 RDD を生成するための前段のステージの実行を省略することができる
- 明示的に RDD をキャッシュした場合
- ステージ内の最後の RDD
- タスクの生成
- DAGScheduler が実行対象の個々のステージに対してタスクを定義する
- 各ステージにおいて、ステージ内の最後の RDD のパーティション数から当該ステージのタスク数が決まる
- ステージに含まれる RDD の変換チェインからタスクあたりの処理範囲が決まる
- タスクの実行場所の決定
- RDD にはプリファードロケーションが定義されている場合がある。 DAGScheduler はそのタスクを実行するエグゼキュータを選ぶにあたってプリファードロケーションをヒントにする
- プリファードロケーションは RDD の種類ごとに定義される
- タスクの実行順序のスケジューリング
- ステージを構成するタスク群はタスクセットとして TaskScheduler に渡される
- タスクセット単位で実行順序のスケジューリング
- 2つのスケジューリング方式
- FIFO
- FAIR
論文紹介
- Resilient Distributed Dataset
- Spark
- あとで探します
Spark Internals by @taroleo , TREASUREDATA.
- いちおうメモってますが、スライドがすでにうｐされていますのでそちらをご覧になったほうがいい内容です！
- 要チェック
- Spark の code をみんなにみてもらおうという企画
- そしてあわよくば Scala のユーザを増やそう、と！！
- すばらしいことに勉強会が始まる前から資料を公開してくれていた。
Spark Code Base Size
- spark/core/src/main/scala
- 一番開発が進んでいるところで 50,000 line
- Scala なので他の言語なら数倍の line があるとおもっていいかも、とのこと
- core なところはあまり変わっていない
- 中心者: mateiz
- Contributer の数は 100 名ほど
IntelliJ Tips
- Scala のコードを速く読むために
- IntelliJ の一択
- Tips は資料が詳しい
- demo
- よく使われているのは map オペレーション
Scala Console (REPL)
- Scala の動作を確認するのに
- $ brew install scala
Scala Basics (Scala で強力なのは)
- Object.
- Singleton, static methods
- Package-private scope.
- private[spark] # visible only from spark package.
- Pattern matching.
- Class に対しても Pattern matching.
Scala Cookbook
- xerial.org/scala-cookbook
- @taroleo さん作：みんな Scala 使いになってほしいな、と作りました、と
以降基本、 Source code を見ながら
Components
Scheduling Process
- RDD Objects
- DAGScheduler
- TaskScheduler
- Worker
RDD
RDD.map operation
RDD Iterator
- StorageLevel
- Off-heap
- Tachiyon
- distributed memory store
- Tachiyon
- Off-heap
Task Locality
- Preferred location to run a task
Delay Scheduling
- Try to run tasks in the following order
- Local
- Rack local
- At anytime
Serualizing Tasks
TaskScheduler: submitTasks
ClosureSerializer
- Clean
- Closure
Traversing Byte Codes
- Using ASM4 library
JVM Bytecode Instructions
- javap -v is your friend, if you want to know of each.
Cache/Block Manager.
- BlockManager
- memoryStore
- diskStore
- shuffleStore
Storing Block Data.
SparkEnv
- Holding spark components.
HadoopRDD
- Reading HDFS data as (Key, Value)
Mesos Scheduler
- 2 Types
- Fine Gained
- Coarse-grained
Cleanup RDDs
- Notified when weakly referenced objects are garbage collected.
QA
- twitter でいくらでも mention してください、とのこと
と、メモは以上です。
とにかくすごい回でした。今回参加できたわたしは幸運でした。（コミュニティーの皆さま、ありがとうございました！）
ってことで、今回はこんなところで。
