Spark 3.0が目指す、よりインテリジェントなUnified Analytics Platform（db tech showcase 2019 Tokyo講演資料、2019/09/25）

© 2019 NTT DATA Corporation
2019年9月25日
株式会社NTTデータ技術開発本部
猿田浩輔
Spark 3.0が目指す、よりインテリジェントなUnified Analytics Platform

© 2019 NTT DATA Corporation 2
$ whoami
 猿田浩輔
 株式会社NTTデータ技術開発本部
 シニア・ソフトウェアエンジニア / Apache Sparkコミッタ
 Hadoop/SparkなどOSS並列分散処理系の開発やテクニカルサポートに従事
 普及活動の一環で講演や書籍執筆なども
 Twitter: @raspberry1123

本日のお話
 Apache SparkはこれまでUnified Analytics Platformとして様々なユースケース
をカバーしてきた
 バッチ
 ストリーム
 機械学習
 グラフ処理
 クエリ処理
 昨今はAIをはじめ、"よりインテリジェントな分析"を実現する機能の導入が検
討されている
 Project Hydrogen
• Spark上で分散Deep Learningを可能にするための下地作り
 Spark Graph
• Sparkの新しいグラフ処理ライブラリ

Project Hydrogen

ビッグデータとディープラーニング
 昨今AI(特にDeep Learning)が身近なものになり、領域を問わず活用されるよ
うになってきた
 Deep Learningは旧来のアルゴリズムと比較して大量のデータの活用によって
精度の向上が期待できる
 大量のデータで学習するために、複数の計算機を用いた分散ディープラーニ
ングが活用されるケースも出てきた
 Distributed TensorFlowやHorovodなど、
分散ディープラーニングを実現可能にする
フレームワークも登場
 Sparkも分散ディープラーニングパイプラインを
構成する一部として用いられてきた
http://cs229.stanford.edu/materials/CS229-DeepLearning.pdf

分散DLのワークロードの中で、Sparkはこれまでどう使われてきたか
① 前処理や、学習/推論部分とデータソースとのインターフェイス
 DLでは学習/推論部分だけでなく、学習データセットや推論対象のデータとの
インターフェイスや前処理も重要
 特に分散DLでは学習/推論以外の部分も分散処理が必要になる。ここで分散ETL
の実績があるSparkが活用されるケースがある
 RDBMSや分散KVS、クラウドストレージ、様々なデータフォーマットに対応
している点(インターフェイスの豊富さ)もSparkが選択される際のポイント
前処理済みデータセット
分散ストレージなど
分散学習
分散
ETL

分散DLのワークロードの中で、Sparkはこれまでどう使われてきたか
② 推論部分の分散実行
 学習自体はTensorFlowなどに任せて、作成したモデルを用いて推論部分を分散
実行するケースもある
モデルの
生成前処理 + 分散推論
学習済みモデル

 SparkクラスタとDLクラスタ間での連携にはユーザ側で作りこみが必要
 同じマシン上でSparkとDLフレームワークを動かしていても課題は一緒
 異なる種類のクラスタを運用することによる、オペレーションの煩雑化も
SparkとDLクラスタの連携には工夫が必要
Sparkクラスタ
• 外部からのデータロード
• データの前処理
• 分散推論
DLクラスタ
• 分散学習
• モデルの作成
前処理済みデータセット
学習済みモデル
ユーザによる作りこみが必要な連携部分

SparkクラスタとDLクラスタが統合できるとよい
 分散学習/推論が、Spark上のアプリケーションとして実行できるとよい
 Sparkの仕組みに閉じてデータのロードや前処理、学習/推論が完結
 ユーザ側でSparkとDLクラスタ側の連携方法の作りこみが不要
 TensorFlow On SparkやIntel BigDLなど、この課題に着目したフレームワーク
も登場した
 ただし、Spark側でDLのワークロードに求められる機能が不足しているため、
フレームワーク開発者は苦戦を強いられている
 どんな機能が不足しているのかはこのセッションのポイントのひとつ。
概ね以下の通り
• タスク間の同期が可能なスケジューリング機能
• GPUなどのアクセラレータをタスクに割り当てる機能
• 既存のDLフレームワークやそれに付随する外部プロセスとの効率的なデー
タ交換を支援する機能

Project Hydrogen
 Spark上で分散DLを実現するための一連のサブプロジェクト
 主にDLフレームワーク開発者向けの支援機能などの導入がメイン
 あくまで支援機能の導入がメイン。DLにおける学習/推論アルゴリズム
そのものの導入はスコープ外
 大きく3つの取り組みから成り立っている
Barrier Execution
Mode
Optimized Data
Exchange
Accelerator
Aware
Scheduling

Project Hydrogen
① Barrier Execution Mode

従来のSparkの実装では分散学習が難しい
 推論部分は各Executorがモデルをロードしておき、受信したデータに対して
各Executorが推論を行えばよいので、Sparkの既存の機能で実現できる
 分散学習については、AllReduceなどで勾配パラメータを交換時際にタスク間
で同期が必要になるが・・・
 Sparkのスケジューリング機構がタスク間での同期を想定した実装に
なっていないため難しい
Executor Executor Executor
推論対象
データ
学習済みモデルのロード
丸三角星

おさらい: Sparkの処理単位とタスクスケジューリングの基本
 Sparkでは、ユーザが記述した処理から「ステージ」や「タスク」と呼ばれる
処理単位が生成される
 複数のExecutorが異なるタスクを処理することでクラスタ全体で分散処理が
行われる
ステージ1 シャッフルステージ3 シャッフルステージ4
タスク
タスク
タスク
タスク
タスク
タスク
タスク
タスク
タスク
ステージ2
タスク
タスク

おさらい: Sparkの処理単位とタスクスケジューリングの基本
 Executorへのタスクの割り当ては、Sparkのスケジューラが決定する
 依存のあるステージでは、先行するステージのタスクがすべて完了すると後
続のステージのスケジューリングが始まる(図中ステージ1、3、4)
 依存のないステージ同士は同時にスケジューリングされる(図中のステージ1
とステージ2)
ステージ1 シャッフルステージ3 シャッフルステージ4
タスク
タスク
タスク
タスク
タスク
タスク
タスク
タスク
タスク
ステージ2
タスク
タスク

おさらい: 従来からのタスクスケジューリング
スロットは同時にスケジューリングさ
れた複数のステージのタスクで共用さ
れる。
そのため、あるステージのタスクを全
て同時にスケジューリングできるとは
限らない。
Executor
スロット
(タスクを割り
当てる空間)
スケジューリング待ちのタスク
(色の違いは異なるステージを表現)
ドライバ
Executor
スロットが空き次第次々と
タスクをスケジューリング

おさらい: 従来からのタスクスケジューリング
Executor
スロット
(タスクを割り
当てる空間)
スケジューリング待ちのタスク
(色の違いは異なるステージを表現)
ドライバ
Executor
スロットが空き次第次々と
タスクをスケジューリング
スループットの面で有利だが、ステー
ジ内のすべてのタスクが同時にスケ
ジューリングされるとは限らないので、
分散DLのワークロードで求められるよ
うなタスク間の同期が難しい
スロットは同時にスケジューリングさ
れた複数のステージのタスクで共用さ
れる。
そのため、あるステージのタスクを全
て同時にスケジューリングできるとは
限らない。

おさらい: 従来からのタスクのリトライの仕組み
 あるタスクが失敗した場合、当該タスクのみリトライされる
 ステージ内の他のタスクは影響を受けずに処理を継続できる
 一方で協調動作が必要なタスク群はまとめてリトライしてほしい場合もある
タスク ×
完了
完了
リトライが必要なのは
失敗したタスクだけ
タスク
タスク

Barrier Execution Mode
 Spark 2.4から導入されたBarrier Execution Modeでは、従来のスケジューリ
ング方式に加えてギャングスケジューリングが可能になった
 Barrier Mode Executionの対象のステージに含まれるタスクは、一度にまとめ
てスケジューリングされる
 十分なスロットがなければ待つ
 対象のステージ内の全てのタスクが成功するか、あるいは全て失敗するかの
いずれか(All or Nothing)
 リトライのスケジューリングもまとめて行う
 タスク間の同期を支援する仕組みも導入された
 同期のためのAPIや同期が必要な他のタスクの把握するAPIが導入された

Barrier Execution Modeの利用例
 RDD#barrierメソッドで、Barrier Execution Modeでのスケジューリング対象
を設定できる
 BarrierTaskContext#barrierメソッドで、タスク間の同期点を設定できる
 具体的な通信処理ロジックなどはDLフレームワーク側やDLアプリケーション
開発者が実装する必要がある
 Barrier Execution Modeは協調を可能にする仕掛けを提供するだけ
rdd.barrier().mapPartitions() { iter =>
val context = BarrierTaskContext.get() // バリアタスクコンテキストを取得
<何か処理>
context.barrier() // タスク間の待ち合わせ。全てのタスクがここに到達したら先に進む。
<何か処理(勾配パラメータの交換など)>

Barrier Execution Modeの開発状況
 基本的な機能は概ねSpark 2.4で完成している
 DLのユースケースで用いられることの多いPythonでももちろん利用可能
 Dynamic Resource Allocationとの併用は現段階では不可
 3.0でも少しだけアップデートあり
 WebUI
 ギャングスケジューリングが不可能な場合の
ログメッセージの改善
 設定項目のドキュメントが追加された
Barrier Mode Executionの対象となる
オペレーションは緑色で表示される

Project Hydrogen
② Accelerator Aware Scheduling

DLのワークロードではGPUなどのアクセラレータの活用が当たり前に
 DLのワークロードではGPUを活用することが当たり前になってきている
 多くのDLフレームワークがGPUをサポートしている
 DLフレームワークをSpark向けに開発する場合、Spark内部からGPUなどのア
クセラレータを扱える必要がある
 これまではGPUなどのアクセラレータを想定した作りになっていなかった

これまでのSparkはアクセラレータの割り当て制御が不十分
 YARNやKubernetesなどは既にGPUをサポートしているはずでは？
 YARNやKubernetesがGPUの割り当てを制御するのはコンテナやPodの単位
 コンテナ/Pod単位ではGPUが適切に分離される
Executor
(コンテナやPod内で動作)
GPU GPU
GPU
GPU
GPU
GPU
スレーブサーバ内
のGPU
NodeManager/Workerは、
GPUプールの中から要求
された数のGPUを割り当
ててコンテナ/Podを起動
割り当てられている最中
のGPUは、他のコンテナ
やPodに割り当てられた
り、アクセスされないよ
うに制御される
スレーブサーバ

これまでのSparkはアクセラレータの割り当て制御が不十分
 SparkではExecutorプロセスがコンテナやPod内で動作するが、Executorの中
で更に複数のタスクがスロット分だけ並列で実行される
 YARNやKubernetesはコンテナ/Podの中身については関知しないので、タスク
に対してGPUをどのように割り当てるかは制御できない
Executor
GPU GPU
GPUなどのアクセラレータは
タスクに対して割り当てが制
御されていないため、競合や
無駄が生じる
スロット

Accelerator Aware Scheduling
 Executorにどれだけアクセラレータを割り当てるかだけではなく、タスク対
して割り当てる数を設定できる
 タスクのスケジューリングは、要求する種類/数のアクセラレータを満足する
スロットに対して行われる
Executor
GPU GPU
タスクに割り当てられたアクセラ
レータは他のタスクからアクセス
されないように分離される
GPU GPU

Accelerator Aware Schedulingの利用例
 Executorやタスクに割り当てるGPUの数などを設定する
 アプリ側では、TaskContext#resourcesで、タスクに割り当てられたGPUの識
別子を取得できる
context = TaskContext.get()
// タスクに割り当てられたGPUの識別子を取得
assigned_gpu = context.resources()[“gpu”][0]
with tf.device(assigned_gpu):
<何か処理>
・・・
// Executorあたり4つGPUを割り当てる
spark.executor.resource.gpu.amount=4
// タスクあたりに割り当てるGPUの数
spark.executor.task.gpu.amount=2
// Executorに割り当てられたGPUを検出するスクリプトの設定
spark.executor.resource.gpu.discoveryScript=...

Accelerator Aware Schedulingの開発状況
 Spark 3.0への導入に向けて開発が進行中
 YARN/Kubernetes/Standalone向けにはすでにパッチマージ済み
 Mesos向けにもJIRA上にチケットが切られてはいるが、優先度は低
 割り当てられたアクセラレータにアクセスするためのAPIもマージ済み
 基本的にはGPUに依らないアクセラレータを考慮したスケジューリングの仕
組みだが、当面はGPUを対象としている
 そのほかWebUIからもアクセラレータの割り当て状況が確認できるように開
発が進められている(SPARK-27489)

Project Hydrogen
③ Optimized Data Exchange

 Spark向けにDLフレームワークを開発するといってもやり方はいろいろ
 最初からSpark向けに作る
 TensorFlowやHorovodなど、既存のフレームワークをSparkに移植/統合
する
• 例えばSparkのExecutorがDistributed TensorFlowクラスタを構成する
イメージ
• 処理基盤がSparkに変わるだけで、ユーザの視点で見ればインター
フェイスが一緒な分使いやすい
Spark向けDLフレームワークの実現の仕方も色々

 既存のDLフレームワークの中にはJVM上で動作する言語以外で記述されてい
るものもある
 特にPythonで動作するフレームワークが多い
 このようなフレームワークをSparkに統合する場合各Executorは外部プロセス
を制御しつつ、JVMと外部プロセスとの間でデータ交換が必要
既存のDLフレームワークをSpark向けに統合する際の課題
Executor 外部プロセス
(Pythonなど)
両プロセス間でデータ交換が必要

既存のDLフレームワークをSpark向けに統合する際の課題
 Executorと外部プロセス間のデータ交換を効率的に行うためには、考えなけ
ればならないことがある
 JVMと外部プロセスとの間のデータ転送効率
 JVMと外部プロセスとの間でのリソース利用効率
 etc
 DLフレームワークをSparkに統合するにあたって、データ交換を効率的に行う
ための一連の取り組みがOptimized Data Exchange
 Optimized Data Exchange自体更にさまざまな取り組みから構成されている

Pandas UDFでExecutor-Python間の効率的なデータ交換はある程度達成済み
 Spark SQLをPythonから利用する場合、UDFはPython上で動作するためJVM
とPython間でデータ交換が必要
 Pandas UDF(Spark 2.3～)の導入により、JVMとPythonプロセス間のデータ転
送効率はある程度改善された
 JVMとPythonの両方で扱えるArrowを共通の中間フォーマットとし、両プロセ
ス間で複数のレコードを効率よくまとめてやりとりする
UDFで処理
対象になる
DataFram
Executor (JVMプロセス)
「バッチ」と呼
ばれる単位で
Apache Arrow
でシリアライズ
Pythonプロセス
Python側では
Pandasのデータ
構造にデシリア
ライズ

まだまだ改善の余地もある
 Pandasが必要ないシーンではArrowでシリアライズしたデータからPandasへ
の変換が無駄
 ArrowからPandasを経由せずに直接NumPy arrayを得たい場合など
 Arrowベースの中間フォーマットがユーザやF/W開発者に公開されていない
 Spark SQLでPandas UDFを利用する場合以外にはJVMと外部プロセスとの
データ交換は効率化されない
 ExecutorとPythonプロセスの処理がパイプライン化されていない
 片方のプロセスがデータ処理している間もう片方のリソースが無駄に
UDFで処理
対象になる
DataFram
Executor (JVMプロセス)
「バッチ」と呼
ばれる単位で
Apache Arrow
でシリアライズ
Pythonプロセス
Python側では
Pandasのデータ
構造にデシリア
ライズ

Optimized Data Exchangeの開発状況
 Pandas UDF Prefetch (SPARK-27569)
 次にPandas UDFで処理するバッチをPython側であらかじめフェッチしておく
ことでパイプライン化を実現する試み
 3.0への導入に向けて開発中
 Databricksが先んじて内部で開発/利用中。1.5倍程度の高速化を達成したと報告
されている
 Public APIs for extended Columnar Processing Support (SPARK-27396)
 Sparkと外部プロセスとの間でやり取りされる効率的な中間フォーマットとAPI
を整備する試み
 導入は3.0以降？
 そのほかすでにマージされたものも(Pandas UDFの改善)
 UDF側で必要な初期化ロジックなどを、バッチごとではなく1回で済ませる仕
組み (SPARK-26412)
 Scalar UDFで複雑なデータ構造の返却をサポート (SPARK-23836)

Spark Graph

Spark向けのグラフ処理ライブラリ
 グラフはアナリティクスではテーブルライクなデータ構造と同様にポピュ
ラーなデータ表現のひとつ
 ソーシャルグラフ
 ナレッジグラフ
 不正検知
 etc
 これまでもSpark向けに様々なグラフ処理ライブラリが存在する
 GraphX
 GraphFrames (サードパーティ・パッケージ)

従来のSpark向けのグラフライブラリの問題点
 GraphX
 RDDベース
 Scala APIしか提供されていない
 ほとんどメンテナンスされていない
 GraphFrames
 DataFrameベース
 SparkPackagesで提供されるサードパーティパッケージ
 エッジやノードのセマンティクスが弱く、単純なグラフマッチングしか
行えない

GraphFramesのデータモデル
 GraphFramesではノード集合やエッジ集合をDataFrameで表現する
 各レコードがノードやエッジに対応する
 DataFrameとして表現されるためノードやエッジが属性を保持できる
 ただし、ノードやエッジそのものに「型」は定義できない
• ノードやエッジの種類の違いを区別できない
太郎次郎
東京 NYC
姉妹都市
居住
兄弟
居住
駐在経験
• 右のグラフで緑のノードは場所を表し、
水色のノードは人を表す(型が違う)。
• エッジについても色ごとに種類が異なる。
• GraphFramesではエッジやノードの
「型」を設定できないため、種類の違い
を区別できない

GraphFramesのグラフマッチング
 GraphFramesではMotifsと呼ばれる簡易的なクエリでグラフマッチングが可能
 ただし、エッジやノードに型が定義できないため、形状に基づくマッチングし
か行えない
 属性(例えばノードに関連付けられた人の名前など)を考慮したマッチングもサ
ポートされていない
 Motifsでマッチした結果はDataFrameとして得られる。複雑な条件で部分グラ
フを得たい場合はMotifsとSpark SQLのオペレーションを併用する必要がある
val motifs = g.find(“(node1)-[edge]->(node2)”)
val filtered = motifs.filter(“edge.rel = ‘居住’”)
先述のグラフで居住者と居住地を表す部分グラフを抽出したい場合は、Motifsでマッチングした後
にエッジに付与された属性が「居住」であるものをフィルタする必要がある

Spark Graph
 Sparkの新しいグラフ処理ライブラリ
 Property Graphと呼ばれるデータモデルを採用し、エッジやノードに「属性」だ
けでなく「型」が設定できる
 Cypherによるグラフマッチングが可能
 Property Graphに対して、型や属性に基づくマッチングが可能
 マッチしたエッジやノードから属性を取り出し、DataFrameとして返却する
ことも可能

Spark Graphの開発動向
 Spark 3.0への導入を目指して開発が進められている
 Neo4jの開発者が積極的に開発に参加している
 現時点でソースツリーにSpark Graph向けの新たなサブモジュールが追加され
ている(ただしコードはまだない)
 graph/api
• ユーザ向けのAPIが格納される
 graph/cypher
• グラフクエリ処理エンジンが格納される
• クエリエンジンはokapiをベースに実装される？
 graph/graph
• Spark Graphベースのグラフアルゴリズムの実装が格納される

まとめ

まとめ
 Project Hydrogen
 分散DLにおけるデータロードや前処理だけでなく、学習/推論もSparkで実現可
能にするための取り組み
 大きく3つの取り組みから構成される
• Barrier Execution Mode
• Accelerator Aware Scheduling
• Optimized Data Exchange
 Project Hydrogenの支援によって、Spark上で動作する洗練された分散DLフ
レームワークの登場に期待したい
 Spark Graph
 Sparkの新しいグラフ処理系
 Spark上の従来のグラフ処理系よりも高度なグラフマッチングを可能にする
 ポピュラーなグラフアルゴリズムも同梱される予定
 Spark SQLとの連携も可能

Spark 3.0が目指す、よりインテリジェントなUnified Analytics Platform（db tech showcase 2019 Tokyo講演資料、2019/09/25）

Recommended

More Related Content

What's hot (20)

Similar to Spark 3.0が目指す、よりインテリジェントなUnified Analytics Platform（db tech showcase 2019 Tokyo講演資料、2019/09/25） (20)

More from NTT DATA Technology & Innovation (20)

Spark 3.0が目指す、よりインテリジェントなUnified Analytics Platform（db tech showcase 2019 Tokyo講演資料、2019/09/25）