11/19(火) は「Spark Meetup Tokyo #2 (Spark+AI Summit EU 2019)」に参加してきました。
spark-meetup-tokyo.connpass.com
会場は NTT Software Innovation Center さん。
目次
Spark Meetup Tokyo とは
グループの概要から引用します。
分散並列処理フレームワーク Spark というのはこちらです。
近年注目されているOSSの超高速の統合分析エンジンです。
内容
開催概要から引用します。
Spark+AI Summit (SAIS) Europe 2019で発表があったSparkの最新開発状況，ユーザからのユースケース報告，関連OSSであるKoalas/MLflow/Delta Lakeなどに関する最新情報をお伝えします．
- Spark+AI Summit Europe - イベント内容: databricks.com
- Koalas - Spark用のPandas DataFrame APIs: pypi.org
- MLflow - 機械学習によるデータ分析のライフサイクル管理ツール: pypi.org
- Delta Lake - データレイクを実現するためのSpark用のストレージレイヤ: delta.io
イベントと会場に関する説明
Takeshi Yamamuro(Twitter:maropu)@NTT1 さん
SPARK+AI Summit Europe 2019 セッションハイライト
萩原 悠二/Yuji Hagiwara１ さん and 酒井 遼平/Ryohei Sakai@NTT Data さん
[資料は公開されたら追記します]
Spark+AI Summit EU 2019について
とはいえ
- 昼食会場は席が足りない
- 日本からの参加者は少ない
- ヨーロッパ周辺からの参加者が多い
キーノート
Auto Logging
ML Flow Model Registory
- モデル管理の課題
- 大人数でモデルを管理するとき
- どのモデルを使えばいいか
- どうやってモデルが作られたのか
どうやってレビューするか など
モデルに対して名前やコメント、タグを付けてバージョン管理できるレジストリ
- 各モデルのステージ(開発用、ステージング、本番用など)の状態遷移、その履歴も管理する
- デモでは実際の画面を見せてどんな事ができるかを確認できた
- モデルの読み込み時にモデルの名前とステージを指定して読み込みができるようになる
10/30 に ML Flowがリリースされた。ML Flow mkdel Registoryも含まれている
事例 * フランスのメガバンクの事例 * ビジネス * データサイエンティスト * データエンジニア
- 手動でコピー
- データの品質不明
- プログラミング言語
- 手動デプロイ
- などの課題
取り組んできたこと
- データローカリー(HDFSに保存して、是認がそこを見る)
- アプリケーションの信頼性
- 様々なPythonパッケージ
- モデル管理
- トラッキングサーバーの信頼性(冗長化)
- モデルサービング(モデルの使い方)
具体的には
- インターネットから得られるニュースの解析(コンプライアンス部門で使用)
キーノート
- Spark周りのエコシステムの状況
- Sparkエコシステムに関する最近の取り組み
Spark3.0の改善ポイント
- Adaptive Query Execution
- Spark SQLのパフォーマンス改善ポイント
- 実行中にデータを見てからクエリプランを変更
Dyanamic Partition pruning
- ディメンションテーブルに対するフィルタ条件をもとにして巨大なファクトテーブルをフィルタ
2019/11/6に Sparl 3.0のPreviewがリリースされている
Delta Lake
- ACID transaction on SparkScalable metadata handring
- Streaming and batch unification
- Schema enforcement
- etc...
これまでのアーキテクチャで辛いポイント
- データ分析をリアルタイムでしたい
- もう少し精緻な形で分析したい
- こういう条件が２つが並行で存在する場合に２つのアーキテクチャを作る必要がある
DeltaLakeを使うことで改善できる
- 2018年4月にOSS化
Koalasとは
- Pandasと同じコードでSparkで動かす
- モチベーション
- データサイエンティストは自身のラップトップ上でコーディング
- 実際の分析のときに書き換えることにあるのは辛い
- PandasからSparkへの書き換えが1%くらいで済むようになる
なぜクラウドでオートスケーリングが重要か？
Sparkクラスタにおけるノードの役割
- コンピュート
- 一時データの保管
UpscaleはかんたんだがDownscaleは難しい
- ノードの除外にあたって
- 実行中のコンテナが存在しない
- 一時データが存在しない
ことの確認が必要になる。
課題
- フラグメンテーション
- 一時データ
解決策
- フラグメンテーション
- リソースの使用状況に応じてノードを３種類に分類してジョブの割当優先度を設定
一時データ
- Suffuleファイルは各Executorのローカルストレージ上に存在
- Suffule Cleanup
- TTLベースでファイルを削除
- コンピュートストレージの分離
- nfsマウントした場所に置くことで回避
Koalasの開発状況 (Updates)
Takuya Ueshin(Twitter:ueshin)@Databricks さん
www.slideshare.net
Koalas
なぜ作ったか
- データサイエンティストはPandasを使って教育を受けることが多い
- Pandasは小さなデータのときは良いけど、実務では大きなデータが必要なので困る
Spark(UC Barklay→Databrics)
- Scalaで実装
Pandas DataframeとSpark DataFrameは意外に違う
- カラムの追加、リネーム、値のカウントなど。。。
- 学習コストが、、、
- Sparkで書くほうが少し冗長
- →Koalasを開発
Koalasの開発
- PandasのAPIを優先して開発
とはいえ違いはある
鍵となる違い
- Pandasはその場で計算、Sparkの場合はそうならない
- データの処理後の順番はSparkは分散システムなので保証されない
2週間に１回のリリース
- 日次のダウンロード10kを超える
キーノートのビデオが公開されている
現在の開発状況
- かなりアクティブに開発中
- PAndasAPIの60%、DataframeGroupBy/SeriesGroupBy 60%実装済み
- Plot関数80%
- parquetの読み込みなど
- MuktiIndexColumn 90%
700コミットを超えている
- 日次ダウンロードも15k以上に増加
- 1%のコードを変えただけで１０倍高速化した
今後の動き
pip/condaでインストール可能
Quick Overview of Upcoming Spark 3.0 + α（SAIS Europe 2019で個人的に興味のあった発表紹介）
Takeshi Yamamuro(Twitter:maropu)@NTT さん
www.slideshare.net
ML Flowの公式アカウントにイベント告知のリツイートをしてもらった
Join #ApacheSpark Meetup Tokyo No.2 - Spark+AI Summit EU 2019 Edition on #DeltaLake #MLflow #Koalas with @tokyodataguy @ueshin @maropu @kiszk and more https://t.co/3MiBgePCEi cc @databricks
— MLflow (@MLflow) November 14, 2019
Spark3.0の時期リリース 20120のQ１と言われている
- 互換性が壊れる変更が多く入っている
- previewは事前の確認用の先行的な公開という位置づけ
- 正式リリースではないので、パッケージでの配信などはない
開発中なので、メジャーアップデートの全機能はわからない。
これまでのクエリ実行
- Sparkのクエリは入力データの統計を用いて「実行前」に決定
- 実行計画は途中では変わらない(不変)
物理プランを複数のクエリステージに分割して各ステージの実際の出力プランの出力データの統計情報を用いて次のステージの実行計画を決める
Dyanmic Partition pruning
- 隣接するFilter処理の述語(Where)を動的なパーティショニングに活かす
- 属性テーブルの結果を天パンすることで最大100倍高速化
Sparkの実行計画が読みにくい
- 見やすく修正された
DataFrame Cogrouping
- Pandas UDFでグループ化してMAP処理が可能に
Join Hints
- 3.0からはすべてのJoinに対するHintが可能に
PostgreSQL Sialect Support
- PostgreSQLとの挙動のち外野未サポート機能を把握するためにリグレッションテストの一部を移植
- 共通性の高い課題に関してはSparkの動作に反映。PostgreSQLの独自の振る舞いについてはオプション設定をすることで反映
- ただし、開発中なのでどこまで取り込まれるかは未定
Spark@Facebook
- FacebookはSparkのヘビーユーザーで知見を共有している
- 推論とIndexingに使っている
- Sparkと外部プロセスの間のI/O処理の効率化
- 開発環境ではデバッグ効率重視のテキスト形式、プロダクションでバイナリに変更
- Apache Arrow
Scriptb Transformation
- テーブルに対してシェルなどのコマンドをApply出来る。
Delta アーキテクチャ
Paulo Gutierrez(Twitter:tokyodataguy)@Databricks さん
www.slideshare.net
Delta Lamdaアーキテクチャ(Apache Storm)よりは先、Kafca(Kappaアーキテクチャ)の次なのでDelta
kafka Kinesis Spark Table Spark AI、Reporting DataLake
リアルタイム分析 Spark Streaming
AI/AI、Reporting Spark batch
- アーキテクチャが複雑になる
- コードの管理が大変
何が問題か？
- コンスタントな読み込み ライターとリーダーの分離が必要
- 最適化されたファイルのサイズとソースが必要
- バージョンによるロールバック(タイムトラベル)
- 履歴データのリプレイ
- 後で来たデータもストリーミングでUpseartできる
バッチとストリーミングを統合して継続的にデータを処理する
- バッチとストリーミングの統合
- インクリメンタルなロード
Intermidiate Hops
- 出来るとことから処理を開始する
ストレージレイアウトの最適化
- パーティショニング カーディナリティの低いデータはこっちで
- Z-Ordering
- parquetを採用しているので出来る
再処理時
- Infinite retention
データクオリティ
- ブロンズ 生データ
- シルバー ある程度クレンジング
- ゴールド アグリゲーション。タグ/ラベル付
Project Hydrogenの最新情報
Kazuaki Ishizaki(Twitter:kiszk)@IBM Research - Tokyo さん
www.slideshare.net
AparkとAIフレームワークを統合するHydrogenプロジェクトについて
- ユースケース
- 分散学習、推論
- 実施の使われ方
ある意味、3度めの正直
- TensorFlow on Spark（Yahoo）
- SqqpLearning Pipekines(Databrics)
Spark上で分散AIフレームワークを実現する
- 分散学習
分散学習では並列処理の形態がこれまでと異なる * MapReduce * 部分再実行 * 分散学習 * 全タスクを再実行
Barrier Execution Mode
- すべてのタスクを同時に実行する
- 故障が起きたら部分だけキャンセル
故障が発生した場合の再実行も自動的に行われる
- 故障のためのコードを書かなくても良いSparkの良さはそのまま
Barrier Execution Mode 利用例
- Databrice 5.0上でのHorovoidとの統合
- Horovoid
- 分散トレーニングを可能にするフィレー無ワークに依存しないランタイム
Accelarator-aware Scheduling
GPUの自動検出、Executor/Taskに割り当てるGPUの数
- Taskが実行されているGPUを取り出してTensorFlowにk情報を与える
Spark3.0 previewでのサポート状況
- ストリームデータの推論
推論ではAIフレームワークとの高速データ交換が重要
- 性能に大きく影響する
Pandas UDFを使うと遅かったPySparkがSpark 2.3からは3倍から100倍高速化
- 実装はApache Arrowを使っている
- 推論でよく見る「ラベルとスコアのペア」を高速にSpark側に渡すことが出来る
- Pandas UDF自体の高速化
Pandas UDFの1バッチを実行している間に次に使われるバッチを前乗ってApark側からPython側に転送しておく
- PandasUDF内で一度呼んだモレルを再実行する
Spark極めて性能向上の話
Chris Kong(Twitter:val_mukong)@Rakuten さん
[資料は公開されたら追記します]
Rakuten AnalyticsTracker Platform
- 12万QPS
- 3.8B レコード
- 1.9PBデータ
データ収集
Front JS Tracker Logstash Spark Streaming/Kafka SDK DMP
Spark Streaming の最適化
- Kafkaからの読み込み/書き出し
何が問題か？
- セールなどのときに処理が重くなる。
- アップストリームにあるので、ここの遅延はまずい
- Shfflingの時間がかかりすぎるのが問題
- →Executerを増やす
- 改善した
しかし、まだ問題が
- マイクロバッチの処理
- スケジューリングの遅延
- →最適なmaxRatePerPartiotionを見つける
- 遅延を早く改善することを目的としている
どうやって最適値を見つければいいか？
- 秒間処理速度を概算して大体のmaxRatePerPatitionを逆算
レポートエンジンの改善
- ユースケース
- OLAPで処理できないクエリがある
MapReduce on Yarn
- 処理時間がかかりすぎ、Preemptされる
- →Spark SQL を使うことにして劇的改善
しかし、バグが有って複雑なクエリを処理できないことが分かった
- →Spark SQLをやめてDataSetを使う
チューニング
チューニング
- Dynamic Resorce Allocation
結果
- 処理時間が半分くらいになった
- ただし会社からグラフの詳細度が。。。笑
これからやりたいこと
- ストリーミング
- バッチ
- それぞれでやりたいポイントあり
LT1: Koalasのココが良いよね
Harutaka Kawamura(Twitter:harupy)@ARISE さん
Koalasとは
- 4月にDatabricsが公開
Koalasの特徴
- PandasのAPIを真似る
Pandasを真似ることで得られる利点
- PySparkの作法を学習「しなくて良い
- 切り替えコストがk低い
- PandasにあるがPySparkにはない機能＆関数
Koalasを使えばPySparkよりかんたんにデータを処理できる
LT2: Higher-Order Functions をちょっと深掘りしてみた
Kamuela Lau(Twitter: kamu_lau)@Rondhuit さん
[資料は公開されたら追記します]
高階関数とは
- 引数として関数を受け取る
- 戻りとして関数を返す
高階関数の例
- Transform
- filetr
- aggrigate
- exists
- sip_with
Map
- UDF
- 高階関数
懇親会
体調を考えて、懇親会は最初だけ参加して帰りました。
Apache Arrow
Apache Arrowというメモリ内データ用の言語間開発プラットフォームも、このプロジェクトから派生したOSSの一つです。 こちらも関連技術として、興味深いとおもいます。近々イベントも予定されていますのでリンクを貼っておきます。
まとめ
正直なところ、あまりSparkについて追いきれていなかったので、情報量の多さに着いていくのがやっとでした。 でも、メモを取りながら「こんなことまでできるようになってきているのか」とか得るものが多くて、参加できてよかったなと思います。 次回までにはもう少し勉強して、理解した形で参加したいなと思いました。
講演者、スタッフ、参加者の皆さん、ありがとうございました！
