Google BigQuery Analytics 読書会#2

2014/08/26(Tue)tagomoris

MapReduce

ここ10年くらいのびっぐでーたなアレ

データ処理の抽象化がキモ

Map: データ変換

Reduce: データ集約

data.map(&:convert).reduce(&:aggregate)

キモ(い)

かわいい

Hadoop

Doug CuttingがYahoo!でつくった

MapReduce Design実はMapとReduceだけじゃない

Map, Combine, Shuffle, Reduce + 分散FS

FS

Map

Map

Map

Map

Map

Combine

Combine

Combine

Combine

Combine

Reduce

FSReduce

Reduce

Reduce

shuffle

Map phase

Map: 副作用なしで作りましょう

これにより順序や並列度を好きにできる

Mapper in MapReduce

input -> [ (key, value), (key, value), ... ]

Combine phase

Combiner in MapReduce

Mapperの出力をまとめてI/Oを最適化

Shufflerにわたす

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を行う

Reduce phase

Reduce: 結果セットをまとめる

Reducer in MapReduce

(k,[v1,v2,...]) -> (k,V)

MapReduce example

みんな大好きword count

省略！

Storage system

MapReduce自体はストレージ非依存だが実際には分散ストレージが必要大量の並列DiskI/Oを高スループットで処理する必要がある

書かれていないが並列度以外にスループット確保のためのbig chunk sizeが必要なはずでも書かれてないってことはGoogleは……？

Worker management

Worker managerが必要Controller in Google MapReduceName Node in Hadoop: 間違い！正: JobTracker (MRv1) or AppMaster(MRv2)

大量のノード管理、failed worker管理、failed job管理アクシデントで死んだworkerと、バグや入力データがおかしくて死んだworkerの区別

Comparative analysis(1)

フツーのHWを買い足せばリニアにスケール

Mapper/Reducerを書けばなんでもできる

ノードのspinupが遅い、shuffle待ちが長い

手を動かしながらの解析には向かない

MapとReduceに処理を分解するのはダルい

あれこれやると多段MRになりダルさ倍増

Comparative analysis(2)

ダルいんでみんなあれこれ作っている

Cascading: Java+FluentAPI -> MR

Hive,Pig: SQL or SQL-style queries -> MR

PigはSQLじゃないだろ……手続き型なDSL

Comparative analysis(3)MapReduce: 低レベルフレームワーク

いろいろ考えないといけない

Googleではもう普通は直接使わない

FlumeJava経由でMapReduce使う

デカいデータ変換とかで使われてる

データ調査についてはDremel

Summary

BigQueryがどう動くか見たよ

Dremel query engine + Colossus FS次になんか起きたらどうにかできるかもね

HadoopやMySQLと較べたよ

何にでも向くものはないよね、選ぼう

次章はいろんなクエリを見ていくよ