Data-Intensive Text Processing with MapReduce(Ch1,Ch2)

5,325 views

Published on

This document is written about "Data-Intensive Text Processing with MapReduce" Chapter 1 and 2.
It includes basic topics about MapReduce programming model.
Next document will be more advanced topics.

Published in: Technology
0 Comments
9 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
5,325
On SlideShare
0
From Embeds
0
Number of Embeds
2,286
Actions
Shares
0
Downloads
80
Comments
0
Likes
9
Embeds 0
No embeds

No notes for slide

Data-Intensive Text Processing with MapReduce(Ch1,Ch2)

  1. 1. Data-Intensive Text Processing with MapReduce (ch1, ch2) 2010/09/23 shiumachi http://d.hatena.ne.jp/shiumachi/ http://twitter.com/shiumachi
  2. 2. Agenda ● この勉強会について ● 1章 イントロダクション ● 2章 MapReduce基礎 ● 2.1 関数型言語 ● 2.2 mapper と reducer ● 2.3 実行フレームワーク ● 2.4 Partitioner と Combiner ● 2.5 分散ファイルシステム ● 2.6 Hadoop クラスタアーキテクチャ
  3. 3. この勉強会について ● Jimmy Lin, Chris Dyer著の Data-Intensive Text Processing with MapReduce を読む会です ● 全3回ぐらいでやる予定 ● shiumachi, marqs が交代で各章の解説をします
  4. 4. Chapter 1. Introduction 1章 イントロダクション
  5. 5. この本は? ● MapReduceを用いて大量のテキストを処理す るためのスケーラブルな方法についての本 ● NLP(自然言語処理)、IR(情報検索)について フォーカスしてる ● が、グラフなんかも扱ったりする ● Hadoopをベースに扱ってはいるけどHadoop本 ではない ● オライリーのHadoop本でも読んでな [3]
  6. 6. Big Dataの時代! ● 我々のデータ蓄積能力は、データ処理能力を大 幅に上回っている ● Big Data(数十TB以上)を扱うのは当たり前 ● そもそも現実世界は Big Data である ● だから現実世界のシステムはこれに立ち向かわなけ ればならない ● Big Data を扱うのは技術がいる ● 分散処理、アルゴリズム、etc...
  7. 7. 世界の企業が扱うBig Data ● Googleは2008年時点で20PBをMapReduceで 処理してた ● eBayは約10PB ● FaceBookは2010年時点で15PB [1]
  8. 8. なんで Big Dataを扱うの? ● 「そこにデータがあるからだ」 ● たくさんのデータがあれば、よりよいアルゴリ ズムを使うことができる ● 現実世界の問題を解決しやすくできる これで Why は説明した この本の残りは全て How について説明する
  9. 9. クラウドコンピューティング ● かつて「ユーティリティコンピューティング」 と呼ばれていたもの [2] ● ユーティリティコンピューティングの基本コン セプトは、「Everything as a Service」
  10. 10. IaaS, PaaS, SaaS そして MapReduce ● IaaS とは、物理ハードウェアの抽象化である ● PaaS, SaaS も同様の説明ができる ● そして MapReduce プログラミングモデルも、 大量データ処理を「どのように」処理するかと いう問題から「どんなデータを」処理するかと いう問題を分離するための強力な抽象化である
  11. 11. IaaS, MapReduce IaaS ここで抽象化 ハードウェア ネットワーク MapReduce ここで抽象化 分散処理のマネージャ (リソース管理、ジョブ管理、 障害管理、データ管理etc...) 計算ノード 計算ノード 計算ノード 計算ノード
  12. 12. MapReduceの基本コンセプト ● スケール「アウト」、「アップ」じゃないよ ● 障害発生は当たり前 ● データのある場所で処理 ● シーケンシャルにデータ処理し、ランダムアク セスを避ける ● Ap開発者からシステムレベルの詳細を隠蔽する ● シームレスなスケーラビリティ
  13. 13. MapReduceは何が違うのか? ● 世界中で広く採用された、最初の非ノイマン型 モデル ● MapReduceは最初の並列処理モデルではない ● PRAM, LogP, BSP, etc... ● MapReduceは最後の並列処理モデルではない ● 欠点もいろいろある だからこそこの本で MapReduce を学ぼう はじめよう、我々の冒険を!
  14. 14. Chapter 2. MapReduce Basics 2章 MapReduce 基礎
  15. 15. 分割して統治せよ Divide and Conquer ● 巨大なデータを扱う問題に対処するには今のところこの方 法しかない ● しかし以下の通り、実装は難しい ● どうやって巨大な問題を小さなタスクに分割するのか? ● どうすれば個々に性質の違うワーカーに対し効率よくタスクを割り当て ることができるのか? ● どうすればワーカーが必要なデータを確実に取得できるようになるの か? ● どうすればワーカー間で同期をとることができるのか? ● どうすればワーカーの出した結果を別のワーカーと共有できるのか? ● ソフトウェア・ハードウェア障害が起きる中でどうすれば上の要件を満 たすことができるのか?
  16. 16. この章で話すこと ● MapReduceプログラミングモデルとその下に ある分散ファイルシステムについて説明する ● 関数型プログラミング言語について(2.1) ● mapper, reducer (2.2) ● 実行フレームワークとジョブ (2.3) ● partitioner, combiner (2.4) ● 分散ファイルシステム (2.5) ● Hadoop クラスタ (2.6)
  17. 17. 2.1 関数型言語
  18. 18. 関数型言語 ● MapReduceのルーツは関数型言語である ● 関数型言語の(ここでの)重要な特徴は2つ ● 高階関数 ● 関数の引数として関数をとれる ● map, reduce は2つの有名な高階関数 map, fold からきている
  19. 19. 図2.1 map関数とfold関数 map(図のf)はデータの要素を個別に変換するための関数であり、 fold(図のg)はその結果を集約処理するための関数であるとも言える
  20. 20. MapReduceの流れ 1.ユーザ定義の処理を、全ての入力レコードに適 用する 2.別のユーザ定義の処理により、1.で出力された 中間出力が集約される これだけ。
  21. 21. MapReduceのコンセプト 1.MapReduceとはプログラミングモデルである 2.MapReduceとは実行フレームワークである 3.MapReduceとはプログラミングモデルと実行 フレームワークのソフトウェア実装である • Google MapReduce(以下GMR), Hadoop 以外にも たくさんあるよ • マルチコアCPU用、GPGPU用、CELL用などなど • この本では広く使われているHadoopを中心に扱う
  22. 22. 2.2 mapper と reducer
  23. 23. MapReduceで扱うデータ構造 ● MapReduceにおける基本的なデータ構造はキーバリュー 型 ● といってもキーにもバリューにも型の制約はないので実質 好きなデータを使える ● 複雑なデータ構造を使いたければ Protocol Buffers, Thrift, Avro なんかを使えばいい ● 日本なら Message Pack とか ● キーバリューで表せるものはたくさんある ● ウェブページ = [ ( url, html ) ] ● グラフ構造 = [ ( ノードid, [ 隣接したノードid ] ]
  24. 24. mapper と reducer ● それぞれ map, reduce を実行するもの ● 入力→出力が以下の形になるよう定義する map: (k1, v1) → [(k2, v2)] reduce: (k2, [v2] ) → [(k3, v3)] ● map と reduce の間の中間データに対し、分散 group by の処理を行っている
  25. 25. 図2.2 MapReduceの流れ(簡易版) 完全版は後ほど登場 ここでは map → shuffle と sort → reduce という流れを把握すればいい
  26. 26. おなじみワードカウント ● 説明は省略 ● 後の章でも出てくる
  27. 27. GMR と Hadoop の違い ● GMRはセカンダリソートができるがHadoopは できない ● キーでソートしたあとにバリューでソートできない ということ(※ しかしHadoopでの手法はHadoop本 にも書いてあるぐらいメジャーな方法だと思うのだ が……?[3] ) ● GMRではreducer中にキーを変更できないが Hadoopはできる
  28. 28. mapper, reducerの制約 ● 副作用を持つことができること ● mapタスク同士で共通のデータを持つことができる ● 関数プログラミングでは不可能 ● これにより最適化アルゴリズムを作ったり (Ch.3)、外部ファイルを利用してさらに高度な 処理をできるようになる(4.4, 6.5) ● 次章からよく出てくる ● 一方で、特に外部リソースを扱う際には競合が 発生し、ボトルネックになりやすい
  29. 29. その他トピック ● mapやreduceに恒等関数を使うと、ただソート したいだけのときなどにも便利 ● BigTable や Hbase などの疎かつ分散された多 次元マップに対して入出力するのも便利 ● 入力なし(あるいはほとんどなし)でMapReduce 使う場合もある ● piの計算とか
  30. 30. 2.3 実行フレームワーク
  31. 31. ジョブと実行フレームワーク ● ジョブ=mapper のコード + reducer のコード ( + combiner , partitioner ) + 設定パラメータ ● Hadoopなどの実行フレームワークは、この ジョブを各ノードに投げて計算させる
  32. 32. 実行フレームワークの役割 ● スケジューリング ● 投機的実行により安定してジョブを完了できる ● データ/コードコロケーション ● 基本はデータのあるノードで計算を実行する ● しかし、それができない場合はデータが移動する ● 同期 ● reduce処理はmap処理が全て完了してから開始 ● エラー・障害ハンドリング
  33. 33. 2.4 Partitioner と Combiner
  34. 34. Partitioner ● map出力のキーを見て、複数のreducerに振り 分ける ● 一番単純な振り分け方はレコードのハッシュを とってmodの結果を使うこと ● Hadoop でいう HashPartitioner ● 上記のように、Partitionerによる振り分けは均 一ではない ● Hadoop ならサンプリングしてデータ量が均一にな るようにする
  35. 35. Combiner ● map処理後の中間データに対し、あたかもreducerを かけるように処理する ● 要するに ミニreducer ● データ転送量を大幅に減らすことができる ● しかし reducer と互換性がないことに注意 ● 入力と出力の型は必ず同じでなければならない、すなわち map出力の型を維持しなければならない ● Hadoopではさらに以下の制約がある – 何度でも(0回でも!)実行されうる
  36. 36. 図2.4 MapReduceの流れ(完全版) 図2.2 に combiner と partitioner を加えたもの。 Hadoopの実装とは異なることに注意
  37. 37. 2.5 分散ファイルシステム
  38. 38. 大量データ処理におけるファイルシステム ● 「読んで処理して書く」という基本は同じ ● HPCではNAS/SANを使用 ● ノード数多くなると、ノード間の通信がネック になる ● 10GbEやInfinibandを使うと高い ● MapReduceでは分散ファイルシステム(DFS)を 使う ● 別に必須ではないが、DFS使わないとMRの恩恵は あまり得られない
  39. 39. DFS? ● 別に新しいアイデアじゃない ● データは64MBなどの大きめのブロックに分割 し、複数にレプリケーションした上で異なる ノードに分散配置 ● 名前空間はマスタ−が管理 ● Google File System(GFS) では GFS Master ● Hadoop Distributed File System(HDFS) では namenode
  40. 40. HDFSにおけるデータシーケンス ● クライアントはまずネームノードに問い合わせ ● データの場所を確認後、スレーブ(データノー ド)と直接通信 ● 図2.5も参照のこと
  41. 41. 図2.5 HDFS 名前空間(だけ)はネームノードが管理 クライアントはデータノードと直接データのやりとりをする
  42. 42. レプリケーションファクター ● データをどれだけ冗長化するかを示すパラメー タ ● Hadoopはデフォルト3 ● ノードに障害が起きた場合は、別の生きている ノードに残りの2つのデータブロックからコ ピーし、RFを一定に保つ ● 一方、ノードが復帰しコピーが4つになった ら、不要な1ブロックを削除する
  43. 43. DFSの特徴 ● そこそこの数の大きなファイル(数GB〜)を扱う ● バッチ指向、たくさん読んでたくさん書く ● 低レイテンシよりも持続的な帯域確保が重要 ● 非POSIX準拠 ● 不特定多数が扱えるほどの認証機構はない ● Hadoopは一応0.21でKerberosが入ったが Experimental ● コモディティサーバを使うこと前提なので障害 は当たり前→だから自己監視・修復が必須
  44. 44. DFSの弱点 ● CAPのC重視 ● P(分割耐性)はDFSではどのみち無理 ● GFS,HDFSはA(可用性)よりC(一貫性)を取った ● マスタサーバはSPOF ● ホットスタンバイのマスタを用意したりとか、対策 はしっかりとっておこう ● データ通信をするわけじゃないのでボトルネックに はならない
  45. 45. 2.6 Hadoop クラスタアーキテクチャ
  46. 46. 図2.6 Hadoopクラスタ でもこの図セカンダリネームノード(チェックポイントノード)が ないので現実の構成としては不完全な気がする
  47. 47. Hadoop上でのジョブの流れ ジョブ実行開始(JobTracker) ジョブをTaskTrackerに配布 Mapタスク実行 タスク数はユーザ指定パラメータだけでなく ブロック数にも依存 Reduceタスク実行 ユーザが任意のタスク数を指定可能 ● mapやreduceでは外部データを持たせることも可能 ● 統計データとか辞書読ませたりできる ● 開始時と終了時にフックできるHadoop API が提供されている (Javaのみ)
  48. 48. 参考文献
  49. 49. 1. Facebook has the world's largest Hadoop cluster!, Facebook has the world's largest Hadoop cluster!, http://hadoopblog.blogspot.com/2010/05/facebook-has- worlds-largest-hadoop.html 2. ユーティリティコンピューティング, wikipedia, http://ja.wikipedia.org/wiki/ %E3%83%A6%E3%83%BC%E3%83%86%E3%82%A3%E3%83%AA %E3%83%86%E3%82%A3%E3%82%B3%E3%83%B3%E3%83%94%E3%83 %A5%E3%83%BC%E3%83%86%E3%82%A3%E3%83%B3%E3%82%B0 3.Hadoop, Tom White, オライリー・ジャパン, 2009 4.
  50. 50. Thank you !

×