#hcj13w 午後1.Huahin Framework

Hadoop Conference Japan 2013 Winterの午後1（会場：1B）『Huahin Framework For Hadoop』のメモです。
講演者はブレインパッドの小林 隆さん。（→資料）

今回一番興味のあったHuahin・AZAREA・Asakusaの3フレームワークの一番手。

Huahin（ホアヒン）はタイの地名で、ワインの産地らしい。
ブレインパッドでは、社内規定で「コードネームはワインに関するものにする」と決まっているのだそうだ。
そこで適当に検索して、Huahinに決めたのだとか(笑)

Huahinは、MapReduceを簡易化（Javaで書くものをラッピング）したフレームワーク。
Writableやセカンダリーソートを自分で書かなくて済む。

Pig/Hiveでは難しい処理（例えば1つのMapReduceの中で直接関係の無い計算を並列でやるとか）がある（しかしMapReduceを直接書きたくはない）ので作ったのだそうだ。

Huahin Frameworkにはいくつかのコンポーネント?がある。

●Huahin Unit
MRUnitをラッピングしたもの。

●Huahin Core
プログラムに関する部分。
結合に関しては、メモリーに乗り切る部分はSimple Join、そうでない場合はBig Joinとなる。

●Huahin Tools
今はApacheのログを整形するものだけしか無い。

●Huahin Manager
REST APIで操作できる。
ジョブの一覧や詳細を表示したりkillしたり出来る。
ジョブの実行をキューで管理することも出来る。実行できるのはMapReduceのjar、Hive script、Pig Script。

対応バージョンはHadoop1系・2系、Hortonには未対応（会場のその場の挙手では、Hortonを使っている人は居なかった＾＾；）。
HDFSのバージョンが違うと詳細情報が取れないので、Hadoop1・Hadoop2・CDH3・CDH4で分けている。

●Huahin EManager
EMRに特化したManager。
出来る事はHuahin Managerと同様だが、EMRの仕様に合わせてある。
・EMRクラスター（ジョブフロー）の再利用が出来る。（EMRは1時間単位の課金なので、短いジョブを複数実行するには毎回起動するのではなくて再利用した方がよい）
・EMRのステップ（MapReduceジョブ）の上限が255なので、それに達したら自動的に再起動する。
・実行用のjarファイルをS3に置く必要が無い。（自動的にアップロードする）
・EMRはジョブのkillが出来ない（sshでマスターノードに入れば出来るが面倒だ）が、EManagerでは出来る。

説明を聞いていると、Managerにかなり力を入れているように感じられる。
TwitterでHuahinが話題になるのもHuahin Managerばかりのような気がするしｗ

#hcj13w 昼.LT

Hadoop Conference Japan 2013 Winterのお昼のLT（ライトニングトーク）のメモです。

といっても、知り合いと話したり食べたりしていて、1つしか聞けませんでした、ごめんなさい。

ちなみに昼食や飲み物が無料で提供されていました。
今回は6種類あって、なんだかフランス料理の簡易版みたいなかっちょいい名前が付いてて中身が何だかよく分からないメニューもありましたが(爆)、ありがとうございました！

で、唯一聞いたLTは、ちょうどこれだけは聞きたいと思っていた『本当にCOBOLがHadoopで動くのか？！～NetCOBOLの真実～』。
講演者は富士通研究所の上田 晴康さん。

NetCOBOLはWindowsやLinux等で動くCOBOLらしい。HadoopのプログラムとしてNetCOBOL v10.5を使ったということらしい。

COBOLアプリケーション（というか、たぶん汎用機のアプリケーションのパターン）では、ファイルをソートユーティリティー（ソート専用プログラム）でソートしてからプログラム（COBOL、自分の経験ではPL/I）に読み込ませて処理することがよくある。
これはMapReduce（シャッフル（ソート）してからReducerで処理するという仕組み）とよく似ている。
という訳で、ソート部分をシャッフルに任せ、Hadoop Streaming（標準入出力でデータをやりとりする）のReducerにCOBOLプログラムを使用した、ということのようだ。
トランザクションデータとマスターデータのマッチング処理にも対応しているとのこと。マスターはプロセス間通信で渡すと言っていたが、どうやるのかいまいち想像できないな＾＾； 

ただ、既存COBOLでは標準入出力は使わないのでファイル入出力に変えたり、文字コードはEBCDICなので変換したりといった部分は作り込んだ模様。
これにより、アプリケーション部分のCOBOLプログラムは何も修正せずに動く。（修正しないから、改めての単体テストは不要という考えらしい）

これにより、トランザクション128GB/マスター512バイトを処理するアプリが、従来だと150分、Hadoop+COBOLで50分になったらしい。
さらに、これはHDFSへの転送に時間がかかっていたので、富士通製の転送製品に置き換えたら8分になったとのこと。

結論としては、これは「ソート+処理」というパターンのCOBOLプログラムならHadoop Streamingで実行できる（その為のラッパーを作った）ということであって、COBOLプログラムをHadoop用に変換する（どんなCOBOLプログラムでも対応できる）とかっていうことではないんだな＾＾；

#hcj13w 午前4.EMR

Hadoop Conference Japan 2013 Winterの午前4『Amazon Elastic MapReduceとHadoopコミュニティの関わり』のメモです。
講演者はAWSのPeter Sirotaさん。

えー、すみません、英語のスピーチだったので、ほとんど分かりませんでしたorz
（こういう講演がさらっと入っている辺り、英語くらい使えるようになれという無言のメッセージを感じますね＾＾； 若い人は頑張って下さい！）

気になったキーワードだけ拾い出すと、「AWS Public Datasets」ってのがあったけど、何だろう？

EMRは370万クラスター使われたらしいですね。（去年だけで200万？）

HBase on EMR（EMR上で使えるHBase）は、S3にバックアップを取ることが出来るらしい。「full or incremental backup」って書いてあった。これは初耳。
HBaseはデータベースだからデータを蓄積しておくもののはずだが、EMRは使うときに毎回起動する（データは消える）のでHBaseと相性悪いのでは…と思っていたので、S3にバックアップして復元も出来るとあれば、データベースらしい使い方も出来そうな気がしてくる。
（ちなみにHBaseのBが小文字になっている箇所が何箇所かあったような気がするが、HBase四天王の@ueshinさんはまさかりを投げただろうか、いやきっと投げたに違いない（twitter見てないから分からない）ｗ）

あと、S3→EMR→DynamoDBや、逆のS3←EMR←DynamoDBも簡単に出来ると言っていたような気がする。

#hcj13w 午前3.TreasureData

Hadoop Conference Japan 2013 Winterの午前3『Hadoop meets Cloud with Multi-tenancy』のメモです。
講演者はTreasure Dataの太田 一樹さん。（→資料）

自分はTreasure Data（TDと略す）という会社が作られたのは知っていたけれど、何をしているのかはよく知らなかった。
「TDって何をしている会社？」という質問に対し、一般向けには「Cloud+Big Data」と答えているらしい。

Hadoopエコシステム（Hadoop関連のプロダクト）は、ソリューションや機能が多すぎ・複雑すぎる。“何でも出来る”のだが、どれを使えばいいか・どうすればいいか分からない。
という訳で、TDとしては、シンプルなインターフェースで（色々な目的に）使えるものを作るという方針なんだそうだ。

また、オンプレミス（自社設備）からクラウドへ～という流れの中で、匿名化できるデータは意外と多い。少なくとも世間で思われているほど無理ではない。

ということから、TDのサービスは、（クラウドを使った）レポーティングに特化している。
すなわち、「collect+store+query」。
collect： td-agentでデータ収集
store： AWSに保存
query： REST APIやJDBC/ODBCで検索
顧客のシステムからデータを転送・保存し、ローカルからクエリーを発行するとクラウド上で実行されて結果が返ってくるという仕組み。

AWSとの違いをよく聞かれるらしいが、AWSはコンポーネント指向といえるような構造（S3・EC2・EMR・Redshift）で、個々に（色々な目的に）使える要素を提供しているが、TDはレポーティング用の機能を構築・提供している。

Hadoopクラスターは、世界でたぶん初のマルチテナンシーを実現している。
4種類のデータセンターで4つのHadoopクラスターを持ち、「どの顧客をどのクラスターへ振り分けるか」を受け持つグローバルなジョブスケジューラーを作成したそうだ。
マルチテナンシー（1つのHadoopクラスターを複数の顧客で共有する）って、けっこう昔から「やりたいという声がある」とは聞いていたけれど、今まで「実現した」って話は聞いたことが無かった。やってる所があったんだなぁ。

#hcj13w 午前2.LINEのHBase

Hadoop Conference Japan 2013 Winterの午前2『LINEのHBaseを利用した大規模なメッセージストレージ』のメモです。
講演者はNHN Japanの中村 俊介さん。（→資料）

LINEではHBaseを使っていて、1日100億行を扱い、レスポンスは10ミリ秒以下（書き込みは1ms、読み込みは1～10ms）。
トラフィックのピーク（正月の「あけおめ」メッセージ）に対しては2ヶ月前から準備していて、特に問題は起きなかったとのこと。

IDC migration（データセンターの移転）の話は面白かった。
サービスを止めずにデータを転送する為に複製用のアプリケーションを自作したらしい。これは参考にしたい（欲しい）人がいるかも。

NameNode failoverの障害の話もなかなか。
当初はDRBD+VirtualIP+Pacemakerという、本とかでよく紹介されている構成にしていたが、アクティブとスタンバイの両方がプライマリーになってしまう障害があって、仕組みを見直した。
それが『In-house failure handling』。/etc/hostsを書き換える単純な方式！ｗ（ちょっとのダウンタイムは許容するという方針。書き換えのスクリプトは用意する）
まぁ、ややこしい設定が少ないのはよいことだと思います。