#hcj13w 午後2.AZAREA-Cluster

Hadoop Conference Japan 2013 Winterの午後2（会場：1B）『AZAREA-Cluster HadoopアプリケーションをGUIで簡単に開発』のメモです。
講演者はCACの田中 等さん。（→資料）

CACは従業員数1300人くらいの会社で、信託銀行や製薬系に強いのだそうだ。
AZAREA-ClusterはAZAREAソリューションファミリー（ウェブ系とか）の一つという位置付け。

なぜAZAREA-Clusterを作ったかというと、
1.もともと業務システムのバッチ処理を開発していたが、パフォーマンス面で苦労することもあった
2.Hadoopを検証してみたところ、速度面では問題なさそう
3.しかしアプリケーション開発（生MapReduce）の難易度は高い
　（Pig/Hiveは複雑なバッチは無理（SQLだけで業務バッチを作れないのと同様））
→自前でフレームワークを作ろう！

フレームワークの方針としては、「Hadoopにより分散アプリケーションの開発は簡単になったが、大多数の開発者にとっては難しい」ので、
○業務システム開発に近づける
　・OSはWindows（Linuxにも対応）
　・Java（CACではJavaや.NETが主流）
　・JavaなのでEclipse（コマンドラインは使わない）
○シミュレーターを用意する
　・HadoopをインストールしなくてもEclipse上でデバッグ可能

AZAREAの用語は以下の通り。
・エンティティ： データを表す
・処理： エンティティを入力してエンティティを出力する（変換や結合・集計・ソート）
・アプリケーション： エンティティの処理フロー

Excelでエンティティを定義し、エンティティクラスを生成することが出来る。
EclipseのASTParserを利用してJavaソースを解析している。（Javaソース以外では情報は保持しない）
図のSVG出力機能にはApache Batikを使用している。

AZAREAは、元々はGUIは無く、全て手でコーディングする前提だったそうだ。
ソースの構造を解析してフロー図を表示する機能を追加し、さらに拡張して編集も出来るようにした。

以下、各処理の詳細について少し。
○結合
入力が大きい場合はReducer、小さい場合はMapperで処理される。
フレームワークがファイルサイズを見て判断する。
（シミュレーターでは想定サイズを入力することが出来るので、MapReduce（実行計画）の図もそれに応じて変わる）

○グループ化集計
Combinerはオーバーヘッドが大きいようなので、デフォルトでは使っていない。
（ちなみに、次のLTでCombinerのオーバーヘッドを減らす話が出ていたｗ）

○処理最適化
複数の処理が1つのMapper/Reducerに割り当てられることがある。（一般的に、ジョブ数が少なくなる方が全体として速くなる為）
バージョン0.9.1は0.9.0より若干改善されている。
なお、0.9.1は1/18（3日前やんけｗ 知らんかった＾＾；）に公開された。

あと、何度かライブコーディングをやっていた。自分は0.9.0評価版を試してみたのだが、ここが不便と思った箇所がけっこう改善されていたのでびっくり(笑)
・フローの箱の座標がアノテーションに記述されている
・処理に「表示名」が入力できるようになっている
・処理をダブルクリックすると該当ソースへ移動する
・フローの箱を範囲選択してまとめて移動できる
・Hadoopジョブのカウンターに「表示名」も表示されている
なんて素早い対応！

#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クラスターを複数の顧客で共有する）って、けっこう昔から「やりたいという声がある」とは聞いていたけれど、今まで「実現した」って話は聞いたことが無かった。やってる所があったんだなぁ。