Hadoop Conference Japan 2014参加レポート

Hadoop Spark

最近Apache Spark関連のお仕事をしているので、2014/7/7に開催されたHadoop Conference Japan 2014に参加してきました。
Hadoopユーザー会主催、リクルートテクノロジーズ後援で、今回で５回目だそうです。

イベント概要＆資料/Ustream公開

当日のタイムテーブル、および録画(Ustream)はこちらから参照できます。

https://hcj2014.eventbrite.com/

参加者に配布されたパスと扇子。

全体を通して

参加登録者数が1300名、うち65%は本カンファレンスに初参加とのことでした。
BigData処理に対する関心の高まりを感じるとともに、実際に利用しているユーザーはまだ少数派で、これから本格的に普及するというステージのようです。
Hadoopエコシステムの拡大に伴い、単純な分散ファイルシステム(HDFS)と並列バッチ処理(MapReduce)という使い方から、SQLによるアドホッククエリ、インメモリ処理による高速化、機械学習/グラフ処理への応用など、ユースケースが高度化しています。
それらを受け、今回のカンファレンスでは「SQL処理(BigQuery/Norikra/Drill/Impala/Presto)」「インメモリ処理(Spark)」「機械学習(Hivemall/Mahout)」をメインテーマとしてセッションを構成したとのこと。

基調講演

NTTData 濱野氏

資料) http://www.slideshare.net/hamaken/hadoop-conference-japan-2014-36781484

Hadoopは「はじめて」一般に普及した並列分散処理系であると言える。その理由の一つとして「シンプル」であることが挙げられるであろう。データリードの高速化とシンプルな処理モデル(MapReduce)に特化することで、大量データを全件処理しなければならないニーズに対応してきた。

Hadoopエコシステムの今後の方向性として以下が挙げられる。

  • MapReduce以外の多様なアプリケーションへの対応: YARN(Yet Another Resource Negotiator)の普及により下地が整いつつある。MapReduceは手堅くなくなることは無いが、それ以外の選択肢が求められている。
  • インメモリ処理への対応: Hadoopの弱点である「レイテンシー(遅延)」を解決するために必要。メモリの低価格化により、すべてをインメモリ処理することも非現実的ではなくなりつつある。Sparkが筆頭。

Hadoopエコシステムで利用の多いプロダクトはHDFS/MapReduce(v1)に加え、Hive/Zookeeper/HBaseあたり。個人的にはHBaseがこれほど使われていることが驚き。ImpalaやSparkなどは前回比で急成長している。

Doug Cutting氏 "The Future of Data"

資料) http://www.slideshare.net/Cloudera_jp/the-future-of-data-jp

未来は予言できないが、事実から予測することはできる。これまでの事実からHadoopの今後を予測してみる。

  1. ムーアの法則は依然有効であり、CPU/メモリ/ディスク/ネットワークのコストは下がり続けていく。コモディティハードウェアによる分散処理は、今後ますます普及していくだろう。
  2. データが生命線である。データを活用することが企業を競争優位に導くより重要な要素になるだろう。
  3. オープンソースソフトウェア(OSS)が生き残る。Linux、Android、Apache、LuceneといったOSSはオープンであるがゆえにエコシステムを形成しやすい。特にプラットフォーム技術はOSSが主流になるだろう。ビッグデータの基盤としてHadoopは今後もメインストリームであり続ける。
  4. Hadoopはさらに拡大していく。最初はコア機能以外何も無かったが、セキュリティやSPOF(単一障害点)除去、MapReduce以外への対応など、成長を続けている。
  5. Hadoopが普通になる。ビッグデータ処理と言えばHadoopを使うことが当たり前になっていく。
  6. Hadoopがビッグデータにおいて支配的になる。IBM/Microsoft/OracleなどのベンダーもHadoopエコシステムに参加している。
  7. トランザクション処理にもHadoopが利用されるようになる。既に実装は始まっており、将来的にはOSSになる予定。

Hadoopエコシステムが目指すのは「Enterprise Data Hub」になることである。企業のすべてのデータが一カ所にまとまり、必要なときに必要なデータがすぐ利用できるという環境を実現したい。

Patric Wendell氏 "The Future of Spark"

資料) http://www.slideshare.net/hadoopconf/the-future-of-apache-spark

Apache Sparkのメイン開発者の一人。(スライドの日本語の一部は自分で翻訳したそうです。)

Sparkコミュニティは非常にアクティブ。以下を基本的な方針として開発を進めている。

  • 表現力の高い、クリーンなAPIの提供
  • 統一されたプラットフォーム
  • 拡張性の高いツールの提供

Spark1.0以降はpublic API(安定的)とexperimental API(実験的)に分け、開発者に優しいプラットフォームを目指している。また、マイナーリリース(1.1など)は３ヶ月毎に定期的に行い、必要に応じてメンテナンスリリース(1.0.1など)を行うなど、リリースサイクルを明確化している。

Sparkのアーキテクチャは安定したCore Runtimeと、拡張機能を提供するSpark Libsに分かれている。(JavaにおけるJavaVMとJVM言語の関係に近い。)Sparkの未来はSpark Libsにかかっており、今後も拡張を続けていく。特に重要なのは以下。

  • Spark SQL: もっとも成長しているライブラリ。スキーマによる型付けに対応したRDDを提供する。NoSQL(Cassandra,HBase,MongoDB)やRDBとの統合を実装中であり、Spark1.1ではJDBC/ODBCドライバを提供予定。(1.0.1でベータ公開)
  • MLlib: 二番目に成長しているライブラリ。Sparkの基盤上で高速な機械学習を行う。新しいアルゴリズムも順次追加していく。
  • SparkR: RからSparkに連携できるライブラリ。MLlibとの連携機能を予定している。
  • Spark Streaming: Sparkでストリーミング処理を行うライブラリ。新しいデータソースへの対応や、Flume連携強化を予定している。

Databricks Cloudデモ: 以下の操作がブラウザから行える。詳細はUstreamを参照。ベータユーザー募集中なので登録してね、とのこと。

  • Spark Cluster作成。
  • Notebook(作業場所)を作成し、SQLクエリやScala/Pythonコードを記述して実行。全体はmarkdown記法で記述できるようです。
  • Parquetファイルのアップロード。(外部システムからのデータ連携)
  • ロードしたファイルのスキーマを表示、SQL実行。
  • ダイナミックダッシュボードによるデータ表示。SQL実行結果も動的にグラフ表示可能。
太田一樹氏 "Hadoopエコシステムの変遷と、見えてきた使いどころ"

資料) 未公開

TreasureDataのCTOで、FruentdやPrestの開発にコミットしている。

Hadoopの普及に伴い、闇雲にHadoopを使いたいという人も増えてきた。「なぜHadoopを使うのか？」を考えることが重要。

太田氏の意見:「Collect/Store/Use/Better Use」の全サイクルを行うならばHadoopが有効。逆に、Collectだけなら専用ソリューションを使った方がよい。

各フェーズにおいて注目すべきキーワードは以下:

  • Collect: Fluentd / Flume / Sqoop / Kafkaなど、組み込みに特化したものなどもありバリエーションが増えている
  • Store: Parquet / ORCFile / HDFS / HBase / Acculo / Ambariなど、運用管理が弱いのが課題であり、マネージドサービスの普及が期待される
  • Use: Spark / Tez / YARN / Cascadingなど、新しいユースケースへの対応が拡大している
  • Better Use: SQL on Hadoopや機械学習など、より高度なデータ利用

DBの進化、特にMPP(Massively Parallel Processing)が著しく、Hadoopとの棲み分けの境界線があいまいになってきている。MPPはスキーマを事前に決める必要があるため、データ処理効率は有利だが、新しいデータを投入したいというニーズへの対応に時間がかかる(通常は数週間)のが問題。

現時点では構造化データはMPP、非構造化データはHadoopが強いが、今後は技術の発展により混沌としてくるのではないか。

午後の部

判別しづらいので、勝手にセッションの通し番号振ってます。

C-1 マルチテナント化に向けたHadoopの最新セキュリティ事情 <小林氏(Cloudera)>

資料) http://www.slideshare.net/Cloudera_jp/hadoop-hcj2014

2012/9入社でCloudera製品のテクニカルサポートを担当。

Hadoopのユースケースが「バッチ(MR/Hive/Pig)」から「インタラクティブ分析(Impala/Presto)」に変化してきている。また、従来は部門別にHadoopクラスタを構築しているユーザーが多かったが、クラスタ間データコピーの手間や運用負荷、リソース利用効率の悪さなどから、クラスタを一元化したいというニーズが増えてきている。

クラスタ一元化に伴い、リソース管理(特定ユーザーの占有を防止)とアクセス制限(認証認可)が必要となる。本セッションでは認証認可について紹介する。

従来のHadoopでは以下のような状況であった:

  • 認証: Kerberos ⇒Hive/Impalaも対応
  • 認可: HDFS ACL ⇒Hive Server2でKereros対応可能だが、行/列レベルの細かい制御はできない

Apache SentryはHive/Impala用の認可モジュールを提供しており、この課題に対処できる。具体的には「server - database - table(view) / URI」の階層でポリシーを定義し、認可を設定することが可能。

現状ではポリシーファイル(.ini)で設定する方法だが、Sentry1.4(CDH5.1)ではGrant/Revokeなどの操作によりポリシー定義が可能になる予定。

Sentryはライブラリとして提供されており、Hive/Impalaなどとの統合レイヤーを利用して組み込むアーキテクチャになっている。統合レイヤーは拡張可能。

B-1 Hadoop用の標準GUI、Hueの最新情報 <川崎氏(Cloudera)>

資料) http://www.slideshare.net/Cloudera_jp/hadoopgui-hue

Hue = Hadoop User Experience、コマンドラインを使わず、簡単にHadoopが使えるようにするというのが目的。

開発はGitHub上でOSSとして進められており、コア開発者は3名。GitHub上が最新であり、そこからバイナリディストリビューション(tar ball)→CDHと展開される。新しいバージョンを試したければGitHubから取得してください。

Hueの過去バージョンではいろいろ使いにくい点があったが、3.5以降では大きく改善されており、3.6では可視化機能が大きくパワーアップしている。Solrで検索した結果をダッシュボードで可視化できる。ダッシュボードはブラウザ上でドラッグ＆ドロップしてカスタマイズも可能。

デモがあったので、見たい方はUstreamで。

Hueサーバー(Djangoで実装されたアプリケーション)は通信オーバーヘッド削減のため、Hadoopクラスタ内に配置するのが推奨構成。また、HueサーバーはHA構成も可能。

認証はSimple(DB)およびEnterprise(LDAP/OAuth/SAML)をサポート、ユーザー毎に利用アプリケーションを制限するなどの権限管理も可能。

今後、Sentry対応、Spark対応、Oozie v2対応などが予定されている。

以下が情報源なので併せて参照してください。

B-2 Hivemall: Apache Hiveを用いたスケーラブルな機械学習基盤 <油井氏(産総研)>

資料) http://www.slideshare.net/myui/hdj2014-myui

HivemallはHiveのUDF(ユーザー定義関数)およびUDTF(ユーザー定義テーブル生成関数)として実装した機械学習ライブラリ。油井氏が開発者で、OSS(LGPLライセンス)でGitHub上にて開発を進めている。

開発の動機: プログラミング不要な機械学習のプラットフォームが欲しい。既存のもの(Mahout / Vowpal Wabbit / H2O / Oryx / Spark MLlib)はすべてAPIによるプログラミングが必要だが、非プログラマ向けのソリューションが必要なのでは。

HiveのUDFとして実装することにより、プログラミング不要かつコンパイル不要(試行錯誤が容易)とすることができた。5分もあれば一通りチュートリアルを動かすことができるはず。

HiveのMapReduceへのマッピングを考慮してスケーラブルになるように実装している。かつ、Feature hashingというテクニックを利用することで、メモリに全データが入らなくても大丈夫なように配慮している。

最先端のオンライン機械学習アルゴリズム(CW,AROW,SCW)をサポートしており、他に比べ収束が早い。

反復学習の際に中間結果をHDFSに出力すると遅くなるため、Hivemallでは反復をデータのランダム化処理に置き換えることでエミュレートし、反復回数を削減している。これにより実用的なオーバーヘッドで学習精度の向上を達成している。実際の性能評価でも収束までの時間および精度で優位が確認できた。

Apache incubator化の話があるとのこと。

A-3 A Deeper Understanding of Spark Internals

資料) http://www.slideshare.net/hadoopconf/japanese-spark-internalssummit20143

Sparkを効率的に動かすためには内部構造を知る必要がある。

主にExecution model / Shuffle / Cachingに分解できるが、Cachingの話は後で考えればよい。

Execution modelは以下のフェーズから構成されている:

  1. Create DAG of RDDs: RDDに対する処理をDAGとして構築する
  2. Create logical execution plan: 論理的な実行プランを作る、なるべくパイプライン化できるようにし、複数のstageに分割する
  3. Schedule tasks: stage毎にtaskの実行をスケジューリングする

stage内に含まれるすべてのtaskの実行が完了してから、次のstageの実行に進む。

shuffleデータはディスクに書き出される(大半はOSのディスクキャッシュに収まるはず)、shuffleデータの受け渡しはpullベース(pushベースではない)。

groupby操作では1つのkey-valueペアはメモリ上に格納する必要があるため、巨大なkey-valueペアを避けた方がよい。これは将来のバージョンでは改善したいと考えている。

良くある問題:

  • パーティションの数が少なすぎる: 通常は100から10000程度がよい、最小でもコア数の２倍、最大はtaskの実行時間が100msを超えない程度
  • メモリ消費を最小化せよ: 巨大なkey-valueペアを避ける、GCログやdmesg(OOM-killer)で状況を確認
  • shuffleは必要最小限に: メモリ消費、ディスクI/O、ネットワークI/Oのすべてに影響する
  • 標準APIをきちんと理解して使おう
  • distinct(numPatitions=xx)をうまく使おう?⇒どういう効果があるのか別途調査せねば。

その他のTips:

  • 小さいデータサイズ、キャッシュなしで始め、後からチューニングせよ
  • 可能ならSparkSQLを使おう →Sparkランタイムがチューニングしてくれる(しかも将来的に改善されるはず)
  • rdd.toDebugString()でDAGの内容が確認できる
  • Spark ShellとSpark UIを組み合わせてパフォーマンス分析 →特にFailed TasksやMemory Usageに注目せよ

QA

  • SparkSQLのjoinは内部的にどのような挙動? →単純なHash Joinを行っている
  • Spark Streamingの結果が通常のRDDとして扱えない? →Streamingのための拡張を行っている。Unionするか、SparkSQLで抽出して変換してください。
B-4 Spark1.0での動作検証 - Hadoopユーザ・デベロッパから見たSparkへの期待 <土橋氏(NTTData) / 田中聡氏(NTTDoCoMo)>

資料)
http://www.slideshare.net/hadoopconf/hadoopspark-hadoop-conference-japan-2014
http://www.slideshare.net/hadoopxnttdata/apache-spark-nttdatahcj2014

NTTDoCoMoとNTTDataの共同プロジェクト「社会の頭脳システム」を2009年から運用している。1000ノード程度のHadoopクラスタで、ペタバイト級のデータを処理している。

最近、以下が課題となってきた:

  1. レイテンシの短縮
  2. Hadoopの進化への対応

1.に関して、従来は1時間おきのバッチ処理で十分だったものが、もっと短いサイクルで処理を行いたいというニーズが出てきた。→Sparkによるインメモリ化

2.に関して、MapReduce以外の処理への対応のためにクラスタを新規増設してきたが、管理負荷・資源効率の観点から集約したい。→YARNで多様なワークロードを統合

以上を解決するため、Spark+YARNに目を付けて技術検証を行った。観点は、自分たちのサービスにSpark+YARNが使えるかということで、具体的には数十TBのデータを投入してみて予想外の事象が発生しないかを確認した。

結果は非常に良好で、予想通りデータ量に対してほぼリニアにスケールするパフォーマンスが得られた。

ただし細かく見てみるといろいろな注意点があり、特にshuffle時にネットワークI/OだけでなくディスクI/Oが発生することに注意が必要。また、SparkがRDDで使用するメモリと、キャッシュなどアプリケーション以外で使用するメモリのサイジングが難しい。全体的には全体的に玄人好みのフレームワークと言える。

B-5 Treasure Data on The YARN <小林氏(TreasureData)>

資料) http://www.slideshare.net/ryukobayashi/treasure-data-on-the-yarn-hadoop-conference-japan-2014

TDのサービスはカラム型ストレージ(スキーマレス)とMapReduceの組み合わせで構成されており、Hive/Pig/Impala/Prestoによるクエリーをサポートしている。

ストレージは独自に実装したPlazmaDBを利用しており、AmazonS3上にデータを永続化するようになっている。HDFSはMapReduceの中間ファイル出力以外には利用していない。

Hadoopをカスタマイズして運用しており、MRv1からYARNへの移行中であるが、移行にとても苦労した。ここではその苦労話を紹介する。

TDではHadoopクラスタを４つ運用しており、独自に開発したキュー/スケジューラを通じてHadoopクラスタにジョブが投入されるようになっている。ここに手を入れて、移行先のYARNベースのクラスタに同じジョブを投入するようにし、問題が起きないかをチェックしている。

TDのユーザー数は焼く5000で、データ量は6兆レコード、毎日4万程度のジョブを処理している。

YARNについてはB-3小沢氏の発表がかなり詳しかったので、そちらを参照してください。

http://www.slideshare.net/ozax86/taming-yarn-hadoop-conference-japan-2014-36775198

YARNを利用するにあたってのTips:

  • Job History Serverを稼働させていないと、過去のJobのログが確認できない。必ず起動しておくべき。
  • Hadoop2.4.0以降を使うべし。2.2/2.3のYARNにはバグがあり、スケジューラがデッドロックする。CDH5.0.2のYARNにはパッチがあたっているので大丈夫。
  • hadoop-conf-pseudoには設定ミスがあるので修正が必要(Hadoop2.2の内容のままになっている)
  • CDHやHDPのVMからコピーしてくるか、AmbariやCoudera Managerなどのツールを使うのがよい
  • YARNのWebUIからスタックトレースなどが見られるようになったので便利
  • メモリのチューニングが難しいので、設定支援ツール(hdp-configuration-utils.pyスクリプトやAmberi)を使うのがおすすめ
  • パッケージでYARNを導入しても、必須ディレクトリ等が作られていないので起動できない。忘れずに。
B-5 実践機械学習 - MahoutとSolrを活用したリコメンデーションにおけるイノベーション <草薙氏(MapR)>

資料) http://www.slideshare.net/MapR_Japan/mahoutsolr-hadoop-conference-japan-2014

本セッションの内容は、以下のebook(日本語)に基づいたものだそうです。詳細はこちらを参照するのがよいかと思います。

https://www.hadoop-times.com/technology/pdf-practical-machine-learning.html (要登録)

機械学習を実ビジネスに応用するためには、コストとリターンのバランスを考えることが重要。ここでは、Mahoutが提供する比較的シンプルな機械学習アルゴリズムと検索エンジン(Solr)を組み合わせることで、効果的なリコメンデーションシステムを構築することを考えています。

題材として、AmazonのようなECサイトでのリコメンデーションの実現方法、さらに音楽配信サービスにおけるリコメンデーションについての入門的な内容の紹介がありました。これから機械学習を学ぶには良い教材だと思います。

最後にMapR(Hadoopディストリビューションの一つ)の紹介があり、MapRの特徴としてLucid Works(Solr商用版)のバンドル、およびNFS対応を紹介していました。CDH(Cloudera)やHDP(Hortonworks)などのメジャーディストリビューションとの差別化を図っているようです。

まとめ

全体的にHadoop新時代を感じさせる内容でした。
Sparkは急激に進化していることもあり、内部動作に関する情報はあまりまとまったものがなかったので、今回のセッションは非常に有用でした。