![© 2019 NTT DATA Corporation 26
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=...](https://image.slidesharecdn.com/projecthydrogenandsparkgraphnttdatasaruta-190930215045/85/Project-Hydrogen-and-Spark-Graph-x-AI-Apache-Spark-NTT-2019-2019-09-05-26-320.jpg)
![© 2019 NTT DATA Corporation 40
GraphFramesのグラフマッチング
GraphFramesではMotifsと呼ばれる簡易的なクエリでグラフマッチングが可能
ただし、エッジやノードに型が定義できないため、形状に基づくマッチングし
か行えない
属性(例えばノードに関連付けられた人の名前など)を考慮したマッチングもサ
ポートされていない
Motifsでマッチした結果はDataFrameとして得られる。複雑な条件で部分グラ
フを得たい場合はMotifsとSpark SQLのオペレーションを併用する必要がある
val motifs = g.find(“(node1)-[edge]->(node2)”)
val filtered = motifs.filter(“edge.rel = ‘居住’”)
先述のグラフで居住者と居住地を表す部分グラフを抽出したい場合は、Motifsでマッチングした後
にエッジに付与された属性が「居住」であるものをフィルタする必要がある](https://image.slidesharecdn.com/projecthydrogenandsparkgraphnttdatasaruta-190930215045/85/Project-Hydrogen-and-Spark-Graph-x-AI-Apache-Spark-NTT-2019-2019-09-05-40-320.jpg)
![© 2019 NTT DATA Corporation 42
Cypherによるグラフマッチの例
val result: CypherResult = graph.cypher(
"""|MATCH (person: 人)-[rel: 居住]->(loc: 都市)
"""|RETURN person.name, loc.name""").stripMargin
result.df.show()
| person.name | loc.name |
| 太郎 | 東京 |
| 次郎 | 東京 |
Property Graphに対するCypherの適用例](https://image.slidesharecdn.com/projecthydrogenandsparkgraphnttdatasaruta-190930215045/85/Project-Hydrogen-and-Spark-Graph-x-AI-Apache-Spark-NTT-2019-2019-09-05-42-320.jpg)
Project Hydrogen and Spark Graph - 分散処理 × AIをより身近にする、Apache Sparkの新機能 - （NTTデータ テクノロジーカンファレンス 2019 講演資料、2019/09/05）
- 1. © 2019 NTT DATA Corporation 1 © 2019 NTT DATA Corporation NTTデータ テクノロジーカンファレンス 2019 Project Hydrogen and Spark Graph - 分散処理 × AIをより身近にする、Apache Sparkの新機能 - 2019年9月5日 株式会社NTTデータ 技術開発本部 先進基盤技術グループ 猿田 浩輔
- 2. © 2019 NTT DATA Corporation 2 $ whoami 猿田 浩輔 株式会社NTTデータ 技術開発本部 シニア・ソフトウェアエンジニア / Apache Sparkコミッタ Hadoop/SparkなどOSS並列分散処理系の開発やテクニカルサポートに従事 普及活動の一環で講演や書籍執筆なども Twitter: @raspberry1123
- 3. © 2019 NTT DATA Corporation 3 本日のお話 Apache SparkはこれまでUnified Analytics Platformとして様々なユースケース をカバーしてきた バッチ ストリーム 機械学習 グラフ処理 クエリ処理 昨今はAIをはじめ、"よりインテリジェントな分析"を実現する機能の導入が検 討されている Project Hydrogen • Spark上で分散Deep Learningを可能にするための下地作り Spark Graph • Sparkの新しいグラフ処理ライブラリ
- 4. © 2019 NTT DATA Corporation 4 Project Hydrogen
- 5. © 2019 NTT DATA Corporation 5 ビッグデータとディープラーニング 昨今AI(特にDeep Learning)が身近なものになり、領域を問わず活用されるよ うになってきた Deep Learningは旧来のアルゴリズムと比較して大量のデータの活用によって 精度の向上が期待できる 大量のデータで学習するために、複数の計算機を用いた分散ディープラーニ ングが活用されるケースも出てきた Distributed TensorFlowやHorovodなど、 分散ディープラーニングを実現可能にする フレームワークも登場 Sparkも分散ディープラーニングパイプラインを 構成する一部として用いられてきた http://cs229.stanford.edu/materials/CS229-DeepLearning.pdf
- 6. © 2019 NTT DATA Corporation 6 分散DLのワークロードの中で、Sparkはこれまでどう使われてきたか ① 前処理や、学習/推論部分とデータソースとのインターフェイス DLでは学習/推論部分だけでなく、学習データセットや推論対象のデータとの インターフェイスや前処理も重要 特に分散DLでは学習/推論以外の部分も分散処理が必要になる。ここで分散ETL の実績があるSparkが活用されるケースがある RDBMSや分散KVS、クラウドストレージ、様々なデータフォーマットに対応 している点(インターフェイスの豊富さ)もSparkが選択される際のポイント 前処理済みデータセット 分散ストレージなど 分散学習 分散 ETL
- 7. © 2019 NTT DATA Corporation 7 分散DLのワークロードの中で、Sparkはこれまでどう使われてきたか ② 推論部分の分散実行 学習自体はTensorFlowなどに任せて、作成したモデルを用いて推論部分を分散 実行するケースもある 分散ストレージなど モデルの 生成前処理 + 分散推論 学習済みモデル
- 8. © 2019 NTT DATA Corporation 8 SparkクラスタとDLクラスタ間での連携にはユーザ側で作りこみが必要 同じマシン上でSparkとDLフレームワークを動かしていても課題は一緒 異なる種類のクラスタを運用することによる、オペレーションの煩雑化も SparkとDLクラスタの連携には工夫が必要 分散ストレージなど Sparkクラスタ • 外部からのデータロード • データの前処理 • 分散推論 DLクラスタ • 分散学習 • モデルの作成 前処理済みデータセット 学習済みモデル ユーザによる作りこみが必要な連携部分
- 9. © 2019 NTT DATA Corporation 9 SparkクラスタとDLクラスタが統合できるとよい 分散学習/推論が、Spark上のアプリケーションとして実行できるとよい Sparkの仕組みに閉じてデータのロードや前処理、学習/推論が完結 ユーザ側でSparkとDLクラスタ側の連携方法の作りこみが不要 TensorFlow On SparkやIntel BigDLなど、この課題に着目したフレームワーク も登場した ただし、Spark側でDLのワークロードに求められる機能が不足しているため、 フレームワーク開発者は苦戦を強いられている どんな機能が不足しているのかはこのセッションのポイントのひとつ。 概ね以下の通り • タスク間の同期が可能なスケジューリング機能 • GPUなどのアクセラレータをタスクに割り当てる機能 • 既存のDLフレームワークやそれに付随する外部プロセスとの効率的なデー タ交換を支援する機能
- 10. © 2019 NTT DATA Corporation 10 Project Hydrogen Spark上で分散DLを実現するための一連のサブプロジェクト 主にDLフレームワーク開発者向けの支援機能などの導入がメイン あくまで支援機能の導入がメイン。DLにおける学習/推論アルゴリズム そのものの導入はスコープ外 大きく3つの取り組みから成り立っている Barrier Execution Mode Optimized Data Exchange Accelerator Aware Scheduling
- 11. © 2019 NTT DATA Corporation 11 Project Hydrogen ① Barrier Execution Mode
- 12. © 2019 NTT DATA Corporation 12 従来のSparkの実装では分散学習が難しい 推論部分は各Executorがモデルをロードしておき、受信したデータに対して 各Executorが推論を行えばよいので、Sparkの既存の機能で実現できる 分散学習については、AllReduceなどで勾配パラメータを交換時際にタスク間 で同期が必要になるが・・・ Sparkのスケジューリング機構がタスク間での同期を想定した実装に なっていないため難しい Executor Executor Executor 推論対象 データ 学習済みモデルのロード 丸 三角 星
- 13. © 2019 NTT DATA Corporation 13 おさらい: Sparkの処理単位とタスクスケジューリングの基本 Sparkでは、ユーザが記述した処理から「ステージ」や「タスク」と呼ばれる 処理単位が生成される 複数のExecutorが異なるタスクを処理することでクラスタ全体で分散処理が 行われる ステージ1 シャッフル ステージ3 シャッフル ステージ4 タスク タスク タスク タスク タスク タスク タスク タスク タスク ステージ2 タスク タスク
- 14. © 2019 NTT DATA Corporation 14 おさらい: Sparkの処理単位とタスクスケジューリングの基本 Executorへのタスクの割り当ては、Sparkのスケジューラが決定する 依存のあるステージでは、先行するステージのタスクがすべて完了すると後 続のステージのスケジューリングが始まる(図中ステージ1、3、4) 依存のないステージ同士は同時にスケジューリングされる(図中のステージ1 とステージ2) ステージ1 シャッフル ステージ3 シャッフル ステージ4 タスク タスク タスク タスク タスク タスク タスク タスク タスク ステージ2 タスク タスク
- 15. © 2019 NTT DATA Corporation 15 おさらい: 従来からのタスクスケジューリング スロットは同時にスケジューリングさ れた複数のステージのタスクで共用さ れる。 そのため、あるステージのタスクを全 て同時にスケジューリングできるとは 限らない。 Executor スロット (タスクを割り 当てる空間) スケジューリング待ちのタスク (色の違いは異なるステージを表現) ドライバ Executor スロットが空き次第次々と タスクをスケジューリング
- 16. © 2019 NTT DATA Corporation 16 おさらい: 従来からのタスクスケジューリング Executor スロット (タスクを割り 当てる空間) スケジューリング待ちのタスク (色の違いは異なるステージを表現) ドライバ Executor スロットが空き次第次々と タスクをスケジューリング スループットの面で有利だが、ステー ジ内のすべてのタスクが同時にスケ ジューリングされるとは限らないので、 分散DLのワークロードで求められるよ うなタスク間の同期が難しい スロットは同時にスケジューリングさ れた複数のステージのタスクで共用さ れる。 そのため、あるステージのタスクを全 て同時にスケジューリングできるとは 限らない。
- 17. © 2019 NTT DATA Corporation 17 おさらい: 従来からのタスクのリトライの仕組み あるタスクが失敗した場合、当該タスクのみリトライされる ステージ内の他のタスクは影響を受けずに処理を継続できる 一方で協調動作が必要なタスク群はまとめてリトライしてほしい場合もある タスク × 完了 完了 リトライが必要なのは 失敗したタスクだけ タスク タスク
- 18. © 2019 NTT DATA Corporation 18 Barrier Execution Mode Spark 2.4から導入されたBarrier Execution Modeでは、従来のスケジューリ ング方式に加えてギャングスケジューリングが可能になった Barrier Mode Executionの対象のステージに含まれるタスクは、一度にまとめ てスケジューリングされる 十分なスロットがなければ待つ 対象のステージ内の全てのタスクが成功するか、あるいは全て失敗するかの いずれか(All or Nothing) リトライのスケジューリングもまとめて行う タスク間の同期を支援する仕組みも導入された 同期のためのAPIや同期が必要な他のタスクの把握するAPIが導入された
- 19. © 2019 NTT DATA Corporation 19 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() // タスク間の待ち合わせ。全てのタスクがここに到達したら先に進む。 <何か処理(勾配パラメータの交換など)>
- 20. © 2019 NTT DATA Corporation 20 Barrier Execution Modeの開発状況 基本的な機能は概ねSpark 2.4で完成している DLのユースケースで用いられることの多いPythonでももちろん利用可能 Dynamic Resource Allocationとの併用は現段階では不可 3.0でも少しだけアップデートあり WebUI ギャングスケジューリングが不可能な場合の ログメッセージの改善 設定項目のドキュメントが追加された Barrier Mode Executionの対象となる オペレーションは緑色で表示される
- 21. © 2019 NTT DATA Corporation 21 Project Hydrogen ② Accelerator Aware Scheduling
- 22. © 2019 NTT DATA Corporation 22 DLのワークロードではGPUなどのアクセラレータの活用が当たり前に DLのワークロードではGPUを活用することが当たり前になってきている 多くのDLフレームワークがGPUをサポートしている DLフレームワークをSpark向けに開発する場合、Spark内部からGPUなどのア クセラレータを扱える必要がある これまではGPUなどのアクセラレータを想定した作りになっていなかった
- 23. © 2019 NTT DATA Corporation 23 これまでの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に割り当てられた り、アクセスされないよ うに制御される スレーブサーバ
- 24. © 2019 NTT DATA Corporation 24 これまでのSparkはアクセラレータの割り当て制御が不十分 SparkではExecutorプロセスがコンテナやPod内で動作するが、Executorの中 で更に複数のタスクがスロット分だけ並列で実行される YARNやKubernetesはコンテナ/Podの中身については関知しないので、タスク に対してGPUをどのように割り当てるかは制御できない Executor GPU GPU GPUなどのアクセラレータは タスクに対して割り当てが制 御されていないため、競合や 無駄が生じる スロット スレーブサーバ
- 25. © 2019 NTT DATA Corporation 25 Accelerator Aware Scheduling Executorにどれだけアクセラレータを割り当てるかだけではなく、タスク対 して割り当てる数を設定できる タスクのスケジューリングは、要求する種類/数のアクセラレータを満足する スロットに対して行われる Executor GPU GPU タスクに割り当てられたアクセラ レータは他のタスクからアクセス されないように分離される スレーブサーバ GPU GPU
- 26. © 2019 NTT DATA Corporation 26 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=...
- 27. © 2019 NTT DATA Corporation 27 Accelerator Aware Schedulingの開発状況 Spark 3.0への導入に向けて開発が進行中 YARN/Kubernetes/Standalone向けにはすでにパッチマージ済み Mesos向けにもJIRA上にチケットが切られてはいるが、優先度は低 割り当てられたアクセラレータにアクセスするためのAPIもマージ済み 基本的にはGPUに依らないアクセラレータを考慮したスケジューリングの仕 組みだが、当面はGPUを対象としている そのほかWebUIからもアクセラレータの割り当て状況が確認できるように開 発が進められている(SPARK-27489)
- 28. © 2019 NTT DATA Corporation 28 Project Hydrogen ③ Optimized Data Exchange
- 29. © 2019 NTT DATA Corporation 29 Spark向けにDLフレームワークを開発するといってもやり方はいろいろ 最初からSpark向けに作る TensorFlowやHorovodなど、既存のフレームワークをSparkに移植/統合 する • 例えばSparkのExecutorがDistributed TensorFlowクラスタを構成する イメージ • 処理基盤がSparkに変わるだけで、ユーザの視点で見ればインター フェイスが一緒な分使いやすい Spark向けDLフレームワークの実現の仕方も色々
- 30. © 2019 NTT DATA Corporation 30 既存のDLフレームワークの中にはJVM上で動作する言語以外で記述されてい るものもある 特にPythonで動作するフレームワークが多い このようなフレームワークをSparkに統合する場合各Executorは外部プロセス を制御しつつ、JVMと外部プロセスとの間でデータ交換が必要 既存のDLフレームワークをSpark向けに統合する際の課題 スレーブサーバ Executor 外部プロセス (Pythonなど) 両プロセス間でデータ交換が必要
- 31. © 2019 NTT DATA Corporation 31 既存のDLフレームワークをSpark向けに統合する際の課題 Executorと外部プロセス間のデータ交換を効率的に行うためには、考えなけ ればならないことがある JVMと外部プロセスとの間のデータ転送効率 JVMと外部プロセスとの間でのリソース利用効率 etc DLフレームワークをSparkに統合するにあたって、データ交換を効率的に行う ための一連の取り組みがOptimized Data Exchange Optimized Data Exchange自体更にさまざまな取り組みから構成されている
- 32. © 2019 NTT DATA Corporation 32 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のデータ 構造にデシリア ライズ
- 33. © 2019 NTT DATA Corporation 33 まだまだ改善の余地もある 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のデータ 構造にデシリア ライズ
- 34. © 2019 NTT DATA Corporation 34 外部プロセスとの連携のパイプライン化 Pandas UDF Prefetch(SPARK-27569)でデータのプリフェッチによる改善が検 討されている 時刻 JVM Pythonプロセス t1 バッチ1の書き出し t2 バッチ1の処理 t3 バッチ2の書き出し t4 バッチ2の処理 時刻 JVM Pythonプロセス t1 バッチ1の書き出し t2 バッチ2の書き出し バッチ1の処理 t3 バッチ2の処理 ・ ・ ・ ・ ・ ・ 理想的にはJVMもPythonもパイプライン 的に動作することでリソースを無駄なく 使ってほしい Python UDFの利用などでPythonプロセ スと連携する場合、現状はリソースの使 い方に無駄がある
- 35. © 2019 NTT DATA Corporation 35 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)
- 36. © 2019 NTT DATA Corporation 36 Spark Graph
- 37. © 2019 NTT DATA Corporation 37 Spark向けのグラフ処理ライブラリ グラフはアナリティクスではテーブルライクなデータ構造と同様にポピュ ラーなデータ表現のひとつ ソーシャルグラフ ナレッジグラフ 不正検知 etc これまでもSpark向けに様々なグラフ処理ライブラリが存在する GraphX GraphFrames (サードパーティ・パッケージ)
- 38. © 2019 NTT DATA Corporation 38 従来のSpark向けのグラフライブラリの問題点 GraphX RDDベース Scala APIしか提供されていない ほとんどメンテナンスされていない GraphFrames DataFrameベース SparkPackagesで提供されるサードパーティパッケージ エッジやノードのセマンティクスが弱く、単純なグラフマッチングしか 行えない
- 39. © 2019 NTT DATA Corporation 39 GraphFramesのデータモデル GraphFramesではノード集合やエッジ集合をDataFrameで表現する 各レコードがノードやエッジに対応する DataFrameとして表現されるためノードやエッジが属性を保持できる ただし、ノードやエッジそのものに「型」は定義できない • ノードやエッジの種類の違いを区別できない 太郎 次郎 東京 NYC 姉妹都市 居住 兄弟 居住 駐在経験 • 右のグラフで緑のノードは場所を表し、 水色のノードは人を表す(型が違う)。 • エッジについても色ごとに種類が異なる。 • GraphFramesではエッジやノードの 「型」を設定できないため、種類の違い を区別できない
- 40. © 2019 NTT DATA Corporation 40 GraphFramesのグラフマッチング GraphFramesではMotifsと呼ばれる簡易的なクエリでグラフマッチングが可能 ただし、エッジやノードに型が定義できないため、形状に基づくマッチングし か行えない 属性(例えばノードに関連付けられた人の名前など)を考慮したマッチングもサ ポートされていない Motifsでマッチした結果はDataFrameとして得られる。複雑な条件で部分グラ フを得たい場合はMotifsとSpark SQLのオペレーションを併用する必要がある val motifs = g.find(“(node1)-[edge]->(node2)”) val filtered = motifs.filter(“edge.rel = ‘居住’”) 先述のグラフで居住者と居住地を表す部分グラフを抽出したい場合は、Motifsでマッチングした後 にエッジに付与された属性が「居住」であるものをフィルタする必要がある
- 41. © 2019 NTT DATA Corporation 41 Spark Graph Sparkの新しいグラフ処理ライブラリ Property Graphと呼ばれるデータモデルを採用し、エッジやノードに「属性」だ けでなく「型」が設定できる Cypherによるグラフマッチングが可能 Property Graphに対して、型や属性に基づくマッチングが可能 マッチしたエッジやノードから属性を取り出し、DataFrameとして返却する ことも可能
- 42. © 2019 NTT DATA Corporation 42 Cypherによるグラフマッチの例 val result: CypherResult = graph.cypher( """|MATCH (person: 人)-[rel: 居住]->(loc: 都市) """|RETURN person.name, loc.name""").stripMargin result.df.show() | person.name | loc.name | | 太郎 | 東京 | | 次郎 | 東京 | Property Graphに対するCypherの適用例
- 43. © 2019 NTT DATA Corporation 43 Spark Graphの開発動向 Spark 3.0への導入を目指して開発が進められている Neo4jの開発者が積極的に開発に参加している 現時点でソースツリーにSpark Graph向けの新たなサブモジュールが追加され ている(ただしコードはまだない) graph/api • ユーザ向けのAPIが格納される graph/cypher • グラフクエリ処理エンジンが格納される • クエリエンジンはokapiをベースに実装される？ graph/graph • Spark Graphベースのグラフアルゴリズムの実装が格納される
- 44. © 2019 NTT DATA Corporation 44 まとめ
- 45. © 2019 NTT DATA Corporation 45 まとめ Project Hydrogen 分散DLにおけるデータロードや前処理だけでなく、学習/推論もSparkで実現可 能にするための取り組み 大きく3つの取り組みから構成される • Barrier Execution Mode • Accelerator Aware Scheduling • Optimized Data Exchange Project Hydrogenの支援によって、Spark上で動作する洗練された分散DLフ レームワークの登場に期待したい Spark Graph Sparkの新しいグラフ処理系 Spark上の従来のグラフ処理系よりも高度なグラフマッチングを可能にする ポピュラーなグラフアルゴリズムも同梱される予定 Spark SQLとの連携も可能
- 46. © 2019 NTT DATA Corporation 本資料に記載されている会社名、商品名、又はサービス名は、各社の登録商標又は商標です。