Hadoopソースコードリーディング第5回

Hadoopソースコードリーディングに（開催はもう5回目なのに）初めて参加しました。
（→Hadoopソースコードリーディング第5回 ハッシュタグまとめ）

今日の会場は楽天タワーだー。品川シーサイド駅から徒歩1分。
って外に出るまでの地下が長いじゃん。やられた＾＾；

---

最初はNTTデータの濱野さん。Hadoopチーム11人でやってるそうで。

・数十TB～100TBをPostgreSQLでやってきたが
・10億件超・60万件/時でHadoop
・2008年ごろから数十～数千台のクラスターを動かしてきたので、環境の同一性確保や故障時の再構築といった運用面のノウハウがある。
・2～3台ではHadoopを生かせない。20台くらいのクラスターが今後増えてくるのではないか。

・台数を増やすとスペックの違うマシンが混在するようになってくる。すると処理遅延や処理失敗を引き起こす。★★★
300台構成のクラスターは、全部同じスペックにした。
（◆●どういう理由で処理が失敗するんだろう？？）

・1000台構成だと、エンドのスイッチは安めだが、ラック間は10Gとか。ラック内も1Gとか。

・クラスターの台数は、MapReduceの処理（ジョブ）数ではなく、データ数から決めている。★★★
1TBのハードディスクを4玉、CPUはそれに見合ったもの。

---

次はNTTデータの山下さん。Hadoop Summit 2010の紹介。（◆●6/29、サッカー日本代表の試合の日だったそうだｗ）

Yahoo：
5億クリック/日、のデータを使用して個人の嗜好を分析。
なお、Yahooでは「リアルタイム」を5分間隔としているらしい。★★★
YahooメールのスパムフィルターはGmailより優秀だとか。

Amazon：
今まではHadoop0.18.3・Hive0.4・Pig0.5
これからはHadoop0.20・Hive0.5・Pig0.6
SPOT INSTANCE
Elastic MapReduceで処理時間が短縮・値段も20％削減。

Facebook：
2250ノード・2万3000コア・32GB RAM/ノード・36PB Hadoopクラスター
ジョブの95％はHive
障害に備えて、2クラスターに全く同じデータを入れている。★★★
（◆●実際に障害が発生したことってあるのかな？？）

Twitter：
HBase使用（◆●なんか久しぶりにHBaseの名前を聞いた＾＾；）

その他：
天体画像（星の位置関係を計算）でHadooop利用

◆●Hadoop関連プロダクトの“マスコット”一覧にみんな失笑。“マスコット”という言葉から連想されるような可愛いキャラは皆無だ(爆)

---

@okachimachiorzさん『ClouderaのHdoopトレーニングについて第4回』
（◆●けど自分は初参加なので、前が分からない＞＜）

『グラフアルゴリズムin MapReduce』
グラフはリストや行列で表せる！★★★
行列は数学的には扱いが楽で、逆ポインターも分かる。が、0が多いので無駄が多い。
リストは逆ポインターは分からないが容量がコンパクト。プログラムはこっちを使用する。

探索は深さ優先探索と幅優先探索がある。
深さ優先…再帰的
幅優先……キュー。MapReduceはこちら
MapReduceは関数型だが、分散処理するので幅優先で探索すべし。★★★

『ダイクストラ法』（◆●名前だけは聞き覚えがあるが…）
スタートノードからつながっている全てのノードの距離を幅優先で算出。
次に一番近かったノードに対して同様に処理していく。
しかしこの方法はMapReduce向きではない。（◆●理由はよく理解できなかった＞＜）
なお、Hadoopトレーニングではダイクストラ法は1分で説明が終わったらしい(爆)
→@cocoatomoさんの文系 Hadooper でも分かる Dijkstra アルゴリズム

『SSSP：単一始点最短距離経路』
（◆●説明が早口だったのでほとんどメモ（理解）できなかったorz）
ダイクストラ法が最小のノードだけを調べるのに対し、こちらは全ノードを検索する。
（◆●まぁ数が多くても力技で処理するのがMapReduceか＾＾；）

データによっては、ごく稀に間違った結果が出ることもある。
どこまで行ったら終わりにするかという終了条件が重要。
大抵はベストエフォートでよさそう。（値が一定になってきたら終わる）
原価計算とかなら確実な値が必要。（いつ終わるか分からないけど、最後まで計算する）

『PageRank』
原理：ページの持っているポイントをリンク先に配る
あるページには、複数のリンク元からポイントが入ってくる。（ただの足し算）
そのページから、複数のリンク先へポイントを配る。（ただの割り算）
（ただの足し算と割り算。Googleも大したことないね！by okachimachiorzさんｗ）
ただし、リンク先が無いとそのページにポイントが溜まってしまうので、全ノードにポイントを配る。
このMapReduceを繰り返すと、そのうち収束してPageRankが確定する。

『Hadoopでのjoin』
方法は3通り。
・Mapサイドjoin…王道。ただしメモリーに収まる範囲でやること
・Reduceサイドjoin…join用のキーを同一にしておけば、勝手に集めてくれる。分かり易いがReduceの負荷が上がるのにスケールしないので、やるべきではない
・分散キャッシュ…全ノードにデータを配っておく。トレーニングではmemchachedを使用

（応用として？）分割Map-join…マスターを分割して個別にMap-join。
（◆●マスターを分割してどうして結合できるのか、ちょっと理解できなかった…重要そうな話なのに＞＜）

◆●自分はMapReduceのプログラム方法に興味があるので、join方法の話は面白かった。
分散キャッシュというのは、象本でもSequenceFileをプログラムと共に配布する例が載っていたような。
今度豊洲でHadoopトレーニングがあるらしいが、日本語だったら受けてみたい感じ。

---

@nokunoさんの『MapReduceアルゴリズムデザイン』
（◆●昨日資料が公開されていたけれども、やはり話を聞いた方が理解しやすい＾＾）

パフォーマンス改善の為に、Shuffleフェーズのデータ量を減らそうという話。★★★
Mapperの中で計算して（Combinerと同じことをして）、Combinerを使わないようにする。
Combinerはシリアライズしてたりするので、オーバーヘッドがあるから。
ただし当然メモリーの制限は気にする必要がある。

また、PairsパターンよりStripesパターンの方が良い理由は、エントリーの数が減る、すなわちソートのコストが減るから。★★★

出現頻度が高い単語だけを抽出するような場合、頻度の少ない単語はカットしてしまうような方法が考えられる。
ただしCombinerでカットしないよう注意。（◆●合算すると頻度が高くなるケースも有り得るから？）

キーを可変長整数VIntWritableにすると、キーの量が減らせる。（◆●そういえば、VIntWritableはそのまま大小比較が出来たような気もするので、便利なのかも）

セカンダリーソート：GoogleのMapReduceにはセカンダリーソートがあるらしいが、Hadoopには無いので自前でComparator等を用意する。

◆●初めてHadoopチュートリアルのWordCountを勉強していた頃、「Mapperの中でHashMapに格納して単語数を計算しちゃえばいいじゃん」と思ったけど、そうするとMapReduceらしくないのでダメなのかと思っていた。
今日の発表は、まさにMapperの中で単語数を計算してしまえ、という話だったｗ
「Combinerを使わない」と盛んに言っていたけれど、冗談なのか本気なのか、どちらなんだろう？(爆)

---

最後は@quarterkotaさんのAmazon Elastic MapReduce（EMR）の話
（今日の会場では、EMRを使ったことがある人は1人だけだった模様＾＾；）

なぜEMRを導入したか？
MySQL：
○情報が多い、事例が多い（工数見積もりがブレにくい）
×件数億単位は無理、Oracleに買収されてから怪しい（◆●発表時には敢えて読まれなかった一文ｗ）
Hadoop：
○大量データに強い、事例が増えてきている
×ノウハウ不足、ハードウェアを決定できない（≒スモールスタートできない）
↓
で、AWS勉強会で偶然聞いたEMRに着目
○大量データに強い、スモールスタートに向いている、環境構築工数が少ない
×国内事例がほとんど無い、パフォーマンスが未知数
↓
で、Hiveを使ってパフォーマンスを測定してみた（2・4・8ノード）。
LOADはインスタンス数が多いとオーバーヘッドが多くて遅くなる。
SELECTはほぼインスタンス数に応じた時間になっている。（2ノード→4は半分より良い、4→8はちょうど半分程度）
（でも2ノードではあまり使わないだろう）

EMRは管理性が良い（GUIがある）、Hadoopの知識はそんなに要求されない。
（◆●実際のところ、パフォーマンスを追及すれば、やはり知識が必要になってくるものらしいが）
EMRの情報は少ないが、AWSユーザーコミュニティーがサポートしてくれる（忍者も！）。
EC2の通常のインスタンスとは使い勝手が少し違う。

使われないサーバーリソース（在庫）を自社で持つとコストがかかるが、EMRならAmazonに持ってもらえる。
US-EASTのsmallインスタンスなら1時間0.1ドル。
常駐型でなく、Hadoopを自動起動・自動終了すると良い。

1億2千万件（百数十GB）を8サーバーでSELECTしたのが1200秒＝20分。EMRは1時間毎の課金なので、0.8ドル。

ちょっと別件：S3に構築したら2～3割スピードが落ちた。（その程度で済んでいるとも言える？）

---

◆●最後に、ピザの片付けを手伝いました（残すともったいないので、腹回りを気にしつつも？ｗ）。それくらいしか役に立てなくてごめんなさい。
発表者や会場の皆さん、ありがとうございました。