#garagekidztweetz

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

Apache Sparkを利用した「つぶやきビッグデータ」クローンとリコメンドシステムの構築〜のメモ

今日(2018-02-18)のDevelopers Summit 2016 - Hack the Realで最後に参加したセッション。

個人でこれをやったのは着想がすばらしいなと思ってただただ感心したセッション。

本エントリのコンテンツは以下。

で、以下よりがメモ。

【18-B-5】Apache Sparkを利用した「つぶやきビッグデータ」クローンとリコメンドシステムの構築 / 野田 純一氏 [GMOインターネット]

  • @n428dev
    • Software Design 201511 号
    • ConoHa を使った Hadoop 事例
  • 目的
    • NHK NEWS WEB のつぶやきビッグデータをつくりたい
      • 3月でこの番組なくなる?つぶやきビッグデータも?!
  • Spark について
    • MR とは別のアプローチ、 DAG での並列分散処理
      • Job Scheduling Process
        • RDD Objects
        • Scheduler
      • ITPro の記事。 DAG と MR の違い
    • インメモリ
    • Hadoop ecosystem の一部として扱われるが Hadoop と直接な関係はない
  • Spark Streaming について
    • リアルタイムに流れてくるストリーム対する集計ができる
    • 直近一時間のツイート数を毎分集計する、直近3時間でアクセスが多いIPを集計するなどの、 WINDOW集計が可能になる
    • データソース
      • Kafka, Flume, HDFS/S3, Kinesis, Twitter > Spark Streaming > HDFS, DB, Dashboards
  • 検証サービス説明
    • Twitter > Spark Streaming > Mikasa, Ikazuchi
  • Spark Streaming を使用したオンライン Twitter 解析
    • ここはスライドを参照したい
      • Streaming
        • Twitter Streaming API
          • 400 までの検索キーワードが指定可能
        • Spark Streaming
          • kuromoji: 形態素解析
            • デフォルトの辞書にない情報は自分で追加する必要がある
          • ウィンドウ集計の活用
            • 直近 5 分
            • 直近 60 分
        • Apache Kafka
      • Recommendation
        • Kafka
          • Ruby
        • nginx
          • Data-Driven Document
        • Amazon Product Advertizing API
        • Trend Product Bot (Twitter account へ) @Akihabara_itso
    • 完全スタンドアロン構成 (Mac or Linux)
      • ZK
      • Kafka
      • nginx
      • GraphX
      • Spark Streaming
      • Spark
      • Ruby
      • Java
      • Scala
  • Demo.

資料埋め込み

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

関連リンク

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

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

乗り遅れるな!KafkaとSparkを組み合わせたリアルタイム分析基盤の構築〜のメモ

Developers Summit 2016 - Hack the Realで参加してきた三コマ目のメモを公開。

本エントリ、コンテンツは以下。

以降よりメモ公開。

【18-B-4】乗り遅れるな!KafkaとSparkを組み合わせたリアルタイム分析基盤の構築 / 田中 裕一氏 [日本アイ・ビー・エム]

  • 基盤の構築にフォーカスを当てた話。
  • 講演のターゲット
    • Spark をはじめたい、ビッグデータをはじめたいエンジニアのとっかかり
  • 持ち帰りポイント
    • Spark+Kafka をつかった解析基盤の概要の把握、オリジナルの基盤構築を行うことができる
    • ビジネス担当の方にはこんなことができるんじゃないか?というビジネスの発想の種
  • Hadoop/Spark の広がりについて
    • Spark のひろがり
      • Spark はイノベータ、アーリアダプタを超えて広がりつつある
    • 業界に横串で展開される BigData
    • BigData とはどんなものか
      • 毎日発生し続けるデータ
        • ウェブサイトデータ
        • ログデータ
        • オペレーションデータ
        • オフィスデータ
        • センサーデータ
        • カスタマーデータ
        • ソーシャルデータ
        • メディアデータ
  • 従来の Hadoop 基盤のおさらいと問題提起
    • DataSource>HDFS>YARN>Hive,Mahout>Batch>Data>RDB>BI,API,Batch
    • 問題
      • Input のタイミングの問題
      • 処理時間の問題
        • どうやってレイテンシーを下げるのか
      • データ反映の問題
        • つくったデータをどうやって提供していくのか?
  • Spark/Kafka の概要のおさらい
    • Apache Spark
      • Component
        • SparkSQL, Datasets, DataFrames: SQL IF の提供
        • GraphX: グラフ操作を提供
        • Steraming: ストリーミング処理を提供
        • MLlib: 機械学習アルゴリズムを提供
        • on top of SparkCore.
      • 処理系
        • RDD & DAG, On-memory.
    • Apache Kafka: 分散 MQ
      • Component
        • Producer
        • Broker
          • Topics の単位で処理をキューイング
        • Consumer
  • リアルタイム解析基盤について
    • Kafka と Spark をつかったリアルタイム解析基盤
      • Data>Kafka>Spark>RDB>BI,Batch,API>Kafkaに返す
      • Kafka をデータハブとして使う
    • リアルタイム基盤ではキューが重要
      • キューによる処理系の分離ができる
        • データ
          • 多様なデータソース
          • 多彩なデータ
          • Sparkの障害から分離
        • Kafka
          • どんなデータでも一旦の終端になれる
        • Bigdata
          • Spark側はKafkaにのみ対応
          • データに合わせたロジック
          • 多様なデータソースの障害から分離 *キューをつかったストリーミングフロー制御
        • 処理を並べてフローを作成できる
      • キューを使った処理やアルゴリズムの検証
        • 同じデータから新たな処理を追加したい場合など
  • リアルタイム解析基盤の活用
    • ログをKafkaにキューイング、Sparkで集計処理、Kafkaに返す
    • 既存で HDFS/Hive をもっているときに SparkSQL が Hive の MetaStore を参照するようなインテグレーション例
    • MLlib を利用した異常値の検知システム
    • IoT の場合、大量書き込みが発生する、書き込み部分に HBase を使う事例
  • まとめ
    • Sparkは利活用事例がこれからなサービス
  • DataPalooza が日本でも開催される
    • サイエンティスト向けのイベント。
  • IBM の Hadoop Distribution
  • IBM は Spark に本気。

資料埋め込み

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

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

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

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

そして、 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 次世代アーキテクチャから見たHadoop/Sparkの位置づけのメモ

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/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

実際のところ Spark ソースコードリーディングだった #hadoopreading #16 はネ申回だった!

f:id:garage-kid:20140529233448p:plain

Hadoop ソースコードリーディング #16

  • 日 時: 2014年5月29日(木) 19:00~21:00 (受付開始 18:45)
  • 場 所: 豊洲センタービル (NTTデータ) ← いつもの隣のビル!
  • 地 図: http://www.nttdata.com/jp/ja/corporate/profile/guide/map.html (有楽町線豊洲駅3番出口を出て、左手奥の建物。エスカレータを上がった1Fに受付を設営します)
  • 定 員: 120名
  • Spark 、個人的にはまだ触ったことがないのだけれど、久々に Hadoop ソースコードリーディングが開催されるということで、参加してきました。
  • 今回は、 Hadoop ソースコードリーディングというより、 Spark ソースコードリーディングだったというのはおいておいて、、
    • 飲み食いなし!
    • 本当にソースを読んだ!!
    • スピーカーなお三方のプレゼンは堂々としてネ申!!!
      なまさにザッツ・ストイックなすばらしい勉強会でした。
  • では、一応ブログかくまでが勉強会ということで、とれた範囲でわたしがとってきたメモをいつもどおり公開しておこうと思います。
続きを読む