Delta Commit…の最近...

自己紹介 Name: 桑野 章弘(Akihiro Kuwano) Role: Solution Architect, Databricks Speciality : Database / Infra全般 / DS見習い Personal : ゲーム・SNS Career : Ex-CA / Ex-AWS メディア・ゲーム系のお客様を担当させていただ いてます！ Twitter(X)は @kuwa_tw でやっています！ Delta Lakeは勉強中の身ゆえ、、、

No content

No content

どうもガンキャノンです

NO MORE マサカリ!

• Delta Lakeの同時実行トランザクションと競合解決 • 協調コミットについて アジェンダ

同じテーブルに対して同時に書き込みするパターンはアクセスが増えるほどに必要 に、、、アプリケーションはレイクハウスからデータを読み込むだけでなく、同じテーブ ルに対してUPDATE、DELETE、MERGEを実行するわけですが、、、実際どう実行し ているのか？ 並列トランザクション！ 楽観的並行性制御 Optimistic Concurrency Control

悲観的と楽観的なトランザクション管理が ある 悲観的トランザクション管理 トランザクションの最初にリソースをロックす る。 トランザクションがコミットされるまでロックを解 放しないで最悪の事態を想定する＞悲観的 楽観的？ RDBとか Aさん Bさん ロック

悲観的と楽観的なトランザクション管理が ある 悲観的トランザクション管理 トランザクションの最初にリソースをロックす る。 トランザクションがコミットされるまでロックを解 放しないで最悪の事態を想定する＞悲観的 楽観的？ RDBとか Aさん Bさん ロック 駄目だよ

悲観的と楽観的なトランザクション管理が ある 楽観的トランザクション管理 コミットをまず準備段階においた時に、解決で きない競合がある場合のみ失敗させる ほとんどの競合は解決されるか、競合が発生 する可能性は低いと考える ＞楽観的 楽観的？ _delta_log 00000.json 00001.json 00002.json Aさん Bさん ロック しない

悲観的と楽観的なトランザクション管理が ある 楽観的トランザクション管理 コミットをまず準備段階においた時に、解決で きない競合がある場合のみ失敗させる ほとんどの競合は解決されるか、競合が発生 する可能性は低いと考える ＞楽観的 楽観的？ _delta_log 00000.json 00001.json 00002.json Aさん Bさん ロック しない やってみて駄 目なら エラー アクセス 可

悲観的と楽観的なトランザクション管理が ある 楽観的トランザクション管理 コミットをまず準備段階においた時に、解決で きない競合がある場合のみ失敗させる ほとんどの競合は解決されるか、競合が発生 する可能性は低いと考える ＞楽観的 楽観的？ _delta_log 00000.json 00001.json 00002.json Aさん Bさん ロック しない やってみて駄 目なら エラー アクセス 可 Deltaはこっち

トランザクションの一生 スナップショットを 読む ステージ変更 コミットを試行 楽観的トランザクションを開始。 テーブルの最新バージョンを読み取り、変更 が必要なファイルを特定する。 みせられないよ！

トランザクションの一生 スナップショットを 読む ステージ変更 コミットを試行 新しいデータファイルと削除ベクトルを書き込 むことで、変更を記録する。 みせられないよ！

トランザクションの一生 スナップショットを 読む ステージ変更 コミットを試行 変更をコミットする前に、スナップショットが読 み取られてから他の変更との競合がないか チェックする。 競合がある場合、書き込み操作は失敗する （例外が投げられる） みせられないよ！

• あるサービスでは、ユーザに時系列データ／予測を保存、更新、分析を共有す る機能をユーザーに提供したい！ • 各時系列予測は、時間の粒度と予測の長さに応じて、数百から数千の行で構成 される可能性があります。 • サービスではこれをサポートするためにDatabricksとDelta Lakeを使いたい！ • 実際の例 同時実行トランザクションの例

このパターンではACID一貫性保証を提供する並行読み取り、更新、削除を可能に することが必要 同じ時系列オブジェクトへの並行書き込み（稀なパターン）や、異なる時系列オブジェ クトへの並行書き込み（一般的なパターン）を可能に！ そのためには？ シナリオ

• Databricksはテーブルをロックしますか？ • 何人かのユーザが同じ時系列オブジェクトを同時に更新しようとするとどうなりま すか？ • 異なる時系列オブジェクトを同時に更新しようとするとどうなりますか？ • ユーザーはいつでも自分のジョブをスケジュールできます。 100個の時系列オブ ジェクトを同時に削除しようとするとどうなりますか？ よくある質問

• 2つの操作が同じファイル・セットに書き込ま れると、競合するかも • パーティショニングは競合の可能性を減らせ る • パーティショニングされていないテーブルを使 用する場合、同時実行の単純化を実現 • 削除ベクトルを有効 • 行レベルでの競合を検出、同時書き込みが ファイル内の異なる行を更新または削除した 場合に、自動的に競合を解決する 競合の解決にはどういう方法がある？ パーティショニング 行レベル競合解決

削除ベクトルは特定のバージョンのデル タテーブルでは有効ではなくなった（「削 除された」）特定のパーケージファイルの 行の集合を表す最適化されたビットマッ プ Parquetファイルの n 番目の行には行イ ンデックス n が割り当て、削除ベクトルの n 番目のビットに関連付け 削除ベクトル（Deletion Vector） 4行目は「スキップ」または「削除」 とマーク。データを読み込む際に は、DVと組み合わせて結果を取 得

削除ベクトルは、更新や削除の際にファイルを書き換える必要がなくなる マージ作業に費やす時間の大部分を占めることが多い 削除ベクトル（Deletion Vector）

• Delta は2つの競合を検出する • 2つの同時書き込み操作が同じ行を変更しようとしているか（物理的競合） • 2つのトランザクション間にデータ依存関係があるか（論理的競合） • 競合はメンテナンス操作と書き込み操作の間で解決 • Row-Level Concurrency (DBR 14.2 に GA) • 現在のRLCはコンフリクトを一度に1つずつ解決 競合の解決 行レベルのコンフリクト

• 2つのオペレーションが競合するかどうかは、それらが同じファイル・セットを操作 するかどうかに依存 • パーティショニングは、複数のパーティション間でより多くの同時トランザクション を処理できる可能性を提供 • パーティショニング戦略大事 • コンフリクトは行レベルではなくパーティションレベルで検出されることに注意 • 行レベルでは競合していない同じパーティションの2つの同時実行トランザクションが競合す る可能性 競合の解決 パーティショニング

• RLCを使用時、SELECT、 MERGE、DELETE、INSERTを 実行した同一テーブルの同時 更新はすべて成功する（削除 ベクター有効） • クエリで同じ行が更新されるこ とはなし！ 競合の解決

• この場合、5人のユーザーが同じ時系列 オブジェクト（つまり同じテーブルの同じ 行）をマージしようと、、、 • 1つのトランザクションだけが成功し、他の トランザクションは例外/エラーで終了 • この場合、呼び出し元のアプリケーション はエラーをどのように処理するかを決定 する必要アリ 競合の解決 RLC

• 異なる行グループに対して100件の同時削除 トランザクション • いくつかのトランザクションは成功したが、他 のトランザクションは失敗するものもあり 競合の解決 並行性の高い場合のRLC

• 4,096のパーティションを持つテーブルに対して、 100の同時削除トランザクションを実行 • すべての削除は個々のパーティションに対して実 行 • 正常に完了 • 50の同時トランザクションを持つ4,096のパー ティションでは、2つのトランザクションが衝突する 確率は26％ 競合の解決 パーティショニングとの比較

• ここまでの話は現状シングルテーブルでの話 • マルチテーブルの場合は協調コミット（Coordinated Commits）が実装中Delta Lake 4.0でPreview おまけ マルチテーブルは、、、？

• Delta Tableでコミットを行うオープンで柔軟な方法 • 全テーブルにはシングルコミット・コーディネータ をもっている • コミットコーディネータがやること： • コミットがどのように行われるかの定義 • 複数のWriter間の調整 • Readerにとって最新のコミットの正の情報源 • Open: 誰でもコミット・コーディネーターになれる • 例：UC / DynamoDB / Glue / HMS など 協調コミット はじめに

Pseudocode Interface CommitCoordinator { // Commits the given iterator of changes to a given version def commit(version, content): Commit // Returns the uuid commits in the given range (if any) def getCommits(from, optional_to): Array[Commit] } Class Commit { String path; Int length; Long commitTime; } 31 コミット・コーディネーター・インターフェース このインターフェイスを実 装することで、コミット・コー ディネーターになれる、君 もなれる シンプル、柔軟、オープン

• DeltaLog に保存されるコミットコーディネータ情報 • ライターテーブルの新機能: `coordinatedCommits` • 新しいコミットフォーマット： ..json • 例：23.46d70172.json 協調コミット 実施内容

Commit flow with Coordinated Commits commit(version, content) getCommits() Commit Coordinator Client Identify Commit Coordinator Make changes to data files Ask Commit Coordinator to commit Success Delta Client 1 -> 1.uuid-x.json 2 -> 2.uuid-y.json 3 -> 3.uuid-z.json Some Storage Object Store Storage S3 _commits/ 1.uuid-x.json 2.uuid-y.json 3.uuid-z.json Commit Coordinator

Commit flow with Coordinated Commits commit(version, content) getCommits() Identify Commit Coordinator Make changes to data files Ask Commit Coordinator to commit Success Delta Client 1 -> 1.uuid-x.json 2 -> 2.uuid-y.json 3 -> 3.uuid-z.json 4 -> 4.uuid-p.json Some Storage Commit Coordinator 1 -> 1.uuid-x.json 2 -> 2.uuid-y.json 3 -> 3.uuid-z.json Storage S3 _commits/ 1.uuid-x.json 2.uuid-y.json 3.uuid-z.json 4.uuid-p.json Object Store Commit Coordinator Client

35 commit(version, content) getCommits() Commit Coordinator Client version-fileName-map 1 -> 1.uuid-x.json 2 -> 2.uuid-y.json 3 -> 3.uuid-z.json DynamoDB • コミット・コーディネーターがバージョ ンとファイル名のマップを追跡 • 例 • カタログUnity Catalog、HMS • DynamoDB • 任意の永続ストレージ コミット・コーディネーター 最近のコミットに関する情報を保持

Commit Coordinator Commit Coordinator table_dir/ _delta_log/ 0000.json 0001.json _commits/ 2.uuid-p.json 3.uuid-q.json 3.uuid-r.json 2 -> 2.uuid-p.json 3 -> 3.uuid-r.json Commit Coordinator 3 -> 3.uuid-r.json table_dir/ _delta_log/ 0000.json 0001.json 0002.json _commits/ 3.uuid-q.json 3.uuid-r.json { empty } table_dir/ _delta_log/ 0000.json 0001.json 0002.json 0003.json _commits/ • バックフィル： uuidコミットを確認可能な フォーマットにコピーす る:.json • これにより古い Delta クライアントも coordinated-commit テーブル を読める様になる リードは下位互換 コミットの埋め戻し