Apache spark 2.3 and beyond

© 2018 NTT DATA Corporation
2018/09/20
株式会社NTTデータ技術開発本部
猿田浩輔
Apache Spark 2.3 and beyond - What's new? -

© 2018 NTT DATA Corporation 2
 猿田浩輔
 株式会社NTTデータ技術開発本部
 Apache Sparkコミッタ
 Hadoop/SparkなどOSS並列分散処理系のテクニカルサ
ポートに従事してきた
$ whoami

 オープンソースの並列分散処理系
 並列分散処理の面倒な部分は処理系が解決してくれる
 障害時のリカバリ
 タスクの分割やスケジューリング
 etc
What is Apache ?
大量のデータをたくさんのサーバを並べて
並列分散処理し、
現実的な時間(数分～数時間)で
目的の処理結果を得る

 処理対象のデータをRDD(Resilient Distributed Dataset)と
呼ばれる、耐障害性が考慮された分散コレクションに抽象化
する
 RDDに対して、リスト処理に類するオペレータを連続的に適
用することで複数ステップから構成されるデータ処理を表現
する
 RDDは「パーティション(部分コレクション)」に分割されている
 各パーティションを異なる計算機で処理することで、並列分
散処理を実現する
Sparkのデータ処理モデル
RDD RDD RDDRDD
フォーマット変換グルーピングフィルター集計入力

HDFS
 RDDに対する処理は、配列やリストなどのコレクションのよう
に記述できる
リスト処理を記述するように並列分散処理を記述できる
// 例
val rdd = sc.textFile(...) // HDFSなどのストレージから
//ファイルの内容をRDDにロード
rdd.filter(...).map(...).reduceByKey(...).saveAsText(...)
フィルタして加工して集計して結果を保存
RDD RDD RDD
HDFS
filter map
RDD
reduceByKeytextFile saveAsText

充実したライブラリ / エコシステム
Spark Core
(Sparkのデータ処理エンジンや基本的なAPIなどを含む)
Spark Streaming
(ストリーム処理)
Spark SQL
(クエリ処理)
Structured
Streaming
(ストリーム処理)
GraphX
(グラフ処理)
MLlib / Spark ML
(機械学習)
SQL

 近年は、RDDを直接利用するのではなく、これをラップした
DataFrame / Datasetを利用するのが主流
 DataFrame / DatasetはSpark SQLのデータ構造で、テーブ
ル状のデータ構造
 機械学習 / ストリーム処理向けのライブラリも、DataFrame /
Dataset向けに設計されたものが整備されている
 Spark ML
 Structured Streaming
RDDからDataFrame / Datasetを中心とした処理系へ

 SQLやSQLに似た宣言的なAPIで、テーブルにクエリを発行する
ように処理を記述できる
 実行時にオプティマイザによる最適化が施される
 開発言語の違いによる性能差が出にくい
DataFrame / Datasetを利用するメリット
DataFrameで同様
の処理を記述

 Spark 2.3
 2018/9/20時点で最新のフィーチャーリリース
 大きめの新機能が10+
 1400+のチケットが解決された
 Spark 2.4
 次期フィーチャーリリース
 2018/9/20時点で2.4向けのブランチが切られている
 10月くらいにリリース？
 新しい取り組み - Project Hydrogen -
Spark 2.3, 2.4

Continuous Processing

 Apache Sparkの新しいストリーム処理系
 DataFrameをベースとする
 Spark 2.0で試験的に導入され、2.2でα版を卒業
 RDDベースのSpark Streamingには無かったセマンティクス
をサポート
 イベントタイムウィンドウ集約
 遅れて到着したデータのハンドリング
 End-to-End Exactly Once
• ※ ただし動作モードやシンクの種類による
Structured Streaming

 マイクロバッチベースの実行モード
 短いバッチ処理(マイクロバッチ)を短い間隔で実行することでストリーム処
理を実現
 マイクロバッチごとに、その時点で到着しているデータを処理する
 データの到着から処理完了までを100msオーダー以下に抑えることが難
しい
Micro-batch Processing
出展: https://databricks.com/blog/2018/03/20/low-latency-continuous-processing-mode-in-structured-streaming-in-apache-spark-2-3-0.html

 新たに導入されたストリーム処理実行モード
 各Executorにロングランニングタスクを一度スケジューリングした
後は、当該タスク内のイベントループでストリーム処理を行う
 データの到着から処理完了まで、数ミリ秒で実現可能になる
Continuous Processing
出展: https://databricks.com/blog/2018/03/20/low-latency-continuous-processing-mode-in-structured-streaming-in-apache-spark-2-3-0.html

 Spark 2.3の時点ではまだ制限が多い
 Experimental扱い
• デフォルトの実行モードはMicro-batch Processng
• プログラムでContinuous Processingに切り替え可能
 実行可能なオペレーションも限られている
• スカラ値 -> スカラ値のような射影
• 単純なフィルタ
• グルーピングを伴わない集約処理
 サポートしているSource / Sinkは事実上Kafkaのみ
• ※ほかにもあるにはあるが、テストや動作確認を意図したもの
 Spark 2.4+以降？
 安定化
 ジョインやグルーピングを伴う集約処理のサポート
開発ステータス

Kubernetesサポート

Spark on Kubernetes
Spark Core
(Sparkのデータ処理エンジンや基本的なAPIなどを含む)
Spark Streaming
(ストリーム処理ラ
イブラリ)
Spark SQL
(クエリでデータ処理を記述する
ためのライブラリ)
Structured
Streaming
(ストリーム処理ラ
イブラリ)
GraphX
(グラフ処理処理ラ
イブラリ)
MLlib / Spark ML
(機械学習ライブラリ)
YARN Standalone Mesos Kubernetes
New!

 Spark 2.3からはKubernetesをサポート(SPARK-18278)
 Kubernetes 1.6以上をサポート
 コンテナイメージはAlpine Linuxベース
 Kubernetes / コンテナのメリットを享受可能
 マルチテナントでの利用
 計算リソースの効率的な利用
 アプリケーションのポータビリティ
 開発環境と本番環境の差分を極小化する
Kubernetesサポート

アプリケーションデプロイ時の挙動
https://databricks.com/blog/2018/02/28/introducing-apache-spark-2-3.html

 Spark 2.3
 Experimental
 クラスタモードでのみ動作
 Java/Scalaで記述されたアプリケーションに限定
 アプリケーションが依存するライブラリは以下のように配置
• コンテナに事前に組み込む
• リモート(HTTPやHDFS)からダウンロード可能な場所に配置
 Spark 2.4(予定)
 PySpark対応(SPARK-23984)
 SparkR対応(SPARK-24433)
 クライアントモード(SPARK-23146)
 Spark 3.0以降？
 ダイナミックアロケーション対応(SPARK-24432)
 Kerberos認証サポート(SPARK-23257)
 ローカルに配置された依存ライブラリやファイルの利用
Kubernetesサポートのステータス

Vectorized UDF

 SparkのAPIのPythonバインディング
 DataFrameの導入などにより、これまでもパフォーマンスが改善さ
れてきた歴史がある
 DataFrameベースの処理では、Pythonで記述されたコードをもと
にオプティマイザがJVM上で実行可能なジョブを生成するため
PySpark
出展: https://databricks.com/blog/2015/04/24/recent-performance-improvements-in-apache-spark-sql-python-dataframes-and-more.html

 DataFrameベースの処理も、ユーザ定義関数(UDF)を用い
る場合はパフォーマンスを損なうことが多かった
 DataFrameベースの処理であってもPythonで書かれたUDF
はPythonのインタプリタで実行しなければならない(Pythonイ
ンタプリタの相対的な遅さ)
 レコードごとにPythonインタプリタ上のUDFを実行
• JVM上で動作するExecutorとPythonインタプリタ間の通信
に伴うシリアライズ/デシリアライズが遅い
• レコードごとのJVMとPythonインタプリタとの通信が非効率
UDFのパフォーマンスには課題が残っていた

 Pandasのデータ構造を受け取り、返すことが可能なUDFを定義で
きる仕組みを整備
 UDFの中でPandasが利用できるため、複数のデータ対して
同時に高速な処理が可能(Pandasのクリティカルな部分は
C/C++のコードベースで動作する)
 シリアライズにはApache Arrowを利用し効率化
 Arrowはカラムナインメモリフォーマット(同じ列のデータを効率
の良い物理配置でシリアライズできる)
 レコードを複数まとめてシリアライズ / 転送
Vectorized UDF (Pandas UDF)

 Spark 2.3
 Scalar UDF
• レコード単位で独立に可能な処理を並列に行いたい場合に利用
• 異なるベクトルの要素同士の演算など
• pd.Seriesを受け取り、pd.Seriesを返す
 Group Map UDF
• グループ内の個々のデータ残しつつ、グループ内のレコードすべ
てをまとめて扱う必要のある計算
• 偏差値計算など
• pd.DataFrameを受け取り、pd.DataFrameを返す
 Spark 2.4(予定)
 Grouped Agg UDF
• pd.Seriesを受け取り単一値を返す集約処理
• Window関数もサポート
サポートするUDFの種類

JVMからPythonインタプリタへのレコードの転送
A B
10 80
30 100
20 60
50 20
JVM
A B
10 80
30 100
A B
20 60
50 20
タスク1つが処理対象
とするレコード群
処理対象のカラムを複
数レコードごとにまとめ
てArrowでシリアライズ
A B
10 80
30 100
A B
20 60
50 20
Pythonインタプリタ
プロセス間転送
Scalar UDFの場合バッチサイズ(デフォルト10000レコード)ごとに、
Grouped Map UDF / Grouped Agg UDFの場合はグループごとにシリアライズ

Scalar UDFの例(ベクトル同士の足し算)
A B
20 60
50 20
・・・・・・
A+B
A B
10 80
30 100
pd.Series pd.Series
A+B
90
130
A+B
80
70
UDF(1回目の呼び出し) UDF(2回目の呼び出し)
A+B
 シリアライズされたバッチごとにpd.SeriesにデシリアライズしてUDFに渡す
 pd.Series内の要素を複数同時に演算
・・・
pd.Series
・・・・・・
pd.Series
UDF(n回目の呼び出し)

Group Map UDFの例(偏差値計算)
名前科目点数
A 数学 80
B 数学 75
名前科目点数
A 国語 90
B 国語 80
・・・
・・・
国語の偏差値を計算
UDF(1回目の呼び出し)
名前科目偏差
値
A 数学 70
B 数学 60
数学の偏差値を計算
名前科目偏差
値
A 国語 68
B 国語 55
pd.DataFrame pd.DataFrame
 シリアライズされたグループごとにpd.DataFrameにデシリアライズしてUDFに渡す
 pd.DataFrame内の要素を複数同時に演算
・・・
pd.DataFrame
・・・
pd.DataFrame
・・・

Grouped Agg UDFの例(平均値計算)
点数
80
75
点数
90
80
・・・
国語の平均点を計算
平均点
77.5
平均点
85
pd.Series pd.Series
数学の平均点を計算
 シリアライズされたグループごとにpd.SeriesにデシリアライズしてUDFに渡す
 UDF内ではpd.meanなどPandasの集約処理関数で効率的に計算
・・・
・・・
pd.Series pd.Series

PythonインタプリタからJVMへの計算結果の返却
JVM
UDFの呼び出しごとの計算結果
UDFのでの計算結果ごとに
Arrowでシリアライズ
Pythonインタプリタ
A+B
90
130
A+B
80
70
A+B
90
130
A+B
80
70
プロセス間転送
Sparkの内部表現に
デシリアライズ

 従来のUDFと比較して、最大200倍以上の高速化を実現
Vectorized UDFの効果
出展: https://databricks.com/blog/2017/10/30/introducing-vectorized-udfs-for-pyspark.html

Project Hydrogen

 ビッグデータとAI(機械学習/DL)は昨今のデータ活用における大き
な要素
 これまでSparkはビッグデータだけでなく機械学習/DLの統一プ
ラットフォームとして活用されてきた
 Spark向けに設計されたDLフレームワーク
• Deep Learning Pipelines (Databricks)
• BigDL (Intel)
 既存のDLフレームワークのSparkインテグレーション
• TensorFlowOnSpark (Yahoo!)
• CaffeOnSpark (Yahoo!)
 ビッグデータとDLの融合をより進めるうえで足りないピースもある
 分散学習を可能にするスケジューリングの仕組み
 SparkとDLフレームワークとの間の効率的なデータ交換
 GPUなどのアクセラレータを搭載した計算機へのスケジューリング
ビッグデータとDLの統一プラットフォームとしてのSpark

Project Hydrogen
Barrier Execution Mode Optimized Data Exchange
Accelerator Aware
Scheduling
分散学習を可能にする
スケジューリングの仕組み
SparkとDLフレームワーク
との間の効率的なデータ交換
アクセラレータアウェアな
タスクスケジューリング

 Barrier Execution Mode
 Sparkの新しいタスクスケジューリングモード
 DLの分散学習におけるタスク間の通信など、タスク間で協調を
可能にする仕組みを提供する
Barrier Execution Mode

タスク
タスク
タスク
• 個々のタスクは協調することなく個別
にスケジューリングされる
• あるタスクの失敗がほかのタスクに
影響しない
• パフォーマンスの面では有利
• 協調が必要なタスクを包括でスケジュー
リング
• タスクの失敗時には、協調するほかのタ
スクも再スケジューリング
• タスクが協調するための同期点(バリア)
をプログラムで制御可能
従来からのタスクスケジューリング
タスク
タスク
タスク
Barrier Execution Modeによるタスクスケジューリング

 RDD#barrierメソッドで、各タスク間で待ち合わせするタイミ
ングを制御可能
 barrierメソッドが適用されたタスクが、Barrier Execution
Modeでのスケジューリング対象となる
 具体的な通信処理ロジックなどはDLフレームワーク側やDL
アプリケーション開発者が実装する必要がある
 Barrier Execution Modeは協調を可能にする仕掛けを提供
するだけ
rdd.barrier().mapPartitions() { iter =>
val context = BarrierTaskContext.get() // バリアタスクコンテキストを取得
<何か処理>
context.barrier() // ここでタスク間の待ち合わせ

Spark 2.4
 Barrier Execution Mode(基本的な部分)
Spark 3.0?
 Barrier Execution Mode(継続)
 Optimized Data Exchange
 Accelerator Aware Scheduling
Project Hydrogenステータス

その他のトピック

 2.3以降で追加された機能もろもろ(一部)
 Stream-Stream Join (SPARK-18791)
 Vectorized ORC reader (SPARK-16060)
 Image Support in Spark (SPARK-21866)
 Streaming ML
 Spark 3.0?
 Project Hydrogen
 Java9サポート
 Scala 2.12サポート
 Hadoop 3系サポート
その他のトピック

Apache spark 2.3 and beyond

More Related Content

What's hot

Similar to Apache spark 2.3 and beyond

More from NTT DATA Technology & Innovation

Apache spark 2.3 and beyond