こんにちは。
落合です。
遅くなりましたが、
Hadoop Conference Japan 2013 Winter
に参加したので、聞いてきたセッション＋発表したセッションの内容を書きます。
場所：東京ビッグサイト
参加者数：820名
事前予約は1000人を超えていたそうです。
すごい人数ですね。
キーノートの講演は、
・Publickey
・ITpro
・Gihyo.jp
など記事が多数なので割愛して、
3並列のセッションのうち聞いてきたものの内容を書きます。
1. リクルート式Hadoop の使い方 2nd Edition
石川信行さん (リクルートテクノロジーズ)
昨年10月にグループ会社を
7事業会社、3機能会社に再編。
研究拠点としてのリクルートテクノロジーズも強化された。
Hadoopの使いどころとしては、
主にレコメンドで事業の収益向上をさせるために活用している。
「8割の会社が情報活用に失敗する」
と言う調査結果がある中、
リクルートは「ここが生命線」と、力をかけている。
Hadoopの通常利用だけでなく、
・HBaseのリアルタイムレコメンド
→HBase0.9.2 から使えるコプロセッサにも注目
・Apache Drill, Cloudera Impara 導入の検討中
→事業担当者がHiveQLに慣れた今が導入のチャンスと見ている
など、
よりリアルタイム性を追求した、他に先んずるための施策にも取り組んでいる。
2. Introduction to Impala 〜Hadoop用のSQLエンジン〜
小林 大輔さん（Cloudera）
川崎さんの代打で、急遽小林さんが登壇。
Hiveと同じクエリ（一部制限あり）を投げると、
高速に処理結果を返してくれるのがImparaである。
C++で実装されており、
MapReduceの機構を使っていない。
Impara は Hiveのメタストアを利用している。
各ノードの
Query Planer ←Javaで実装（Hiveメタストアにアクセスするため）
Query Coordinator ←C++で実装
Query Executer ←C++で実装
が処理を司る。
Hiveと比較したときの制限事項は、
・扱えるクエリの種類が一部制限されていること
・メモリ上で処理して結果を返すため、処理できるデータ量に制限があること
である。
3. Hadoop上の多種多様な処理でPigの活きる道
山下 真一さん（NTTデータ）
収集→バッチ処理→レポートの定期出力
からHadoop利用をスタートしたユーザは、
次第に、
収集するデータの種類と量が増え、
複数の分析をしたくなる。
早く結果が欲しくなるため、
MapReduceによるバッチ部分を、
HiveやPigで置き換えて用意に集計処理をするニーズが出てくる。
Pigについては、
UDFの利用で、
MapReduceと同様に分散キャッシュを利用する事ができる。
カウンターも利用可能。
Pigの性能については、
MapReduceを直接書くより遅い場合があるのは事実だが、
バージョンが上がるにつれて改善されてきている。
50%くらいは、MapReduceで書くのと処理時間が変わらない。
開発工数を考えると、
やはりMapReduceを直接書くより高級言語を使った方がよい。
4. Log analysis system with Hadoop in livedoor 2013 Winter
田籠 聡さん（NHN Japan）
この講演は特に面白かったです。
4世代に渡るHadoopクラスタの進化の歴史が解説されていて、
どこに苦労したかもよくわかります。
（何と言っても、これを一人で構築しているのだからすごい。）
livedoor の複数のサービスのログを集めると、
1.5TB/日 数十億行のレコードが毎日発生する。
2011年の第一世代Hadoopクラスタから改良を重ねた結果、
今月移行したCDH4.1.2 の第4世代では、
問題点が解消されている。
・Hiveによる処理実行までのタイムラグの解消
Fluentd を使って、Hadoopにデータを流し込む際に、パーズ処理を終えているので、
ログ発生後すぐにHiveの処理の対象にすることができる
・リアルタイムに欲しい情報が取れる
Fluentd を使って、簡単な集計処理は終わらせてしまい、
4xx, 5xxステータスコードの増加などは、
リアルタイムにグラフ化し、警告も出す
・クラスタのバージョン変更の影響を最小化
WebHDFSを使う事により、
Hadoopのバージョンを意識せずに通信できる。
また、HTTPFS(Hoop)を使うとそこがSPOFになってしまうが、
WebHDFSを使う事で回避。
・SPOFの解消
CDH4にしたことで、NameNodeがSPOFになっている問題が解消された。
これが第4世代の状況。
5. いかにしてHadoopにデータを集めるか
古橋 貞之さん（Treasure Data）
ログ収集は難しい。
scpコマンドで定期的に収集なんてとんでもない。
それを簡単にしたのが、
Flumeや、Fluentd。
Flumeより少ない記述量で処理を定義できるし、
RubyGemsでプラグインが沢山公開されているし、
やっぱりFluentdがいいよね！
という内容。
話を聞いているうちに、どんどんFluentdを使いたくなってきます。
ストリーム処理において、
データの再送は基本的に筋の悪い方法で、
「一度失敗したものはまた失敗する可能性が高いからむやみに再送しない」
と考える。
システム全体としてデータの欠損が発生しない仕組みを考えるべき。
6. トラブルシューティングのために欲しかった、Hadoopがまるっと分かる可視化ツール
落合 雄介（Acroquest Technology）
ということで、私の発表です。
Hadoop/HBase 可視化OSS 「halook」の紹介と、
halookを使ってHadoopを可視化して見た例の紹介でした。
説明は、1/22の記事にも書かれているので、
ここには発表スライドと、発表中に使ったデモ動画を載せておきます。
発表スライド
halook (Hadoop/HBase可視化OSS) - Hadoop Conference Japan 2013 Winter 発表資料 from Acroquest Technology
デモ動画1
デモ動画2
デモ動画3
ぜひ使ってみてください！
https://github.com/endosnipe/halook
そしてHive Tシャツ
懇親会は、30人以上の人たちが Hive Tシャツを着ている不思議な光景でした。
私ももらいました。ありがとうございました！
Pigの勉強会の時にでも着て行こうかな。
