Spark Casual Talk #1

Spark Casual Talk #1 - connpass

  • 敷居を下げるためにカジュアルとつけたけど、LTのラインナップを見るにかなりガチですね
  • Sparkなんで既定路線ということで

Spark Summit 2015 参加報告

  • @potix2
    • 神田さん
    • CAアドテク本部 AMoAd
    • OS/分散システム専門でやってます
    • 毎月Lispのミートアップもやってます
  • Sparkと私
    • 広告のデータ分析基盤としてのSpark
    • 業務とは離れるけど、社内の研究支援制度でSparkゼミをやっている
      • 業務でやってるならSparkにコントリビュートしよう、という感じで
      • ソースリーディングやIssuesやPR上げたりをもくもくとやっている
  • Sparkとは
    • Sparkユーザは会場に半分くらい
    • 高速な汎用計算エンジン
    • メモリにキャッシュするので繰り返し計算に強い
    • ロジスティック回帰は100倍早いです、というよくある謳い文句
      • うそ臭いなあといつも思うのですが出しておく
    • コンポーネント
      • Spark core
        • Spark SQL
        • MLlib
        • GraphX
          • 最近あんまり活発でない、ですが、Spark Summitでは事例が出てました
        • Spark Streaming
          • リアルタイム処理ライブラリ
    • Sparkを取り巻くエコシステム
      • YARN、Mesos
        • YARNの方がメジャー、Mesosは実装が足りなかったりする
        • 最近Dockerでも動くようにサポートされました(1.4~)
    • コミュニティも成長を続けている
      • 1年でコントリビューターが255人から730に
      • コード量も175kから400kに
        • 大丈夫かな、と思いつつ、コアはあんまり膨れてないらしい
    • 「IBMがApache Sparkプロジェクトに3500名を投入」
    • 最近のリリース
      • 6月に1.4、3月に1.3
        • 1.3のDataFrame APIがとても大きい、のでここで触れておきます
    • DataFrame API

Spark Summit 2015 振り返り

  • 先週6/15~17
    • 1日目、2日目がKeynote,各コミュニティのセッションx28x2日
  • データ分析に関わる内容が多かった
    • データ分析基盤としての活用事例が多い
    • 「Baiduでは8000ノード使っています」みたいな
    • MLlib活用して予測モデルを建てたり、といった事例がたくさん
      • 先進的な事例が多いので、性能改善がコミュニティ内部での優先度高に
  • 出自が出自(大学の研究室)なので、産学連携しながらコミュニティが成長している
    • アカデミックな雰囲気も有るカンファレンスでした

SparkSQL/DataFrameAPI関連

  • DataFrame APIチュートリアル
    • Spark DataFrames: Simple and Fast Analysis of ....
    • おそらく今週くらいにSpark Summit公式にスライドが上がってきます、もうちょっとして動画も

パフォーマンス向上関連

  • 今回喋りたいトコ
  • Making Sense of Spark Performance
    • UCBの方
    • Sparkのパフォーマンス改善の方向性を示している
    • NSDI'2015採択のペーパー
      • 以下の条件が揃った結果、CPUがボトルネックになっている
        • HW性能向上(10GNW, 広帯域SSD)
        • 十分に最適化されたIO
        • Dataformatの最適化(Parquetなどのbinary format)
  • How to Boost 100x Performance for Real World Application w/ Apache Spark
    • Intel上海チームのSpark性能改善タスクの共有
  • プロジェクトTungsten
    • From DataFrames to Tungsten: A Peek into Spark's Future
    • 今後五年間のために準備しているプロジェクト
      • CPUのために実行速度をあげよう
        • 実行時コード生成
        • 局所性を活かしたキャッシュ
        • オフヒープメモリ
          • JVMを見限ってUnsafeに自前でメモリ管理していきます、というもの
    • Tungstenが描く未来
      • 言語フロントエンドにはSQL, Scala, Python, R, ...
        • これらはDataFrame Logical Planに落とし込まれ、
          • (Catalystというロジカルプランを組み立てるプロジェクトも走っている)
      • Tungstenで実行時のコード最適化ののち、backend(JVM, LLVM, GPU,...)で実行されていく
    • フロント→DataFrame→Tungsten Execution、という流れ

まとめ

  • DataFrame API, Spark SQLなどデータ分析の基盤となる機能は継続して開発
  • データ分析基盤として活用するユーザー企業が増えている

  • 性能改善へのニーズが増してきている

  • Q&A

    • 英語はペラペラなんですか？
      • 全然ダメで、MeetUpでも質問してみたけどボロボロでした
    • DataFrameAPIはテーブル型なのでMLやGraphXとは関連しない？TungstenはDataFrameAPIに特化したプロジェクト？
      • Tungsten使ってもMLlibは早くならない？
      • (NTTデータ 土橋さん)MLはRDDバックエンドだが、別プロジェクトのSpark MLは入力としてDataFrameAPIを使うように進んでいる
        • 今後の流れとしてはMLもDataFrameに合わせていきそう
    • CAではSparkはどう使っていく？
      • ウチ(AMoAd)では分析基盤、別の場所ではストリーミング
      • 規模感としては共通基盤はないので、チームごと・PJ単位でアドホック的に気軽に使う程度、今後変わるかも
    • CPUボトルネックで困ってる、みたいなケースはある？
      • CAではまだない
      • モダンなハードウェアでDataFrameをガチガチに使い込んで初めてCPUボトルネックが見えてくる、という領域だと思います
        • SSD24個とか、10GNWとか

メキメキ開発の進むApache Sparkのいまとこれから

  • NTTデータ土橋さん、猿田さん
    • 猿田さん
      • 6月Sparkコミッタに就任
      • コアエンジニアに近い立場、dev寄り
    • 土橋さん
      • 去年Spark Summit '14で事例紹介しました
      • OSSを使い倒すチーム、ユーザー寄り

Spark開発の最前線(猿田)

  • '14とくらべても非常にドラスティックに変わっている
  • ざっくりおさらい、Apache Spark
    • 1.3.0までのホットトピックをおさらい、1.4.0のホットトピックをキャッチアップ
    • 従来のMapReduceが苦手なスループットとレイテンシの両立が領域にアプローチするためのプロダクト、そのうち最も早く商用に載ったもの
      • UC BarkleyのMateiさん(Databrick CTO)がScalaで開発
      • RDD、部分故障への耐性のある分散コレクションに仕事をする
    • Sparkの全体像
      • 分散システムなのでYARNやMesosのスケジューラが要るけど、小規模なら自前のStandaloneマネージャでも動きはする
      • HDFSに対しても使える
    • 1.3までのホットトピック
      • Kafka連携(Spark Streaming)
        • SimpleConsumerAPIでZookeeper不要で、SparkStreaming側でオフセット管理を行う
          • オフセットをWALに書きだす必要がなくなった
          • Exactly Onceの保証が楽に
      • Pipeline API(MLlib)
        • 学習アルゴや最適化アルゴのみならず、Scikit-Learnのような機械学習全体のパイプラインをサポートするAPIが提供されている
        • 1.2で入ってまだalphaだけど、活発にコントリビュートされてる印象
      • DataFrame API(Spark SQL)
        • 1.2まではSchemaRDDと呼ばれていたテーブル構造、が名前変更
        • SQL,HiveQLで発行できるのみならず、ScalaやPythonでアクセスするAPIも提供
        • Core API経由にくらべてカラムに名前でアクセスできるようになり、書きやすくなった
        • DataFrameAPIを使うと、言語の差がほとんど出なくなる
      • 1.4のアップデート
        • SparkR
          • Rで分散処理が記述できる
          • 手慣れたRでSparkコアの動作を意識せずDataFrameの操作を記述するだけで分散処理が実行できる
        • WebUIの可視化が強化
          • Spark Streaming統計情報の強化
            • 単位時間あたりのデータ流量、スループットが確認できるように
            • キャパプラや異常検知に使える
          • RDDの変換過程の可視化(WebUI)
            • 複雑な変換チェインや、エコシステムによって生成された全体像が把握しやすくなった
            • チューニングに役立つ
          • タイムラインの可視化
            • 分散システムのトラブルシュートをやると、処理全体を俯瞰したいときがままある
            • いつ、どんなジョブが、どのくらい、exeuctorがどう動いて...が見える
            • クラスタ内のタスクの時間・リソース・executorとの分布が見える
        • Project Tungsten
          • メモリ独自管理、GC削減
          • CPUキャッシュの局所性をを活かしたコード生成
            • CPUキャッシュは番地だけでなく隣接するデータも拾う、ここを活用したコードへ
          • モダンなCPUの活用
            • LLVMみたいなJITを叩いてSSEやSIMDに乗っかるコードにしたり
            • 高負荷処理をGPUにオフロードさせたり
          • JavaのHashMapを自前のデータコードにして効果が出た、という事例がありました

始めようSpark(土橋)

  • 今から使うならどう使う？
    • スキーマレスデータはRDD、構造化データはDataFrame
      • 今は連携できるので、うまい方を使いながら組み合わせられる
    • 去年までは統計処理が多めだが、今年はストリーム処理・機械学習との連携が多かった
      • MLlibは「分散処理の恩恵を受けられるアルゴリズムを実装する」という方針だが、定番アルゴはまずまずの充実度
        • 細かいところが足りない、と思ったら積極的にコミュニティに意見しましょう
    • DataFrameほか、いろんなデータソースを意識するように
      • センサデータみたいなものも取り込めるように
      • 構造が異なるデータも柔軟に扱える
      • 大規模データでの動作もだいぶ安定していた
        • ちょっと前はメモリに全部ぶち込んでたので不安があった
  • 気に留めておきたいこと
    • 動かすだけなら簡単、まじめに追い込むならパラメータチューニング必須
      • 機械学習をやってる人にしてみればどノーマルでは仕方ない、というのはハラオチするはず
      • 公式のチューニングガイドをあたろう
    • やはりScala実装が最も進んでいるが、最近はPythonも頑張っている、SQLもそれなりに使える
      • SparkSQLはDataFrame側に寄りつつ有る
      • 個人的にはSQLで書きたい業務処理と、コレクション操作で書きたい処理は別なので、両方対応できるのは嬉しい
  • Sparkを動かしてみよう
    • 半分がユーザー、という脅威の数値が出ましたが...
    • prebuilt版が公式にパッケージされてるので、展開すれば動きます
      • Windows対応をめっちゃ頑張ってるのがコミュニティに２人いるけど、２人しかいないのでLinuxでサクッと動かしたほうが良い
    • /bin/spark-shell --master localでscalaのreplが出ます
  • Zeppelinと一緒にSparkの簡単な動作を紹介
    • Apache Zeppelin
      • Mathematicaみたいなノートブック
      • のんびり開発中、コントリビューター募集中
  • DataFrame入門
    • 定期預金契約に関するサンプルデータを読んで、Sparkで処理
    • デモ: spark-csvを利用して、DataFrameAPIで特定カラム抜き出し、Zeppelinでグラフ化
    • spark-shellでもzeppelinでもMavenパッケージをそのまま使えます
      • %dep z.load("...")
      • spark-shell --packages
    • sqlContextでcsvをSQLっぽく読む(DataFrame型)
      • .selectで抽出したDataFrame型に
    • %sqlでSparkSQL文で解釈して、Zeppelin組み込みのグラフ表示までやってくれる
    • バックエンドでデバッグするだけでなく、SparkのWebUIから参照できるので

  • RDDとMLlibの事例は興味があれば

    • スマホのジャイロで座ってるのか、立ってるのかを当てるデモ

  • まとめ

    • 後方互換性をかなり保ちながらも、1.2以降ドラスティックに変わってきています
    • 動かすこと自体は難しくないので、ちょっと気になったら公式quickstartが詳しめ
    • 本気で使う方は開発現場を盛り上げていきましょう

  • Q&A

    • iPython系もSpark使えた気がするのですが、シェア的にはどっちが多い？(→土橋)
      • 実はiPython自分も使ってます、カーネルの実装が２、３個あり、メジャーなのはIBM実装
      • Sparkに限るとどちらが、とはいいにくいが、母数は圧倒的にiPython
      • Zeppelinはコードベースが枯れてない
      • iPythonは言語をまたぐようなものはない、Jupiterがそれっぽいことをやってたかもしれないけど
    • keyの偏りみたいなものをなんとかするコツはありますか？(→猿田)
      • 銀の弾丸はなく、ケースバイケースという感じ
      • 常套手段としてはジョブを細切れにする
        • １つのジョブを複数に分割して、あとで纏めるようなパターンもありました
        • Sparkに限らないネタだと思う
          • Stormを使っていた時も、特定キーへの偏りはあった
            • RDBと同じだが分散キーのカーディナリティを複合キーにするなどしてなんとか担保する
            • Sparkも分散キー次第、計測→実装に落とす、というサイクルは抜けないと思う
    • Sparkは分析をメインにしていく、というイメージ？前処理の部分もこれまで通りやっていく？(→土橋)
      • 「前処理にもパワーや試行錯誤が必要です」というケースがたくさん出てきている
      • どの説明変数が効果的か、というような、前処理とアルゴリズムの選択を一緒くたにできるのがSparkの嬉しいところ

LT

SparkSQLの構文解析

  • @iyunoriue
    • CA
  • sqlContext.sql("SELECT * FROM records")
    • sqlメソッドの詳細へ
    • LogicalPlanを返すparseSqlメソッド
      • 文字列を受け取ってゴニョゴニョ
    • ddlParser.parse(sqlParser.parse(SparkSQLParser(getSQLDialect())))
      • Dialect ←方言、ここでは「SQL方言」の意
      • sqlかhiveqlか
    • ddlParser.parseが成功すればそのままLogicalPlan
      • 失敗すればSparkSQLParser.parse
      • さらに滑るとgetSQLDialect
    • AbstractSparkSQLParser.parseのオーバーライド
    • Project Tungstenでの構文解析
      • パーサ・コンビネータからRuntime Code Generationに変更
        • quasiquotesでruntimeにコードを生成
        • パーサ・コンビネータはO(n^k)、遅い
      • 実装も4行に収まりました

Run Streaming + Amazon Kinesis

  • @imai_factory
    • Amazon
    • 前職では広告配信サーバに携わったりしてました
  • SparkStreamingのいいところ
    • KafkaやKinesisのようなデータストリームにFRPっぽく書いていける、身近に書かせてくれるのが良い
  • DStream
    • 処理の単位、くらいのもの
    • いろんなデータソース(socket, file, Flume, Kafka, Kinesis, Twitter, (pluggable dstream))->DStreamへ
  • Amazon Kinesis
    • フルマネージドなストリームサービス/メッセージブローカー
    • 怒られちゃうけど平たく言うとフルマネージドKafkaみたいなやつです
  • Kinesisのストリームにウィンドウ関数/SparkSQLする
  • Kinesisバックエンドの実装
    • API, SDKでスクラッチ
    • KCL
    • AWS Lambda
    • Storm, Spark
  • td経由のjson→Kinesis→Spark
    • KinesisUtils.createStreamのDstreamをunion、foreachRDDしてgroupBy
  • EMR上でもSparkが一撃化しました
    • 最新ではなく1.3.1なので注意

ML Pipelineで実践機械学習

  • 谷口さん
    • CA アドテクスタジオ
    • 「いつになったらカジュアルトークになるんだろう...」
    • 広告配信部門のデータサイエンティスト
    • OSS(Spark)、QConTokyo...
  • 機械学習の流れ
    • Training Data
      • with (label, ...)
    • Feature Engineering
      • 特徴抽出
    • Machine Learning
      • 学習
    • Prediction
      • 予測
  • ML Pipeline
    • 記述的に機械学習の流れを書いていくことが出来る
    • Cross Validation, Grid Searchに対応
      • Grid Search: 最適なパラメータの探索
      • Cross Validation: モデルの評価
      • これらをパイプライン内で一括でできる
  • DataFrame -> Pipeline -> Pipeline -> Modelの流れ
  • Logistics回帰の例
    • (id, label, text) -> トークナイズ -> (id, label, text, words) -> Vector抽出 -> (id, label, text, words, features)
    • Transformer
      • Pipelineの一つの要素(Stage)
      • URLからドメインを抜くTransformer
        • ある列から持ってきて、有る列に差し込む
    • VectorUDT
      • pipelineは最後にVectorUDTで渡す
      • Transformer自作しようとしたらprivateなので自前で実装してみたら、後で呼ばれていた
        • 実装が安定してない!!!
  • アルゴリズムを変える、みたいなところでも一箇所変えるだけでよい

アドホック分析で活躍するApache Spark

  • @moyomot_
  • 一言で言うと
    • サクッとSparkを試すにはEMRがオススメ
  • Gunosyのデータ分析の主軸はRedShift
    • RedShiftに無いデータを分析するところでSparkが出てくる
    • 日々追加する中で、Redshiftにないデータを一時的に集計するとき、など
  • Sparkのここが嬉しい
    • S3との親和性が高い
    • JSON取り出しが容易
    • SparkSQL、DataFrameが使える

  • 分散基盤の運用は大変

    • そこでEMRです
    • 先週正式サポートされました

  • ホントにカジュアルなネタを用意してきたのですが、違ったのかなあという気がしています

HUE NOTEBOOK

  • @kernel023
    • Cloudera
    • Tatsuo Kawasaki
      • インストラクター
      • 今日はYARNを２時間くらい喋ってました
  • 今日言いたかったこと
    • 『ラーニングSpark』日本語版が8月か9月に出ます
      • 翻訳は象本でおなじみの玉川さん
  • Jupiter、Zeppelinみたいなものがもう一つあるのでこれを...
  • Hue
    • ふえじゃないです
    • Hadoop User Experience
  • Hue以前はパワーユーザーがコマンドラインで分析してました
    • Hueからならブラウザ経由でカジュアルに叩けます
  • Zeppelinとおなじくノートブックで使えるようになりました
    • まだBETAです、次で安定するかも
    • Scala, Python, Impala, Hiveなどに対応しています
  • iPython, Zeppelin, Jupiterなどが有名ですが
    • HueはEMRバンドルなので、じきにデフォルトで使えるようになるかも

Dynamic Resource Allocation on YARN

  • YARN
    • リソースマネージャの実装
  • Sparkの話だったんですが、YARNを使うとMapReduce使ってるリソースをそのまま使えるようになります
  • YARN overview
    • すべてのリソースを知っているResourceManager
    • いくつかのNodeManagerに仕事を振っていく
  • Spark on YARN
    • yarn-cluster mode
      • SparkのマスターをNodeManagerの上に建てる
      • spark driverがNodeManagerの上で動く
        • ジョブをもらってから、コンテナをいくつ建てるかなどをNodeManagerが判断
    • yarn-client mode
      • spark driverがクライアント側で立つ
      • spark-shellをクライアントで動かすため
      • shellがResourceManagerとやりとりする
  • 問題
    • yarn-clusterではexecuterの数を起動時に指定している
      • RDDが消えちゃうのでexecuterはジョブが終わるまで終了できない
      • stage1で100%まで張り付くと、stage2が暇になっても開放できない
    • Dynamic resource Allocation
      • RDDの耐故障性がおざなりに
      • external shuffle
        • RDDをNodeManagerに移譲
        • executerが死んでもNodeManagerが覚えてるのでアクセスできるように
    • インストールしようとすると面倒
      • 4ステップ
      • 1.2のドキュメントにはtypoがあるので1.4を読みましょう
        • network.yarnをyarn.networkにtypoしてる
  • Sparkの上でYARNが動くので皆さん使いましょう!!