Spark+AI Summit 2019 セッションハイライト (Spark Meetup Tokyo #1 - Spark+AI Summit 2019)

© 2019 NTT DATA Corporation
2019年6月12日
株式会社NTTデータ技術革新統括本部
Spark+AI Summit 2019 セッションハイライト

© 2019 NTT DATA Corporation 2
はじめに
• 本資料は、Spark+AI Summit 2019で行われたプレゼンテーションの一部をピックアップして、ダ
イジェストで紹介するものである。
• 本資料の内容は、必ずしも当社の見解を表すものではない。
• 本資料に掲載された社名、商品名は各社の商標または登録商標である。

$ whoami
猿田浩輔
株式会社NTTデータ技術開発本部
シニア・ソフトウェアエンジニア / Apache Sparkコミッタ
Hadoop/SparkなどOSS並列分散処理系のテクニカルサポートに
従事してきた

Spark+AI Summit 2019
• 日時: 2019-04-25(水) – 2019-04-26(木)
• 場所: Moscone Center, San Francisco
• 参加人数: 5000人ほど？
Job Board
AI関連の求人も多かった

Spark+AI Summit 2019: 雑感
• とにかく人の数が多い
– Moscone Centerではもはや手狭感
– セッション前に入場待ちの行列がちらほら
• AI系のセッションが多い印象
Microsoftはブースも大きく
基調講演もありで目立っていた

本編

Keynoteでは新プロダクトのお披露目やアップデートなどが紹介された
•キーノートではDatabricks発の新プロダクトのお披露目やアップデートなども
– Koalas => 後のセッションで上新さんから紹介
– MLflow 1.0 => 後のセッションで山室さんから紹介
– Delta Lake => このセッションで紹介

Keynote: Delta Lake
データレイクの課題
• 定型処理やアドホックなアナリティクス問わず、昨今はデータレイクを構え、それを中心に様々な
データ処理パイプラインを構築するケースが増えてきたが課題も散見される
– 安全に読み書きするのが難しい
• 書き込み途中のデータを読み取る場合など
– 同じデータを対象とし、結果を再現するのが難しい
– 非構造化データを気軽に投入できるメリットがあるが、バリデーションが大変
• 気楽にデータを投入できるメリットもあるが・・・
– データが肥大化するとともにメタデータも肥大化し、これがボトルネックになる
• データセット全体が大量のパーティションやファイルで構成される場合、メタデータも大きくなりがち

Delta Lakeとは
• トランザクションサポート付きのストレージソフトウェア
– もともとDatabricksが提供する「Databricks Delta」をOSS化(呼称もDelta Lakeと改める)
– データの蓄積機能自体はHDFSなどの分散データストアに頼る。Delta Lakeはトランザクション機能を提供
• Spark SQLやStructured Streamingのデータソース / データストアとして利用可能
• Snapshot IslationによってDelta Lakeへの書き込み/読み込みを分離
– 更新ごとの内容を記録することで、テーブルを論理的に複数バージョン保持することで実現
– 任意のスナップショットを対象とし、テーブルの一貫したビューを得ることも可能(タイムトラベル)
• トランザクション機能のほかにもスキーマのバリデーションや
スキーマエボリューションなどの機能を有する

Delta Lake上のテーブルへの書き込み
• Delta Lakeへテーブルを作成する例
• テーブルへの書き込みごとに、新たなバージョンが作成される
– テーブルの読み込み時にバージョンを指定することで、対応するバージョンのスナップショットが得られる
val df = spark.range(1, 10)
df.write.format("delta").save("/tmp/delta-table")
オプションで既存のテーブルへの上書き/追記を
制御したり、パーティショニングすることも可能
a a a
b b b
テーブルT @ バージョン n
a a a
b b b
c c c
テーブルT @ バージョン n+1
x x x
y y y
テーブルT @ バージョン n+2
追記上書き
・・・

Delta Lake上のテーブルへの書き込み
• DataFrameWriter#saveが呼び出されると、裏では対応するParquetファイルが作成される
• 同様にDelta Logも作成される
– テーブルのバージョンごとのスナップショットを構成するのに必要な情報などが記録されている
• 目的のスナップショットと直前のスナップショットとの差分となるデータファイルの扱い方など
$ ls /tmp/delta-table
_delta_log
part-00000-818c2e28-849d-4ba1-b294-d302509fb02b-c000.snappy.parquet
part-00000-0af6bf5c-82c4-41ee-90b7-70a145e96888-c000.snappy.parquet
part-00000-8327b217-a2a0-46e6-bb0e-326007ab5f7b-c000.snappy.parquet
part-00000-273e7191-0339-49c8-9c7d-c51b6ef51584-c000.snappy.parquet
part-00000-89bddf8d-d219-4fcc-96fc-54dd9b070804-c000.snappy.parquet
part-00000-279ecb1a-648f-4ce7-b441-efd6dedabad9-c000.snappy.parquet
part-00000-8a634b0e-a5db-420a-bd2c-e6c23cdf8525-c000.snappy.parquet
$ ls /tmp/delta-table/_delta_log
00000000000000000000.json
00000000000000000001.json
00000000000000000002.json
書き込みごとにParquetファイルが作成され、
テーブルの更新内容が記録される
書き込みごとにJSONファイルが作成される。
ファイル名はバージョン番号に対応している。

Delta Lake上のテーブルの読み込み
• Delta Lakeからテーブルを読み込む例
– 特にオプションを指定しない場合は、テーブルの最新のスナップショットが得られる
• テーブルのバージョンや、タイムスタンプを指定してスナップショットを得ることも可能
– Snapshot Isolationによって分離されているため、背後で同じテーブルに対して別の書き込みが進行していて
も、一貫したビューが得られる
val df = spark.read.format("delta").load("/tmp/delta-table")
val df = spark.read.format("delta").option("versionAsOf", "3").load("/tmp/delta-table")
同じテーブルに対して別の書き込みが行われて
いても、このDFに対するオペレーションは常に
バージョン3のテーブルを対象とする。

並行制御
• Delta Lakeではテーブル単位でのトランザクションがサポートされている
• Snapshot Isolationで分離されているため、同じバージョンのテーブルに対する読み込み同士
や、読み込みと書き込みはブロックせずとも安全に行える
• 書き込み同士は競合するため制御が必要
テーブルT @ バージョン n
テーブルT @ バージョン n+1?
テーブルT @ バージョン n+1?
どちらの「バージョンn+1」を採用するか
制御が必要
バージョン nのテーブルに対する
競合するアップデート

並行制御
• 同じバージョンのテーブルに対して複数の書き込みが競合した場合は、楽観並行制御によって
コミットの成否を決める
– Delta Logの書き込みに先に成功したトランザクションをコミット成功とする
• Delta Logのファイル名はバージョン番号に対応しているので、同じバージョン番号のDelta Log
を複数のトランザクションが書き込む場合(つまり書き込みが競合する場合)、後に試行した方が
ファイルを書き込めずに失敗する
HDFS
バージョンn+1のDelta
Logの書き込みを試行す
る2つのトランザクション
n+1
先に書き込みが成功
したのでコミット成功
n+1
n+1のDelta Logがすでに
存在するのでコミット失敗
トランザクションt1
トランザクションt2

スナップショットの構成の仕方
• スナップショットは、どのデータファイルを読み取るか/読み取らないかを取捨選択することで実現す
る
• あるバージョンのスナップショットを構成する場合において、直前のスナップショットからの差分(どの
データファイルを読む/読まない)がDelta Logに記録される
{"commitInfo":{"timestamp":1558850786714,"operation":"WRITE","operationParameters":{"mode":"Overwrite","partitionBy":"[]"},"readVersion":0}}
{"add":{"path":"part-00000-38a99b6c-7b16-480d-92cf-ae7839383362-c000.snappy.parquet","partitionValues":{},"size":431,"modificationTime":1558850784000,"dataChange":true}}
{"remove":{"path":"part-00000-e2fe8e08-0e5e-4124-add7-d70d78f02727-c000.snappy.parquet","deletionTimestamp":1558850786714,"dataChange":true}}
例えばaddオペレーションは直前のス
ナップショットに対してデータファイルを
追加することを意味し、removeオペ
レーションは除くことを意味する。
直前のスナップショットのバージョン番号

スナップショットの構成の仕方(例)
{"add":{"path": "x.parquet"...}...}
{"add":{"path": "y.parquet"...}...}
{"add":{"path": "z.parquet"...}...}
{"remove":{"path": "x.parquet"...}...}
{"remove":{"path": "y.parquet"...}...}
{"remove":{"path": "z.parquet"...}...}
{"add":{"path": "a.parquet"...}...}
{"add":{"path": "b.parquet"...}...}
x.parquet
y.parquet
x.parquet
y.parquet
z.parquet
x.parquet
y.parquet
z.parquet
a.parquet
b.parquet
バージョン0のDelta Log
バージョン0を構成するデータファイル
あるテーブルのスナップショットが構成される流れ
直前のバージョンから
{x,y,z}.parquetを除外
し、{a,b}.parquetを追
加。
「バージョン2」を構成する
ファイルはa.parquetと
b.parquetだと決定できる
直前のバージョンに
対して、z.parquet
を追加
テーブル作成時は
{x,y}.parquetで
構成される

Delta Log
• Delta Logにはほかにもテーブルのパーティションに関する情報などメタデータが記録される
• Delta Log自体Spark SQLのDatasetとして扱われるため、分散して読み書き/処理が可能
– メタデータが大きくなってもボトルネックになりにくい
• スナップショットの読み取りのたびに当該スナップショットまでのDelta LogのJSONファイルを読み
取るのは効率的ではないので、以下のようなタイミングでインメモリテーブルとしてキャッシュされる
– キャッシュされていないDelta Logを読んだタイミング
– Delta Logを作成したタイミング

チェックポイント
• Delta Logのキャッシュ機構があるものの、初めてスナップショットを読む場合などはやはり対応す
るJSONファイルを順番に読まなければならない
• 過去のバージョンにさかのぼって際限なくDelta Logを読まなくてもよいように、「チェックポイント」
という機構が備わっている

• 更新回数が一定回数を経るごとに、チェックポイントファイルが作成される。
– デフォルトでは10回ごと
• チェックポイントファイルはそれまでのDelta Logの内容をまとめたもの
– 過去にさかのぼって大量のDelta Logファイルを読み取るのは実用的ではないので、チェックポイントファイルが
存在する場合は当該ファイル + チェックポイント以降のDelta Logを読み取ってスナップショットを構成する
$ ls _delta_log
00000000000000000000.json 00000000000000000005.json 00000000000000000010.checkpoint.parquet 00000000000000000014.json _last_checkpoint
00000000000000000001.json 00000000000000000006.json 00000000000000000010.json 00000000000000000015.json
• バージョン0から10までのDelta Logの内容が10.checkpoint.parquetに集約されているので、バージョン10以
降のスナップショットを得る場合はチェックポイントファイル + それ以降のバージョン番号のDelta Logを読めばよい
• 最新のスナップショットを得る場合も、_last_checkpointに記録された最新のチェックポイント番号をもとに、対応
するチェックポイントとそれ以降のDelta Logを読めばよい

0 1 2 ・・・ 9 10 10 11 12
Delta Log チェックポイント
バージョン9までのスナップショットを構成
するには0 - 9のDelta Logファイルを
読まなければならないが・・・
・・・
バージョン10から次のスナップショットまでは、バージョン
10のスナップショット + それ以降のDelta Logファイル
だけを読めばよい(0 - 9のDelta Logの内容はバー
ジョン10のチェックポイントに内包されている)

Let's try!
• ローカルモードでも簡単に試せる
• spark-shell + --packagesオプションを利用すれば、事前にDelta LakeをDLする必要もなし。
– インターネットにつながっていることが前提
• パッチも受け付けている様子なので、開発に参加するのもよいかも？
$ spark-shell --packages=io.delta:delta-core_2.12:0.1.0
SparkがScala 2.11と2.12のどちらを利用するよう
にビルドされているかで、適宜パッケージ名を変える

個別セッション

• 田中正浩
• Support Engineer
o トラブルシューティング
o 仕様調査
• 業務の傍ら、OSSへのパッチ投稿
o Apache Hadoop
o Apache Ambari
o などなど

Migrating to Apache Spark at Netflix
当日の様子
※写真はSpark+AI Summit
2019にて投影されたものを加工。
Ryan Blue (Netflix)
本セッションのスライドはこちらです。
https://www.slideshare.net/databricks/migrating-to-apache-spark-at-netflix

Apache Spark at Airbnb
当日の様子
※写真はSpark+AI Summit
2019にて投影されたもの。
Hao Wang, Liyin Tang (Airbnb)
https://www.slideshare.net/databricks/apache-spark-at-airbnb

• 都築正宜
Architect / Software Engineer
→の本の著者
Hadoop, Spark, Kafkaなどの分散技術を
すこし先進的な使い方をしたい企業に
導入するお手伝いをしています。

Introducing .NET Bindings for Apache Spark
当日の様子
※写真は Spark+AI Summit
2019 にて投影されたもの。
https://www.slideshare.net/databricks/introducing-net-bindings-for-apache-spark

Modular Apache Spark: Transform Your Code in Pieces
当日の様子
※写真は Spark+AI Summit
2019 にて投影されたもの。
https://www.slideshare.net/databricks/modular-apache-spark-transform-your-code-in-pieces

Spark+AI Summit 2019 セッションハイライト (Spark Meetup Tokyo #1 - Spark+AI Summit 2019)

Recommended

Recommended

More Related Content

More from NTT DATA Technology & Innovation

More from NTT DATA Technology & Innovation (20)

Spark+AI Summit 2019 セッションハイライト (Spark Meetup Tokyo #1 - Spark+AI Summit 2019)