Hadoop Conference Japan 2014に参加してきました

#イベントレポート

#Hadoop

Satoshi Noto

2014.07.10

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

7/8（火）に開催されたHadoop Conference Japan 2014に参加してきました。

【キーノート】

濱野賢一朗（日本Hadoopユーザー会, NTTデータ）

Hadoop Conference Japan 2014 ご挨拶・Hadoopを取り巻く環境 from hamaken

実際には私用で10:30ぐらいから参加したので聞いていないのですが、ハッシュタグ#hcj2014をたどる限り今回は参加者が1296名で、初参加が65%だったそうです。新規に参加される方が半分以上というのは裾野が広がったということなんでしょうか？

Doug Cutting （Hadoop生みの親, Apache Software Foundation, Clouderar 『The Future of Data』

途中から聞いたのですが、恐らくThe Future of Data | Cloudera VISIONに書かれている内容を話していたようです。

オープンソースの勝利という部分は相当熱く語っていたようで、Twitter上でも反応があった感じでした。
最後にGoogleのSpannerのようにトランザクションをサポートすると言っていたようで、Twitterで反応がありました。ちなみに、Doug CuttingとSpannerではHadoop creator: 'Google is living a few years in the future and sending the rest of us messages' | ZDNetという記事が見つかりました。

Patrick Wendell （Apache Spark主要開発者, Databricks）『The Future of Spark』

PatrickさんがSpark Summit 2014で話した内容を再演してくれた模様です。スライドはThe Future of Spark | Spark SummitにPDFがありました。ちなみに、今日はこの英語版のPDFにPatrickさんが自分で日本語訳を付けてくれていました！

Spark開発者の一日
APIの安定性を重視している。APIを破壊するようなパッチはビルドに失敗するようにしている
マイナーリリースは3ヶ月毎
Spark SQLは他のコンポーネントよりも早く成長している
MLlibは2番めに成長の早いコンポーネント
気になるトレンドとして256GBのメモリも一般的になりつつある

最後にこの前のSpark Summitで公開された（らしい）DatabricksのフルマネージドサービスであるDatabricks Cloudのデモがありました。Web UI上でSparkのプログラムが書けるだけでなく、SQLも実行でき、その実行結果も簡単にグラフ表示ができたりして、とても興味を引かれる内容でした。

太田一樹（Treasure Data CTO）『Hadoopエコシステムの変遷と、見えてきた使いどころ』

太田さんのセッションでは改めてなぜHadoopを使うのかという所から入って、最近のHadoop関連プロダクトと対応するセッションの紹介という流れでした。

Hadoopを使うのがストレージとして安いというが、GlusterFSやCephといったストレージ特化のプロダクトがある
単に安いというだけでなく以下の4つがひとまとめて価値がある
- 1) Collect Any Types of Data
- 2) Store Any Types of Data Economically
- 3) Faster User of Data
- 4) Better Use of Data
BIツールとの接続性では商用のMPPプロダクトがあるがスキーマ設計の手間やクラスタ拡張時の停止という問題がある。また、BI担当者にレポート作成依頼が集中し、レポート作成が追いつかない。レポートを欲しい人が直接データを操作できるかどうかがビジネスの差となる時代がくる
現在のトレンドとしてはまずは全データをHadoopに入れておいて、それを日次でMPPデータベースに入れてBIツールから参照という構成になっているが、これは技術的な制約によるものであって理想の形ではない
Hadoop側は構造化データを、MPPデータベース側は非構造化データを強化し互いの領域に踏み込むことで混沌となるのでは
ユーザーとしては何を利用するのか非常に悩ましい時代

Google BigQueryの大規模JOIN・UDF・Hadoop対応で何が変わるか佐藤一憲（Google）

BigQueryとCloud Pub/Sub、Cloud Dataflowの紹介でした。

Google社内ではログ分析にはMRではなくDremel(BigQuery)を使っている
BigQueryはGoogleアカウントでSign upすれば最初の100GBは誰でも無料で使える。値段も安い
仕組みとしてはColumn Oriented StorageとMPP
BigQueryのMPPは数千ノード。他は数十〜数百で桁が違う
BigQuery + Fluentdで毎秒100万行のログを取り込める。取り込み時に検索性能に影響もない。fluent-plugin-bigqueryを使うだけ
BigQueryのUDF(Coming Soon!)。JavaScriptで書ける
Cloud Pub/Sub(Coming Soon!)
Cloud Dataflow(Coming Soon!)。Google社内で利用しているFlumeJava(Batch)とMillWheel(Streaming)をサービスとして提供するもの

QAは以下の通りです。

Q. Fluentdは同じチャンクを再送することがあるが、どうやって対応すればいいか？
- BigQueryに重複排除の機能はないのでGroup byで対応する
Q. ユースケースとしてバッチを想定しているのかBIを想定してるのか？
- 両方
Q. 6億☓6億のjoinみたいなケースはどうすればいいか？試したらクエリが止まった
- テクニカルサポートで一番高いやつで個別に相談。クォータを上げる
- リザーブドキャパシティというのがあって、それを予め購入するという方法もある
Q. 並列で非同期で処理するとあったが、タイミングによって結果が異なるのでは？
- BigQueryはトランザクションをサポートしていない
- Exactな処理をしたければバッチで処理したほうがいい

Hivemall: Apache Hiveを用いたスケーラブルな機械学習基盤油井誠（産業技術総合研究所）

Hdj2014 myui from myui

Hivemallは名前しか聞いたことがなかったので参加したのですが、機械学習周りはそれほど詳しくないため雰囲気ぐらいしか分かりませんでした。

HivemallはHiveのUDFまたはUDTFとして実装された機械学習ライブラリ
開発したMotivationは既存のMahoutなどのライブラリではプログラミングが必要で敷居が高かったため
Hivemallの特徴
- 1. 利用が簡単
- 2. データに対してスケーラブル
- 3. 計算資源に対してスケーラブル
- 4. 最新のオンライン学習アルゴリズムをサポート
Confidence Weighted (CW)
MADlibやBismarckのようにUDAFを利用しなかったのはFinal mergeがボトルネックになるため
反復処理への対応としてamplify UDTFを提供
性能比較
Apache Incubator化(検討中)

QAは以下の通りです。

Q. 最新のアルゴリズムを適用する基準は？
- よいアルゴリズムを提案されれば随時取り込むつもり
Q. 反復が本質的に必要な教師なし学習のクラスタリングはどうする？
- HivemallでもTezを使うなどして対応しようと考えている

Taming YARN: how can we tune it? 小沢健史（NTT）

Taming YARN @ Hadoop conference Japan 2014 from Tsuyoshi Ozawa

YARNの最新情報や運用時の設定ファイルに関する話などでした。

YARNとは。開発された背景など
YARNとMesosの比較
YARNへの対応状況（MapReduce, Spark, Hive, Impala)
YARNのコンポーネント
- ResourceManager(RM)
- NodeManager(NM)
- ApplicationMaster(AM)
YARNの設定ファイルと注意点
Container Killerに注意
Container Types
スケジューラの一覧
NodeManagerのヘルスチェックに注意
Threadチューニング
ResourceManager High Availability。落ちるとどうなるか、フェイルオーバー時間は？

Apache Drill: Building Highly Flexible, High Performance Query Engines M.C. Srivas （MapR）

Drillも全く追えていないので参加したのですが、英語がほぼ聞き取れませんでした(´・ω・｀)。ただスライドには全て日本語訳がついていたので雰囲気は分かりました。まだ公開されていませんがApache Drill: Building Highly Flexible, High Performance Query Enginesに日本語訳をつけたものであったと思います。

DrillはRDMSで書けるがHiveなどで書けないようなSQLも書けるし、自己記述的されたデータもSQLで扱える
データソースを以下の3つの段階で指定できる
- クラスタ(DFS、HBase、Hiveメタストア)
- ワークスペース(サブディレクトリやHiveデータベース）
- テーブル（DFSならパス、HBaseやHiveならテーブル）
複数のデータソースを結合して処理できる(JSON、CSV、ORC、Parquet、HBaseテーブルなど)
JSONを処理するSQLの例
クエリの実行中にスキーマ変更可能
メタデータを集中管理しなくても良い
Drillの処理の中身
- カラムナフォーマット
- 各種データ構造
- DrillのコンパイラにはJITではなくJaninoを使用
- optimistic execution
- パイプライン化
- コストベース最適化
SQL-on-Hadoopの比較
Drillの開発にMapR内で20名以上参加しており、彼らのデータベース開発経験は合わせると150年以上！
コミュニティも活発

Evolution of Impala - Hadoop 上の高速SQLエンジン嶋内翔（Cloudera）

Evolution of Impala #hcj2014 from Cloudera Japan

Impalaの詳細やロードマップ関する内容でした。

Impalaのアーキテクチャ
- impalad
- statestore
- catalogd(Impala 1.2)
- クエリ計画
- ランタイムコード生成はLLVMを利用
HCJ2013(2013/01/21)の頃との比較。色々できることが増えている
メタデータ管理
UDFはC++とJavaだが、Pythonも開発中
HBase連携
アドミッションコントロール(Impala 1.3)。グループごとにクエリの最大並列実行数、キューの最大長、プールのメモリ総量を制限可能
Llama(ラマ)はImpala 1.4で正式版の予定
セキュリティはApache Sentry
HDFSショートサーキットリード
HDFSキャッシング
Parquet(ぱーけい)
COMPUTE STATS
ベンチマーク。他のプロダクトはI/Oをチューニングしているが、CPU効率の方が重要だと分かってきた。ImpalaはCPU効率がよい
スケーラビリティ。ノード数を倍にした際に
- ユーザ数、データサイズを固定した場合にレスポンスタイムが半分になった
- ユーザ数を倍にして、データサイズを固定した場合、レスポンスタイムが変わらなかった
- ユーザ数を固定して、データサイズを倍にした場合、レスポンスタイムが変わらなかった
ロードマップ

QAは以下の通りです。

Q. ロードマップにUDTFはなかったが、サポート予定はあるのか？
- 恐らく2.0より以降になる。リクエストは多くもらっているので対応は行う予定

並列SQLエンジンPresto - 大規模データセットを高速にグラフ化する方法古橋貞之（Treasure Data）

Presto - Hadoop Conference Japan 2014 from Sadayuki Furuhashi

Prestoの特徴からアーキテクチャ、モニタリングについてなどでした。

PrestoとはGBからPBのデータ分析を対話的に行う分散SQLクエリエンジン
2012秋からFacebookで開発された
Prestoが解決しようとする問題は
- BIツールから直接HDFS上のデータを可視化できない
- 日次バッチでPostgreSQLやRedshiftにデータを入れる必要がある
- いくつかのデータはHDFS上にはない。そのため分析時にHDFS上にコピーが必要
Prestoだと
- クエリをミリ秒から分で処理。ただしETLにはMapReduceやHiveは必要
- BIツールから接続可能。ODBC/JDBCコネクタ
- 複数のデータソースにまたがってクエリを実行可能
Prestoのアーキテクチャ
- Discovery Service
- Coordinator
- Worker
- Connector Plugin
ConnectorはJavaで書かれており、ストレージとメタデータの実装
- Hive Connector
- Cassandra Connector
- MySQL through JDBC Connector(prerelease)
- 自作も可能
Presto自身はデータベースではない。データストアに対してSQLを発行するエンジン
Coordinator HA
BIツールにはODBC/JDBCドライバが必要なのでPrestogresを作った
実行モデルはMapReduceではなくDAG
モニタリングがよく出来ている。JMX HTTP APIで詳細な情報を取得できる
ロードマップ

QAは実際には質問がなかったので想定質問に対する回答になりましたｗ

Q. Impalaとの性能比較
- 現状ではImpalaの方が早い
- Impalaとの違いはクエリは落ちてもプロセスは落ちない
- ログが取りやすい。Prestoは運用周りがよく考慮されている
- 開発体制がオープン。pullreqもすぐに取り込まれる

感想など

各種クエリエンジンのセッションが多く、それぞれ他のプロダクトとの違いについて説明していたので、どの辺が違うのか雰囲気が分かりました。単一のプロダクトの説明を聞くよりは比較する形での説明を聞くほうが特徴が際立って理解しやすいという印象を持っているため、現状のプロダクトが乱立する状況は分散クエリエンジンというものを理解するにはよい状況なのかなーという認識でいます。

ただし、一歩引いて考えると、プロダクトが乱立するのはどこに投資すればよいか分からないということの裏返しでもあり、悩ましい状況でもあると思います。まだまだどこがデファクトになるかは見えない印象です。現状で固まっているのはデータストアとしてHDFSを利用するという点のみで、Sparkも勢いが出てきて処理系としてどこが優位になるかは予想がつかないです。あと、YARNのセッションに参加しましたが、成熟度はいまいち見えない印象でした。もう、普通にみんな使っているんでしょうか？

久しぶりにHadoop分を補充できました。とってもおもしろかったです！主催者、スピーカーの皆さま、ありがとうございました！！