#garagekidztweetz

読者です 読者をやめる 読者になる 読者になる

#garagekidztweetz

id:garage-kid@76whizkidz のライフログ・ブログ!

#hcj2016 Hadoop/Spark Conference Japan 2016 午前キーノートのメモ

スポンサーリンク

今日は大井町きゅりあんで開催された Hadoop/Spark Conference Japan 2016 に参加してきました。

参加してきたセッションだけでも午前に7つ、午後に 5 つと多かったので、午前で1エントリ、午後は個別セッションで5エントリに分けてポストしていきます。

ではまずは午前のキーノートのメモから。

午前のセッションは 7 つあるので各セッションへのリンクは以下のとおり。

Keynote

ご挨拶、Hadoopを取り巻く環境2016 / 濱野 賢一朗氏 (日本Hadoopユーザー会, NTTデータ)

  • Hadoop "Spark" Conference Japan 初開催!
    • 今回のひとつの目玉
  • Hadoop 10th Anniversary!
    • Hadoop Conference Japan は 6, 7 回目
  • 来場者数 (登録者数) 1,347 名
    • 63% が初参加。
    • リピート率低いの?
  • いまの Hadoop
    • Hadoop はオワコン?何が Hadoop かわからなくなってきた?
    • Hadoop はひとつのものではなくなってきた
      • 初期は MR, HDFS が中核をなすものだった
      • しかし周辺に並列分散処理エンジンがでてきた
      • Hadoop 互換の他の SW の登場
      • Hadoop ecosystem という言葉が昔からあったものからの広がり
        • その結果、どこからどこまでが Hadoop か曖昧になってきた
      • Packaging の多様さ
      • Linux distribution でも昔あったような話がここでもでてきたということ
      • Distribution は違っても基本構成要素は同様のものが揃っている
    • それゆえに Hadoop は難しいステージに立っているとも言える
  • 分散処理はまだまだ進化・変化・浸透していく
    • Hadoop の安定はまだ時間がかかるといしても。
    • まだまだこれから!

Apache Hadoopの現在と未来 / 鯵坂 明氏(Hadoopコミッタ)、小沢 健史氏(Hadoopコミッタ)

  • Hadoop とは
    • 並列分散処理を実現する MW
    • 複数のサーバを束ねてひとつの大きな処理システムとして利用するための MW
  • 3 つのコンポーネント
    • MR
      • 並列分散処理を実行するMW
    • YARN
      • 計算機リソースの管理を行う MW
    • HDFS
      • 大量のデータを保持するためのMW
  • YARN の現状
    • もともとは Hadoop の計算機リソース管理を汎用化するための手段
    • 現在では安定し MR を起点として、他の様々な並列処理基盤を実行するような使い方が中心
    • WHY
      • YARNがマスタを立ち上げる
        • Tez などの計算機にコピーするだけで動作する
      • 得意な処理だけを実行する基盤ができた
  • Hadoop をとりまく現状
    • Tez
    • Spark etc...
  • 分散処理MWのIF
    • バッチ処理だとSQLに似た言語による記述
      • HiveQL, Pgi Latin
    • バッチ処理とストリーミング処理を透過的に扱えるような言語
      • Apache Flink, Google Dataflow,
    • 機械学習に特化した高水準言語
      • SystemML, Google TensorFlow
  • 多種多様な分散処理MWの登場
    • 現在の並列処理MWはCPU,メモリ、ディスクを中心にした処理
    • 一方で高水準言語の中でCPUだけでなくGPGPUなおを利用したアーキテクチャを利用したものが登場
  • YARN の将来
    • YARN や GPGPU やFPGA を含む様々な計算リソースを扱えるデータセンターOSへ
  • HDFSの現状と将来
    • 性能→安価になったSSDやメモリの活用
      • 異なる種類のストレージが混在した構成に対応
      • メモリをストレージとして扱う
    • セキュリティ・運用性
      • POSIX ACLs→よりきめ細かいアクセス制御
      • データ暗号化
      • ローリングアップグレード
    • HWの進化に応じてさらなる進化
  • Hadoop の開発コミュニティ
    • 1つの指標→変更コード行数
      • HortonWorks, Cloudera, Huawei
      • 日本からで言うと NTT, NTT-D, Y! Japan
  • Hadoop をよりよくしたい
    • メンテナンスリリースの継続
      • 2.6, 2.7 系はメンテナンスされている
    • Java 8/9 対応
    • 新しい HW を意識した高速な処理機晩
      • SSD
      • GPGPU
      • NVMe SSD
      • インターコネクト
    • Hadoop developer をもっと増やしたい、コミュニティをもっと盛り上げたい
  • Hadoop のユーザコミュニティ
    • YARN はどの程度広まっているのか?
    • 今回の登録者だと 500 人以上使っている
      • その中で 80% がHive, Spark を利用 (YARN 上で使っているとは限らないが)
  • まとめ
    • Spark などの新しい分散処理基盤が広まり、Hadoop は埋もれがちにみえる
    • だが Hadoop は HW の進化に追従する形で着実に進化している
    • 日本でも YARN は広がりつつある

Yahoo! JAPANのデータプラットフォームの全体像と未来 / 遠藤 禎士氏(ヤフー)

  • Y! Japan のマルチビッグデータ
    • Y! のビッグデータ
      • Variaty
        • 100 以上
      • Volume
        • 649億PV/Month
      • Velocity
    • 多数のビッグデータをかかえたマルチビッグデータカンパニー
  • データプラットフォームの全体像
    • Hadoop
      • 6 Cluster
      • 6,000 node
      • 120PB
    • RDB
      • MySQL (Percona)
    • DWH
      • TeraData
    • Object Store
      • プロプライエタリなPF
    • KVS
      • Cassandra
        • 30Cluster: 2000nodes, morethan 1TB
    • これから
      • Presto
      • Redis
      • OpenStack
      • Hadoop 関連だと
        • Tez, LLAP
        • HBase, phoenix
        • Erasure code, Archival Tier
        • Spark
  • Hadoop に関する技術チャレンジ
    • 課題
      • データ需要の指数関数的増大
        • 年率で 4 倍での伸び
        • それによるコスト増大
      • CPU使用率
        • 年率 2.4-3.3 倍
        • 毎年クラスタを追加できるわけではない
      • お金ではなく技術での解決が課題
    • 広告レポートでのチャレンジ
      • 10万Query/hour この要求も 3.3 倍で増える
      • Hive on Tez
        • 最初の性能は 1万Q/hour だった
        • MetaStore の性能ボトルネックを解消→ 2万
        • Resource Manager のランチャースレッド数を増加, RM と AM のハートピート間隔を長く→4万
        • DN: 他ノードでのコンテナ再利用、レプリケーションファクター増加→8万
        • 負荷ツールの最適化、ジョブの終了時にランダムスリープ(ジョブが一斉に終わると HDFS に一斉に書き込み、NNのボトルネックに)→10万
      • まとめ
        • MetaStore は Local mode
        • RM, AM をバランスよくチューニング
        • DNのリソース有効活用
        • クライアントサイドの最適化
  • 最後に
    • Y!Japan の方向性
      • Y!,Inc. の USE から MAKE へ
        • 日本の高い電気代、狭い土地
      • HortonWorks との提携の背景

Hadoopのストレージの現状と展望 / Todd Lipcon 氏 (Cloudera)

  • The Evolution and Future of Hadoop Storage
  • Introduction
    • ML messages sent by him.
      • Quiet for 3 years for developing Kudu.
      • Now become active, so be here hcj2016.
  • A Brief History of Apache Hadoop.
  • Evolution of the Hadoop Platform.
    • 206-2007: Basics: batch processes only, Not stable, fast or featureful.
    • 2008-2011: Production: HBase, ZK, etc... Expanding feature set. Commercial distributions.
    • 2012-now: Security (most important), Performance, Fast Full-featured SQL (ANSI)
  • Evolution of Storage
    • Basics 2006-2007
      • HDFS only
        • Support basic batch workloads. No HA.
        • everything run slowly.
    • Production: 2008-2011
      • HDFS evolves to add HA and security
        • still focused on batch workloads.
      • HBase becomes an Apache top-level project.
        • introduces fast random access.
        • just this phase only early adaptors.
    • Entrerprise: 2012-now
      • Reliable core brings new users
        • Enterprise fearutres.
          • ACL, Disaster recovery, encryption.
        • Fast Query Engines.
          • SQL on Hadoop (Impala, Spark, etc..)
          • HDFS performace improvemenns. (Apache Parquet, ORCFile)
        • Hbase evolves 1.0.
          • Good random access - not fast for SQL analytics.
        • Initial support for cloud storage.
          • AWS, Azure, GCP etc...
  • So what comming next?
    • 2016-2020
      • HDD innovations.
        • Spinning disk -> Solid Stage Storage
          • NAND flash
          • 3D Xpoint memroy
            • 1,000 times faster than NDN, cheaper than RAM
      • RAM is becomming cheaper, and more abundant.
        • 64-128->256 GB over last few years
      • HDFS and HBase
      • Gaps in capabilities.
        • HDFS good at
          • Batch ingest only
          • Large amount of data
        • HBase good at
          • Efficiently finding and writing
      • We need both above so your 3rd option is Kudu.
        • High throughput.
        • Low latency.
      • Kudu (Details are explained at his session this afternoon.)
        • Scalable
        • Fast
        • Tabular
          • support SQL
    • Prediction
      • Kudu will evolve an enterprise feature set and enable simple high performance realtime architecture
      • HDFS and HBase will continue to innobate and adapt to NG HW.
        • Performance, efficiency and scalability.
      • Cloud Storagge.

Spark Conference Japanの開催にあたって / 猿田 浩輔氏(Apache Sparkコミッタ)

  • 開催の経緯:日本における Spark 熱の高まり
    • Meetup
    • 日本語の情報が増えてきた
      • 3 冊の書籍も販売
    • 日本のコントリビューターも増えてきた
    • 商用運用の検討も多数
  • どのくらいの人が Spark に関心があるのか?
    • 70% の参加者が利用もしくは利用を検討
    • 12% はすでに Prod 運用
    • 6% は1年以上の運用経験
  • 利用されているコンポーネント
    • 55% が Spark SQL/ Data Frame
    • 用途のわかりやすい MLlib や Spark Streaming も 40% 近い利用

Spark 2.0: What's Next / Reynold Xin 氏(Databricks)

  • @rxin
  • What is Spark?
    • OSS data processing engie
      • Speed
      • ease of use
      • sophisticated analytics
    • Components
    • Ecosystem
      • Application
      • Envirionments
        • Docker, OpenStack, etc.
      • Data Sources
    • Databricks
      • Enterprise Spark Platform.
    • 2015: Great year for Spark
      • most active OSS project in data
      • new language: R
      • widespread support
  • How are people using it?
    • Divese Runtime Environments
      • Stand alone: 48%
      • YARN: 40%
      • Meson: 11%
      • on Public Cloud: 51%
    • Industries Using Spark
      • SW: 29%, Consulting: 14%
    • Top Applications
      • BI: 68%
      • DWH: 52%
      • Reccomendation: 44%
      • Log processing: 40%
      • User Facing Services: 36%
  • Spark 2.0
    • History
      • 2010 started @ Barkeley
      • 2012: reseach paper
      • 2013: databricks started & donated to ASF.
      • 2014: Spark 1.0 and libraries.
      • 2015: DataFrames, Tungsten, ML Pipelines
      • 2016: Spark 2.0
    • Spark Stack diagram
      • Frontend: API fundation
        • Streaming, DataFrame/Dataset, SQL
        • RDD, DataFrame, ML Pipeline APIs
      • Backend: 10X performance
        • scheduler, shuffle, operators,
    • Guiding Principles for API Foundation
      • Simple yet expressive
      • (Semantics) Well devined
      • Sufficiantly abstracted to allow optimized backends
      • Example (should look the slide)
    • API Foundation in Spark 2.0
      • Streaming DataFrames
      • Maturing and merging DataFrame and Dataset
      • ANSI SQL
        • natural join, subquery, view support.
    • Challenges with Stream Processing
      • stream processing is hard
        • Output overtime
        • Late data
        • failures
        • distribution
      • and all this has to work across complex operations
        • windows, sessions, aggregation, etc...
    • NG Straming with DataFrames
      • Easy to use APIs
      • Well defined semantics
      • Leverages Tungsten.
    • Spark is already pretty fast.
      • Enable to 10x faster with 2.0?
        • Teaser[PR]: SQL/DataFrame Performance is actually enabled it with 2.0.
    • Spark 2.0 Release Schedule
      • Mar-Apr: code freeze
      • Apr-May: official release

さくらインターネットが構築した、Apache Sparkによる原価計算システム / 須藤 武文氏(さくらインターネット)

  • データをあつめて処理して出力する、一般的な処理。ビッグデータというほどのものではない。
    • Asakusa を用いた事例。
    • Spark を使ってふつうの企業システムをつくることができる、という話。
  • さくらインターネット
    • 20th anniversary
    • ハウジングとホスティング
      • 専用サーバ
      • VPS
    • DC
      • 都市型
      • 郊外型→石狩
    • バックボーンネットワークを持ってる
  • Apache Spark を用いた原価計算システム
    • 規模を追求する「持つ経営」
      • 石狩DC以降、資産が増大
      • 不安
        • 投下した資本は計画通り回収出来てるのか?
        • 黒字に転換できるのか?
        • 黒転まで既存の資産で支えられるのか
      • コストがわかれば
        • 上記の問題解決になる
      • これらはもちろんやっていた、最強ツール Ex*** で。
        • しかし、ボトルネックが
          • 処理時間
            • Ex*** がハングする
          • 十分なデータ収集ができない
          • コスト計算の明確なルールの整備不足
      • 目標
        • 原価計算の聖地化・迅速化
        • データの整備と社員の意識向上
        • 分散処理基盤の構築・運用に関する知見を積む
      • 期間
        • 2013 からはじめた
        • 2015 のはじめ頃から Spark を検討し始めた
          • Asakusa が処理エンジンとして裏側で Hadoop をつかうか Spark を使うかを考えなくてよくしてくれた。
      • システム全体像 (slide)
        • データ量: 300GB/day
        • 処理の特徴
          • 各種台帳、時系列
          • IO インテンシブ
          • バッチが複雑で長い
        • オンプレミス
          • サーバはそもそも売るほどある
          • 物理サーバ 30 台
            • コア数 200
            • 総メモリ 1.6TB
            • わりとアドホックに増設 (続きは午後で)

午前のキーノートのメモはここまで。以降、午後のセッションを 5 つエントリをポストしていきます。

資料埋め込みリンク

  • 公開されているものはこちらに埋め込みリンクさえていただく所存。

Hadoop/Spark Hadoop Conference 2016 でとってきた他のエントリへのリンク

  • のちほどリンクを追加していく所存。

garagekidztweetz.hatenablog.com garagekidztweetz.hatenablog.com garagekidztweetz.hatenablog.com garagekidztweetz.hatenablog.com garagekidztweetz.hatenablog.com