デルタテーブルの削除ベクトル：Databricksの操作のスピードアップ

デルタテーブルの削除ベクトル：Databricks操作をスピードアップ

伝統的に、Delta LakeはCopy-On-Writeパラダイムのみをサポートしており、ファイルが書き込まれるたびに基になるデータファイルが変更されます。例：ファイル内の1つの行が削除されると、パーケットファイル全体が書き直されなければなりません。データが複数のファイルに分散して存在し、データへの頻繁な更新がある場合、このパラダイムは効率的ではありません。このような要件に対して、Databricksは最近、Deletion Vectorsという新機能をリリースしました。本記事では、Deletion Vectorsについて、その使用方法と有効化方法について詳しく説明します。

デリーションベクトルは、Delta Lakeテーブルで有効化できるストレージ最適化機能です。テーブルにデリーションベクトルを有効にすると、デルタレイクテーブルに「マージオンリード」という新しいパラダイムが導入されます。削除および更新操作は、パーケットファイルを再書き込みすることなく、削除ベクトルを使用して既存の行を削除または変更します。テーブルの後続の読み取り操作では、デリーションベクトルによって記録された削除を最新のテーブルバージョンに適用することで、現在のテーブルの状態を解決します。

デリーションベクトルの有効化

すべての最適化を活用するために、Databricksランタイム14.1バージョン以上を使用してテーブルにデリーションベクトルを書き込むことをお勧めします。Databricks 12.1ランタイムバージョンではデリーションベクトルを持つテーブルからの読み取りがサポートされていますが、書き込みと最適化をサポートする14.1+バージョンを使用することをお勧めします。さらに、行レベルの同時実行を有効にするには、スイッチを行っている場合には14.2+バージョンを使用できます。

デリーションベクトルは次のようにして有効にすることができます:

CREATE TABLE <テーブル名> [オプション] TBLPROPERTIES ('delta.enableDeletionVectors' = true);ALTER TABLE <テーブル名> SET TBLPROPERTIES ('delta.enableDeletionVectors' = true);

デリーションベクトルを使用したDeltaテーブルの削除方法

Deltaテーブルでレコードを削除または更新するたびに、変更された行の位置がデータファイル自体から別々にマークされ、この操作を「ソフトデリーション」と呼びます。削除された行の位置は、高度に圧縮されたビットマップ形式でエンコードされ、後でデータファイルとは別に縮小されることができます。

これらの変更は、以下のイベントのいずれかがトリガーとしてデータファイルが再書き込まれるときに物理的に適用されます:

テーブル上でOPTIMIZEコマンドを適用する場合。
自動コンパクションが削除ベクトルを持つデータファイルの書き直しをトリガーする場合。
テーブルに対してREORG TABLE ... APPLY (PURGE)を実行する場合。

ファイルのコンパクションに関連するイベントは、デリーションベクトルに記録された変更を解決するための厳格な保証を持っていません。ファイルコンパクションの対象とならない場合、デリーションベクトルに記録された一部の変更は適用されない場合があります。 REORG TABLE ... APPLY (PURGE)は、デリーションベクトルを使用して記録された変更があるすべてのデータファイルを書き直します。

REORG TABLE —

ソフトデリートされたデータを削除するために、Delta Lakeテーブルを再構築してファイルを書き換えます。

REORG TABLE table_name [WHERE predicate] APPLY (PURGE)

例:

REORG TABLE events APPLY (PURGE);REORG TABLE events WHERE date >= '2022-01-01' APPLY (PURGE);

注意:

REORG TABLEは、ソフトデリートされたデータを含むファイルのみを書き換えます。
REORG TABLEは冪等性を持ちます。つまり、同じデータセットで2回実行しても影響はありません。
REORG TABLEを実行した後も、ソフトデリートされたデータは古いファイルに残る場合があります。古いファイルを物理的に削除するには、VACUUMを実行できます。

注：Databricksは、デリーションベクトルを使用して、フォトン対応のコンピューティングに関する更新の予測I/Oを強化します。公式ドキュメント—予測I/Oを使用して更新を加速するについて詳しくはこちらをご覧ください。

削除ベクトルを使用するタイミングはいつですか？

削除操作を行う際に削除ベクトルがもたらす最適化効果を考慮すると、それは明らかな選択肢とされるかもしれませんが、削除ベクトルを使用する際にはいくつかのトレードオフが考慮される必要があります。

書き込み頻度とレイテンシ SLA：書き込み頻度が高い場合や低い書き込みレイテンシが必要な場合、特に小規模なデータ変更が従来のCopy-on-Writeモードで大きな書き込み増幅を引き起こす場合には、削除ベクトルを使用してください。書き込み頻度が低く、柔軟なレイテンシ要件を持つシナリオでは、削除ベクトルはあまり有利ではありません。
読み取り頻度とレイテンシ SLA：高読み取りのシナリオでは、追加の削除ベクトルファイルを処理するための追加の実行時間の累積コストが増える可能性があるため、削除ベクトルを使用する際は注意が必要です。
データレイアウトと変更分布：削除ベクトルは、データの変更が多数のファイルに広がっている場合に優れた効果を発揮します。従来のCopy-on-Writeメソッドで生じる書き込み増幅は非常に高額なため、データ変更の一致する述語に特に注意を払ってください。Leviライブラリでは、基になるファイルの統計情報に簡単にアクセスするためのヘルパーメソッドが提供されています。

制限事項：

Databricksは、Databricks SQLまたはDelta Live Tablesを使用してストリーミングテーブルに削除ベクトルを有効にしないことを推奨しています。

Databricks Runtime 12.1以降では、以下の制限が存在します：

削除ベクトルが有効なテーブルではDelta Sharingはサポートされていません。
削除ベクトルのあるテーブルに対してはマニフェストファイルを生成することはできません。REORG TABLE ... APPLY (PURGE)を実行し、マニフェストを生成するために同時実行中の書き込み操作がないことを確認してください。
削除ベクトルが有効なテーブルに対しては、増分でマニフェストファイルを生成することはできません。

結論：

これらすべてを確認することで、私にとっては学びの機会であり、ここで書いているものではありませんが、DatabricksとDeltaのページを参照しています。それらは素晴らしいです。以下に参照のために共有します：

学びを楽しんでください… Muttineni Sai Rohith 署名…

We will continue to update VoAGI; if you have any questions or suggestions, please contact us!

AzureAzure DevopsData EngineeringData warehouseDatabricks

Was this article helpful?

93 out of 132 found this helpful