NTTデータのHadoop報告書を読んでみた

これで話題になっていたのは知っていたけど仕事と関係無かったこともあり今まで読んでなかったんですが、１か月ほど前からHadoop仕事を始めたこともあり読んでみました。

ま、現状はNTTデータから仕事もらっている立場だし提灯記事でも書こうかとw

目次はこんな感じになってます。

で、全部で375ページもあるわけですが、アプリ開発者がとりあえず読むなら２章です。もうちょっと突っ込むなら関連する８章もプラスして読むといいでしょう。どうでもいいけど印刷して読んだほうがいいかも。僕はiPadで読みましたが２章は割とページをいったりきたりしたので。

２章では渋滞解析アプリケーションを事例としてMapReduceアプリをどのように設計して、実装するのかが記述されていてとても参考になります。というかこれだけまとまった情報は象本にもHadoop徹底入門にもありません。これはすごい。

MapReduceというとワードカウントの例が多いですが、あの例だとMapの出力のKeyがワードでValueが1でReduceはそれを受け取るという感じです。

Hadoop徹底入門のp167の疑似コードを借りるとこんな感じ。

def map(offset, line):
  words = line.split

  for w in words:
    emit(w, 1)

def reduce(key, values):
  sum = 0
  for v in values:
    sum += v
  emit(key, sum)

この例を説明されると、あたかも最初からMapで何を処理して、Reduceで何を処理して、KeyとValueが何なのかが決まっている、かのような印象を受けますが、もちろんそんなことはありません。

例えば数学（に限らないけど）の問題で答えを見て納得したからといって、別の（でも似たような）問題が解けるとは限りません。どのように解くべきかという抽象的な思考パターンを身につけないと応用問題は解けません。

受験生なら同じような問題を数多く解くことによってこの思考パターンを身につけるでしょう。僕にはもうそんな気力と集中力が無いですが、この報告書の２章にはMapReduceの設計ノウハウが書かれているのでこれを読んでお茶を濁すことにします。--);

どこに書かれているかというと具体的には2.3.2のMapReduce 設計です。

こんな流れで検討します。

まずは処理フローを明確にするために、各処理の入出力をデータストアとしたデータフロー図を作成します。データフロー図をもとにデータの依存関係を特定し、これによってMap処理、Reduce処理を決定します。

タクシーがどの道路でどの進行方向でどんな速度で走っているのかを解析するタクシープローブ解析の場合はまず処理フローがこのようになります。これがスタート地点になります。入力データは位置情報を含んだセンサーデータであるプローブデータです。

この処理フローからデータフロー図を作成します。

でこれをもとにデータの依存関係を特定します。「入力データのフィルタリング」は入力データを 1 レコードずつ処理するので他方への依存はなく、「道路の選択」では入力データの位置情報のみで選択するので他方への依存はなく、というふうに考えていきます。

しかし「速度の計算」では他方のデータを必要とすることがわかります。速度＝距離／時間ですからね。タクシー１台のある瞬間の１点の位置情報だけでは速度は求められません。グループ化する必要があります。つまり速度の計算の前までがMap処理対象となり速度の計算がReduce処理対象となります。

といった設計の後は2.4のMapReduce アプリケーションの実装で具体的な実装例まで登場します。ソースはorg.apache.hadoop.mapreduce.Mapperなどの新APIを使って実装されています。

これもお茶を濁したようなソースじゃなくて、独自Key,Valueまで作ってます。その流れで独自Comparator, Partitionerまで書いてある。これはキモイ、じゃなくてすごい。

でも、本当にすごいのはこうしたアプリよりの話よりも、運用や構築といったインフラよりの話がすごく具体的に書かれていることかもしれません。

例えば12章のHadoop 基盤における自動構築手法検討はインフラ弱者の僕が読んでも面白いです。とくに12.4.5の名前解決の方式検討と12.4.6の物理配置を反映した命名方式の検討はすごい。

この章ではKickstartとPuppetを用いてHadoopスレーブサーバの自動構築の話が書かれています。これはHadoop徹底入門の7,8章にも書かれてますね。

で、自動構築されるのはいいんですが、テキトーに管理してると例えばIP アドレス 192.168.3.40 のマシンがどのラックのどの場所に配置されているかわからないわけです。そうなるとハード故障してさあ交換だあとか思ってもどれを交換していいかわからずサーバー室で困ること請け合いです。

そのためにホスト名を自動生成してダイナミックDNSに登録するスクリプトを用意して対応しています。

例えばラック番号 3 のスイッチのポート番号 1/0/12 に接続されたサーバならr3-1-0-12.example.netというホスト名になります。

スイッチの各ポート番号に対応したサーバのラッキングを実施することによって、ホスト名とサーバの物理的な配置場所がマッピングされ運用が楽になります。

こんなやり方はかなり案件こなして実際に苦労してないと思いつかないですよ。これはすごい。

とまあ、たしかにすごい報告書です。Hadoop歴１か月の自分と２年前にこんなの書いていた人を比べると横浜FCとバルセロナくらいの差があるような気がします。--);

Hadooperへの道は遠いですが、一歩一歩前進したいですね。