Hadoop Conference Japan 2014（HCJ）に参加してきました。
各講演の内容はたぶん公開される資料を見る方が確実だと思うので、感想だけ書いておきたいと思います。
まず、基調講演から。
Hadoopカンファレンスの参加登録人数は去年より100～200人くらい増えているが、初参加が65％とのこと。まだそんなに初参加の人がいるとは驚き。
Hadoop利用経験年数は順当に伸びている模様。
Hadoopのバージョンの話も出ていたけれど、0.20→1系、0.23→2系…と思ったら0.23もまだ生きてるみたいだし、確かによく分からない＾＾；
利用しているHadoopエコシステムのトップがHiveなのは相変わらずだけど、2位がZooKeeperで3位がHBaseって、かなり意外。
ZooKeeperを単独で使ってる人ってそんなにいるとは思えないんだけどなぁ。自分もMapRを使ってるから間接的にはZooKeeper使ってるけど。
って、自分は主にAsakusa Frameworkを使っているので、このエコシステムのアンケートでは選択肢が無かったんだよなぁ。AsakusaFWがHadoopエコシステムかと言われると、ちょっと疑問ではあるけれども。
あと、Hadoop開発のソースコード行数のトップはHortonworksだそうだけど、HortonworksはHCJには来てないね＾＾；
それと、Treasure Dataの太田さんが言っていた、「Hadoopを使う理由のひとつとして“安いストレージ”と答える人がいるが、今はGlusterFSやCeph等、ストレージに特化したOSSが存在する」というのは意識してなかったなぁ。
午後1つめはCloudera小林大輔さんのHadoopのセキュリティーの話。→資料
Kerberos認証のデモをやっていた。
Apache Sentryというのは初耳。HiveやImpala用の認可モジュールらしい。
で、昔、MapRだとOSレベルで認証・認可できるという話を聞いたような気もするけど、KerberosやSentryだとどうなんだろうな？
2つ目はGoogle佐藤一憲さんのBigQueryの話を聞いた。→資料
BigQueryではインデックスを作らず、大規模に並列処理している。1TBを1秒以内にアクセスする為には逆算して5000台必要、ということろから台数が決められたらしい。普通の会社なら、仮想マシンを使っても5000台は用意できないよ。すごいなぁ。
BigQueryは680億行のSELECTが20秒程度だそうで、デモでも120億行の正規表現による絞り込みが10秒くらいだった。
データをインサートしながらクエリーを発行することも出来るが、BigQueryにはトランザクション処理は無い（入力データの重複を排除できない）し、スナップショットも無いので、確実な結果が欲しい場合は別のところへコピーしておく等の方法を使う必要があるらしい。
BigQueryはシャードで分散し、ミキサーで集約するという仕組みらしい。
結合は2種類あって、右結合のマスター側が8MB以内なら、オンメモリーで全ノードにコピーして結合する（Small JOIN）。それ以外はシャッフルを行う（Big JOIN）。
AsakusaFWにもデータが小さい場合はサイドデータジョインで処理する最適化機能があるが、8MBはかなり小さいような気がする。
Hadoopとのデータ連携として「Connectors for Hadoop」というのがあるらしいが、純粋にMapReduceのInputFormatとかのクラスを提供しているようで、いまどき素のMapReduceを使う人がどれくらい居るんだろう？＾＾；
あと、提供時期未定だけど「BigQuery UDF（JavaScript）」「Cloud Pub/Sub（メッセージング処理）」「Cloud DataFlow（FlumeJavaによるバッチ処理とMillWheelによるストリーミングを1つのコードで行う？）」とか計画されているらしい。
こういった直接仕事と関係ない話は最近聞いていなかったので、ちょっと新鮮だった。
3つ目はLINE田籠聡さんのNorikraの話。→資料
Norikraの名前は聞いたことがあったけれど、ストリーム処理をSQLで記述するものだったのか。
Esperというライブラリー（昔からあるストリーム処理ライブラリーらしい）も初めて聞いた。
Norikraは、SQLはEsperベースだがスキーマが不要なのだそうだ。
4つ目はNTT小沢健史さん（→資料）、6つ目はTreasure Data小林隆さんのYARNの話（→資料）。
どちらもYARNを実際に使う際の設定値について詳しく説明されていたので、これは公開される資料をちゃんと見た方が良さそう。
とりあえず覚えておくべきは、Hadoop2.2.0・2.3.0・HDP2.0はCapacity Schedular・Fair Schedularにデッドロックするバグがあるので使用すべきではない、ということ。（現時点での最新の2.4.1、HDP2.1はOK。CDH5.0.2はパッチが当たっているのでOK）
YARNが出た当初は「使い物になるの？（立ち消えになるんじゃないの？）」という感じだったが、最近はもうHadoop2系（YARN）に行くのが当たり前みたいな雰囲気だなー。でも直前のバージョンでもデッドロックするようなバグがあるなら、現時点で使うのはまだ少し微妙な気もする。
5つ目はNTTデータ土橋昌さんのSpark on YARN。→資料
Sparkを実際のクラスターで動かしてみたところ、データ量に応じてだいたい線形にスケールするということらしい。
HDFSからデータを読み込む場合、MapReduceが使われるので、ローカリティーは効く。
同じデータを何度も使う場合、HDFSから読み込んだデータがキャッシュ（メモリー）に乗るので、2回目以降は速くなる。
キャッシュに入りきらない場合は、入りきらない部分だけファイルから読み込む（異常終了するわけではない）。
プログラム次第でキャッシュに自由にデータを乗せられるので、何でもかんでも乗せると個々に乗せられる量は減ってしまうので注意が必要らしい。
言われてみれば気になる点ばかり。とても参考になった。
キャッシュに入れるデータ（構造）はシンプルにし、必要であれば（implicit conversion等で）複雑な型に変換して使うのが良さそうとのこと。
PoCで作ったアプリケーションについては割愛されてしまったが、ここが一番興味あったんだよなぁ。Sparkの実務的なコーディングってどんな感じ（ステップ数とかクラスの使い方とか）になるのかなぁ。
結論として「まだ見えない苦労はある」「玄人レベル」とのことだったけど、その辺りの具体的な理由も聞いてみたかった。
7つ目はORACLE大橋雅人さんのSmart SQL Processing。→資料
HadoopとRDBMSは補完関係にあるってことで、HadoopとRDBMSを透過的に扱う（SQL1つでどちらにもアクセスできる）チャレンジをすると。それがSmart SQL Processingだそうです。
で、それが、OracleのDBMS側で発行したSQLでHadoopにもアクセスできるようにすること！
OracleのDBのデータをHDFSにコピーする方法とかHDFS上のファイルをOracleDBに入れる方法は欲しいなぁと思ってたけど、Oracle側のSQLでHadoopにアクセスするとは考えなかった＾＾； RDBMSを扱っている会社ならではの発想だなぁ。
Smart SQL Processingは以下のようなことをするらしい。
- OracleDBからのクエリーでHDFSのデータにアクセスする
- Oracleの関数が全て使える
- 既存のアプリを修正する必要が無い
- OracleDBのメタデータ管理を拡張してHDFS上のオブジェクトを把握する
- Hiveのメタ情報をOracle側のカタログ（外部表）として定義する
- Oracle ExadataのSmart Scan同等機能をHadoopのノードに実装する
- HDFS側でデータの最小値最大値を持っておき、クエリー実行時に範囲外ならスキャンしないようにする
しかし、HDFSのファイルとRDB連携を考えるなら、一番欲しいのは、HDFS上の大容量ファイル（全件）とRDB上のマスターデータとの結合だと思う。それはどうやって解決するんだろう？
最後。講演の合間に流れていたアニメーション。毎回よく作るなぁｗ
今回は象が上手く3Dになって動いていたけど。気になったのは、サッカーボールをドリブルしていた箇所。前足はハンドじゃないのか？ 前「足」だから問題ないのか？＾＾；
あ、それと、お弁当ごちそうさまでした。
Oracle Exadata + Big Data Appliance
の組み合わせみたいでしたので
Exadataのハードの力技で
どうにかする気なんじゃないのかなぁ…
なんて思ったりしてます…。