Chapter9 #8

1. Google BigQuery
Analytics 読書会#2
2014/08/26(Tue)
tagomoris

2. MapReduce
ここ10年くらいのびっぐでーたなアレ
データ処理の抽象化がキモ
Map: データ変換
Reduce: データ集約
data.map(&:convert).reduce(&:aggregate)

3. キモ(い)

4. かわいい

5. Hadoop
Doug CuttingがYahoo!でつくった

6. MapReduce Design
実はMapとReduceだけじゃない
Map, Combine, Shuffle, Reduce + 分散FS
FS
Map
Map
Map
Map
Map
Combine
Combine
Combine
Combine
Combine
Reduce
Reduce FS
Reduce
Reduce
shuffle

7. Map phase
Map: 副作用なしで作りましょう
これにより順序や並列度を好きにできる
Mapper in MapReduce
input -> [ (key, value), (key, value), ... ]

8. Combine phase
Combiner in MapReduce
Mapperの出力をまとめてI/Oを最適化
Shufflerにわたす

9. Shuffle phase
Shuffler in MapReduce: 要は並列分散sort
sort keyはMapperの出力key
同一keyのvalueは同一Reducerに送る
[(k,v1),(k,v2),...] -> (k, [v1,v2,v3,...])
たいてい最も重い
hash partitioningだけでよい場合も多い
がHadoopは完全なmerge sortを行う

10. Reduce phase
Reduce: 結果セットをまとめる
Reducer in MapReduce
(k,[v1,v2,...]) -> (k,V)

11. MapReduce example
みんな大好きword count
省略！

12. Storage system
MapReduce自体はストレージ非依存
だが実際には分散ストレージが必要
大量の並列DiskI/Oを高スループットで処理
する必要がある
書かれていないが
並列度以外にスループット確保のためのbig
chunk sizeが必要なはず
でも書かれてないってことはGoogleは……？

13. Worker management
Worker managerが必要
Controller in Google MapReduce
Name Node in Hadoop: 間違い！
正: JobTracker (MRv1) or AppMaster(MRv2)
大量のノード管理、failed worker管理、failed
job管理
アクシデントで死んだworkerと、バグや入力
データがおかしくて死んだworkerの区別

14. Comparative analysis(1)
フツーのHWを買い足せばリニアにスケール
Mapper/Reducerを書けばなんでもできる
ノードのspinupが遅い、shuffle待ちが長い
手を動かしながらの解析には向かない
MapとReduceに処理を分解するのはダルい
あれこれやると多段MRになりダルさ倍増

15. Comparative analysis(2)
ダルいんでみんなあれこれ作っている
Cascading: Java+FluentAPI -> MR
Hive,Pig: SQL or SQL-style queries -> MR
PigはSQLじゃないだろ……手続き型なDSL

16. Comparative analysis(3)
MapReduce: 低レベルフレームワーク
いろいろ考えないといけない
Googleではもう普通は直接使わない
FlumeJava経由でMapReduce使う
デカいデータ変換とかで使われてる
データ調査についてはDremel

17. Summary
BigQueryがどう動くか見たよ
Dremel query engine + Colossus FS
次になんか起きたらどうにかできるかもね
HadoopやMySQLと較べたよ
何にでも向くものはないよね、選ぼう
次章はいろんなクエリを見ていくよ