ちょっと話題の記事

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

Satoshi Noto

2014.07.10

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

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

【キーノート】

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

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

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

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

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を用いたスケーラブルな機械学習基盤 油井 誠（産業技術総合研究所）

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）

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）

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の特徴からアーキテクチャ、モニタリングについてなどでした。

  • 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分を補充できました。とってもおもしろかったです！主催者、スピーカーの皆さま、ありがとうございました！！

合わせて読みたい

私がこのブロクを書き上げたタイミングが遅いこともありますが、さすがはHCJということで既に大量の参加ブログが見つかりましたｗ

AWS

関連記事

【イベントレポート】筋肉エンジニアのビルドアップ会#4 に参加してきました

佐藤雅樹

2024.04.04

【イベントレポート】「Unreal Engine Meetup in Nagoya Season2 Vol.1」に参加してきました。

入井啓太

2024.03.24

ハックツハッカソン ~ブラキオカップ~ にメンターとして参加してきました

森田力

2024.03.22

「GitLab Connect Japan 2024」に参加してきました

きだぱん

2024.02.16