#garagekidztweetz

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

トップ > conference

エンジニアなら使える深層学習～TensorFlowやDataRobotで機械学習がもっと身近に〜のメモ

conference datascience tensorflow devsumi2016

今日（2016-02-18）はDevelopers Summit 2016 - Hack the Realに参加してきたので、参加したセッションのメモを別々のエントリで公開していこうと思う。

まず、本エントリのコンテンツね。

では、以降からがメモ。

【18-B-1】エンジニアなら使える深層学習 ～ TensorFlowやDataRobotで機械学習がもっと身近に / シバタ アキラ氏 [DataRobot, Inc]

  • 自己紹介： @madyagi
  • 今日お伝えしたいこと
    • あなたも人工知能つかえます。つかってみてください。
    • つかってみていただくことが重要
  • そもそも人工知能って何？
    • Deep learning アルゴリズムの画像処理の性能すごすぎ
    • 機械って人間超えちゃうんじゃね？
    • とりあえず、その辺の技術全般を指すパイプ言語としてバズる
  • 人工知能を作ろうとする人増えてます
  • もうすこしだけ正確に
    • 人工知能＞機械学習＞深層学習
  • 機械学習って何？→技術的にも mature に
    • コンピュータアルゴリズムにパターンを学習させ、予測や識別などの問題を解かせること
      • 種類
        • 教師あり
        • 教師なし
  • 機械学習への入力データと解ける問題
    • 分類
      • 2値分類
      • 多値分類
    • 回帰
      • 連続値
    • 時系列
      • 数値x時間
    • レコメンデーション
      • 数値xアイテム
    • クラスタリング
  • すでに広くのビジネスに応用されている
    • 金融
      • 与信
    • 保険
      • 事故に合う確率
    • マーケティング
      • クリック率
      • キャンペーン効果
    • 人事・採用
      • マッチング
      • 辞めそうか？
    • スポーツ
      • 打率
    • ヘルスケア
      • 再入院率
  • トラディッショナルな機械学習はどんどん進化している
    • 研究者がアルゴリズムを書いて論文で発表
    • 開発者がOSSライブラリでコーディングできるように
    • エンドユーザ、ボタンを押すだけで誰でも使えるレベルへ（データロボット）
  • Demo (データロボット)
    • 写真は不可
    • 自動的にいくつものモデルアルゴリズムを同時に実行させてデータセットに対する分析の結果を比較。
      • 精度の高いモデルを自動で作成される？！
        • 対象のモデルを利用するための REST の API も自動で作成される？！
  • そもそも
    • 深層学習ってなに？
      • ニューラルネットワーク型アルゴリズムの隠れ層を多段にすることで、学習能力を高めたもの
        • 学習方法
          • オートエンコーダー
          • Restricted Boltzmann Machine etc...
    • Shallow Neural Network
      • Input > Linear Transformation > Hidden Representation > Linear Transformation > Hidden Representation > ... > Output
  • 深層学習への入力データと解ける問題
    • 入力データがより人間のそれと近いものへ
      • ブーリアン
      • 数値
      • カテゴリ
      • テキスト
      • 音声
      • 画像
    • 解ける問題
      • 分類
        • 2値分類
        • 多値分類
      • 回帰
        • 連続値
      • 時系列
        • 数値x時間
      • レコメンデーション
        • 数値xアイテム
      • クラスタリング
  • TensorFlow とは
    • 深層学習の構築に必要な線形代数を表現し、GPUなどの分散処理技術を使って計算するためのライブラリ。
      • エンジニアなら Python/C++ から「わりと」簡単に使える
    • 応用例
      • 手書き文字の認識
        • 書いたりすることも？
      • テキストのベクトル化
      • 機械翻訳
      • 自然言語のモデリング
      • イメージ内にある物体の識別 etc....
    • Google の物体識別アルゴリズム Inception3 は Top5 正答率で世界最高精度、人間よりも精度が高い
      • すでに TensorFlow で使える
  • Demo (TensorFlow)
    • pip で TensorFlow をインストール
    • Inseption3 (学習済みのモデル)をもってきて実行させてみる
      • Google の TensorFlow のページにある
    • GiantPanda の画像をデフォルトだと見に行くようになっていて、 GiantPanda だと答える
    • 学習済みであるものについてしか答えられない
  • TensorFlow もどんどん進化
    • Deep Dream もちかぢか TensorFlow で使えるようになる
    • 将来的にはボタン一つでポチッとレベルまでいくだろう
  • 機械学習ができない人も問題を定式化できると多様なアイデアにつながる。
    • ドメインナレッジを活用できるから。
      • 世界の全員 x AI で膨大な問題を解決できる
    • マー
      • 月のクレーターから人の顔に似たものを探すとかいうネタ

資料埋め込み

資料が公開されたらこちらに埋め込ませて頂く予定。

関連リンク

devsumi2016 でわたしがとってきた他セッションのメモ

のちほど他のエントリを書いたら更新する予定です。 garagekidztweetz.hatenablog.com garagekidztweetz.hatenablog.com garagekidztweetz.hatenablog.com

#hcj2016 Hive on Sparkを活用した高速データ分析のメモ

hadoop hive spark conference lifelog

そして、 Hadoop/Spark Conference Japan 2016 午後5コマ目、この日の通常セッション最後の一コマのメモを公開。
（本日中の公開は難しいと思いますが、次に最後の個人的超まとめという名前のリンク集をポストする予定）。

Hive on Sparkを活用した高速データ分析 / 加嵜 長門氏（DMM.comラボ）

  • Spark MLlib, GraphX を用いたレコメンド開発をしている方。
  • 103 slide ある資料なのでザッピングでプレゼンする。
  • Hive on Spark.
    • Hive の Query を Spark 上で動かすもの
  • DMM.com の事例
    • サービス情報を kafka, sqoop で集め、 Have x Spark で分析。

    • その運用を1年ほど

      • 課題
        • Hive が遅い
          • クエリのデバッグに時間がかかる
          • 定期バッチ
            • サービスの追加とともに実行時間が肥大化
      • SQL on Hadoop の選択肢
        • Hive
        • Spark
        • Impala
        • Drill
        • Presto etc...
      • なぜ Hive on Spark?
        • Hive の高速化を目指す
        • 高速とは？
          • 低レイテンシー
          • 高スループット
          • 導入コスト
          • 開発コスト
          • 学習コスト
        • 結果、検討し、 Hive on Spark
          • 導入から運用までのコストが低い 201508 に検証開始して、 201509 に Prod 導入
      • Hive on Spark のメリット
        • 3 時間以上かかっていたバッチが 1 時間まで短縮
          • Job 数が多いほど効果が出る傾向がみられた。
        • Hive クエリの書き換え不要
          • SET hive.execution.engine=spark; だけ。
      • まとめ
        • レイテンシ: 数秒ー数分
        • スループット: Sparkと同等

    • Hive on Spark - 導入手順

      • CDH を使う or Apache Community 版
        • Cloudera Manager を使えば一瞬。
      • SET hive.execution.engine=spark;
    • 実行例
      • Beeline
      • Hue
        • 実行ユーザごとに Application Master が残り続ける
          • 同時実行ユーザ数が多い場合に配慮が必要
    • パフォーマンス・チューニング
      • 初期設定ではあまりパフォーマンスは期待できない
        • default の割当リソースは小さめ
      • チューニング項目
        • ボトルネックとなる箇所の特定
          • コンソール出力
            • Spark の基礎のスライド
              • コンソールの見方
          • Spark UI
          • Explain の出力
        • コンテナのリソースを調整 (スライド参考: 推奨値記載)
          • Driver, Executor メモリを調整
          • Driver, Executor コア数を調整
          • etc..
          • 静的にリソースを割り当てる
            • メモリ詳細設定 (Spark1.5 までと、Spark1.6から)
          • 動的アロケーション
            • 処理量に応じて Executor 数を動的に決定する
            • Executor あたりのCPUやメモリ量は別途指定した方がいい
        • パーティション数(タスク数)を調整
          • タスク数を固定値で指定する
          • 1タスクあたりのデータサイズを指定する
        • その他の項目を調整
          • シリアライザ
          • !! コネクションタイムアウト
            • Client の生成に時間がかかり、タイムアウトする場合がある。
            • default 値が小さい
          • 圧縮
          • ファイルのマージ
            • ただし安易にマージすると Executor のメモリ量によってはシャッフル時に OutofMemoryになる。
            • default 256MB をもうすこし低くする必要があった
          • !! 圧縮 x マージの合わせ技
            • ファイルのマージは出力結果にたいして行われる
            • Textfileのようにファイル全体に圧縮がかかる場合、圧縮ファイルのマージはできない
  • Hive on Spark まとめ
    • 導入〜運用までのコストが低い
      • Hive と Spark を知っていれば学習コストは低い
    • パラメタひとつで高速化
  • 残りは Hive で役立つ SQL 構文が書いてあるので Slideshare みてね。

資料埋め込みリンク

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

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

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

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

#hcj2016 Hiveを高速化するLLAPのメモ

conference hadoop hive lifelog

さらにさらに引き続いて Hadoop/Spark Conference Japan 2016 午後の4コマ目のメモの公開。

Hiveを高速化するLLAP / 小澤 祐也氏（ヤフー）

  • Hive の復習
    • 実行エンジン
      • MR
      • Tez
        • YARN 上でしか動かないが Hive や Pig の実行エンジンとして欠かせない
      • Spark
        • Hive on Spark
        • Not Spark SQL
    • Hive の限界
      • インタラクティブな処理には使えない
      • Hive は ETL まで分析は R, Python, Spark などを使う
        • 元データが大きすぎる場合など
      • とはいえ、最近の Hive は速い
        • SET hive.execution.enting=tez
        • カラムナ型のファイルフォーマットをサポート
          • ORCFile, Parquet
        • CBO (Cost Base Optimizer)
        • Vectorization
          • SIMD 命令を利用した一括処理
  • LLAP (Live-Long-A -Processing)
    • Hive をよりインタラクティブに
    • Hive2.0 からの新機能
    • LLAP の基本的な思想
      • Daemon
        • Daemon の立ち上げによる起動コストの削減
        • Daemon カニは Apache Slider を利用
          • Hadoop 上で Daemon として起動し、任意のプロセスを走らせる
          • Storm や Memchaced などサンプル有
        • Hybrid な環境の実現
          • Tez の Vertex を Daemon 化するのが LLAP
          • TEZ-2003
          • Vertex の一部または全部の実行 Node で LLAP を利用
      • Cache
        • LLAP の Daemon 内でデータを cache する
        • ORCFile のみに対応
        • キャッシュアルゴリズム
          • FIFO, FRFU
        • Daemon の Node ごとに cache を持つ
          • 中央集権的にもっているわけではない
        • Off-Heap の利用
      • Multi Thread Pipeline
        • LLAP の Daemon 内で複数のスレッドを起動
          • 各スレッドが Executor として処理を実行
          • Queue
            • 一般的な実行待ち行列に対する扱い
            • 実行可能な Executor にアサインされる
          • Preemption
            • 長時間動きがない場合は諦める
            • Executor にアサインされたタスクがなんらかの理由で実行できない、など
    • LLAP と mode
      • LLAP によって新たにくわわる mode という概念
        • 特定の Vertex がどちらの mode でうごいているか
      • Mode と Daemon (図解)
        • 4 つの mode
          • none
          • all
          • map
          • auto
    • LLAP vs. Spark SQL
      • LLAP 固有の概念
        • Daemon 内共通で使える cache は Spark にはない
      • Tez vs. Spark
        • データがメモリにのらない場合は Tez が有利
      • 既存の資産の活用
        • クエリの互換性
        • HQLは SQL like だが SQL ではない
      • 分析環境のつなぎ込みでは Spark が有利
        • SQL では ETL 以上の処理をするのは難しい
        • R, Python での分析環境との連携
        • DataFrameAPI や MLlib, GraphX
      • ストリーム処理
        • Spark Streaming
        • Hive も ACID やトランザクションに対応はしている
    • LLAP の実行速度
      • Hive on Tez との速度比較
        • 3 回同じ処理をしての平均実行速度
        • 各クエリはシーケンシャル実行
        • TPC-DSの結果
          • ほとんどのクエリにおいて LLAP を利用したほうが速い
          • ものによっては悪くなっているものもある (Query22のCase)
        • 他、鋭意検証中。
          • Daemon 数、並列数、設定変更による影響、など。
  • LLAP の今後
    • バグ周り
    • セキュリティ周り
      • Kerberos には対応
      • キャッシュされたデータの扱い
      • HS2 からの接続
    • Cacheの洗練、 Localitiy
      • HDFS locality は考慮してくれる
      • cache 現状では個々の node が持っている
      • どこの node がどのデータを cache しているかの考慮はなし
      • そもそも Daemon が立ち上がっている node にデータがない場合
      • cache アルゴリズムは適切か
      • タスクリストや WIP

資料埋め込みリンク

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

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

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

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

#hcj2016 今あらためて考えるHiveのメモ

conference hive hadoop lifelog

続いて Hadoop/Spark Conference Japan 2016 の午後3コマ目のメモを公開。

今あらためて考えるHive ～ユースケースの広がりにより顕在化した課題と対応～ / 吉田 耕陽氏（NTTデータ）

  • Hive の泥臭い話
    • HiveQL の構文、 ORCFile, パラメタチューニング
  • はじめに
    • Hadoop 10 際の今年、 Hive は 8 歳。
    • ユーザの割合、圧倒的。
    • ここ 2,3 年で Hive も大幅に変化
      • 分散処理エンジンが選択可能に
        • Tez, Hive on MRv2, Spark
      • カラムナフォーマットが利用可能
        • Parquet, ORCFile
      • さらに低レイテンシ実現へ
        • Hive LLAP
      • 進化はうれしいが日本語情報が少ない
        • プログラミング Hive
        • Hadoop Hacks
  • 近年みかけるようになってきた Hive の使い方
    • 将来データ量・処理量が増大することを見越したスモールスタート
    • すでに実績のあるHadoop基盤での処理開発・移行
    • ということから、これまでと異なるケースに直面することも
      • 入力テーブルが多い、個々のテーブルサイズは小〜大
      • BIツールが直接 Hive にアクセスすることも。
  • HiveQL 編
    • Hive 利用の増加→新規エンジニア参画も増加→ RDMS と同じようにHiveQLを書いてしまう
      • Hadoop Hacks の Hive 導入章が参考になる
    • 散見するのは
      • 無邪気な order by
      • マルチインサートを使っていない問題
    • こっそりと表現力が増している Hive
      • CTE (Common Table Expression)
        • いわゆる with 句
          • サブクエリを極力排除することができる
          • View だと metastore にアクセスが
      • WINDOW 関数
      • LATERAL VIEW + explode
        • 配列の値を行に展開して引き延ばすことができる
    • まとめ
      • 一昔前はいちぶ MR 、Pig 併用といった処理も Hive で完結させやすい
      • UDF が必要なケースも減ってる (Built-in-Functionお充実)
      • HiveMall で機械学習の分野にも進出
  • パラメタチューニング編
    • データが増える処理では注意が必要
      • Hive は生まれた背景から処理の流れの中でデータが減っていくことを期待しているようなパラメータが多い
        • Reducer数: HDFS上の入力データサイズ / hive.exec.reducers.bytes.per.reducer
  • ORCFile について
    • 高速・高圧縮率のカラム志向ファイルフォーマット
    • RDB のアイデアを持ち込んだ高速化の試み
    • Oreducate Pushdown
      • Stride毎にインデックスをもっている。インデックス情報から走査範囲に検索対象カラムがない場合はスキャンをスキップ
      • テーブル設計がその効果に大きく影響
        • where 句のフィルタ条件に利用されるカラムはソートされているほうがよい、など。
    • 大量テーブルの非正規化＋辞書圧縮の合わせ技
    • 高圧縮率問題
    • 教訓と小技
      • ORCFile を利用した場合 HDFS 上でみえるファイルサイズは信用しない方がいい
        • orcfiledump
          • ORCFile のインデックス情報を確認できる
        • SHOW CREATE TABLE
          • テーブルの統計情報を確認できる
    • チューニングの考え方 (案)
      • Hadoop が本来想定していたワークロードとのギャップを意識することがトラブル対処やチューニングにつながる
        • その例がスライドに。
  • あらためて考えた Hive
    • 様々なワークロードに対応？
      • 最初から最後まで Hive で書くこともできなくは、ない。
    • でもやっぱり難しくなった？
      • 半分 Yes.
    • Hadoop on SQL との棲み分けは？
      • 性能要求がみたされるまでは Hive でよいのかも。見極めは難。
  • まとめ
    • Hive は進化し続けている
    • Hive のポテンシャルを引き出し、ちょっと尖ったケースで活用したい場合は、従来 Hadoop が想定していたワークロードとギャップを意識しつつ適用可能性の検討、 POC から入りましょう。

資料埋め込みリンク

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

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

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

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

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

hadoop cloudera kudu conference lifelog

前のコマで参加したセッションが押した関係で、途中からの参加になりましたが、 Hadoop/Spark Conference Japan 2016 の午後二コマ目は Kudu のセッションに参加してきました。

では、今回も以降にメモ。

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

  • Scalable and fast tabular storage
    • Scalable
      • 1000s of nodes, tes of PBs
    • Fast
      • Millions of RW
      • Multiple GB/second
    • Tabular
      • SQL like schema
      • Fast ALTER TABLE
  • Use cases and Architectures
    • Kudu good at sequential and random RW.
    • Time Series.
      • e.g. fraud ditection & prevention.
      • Workload: Insert, update, scans, lookups.
    • Online Reporting
      • e.g. ODS
      • Workload: Insert, update, scans, lookups.
  • Realtime Analytics in Hadoop with Kudu
    • Solving problems before Kudu.
      • Complicated: using 2 storage system.
      • Long latency. Data is not recent.
      • Cannot handle updates/deletes.
    • Kudu make that system much simpler.
      • Fast for Analytics.
      • One system to operate.
      • No cronjobs or background processes.
  • Xiaomi use case.
    • 4th largest SF maker.
    • own online services like photo sharing.
    • need those service monitoriing & trouble shooting tools.
      • Requirements.
        • Hight write throughput.
        • Query latest data and quick response.
        • Can search for individual records.
      • System diagram before Kudu.
        • Long pipeline.
          • High latency (1hour~1day), data conversion pains.
        • No ordering.
          • Log arrival order not exactly logical order.
          • To read 2-3days log data takes 1day.
      • After Kudu.
        • Data Source > Kafka > Storm > Kudu > Impala > result serving.
          • ETL pipeline (0-10sec latency)
          • Direct pipeline (no latency)
  • How it works? (Technical part)
    • Table is horizontally partitioned into tablets.
      • Range or Hash partitioning
      • Each tablet has N replicas (3or5), with Raft consensus
        • Automatic Fault Tolerance.
        • MTTR: ~5sec.
      • Tablet servers host tablets on local disk drives.
    • Installation of Kudu.
      • Just need Kudu install.
    • Metadata and the Master.
      • Replicated Master.
      • Not a bottleneck.
        • super fast in-memory lookups.
  • Kudu as Columnar Storage.
    • Example(Explanation) of Columnar Storage.
      • Storing each column data separately.
        • Good for analytics. Because they are separated so that we can keep data smaller. We only need to access needed column data.
    • Handling inserts and Updates
      • please read white paper in details.
  • Integration.
    • ???
    • Impala integration.
    • MR
  • Performance
    • TPC-H
      • 75server cluster
      • result show that kudu much faster than parquit average 31%.
    • Xiaomi benchmark results
    • YCSB
      • it shows HBase still much faster than Kudu for random access.
  • Project status.
  • Kudu community

資料埋め込みリンク

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

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

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

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

#hcj2016 次世代アーキテクチャから見たHadoop/Sparkの位置づけのメモ

hadoop RDMA NVM spark conference lifelog

Hadoop/Spark Conference Japan 2016 、午後最初のセッションはノーチラス・テクノロジーズの神林さんのセッションに参加。

最初から、メモを取るのは相当しんどいだろうと覚悟のセッションでしたが、濃厚濃密な内容で最後まで楽しむことができました。
自分が参加した中からベストセッションを選ぶなら間違いなくこの神林さんのセッションがベストでした。こんなの他では聞けませんもの。

では以降よりメモ。

次世代アーキテクチャから見たHadoop/Sparkの位置づけ ～特にRDMA・NVMを軸としたときの分散並列処理の観点から / 神林 飛志氏（ノーチラステクノロジーズ）

  • 完全裏番組宣言。マニア向け。 Hadoop/Spark 知りたいなら表番組に行ったほうがいいよ、の前置きからスタート。
  • そもそもメモをとれるのか、というチャレンジを自分もしにきてみた。
  • ノーチラスがみてるのは 2020 年の展望。
    • 今更、 Hadoop/Spark どう動いてるかのはなしはしないよ。
  • 現状認識
    • ビッグデータ、終わりました。ビジネスになってません。
    • IoT も話題にはなっているけど、お金になってません。
      • POC の話はよくある。
      • 最大のボトルネックは NW
      • まだまだ手探り状態
      • Internet よりも Intranet が多い
    • 結局、従来からの CRM とあまり変わっていない。
    • ほとんどの案件が既存の DWH からの移行案件
  • 日本市場どうよ
    • 中小規模が多い
      • 100node はまれに出る程度
      • 大きいものはあるがとりあえずなんでもつっこんでいるもの、ようはゴミ
    • つまり日本市場では基本的にノードは大規模にせず、どうやってレバレッジ利かす？って考えたほうがいい
  • 日本は圧倒的にデータ容量が少ない
    • 10node 以下がほとんど
    • 1,000node 以上もいるけどほとんどない
    • その間は空洞状態
  • んで、 Hadoop/Spark
    • やっぱり分散並列処理基盤としてはきわめて優秀
    • データ集約基盤として考えると効率が悪い
      • 想定しているユースケースが日本に合わない
    • 課題
      • 100node 以上のクラスターが主要ターゲット
      • 何が問題なのか→故障率が高いこと
        • 常に何かが壊れてると思っていたほうがいい
    • そもそも Hadoop/Spark
      • それゆえに障害復旧のアーキテクチャがそもそも論
        • 難易度が高い
          • 常にどこかで障害が起きていることが前提だから
      • それゆえにトレードオフ
        • バリヤーいれまくり
        • オーバーヘッドを許容する
          • 余分にデータをもつ
          • データ書きまくり、レプリケーションとりまくり
  • ベストは自分で調整できること
    • 結局何が問題なのか、障害対策復旧のトレードオフ
      • 小規模小回り優先 (ノーチラスはここが戦場)
      • 大規模ノンストップ優先
      • 規模にあわせて調整したいができない
  • やれやれ Hadoop/Spark
    • OSS だから Pull-req おくればいいじゃん
      • 100node 以下、みてないし、と却下
    • Hadoop/Spark は OSS でないという現実がある
      • 結局、閉鎖的に
      • 政治・勢力争い
      • ソースがオープンなだけ
      • だーかーら、コミッターがいることが重要だったりする
        • フリーじゃないってこと
  • 重要なところ
    • Hadoop/Spark の基本
      • 100node 以下でも動くけど最適化はない
      • 開発陣営がみてるところが違う
      • Source が Open になった IBM ですよ！
    • 新しいアーキテクチャへの対応は Hadoop/Spark からは出ない
      • 99% SQLだろ、 DataFrame なんていらないだろ
      • MW ベンダで最適化したい人だけでしょ、いるのは
  • 新しいアーキテクチャ
    • トレンド：ムーアの法則おわりました。
      • 終わったと言ってないのが終わってるということ
    • なので IO まわりをガッツリやっていこう
      • 不揮発性メモリ
      • メモリーバス強化
      • ストレージのIOコストを減らす
      • 高密度サーバ
        • TheMachine(HP), RSA(Intel), Firebox(AMPLab)
  • Rack-scale-architecture
    • Intel が提唱
    • ラック単位
    • バックプレーン統合
    • 高速の Interconnect
    • RDMA の提供
    • NVM
    • 1,000core
    • メモリは基本的に共有化
    • 一種の小型のスーパーコンピュータ
      • MS の解説がオンラインになる
      • ASPLOS'14 Scale-out NUMA: Rack scale In memory Computing
      • とにかく Enterprise 系が多い
        • SAPが力いれてる。 HANA が遅い。
        • ようは金がよく流れてる
  • RSAの主たる特徴
    • なにはなくとも不揮発性メモリ
      • NVM (Non-Volatile-Memory)
      • データベースの革新に使うことができる
        • データベースのログリカバリがほぼすべて image ベースになる。
      • これをベースにした OSS がでてくるはず。
        • コミットするなら絶対こっち。
        • 特許切れでバンバンくるよ
    • RDMA
      • 共有メモリー
        • Ramote-Direct-Memory-Access
        • リモートの DMA
        • HPC の主要機能
      • ミドルが全然おいついてないのが問題
        • OSS 陣営は何もできてないが、 MS(独自分散DB開発中), Oracle(EXAに投入したいらしい), SAP はがんばってる
        • というわけで Hadoop/Spark はあと2−3年よ？
  • RSA でおさえておくべきもの
    • OS
      • node 管理の単位としてのOS
      • 全体を統括する単位としてのOS
        • 分散 OS 難しいよね
        • 芽があるとしたら仮想基盤
          • Mesos ぅう？
      • 個々のノードが剥き出しの場合
        • 全体を統括する MW が必要になる
        • アプリだけで分散統括を処理することは非現実的
        • 仮想基盤が対応可能かどうか
    • データの置き方
      • 基本戦略
        • localメモリにデータを可能な限り置く
      • 実はそうでもない。という結果が徐々に出始めている
        • レーテンシー以外にデータ転送でバンド幅を使いきってスループットが極端に落ちるということになる
        • 処理をインターリーブしたほうがいい
      • 分散処理の基本に立ち戻ることになる
        • データを飛ばすか？処理を飛ばすか？
        • バンド幅を使い切ることがないかぎりはデータ転送が有利
        • そうでないかぎりは処理をインターリーブしたほうがいい
      • ベストの戦略は事前に計算できるか？
        • ムリポ
        • 全部 broadcast するか semi-join で往復ビンタするか？→ Population による
        • stats とっておけばよくね？
      • 更新どうする
        • 完全に分散トランザクションの世界
          • 基本的に MVCCC がベースになる
          • 更新されたバージョンをどうよむか？
          • Cache コントロールの話か、分散Tx の話か、整理が必要
  • RSA で押さえておくべき要素技術
    • 処理の選択とリソース管理
      • ひとつのコンピュータとみせる場合
        • 分散OS下で管理
      • 複数ノードとみせる場合
        • 分散ミドルで管理
          • いままでのスケジューラでは機能が足りない
    • 同時制御 - 分散トランザクション
      • 人類にはまだ早い
      • 前提として NVM
        • Snapshot を有効に使える
        • MVCC は大前提になる
        • 低遅延もさらに前提
    • RSA 上での分散トランザクション (主流)
      • SSI方式
        • shared nothing の延長
        • ロックは利用しない
      • SILO方式
        • Writeのみロックをとる
    • オレオレ分散トランザクション最強説？！
      • 前提として分散トランザクションを完全理解していることが前提
      • シンプルな更新は SILO -> 変形 2PL
      • 問題はメンテできるのかソレ問題
    • 同期処理
      • 対障害性設計
        • Byzantine Failure まで考えるのか？
          • Omission Failure は最低でも考えたほうがいい
      • 合意プロセス
        • 何かの障害で値がずれた、まあ、ありがち
          • Paxos はあるか？
          • Raft はあるか？
        • RSA的な環境がノード分散とコア分さんんの中間的な位置づけなのできわめて微妙
  • Hadoop/Spark からみると
    • 居直り戦略
      • 無視するということ
      • 神林さんならこっちをとる
    • Adaptive にいく
      • RSAのようなものにも対応する
      • 対応方針
        • クラウド的なもので対応
          • Mesos が大化けすれば可能性がある？？？？
        • ガチで最適化
  • Hadoop/Sparkでの適応
    • OS 実は分散 OS は必要ない
      • 単純に各ノードでDAGのオペレータが走ればよい
      • とりあえず走るミドルとしては Hadoop/Spark はRSAの最有力候補
    • データの置き方で転ぶ
      • リモートメモリーへの対応がどうしても必要になる
    • スケジューラ
      • 現状では空いてる CPU リソースに突っ込め、が限界
    • トランザクション
      • これは無理
        • RAMP でお茶を濁すレベル
        • 管理粒度変更、TM、ロック制御、全部ない
    • 耐障害設計
      • ZK の魔改造が必要になる
      • 超高速な Omission Failure の処理が最低限必要
  • ということで Hadoop/Spark を RSA に対応させるには
    • 絶望的にいろいろやりすぎる必要がある
    • それをやるにはいろいろ周りにつくりすぎた
  • ようは、無理です、という話。
    • ただし無理なのはわかるがどのくらい無理なのかを知っておく必要があるということ
      • 合意問題
      • 分散トランザクション
      • クエリー最適化
      • NUMA
  • で、以上は全部、予想。
    • うしろからよむとう・そ・よ。おあとがよろしいようで。

資料埋め込みリンク

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

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

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

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

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

hadoop conference spark keynote lifelog

今日は大井町きゅりあんで開催された 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