Hadoop / Spark Conference Japan 2016

概要

Hadoop / Spark Conference Japan 2016に参加したチラ裏レポ、感想です。Hadoopカンファレンス初参加でした。途中仕事のメールが入ったためかなり適当にメモったので適当なこと言っていたらすみませんm(__)m

www.eventbrite.com

基調講演

Hadoopを取り巻く環境2016

  • 濱野 賢一朗 （日本Hadoopユーザー会, NTTデータ）
  • Spark Conference 2016初開催！
  • Hadoop10周年！このカンファレンスは6回目、7年目。
  • 去年1299名→今年1347名。今回は63%が初参加。
  • 「Hadoopはひとつのものではなくなった」
  • 昔はHDFSとMRだけだった。どこからどこまでがHadoopかわかりにくくなってきた。
  • 昔のLinuxも同じことを言われてきた。少しずつ修練されていくと思っている。
  • 今どんな変化があるのかを良く知ることが大事。

Hadoopの現在と未来

  • 鯵坂 明（Hadoopコミッタ）、小沢 健史（Hadoopコミッタ）
  • Hadoopとは。コンポーネントは三つある。
  • YARNの現状と未来。リソース管理を汎用化するための手段。
    • YARNがマスタを立ち上げるため。
    • 得意な処理だけをやらせる。
    • バッチ処理ではSQLに似た言語による記述が主流。DSL。
    • バッチ処理とストリーム処理を透過的に扱える様な言語。Flink、GDF。
    • 高水準言語も登場。SystemML、TensorFlow。
    • CPUだけでなくGPGPUやFPGAなどを利用したミドルウェアを利用。
    • YARNはCPU,メモリ、ディスクの処理に焦点を当てていたが、GPGPU、FPGAなどを含む計算リソースを扱えるようになる。
    • データセンターOSとしてのYARN
  • HDFS
    • 安価になったSSDやメモリを活用。異なるストレージの構成に対応。
    • セキュリティ・運用性の向上。アクセス制御。データの暗号化、ローリングアップグレード。適用領域を広げる。
    • Hadoop変更行数ランキング。Hortonworks, Huawel, Cloudera, NTt, Altiscale, Intel, Yahoo, Microsoft, twitter, Salesforce
    • 今後もHadoopをよりよくする活動。メンテナンスリリースの継続。Java8/9対応。新しいハードウェアを意識。開発者を増やしたい。
    • ざっくりYARNユーザーの80%以上がHive, Sparkを使っている。

Yahoo! JAPANのデータプラットフォームの全体像と未来

  • 遠藤 禎士（ヤフー）
  • マルチビックデータカンパニー。
    • Variety。100以上のサービス。
    • Volume。649億PV。8300万ユニークブラウザ。
    • Velocity。一秒間に5万アクセス。
  • 全体像
    • Hadoop。6つのクラスタ。6000ノード。120PB。
    • RDB。MySQL（Percona）560DB。Oracle200。
    • DWH。テラデータ。月間933万件クエリ。
    • ObjectStore。レガシー1500ノード。10PB。Goで作る単価2円。
    • KVS。カサンドラ2000ノード。30クラスタ。1TB。秒間15万。
  • これから
    • SQエンジン。Tezの導入本格化。LDAPも。
    • インメモリ系。HBase、Phoenix。
    • ストレージ。Erasure code。Archival Tier。
    • Spark。サイエンス部隊で、検索データのグラフデータ化に取り組んでいる。
  • Hadoopに関する技術チャレンジ。
    • データ容量が年率四倍になっている。5年後の1024倍は稟議が降りないでしょう（笑）
    • 3000台のHadoopクラスタリソースを8ヶ月で使い切る。
    • 広告レポートのチャレンジ。毎日13億行が追加される。10万クエリ/hour,、年3.3倍している。
    • Hive on Tez。Metastoreがボトルネック。RemoteからLocalへ変更で性能が二倍。
    • リソースマネージャー。アプリケーションマネージャのランチャースレッド数を2倍に。
    • ハートビート数にRMが耐えられなかったので間隔を伸ばした。結果二倍。
    • 他ノードのコンテナ再利用。レプリケーションファクタの増加。ラストアワープロブレム。直近のデータのレプリケーション数を増やした。10万クエリ捌けるようになった。
    • NameNode。同時クエリ数を調整する。上げれば良いものでない。
    • ジョブ終了時にランダムスリープを入れると良い：ジョブが一斉に終わるとログを書き込む処理がボトルネックになる。
  • 今後のYahoo Japanの方向性
    • USEからMAKEへ

Hadoopのストレージの現状と展望

  • Todd Lipcon（Cloudera）
  • HDFSの初期からの開発者。Kudoのリードエンジニア。
  • 「エンジニアだからグラフが好きだ」
  • 2012年からKudo開発。
  • Hadoopには現在800以上のコントリビュータ。コンポネントも2→26へ。
  • Basics 2006-2007。Early adapterだけ。Facebook、Yahoo。
  • Producion 2008-2011。HDFS HA。HBaseがTLPに。：ランダム・アクセス
  • Enterprise 2012-2015。アクセスコントロール。障害復旧。暗号化。SQLonHadoop。HBase1.0。クラウドステレージの対応。
  • Next-Gem 2016-2020 RAMが安くなった。ランダム・アクセスが早くて、アナリティクが早くなるようなストレージとしてのKudo。
  • Prediction。Kudoのエンプラ対応。HDFSが進化していく。クラウドストレージの重要性が増してくる。

Spark Conference Japanの開催にあたって

  • 猿田 浩輔（Apache Sparkコミッタ）
  • Spark熱が高まっている。
  • 55%以上の人がSparkSQL, Dataframe。MLlibやStreamingも40％に近い結果に。

Spark 2.0: What's Next

  • Reynold Xin（Databricks）
  • SparkのPMCでTangsutenプロジェクトのリーダー。
  • speed, ease of use, sophisticated analytics。オープンソースデータ処理エンジン。
  • 2015は1000のコントリビュータ。R。幅広い業界に採用。
  • environment, standalone48%, yaron40%, mesos11%, public cloud51%
  • BI, DWH, Recommendation、ログ処理、ユーザー向けサービス、不正検出などに使われる。
  • Spark2.0
    • Frontend、RDD, DF, ML。 Streaming, df, SQL
    • Backend, schedular, shuffle, operator。x10performance, Codegenベクトル化。
    • DataframeAPIはLogicalplanが挟まる（Catalyst Optimizer）すると各クライアントがその層を使える。
    • その先はJVMだけだったが、Tungstenが加わる。
  • API Foundation in Spark 2.0はどうなるか。Steraming、DataFrameの成熟。ANSI SQL。
  • ストリーム処理が難しい理由は、長期間のアウトプット、遅延処理、障害、分散。これが複雑なオペレーションにわたって機能しないといけない。
  • SQL/DF performanceが10倍になる。
  • Spark2.0は4、5月にリリース
  • [余談] Fortuneのこの記事を日本ローカライズしたネタ笑った。北川景子をXin氏に伝えたの誰だったんだろ。

Spark as a 北川景子

A photo posted by satoshihirose (@satoshihirose) on

さくらインターネットが構築した、Apache Sparkによる原価計算システム

  • 須藤 武文（さくらインターネット）
  • 規模を追求する「持つ経営」なので、資産が増加していく。
  • どのくらいコストが掛かっているのか。を知りたい。
  • これまでの方法は。手作業に時間がかかる。十分なデータ収集が出来ない。コスト計算の明確なルールが整備不足だった。
  • 原価計算の精緻化・迅速化。データ整備と社員の意識向上。分散処理基盤の構築・運用に関する知見を溜める。
  • データ量は300GB/day。
  • 物理サーバーは30台。総メモリ量は1.6TB。アドホックに増設している。利便性が高くて良い。

各論

YARN: Resource Manager for Analytic Platform

  • 小沢 健史（NTT）
  • YARNの機能
    • 計算機クラスタ内におけるリソース管理
    • YARNアプリケーション実行履歴
    • 動作中のサービスの場所を知るための仕組み
  • なぜYARNを使うのか。
    • データ分析基盤を使い分けたい場合がある。
    • その場合の対応方法
      • クラスタを分ける（管理が複雑）
      • 処理基盤を同居する（計算リソースの分離が困難）
    • YARNはデータを動かさずに複数のデータ処理基盤を同居させる思想
    • 処理系のマスタをジョブ毎に立ち上げられる（Yahoo Incの要望で導入とのこと）
      • これまではJobトラッカーが死活監視していたのがボトルネックになることがあった。それを負荷分散するため。
  • リソースマネジャー。マスタがクラスタ全体のリソースを管理。
  • ノードマネージャー。スレーブが計算機毎のコンテナを管理。
  • 課題：割り当てられたコンテナのリソースが全て使い切れているとは限らない。
  • 実行履歴の管理。パフォーマンス・チューニング。
  • TimelineServer。アプリケーション固有の情報を利用することでリッチな性能解析が可能。例：TezUI
  • ServiceRegistory。ある意味サービスディスカバリー。HivemallのMixServerみたいな用途。
  • YARN上におけるMR派生の並列分散処理基盤。
    • Spark, Tez(Hiveの下で動く）、Flink。汎用的で非循環有向グラフ（DAG）
    • MapMapReduceみたいな感じでジョブの数を減らせる。シャッフルが増えると並列性が行かせない。
    • Tezは、HivePigといった高水準言語を前提に、シャッフル時のソートがないようなDAGを記述することが可能。
  • コンテナの再利用で、コンテナの立ち上げ時間を減らせる。
    • MapReduceにあったContainerReuseとの差は？実装がなくなっていた。セッションにより、リソースを再利用することが出来るようになった。
    • LLAP。Long Lived and Process。立ち上げっぱなしのコンテナ。ふつうのDBとやっていることと同じ。余ってるリソースをYARNから継ぎ足せるのが良い。
    • Spark上におけるYARNでもコンテナ再利用相当の機能は実装済。逆にコンテナが終了できない。リソースの利用率が低下する。動的リソース管理。

KuduによるHadoopのトランザクションアクセスと分析パフォーマンスのトレードオフ解消

  • Todd Lipcon（Cloudera）
  • Why Kudo?
    • TimeSeries。ファイナンシャルマーケット。
    • Online reporting
    • Xiaomiのユースケース。100億/day
      • Kafka->Storm->Kudo
      • table is horizontally partitioned into tablets. replicas 3 or 5 , Raft consensus. fault tolerance 5 seconds.
    • don't need ZK or some module.
  • How to work.
    • カラムなストレージ。
    • データはテーブルに格納する。

Project Tungsten. Bringing Spark Closer to Bare Metal

  • Reynold Xin（Databricks）
  • 独自のメモリ管理でJVMのオーバヘッド（空間的、GC）を克服する。（四文字のストリングも48バイトになってしまう）
  • Janinoコンパイラを使用して、コードの生成時間を減らした。
  • アルファソート。キャッシュフレンドリーなソート。プレフィックスを付けることで、短絡化する。
  • Spark as a Compilerの話。複雑なIOはコンパイル出来ない。

感想

  • Spark、HadoopやKuduのCommiter氏各位の話、分散処理基礎に始まり機能紹介やらコミュニティ今昔やら比較やらが聞けるのでとてもためになる。
  • 濱野氏が最初の挨拶で言っていたようにまだまだHadoopコンポーネントは発展していくのだろうし、開発者が良い判断することは暫くは難しいままだろう。
  • Maintainable Cloud Architecture of Hadoop聞きたかった😣
  • データドリブン企業における、Hadoop基盤とETL ～niconicoでの実践例～も聞きたかった😣
  • DynamoDBの話がどこかでされていたようで、聞きたかった😣

現在の弊社にどう活かせるか

  • 弊社のような小規模な開発チームでは、楽になったとはいえまだ自前でHadoopクラスタを運用するコストを割くことが出来ないなとは思う。
    • そういう意味でTodd Lipcon氏が言っていたようにクラウドストレージの需要はますます高まってくるのは間違いない（Clouderaはプラットフォーム作ってくれないのかしら）（ユーザーの半分はクラウドストレージを使っているって言ってたのTodd氏だっけ？Xin氏だっけ？）
    • もしくは、KuduのようにZKやHDFSに依存しない道や、TDのようにS3にストレージ任せてしまうって道もあるっぽい（トーク聞いていないけどどうやらそんな話をしていたらしい）
  • こう言う意見も全然わかる。
  • 「YARNはデータを動かさずに複数のデータ処理基盤を同居させる思想」みたいなものがデータ処理をスケールさせるためには必要であって、そのためにはストレージを中心にデータ処理周りのコンポーネントの開発が活発なHadoopエコシステムにbetするのは長期的に見て間違いない（別にストレージはAWSとかGoogleとかでも良いんだけど）
  • Sparkはもちろん銀の弾丸って訳ではないのでって当たり障りのない話になってしまうのだけれど、課題に対してメリット（自分でスケールする分散処理の仕組みを用意するより楽）やデメリット（学習コスト運用コストが増える、cronとかダサい）とかを鑑みて最終的な判断する必要がある。