DatabricksのACID保証とは

Databricksはすべての読み取りと書き込みにデフォルトでDelta Lakeを使用しており、オープンソースのDelta Lakeプロトコルが提供するACID保証に基づいて構築されています。ACIDは、原子性、一貫性、独立性、耐久性の略です。

原子性とは、すべてのトランザクションが成功するか、完全に失敗するかを意味します。
一貫性の保証は、データの特定の状態が同時操作によってどのように監視されるかに関連しています。
独立性とは、同時操作が互いに競合する可能性があることを指します。
耐久性とは、コミットされた変更が永続的であることを意味します。

多くのデータ処理およびウェアハウス技術ではACIDトランザクションの使用について説明していますが、具体的な保証はシステムによって異なり、Databricks でのトランザクションは、これまで使用している他のシステムとは異なる場合があります。

注：

このページでは、Delta Lakeによってバックアップされたテーブルの保証について説明します。他のデータ形式や統合システムでは、読み取りと書き込みのトランザクション保証が提供されない可能性があります。

Databricksによるクラウドオブジェクトストレージへの書き込みのすべてにトランザクションコミットが使われ、 _started_<id> と _committed_<id> で始まるメタデータファイルがデータファイルと併せて作成されます。Databricksは定期的に古いコミットメタデータファイルをクリーンアップするため、これらのファイルを操作する必要はありません。

Databricksにおけるトランザクションのスコープ設定

Databricksは、テーブルレベルでトランザクションを管理します。トランザクションのテーブルへの適用は必ず1つずつ行われます。並列トランザクションの管理には、Databricksは最適同時並列制御を使用します。これは、テーブルに対する読み取りまたは書き込みにロックがなく、デッドロックが発生する可能性がないことを意味します。

既定により、Databricks は読み取り時のスナップショット分離と、書き込み時の書き込みシリアル化可能な分離を提供します。書き込み直列化可能な分離は、スナップショット分離よりも強力な保証を提供しますが、その強力な分離は書き込みにのみ適用されます。

複数のテーブルを参照する読み取り操作は、アクセス時の各テーブルの現在のバージョンを返しますが、参照されるテーブルを変更する可能性のある並列トランザクションは中断されません。

Databricksには、複数の操作を1つのトランザクションとしてグループ化できる BEGIN/END コンストラクタはありません。複数のテーブルを変更するアプリケーションでは、トランザクションは各テーブルに順次コミットされます。MERGE INTO を使用して、テーブルに対する挿入、更新、および削除 1つの書き込みトランザクションに結合できます。

Databricksにおける原子性の実装

トランザクションログはコミットの原子性を制御します。トランザクション中、データファイルはテーブルをバックアップするファイルディレクトリに書き込まれます。トランザクションが完了すると、トランザクション中に書き込まれたすべてのファイルへのパスを含む新しいエントリがトランザクションログにコミットされます。コミットが行われるたびにテーブルのバージョンが増分され、新しいデータファイルが読み取り操作で可視化されます。テーブルの現在の状態は、トランザクションログで有効とマークされたすべてのデータファイルにより構成されます。

トランザクションログに新しいバージョンが記録されない限り、データファイルは追跡されません。テーブルにデータファイルを書き込んだ後にトランザクションが失敗した場合、これらのデータファイルはテーブルの状態を破壊しないものの、ファイルがテーブルの一部になることはありません。VACUUM 操作は、失敗したトランザクション内に残るコミット未処理のファイルを含め、テーブル・ディレクトリ内で追跡されていないデータファイルをすべて削除します。

Databricksにおける耐久性の実装

Databricks は、クラウドオブジェクトストレージを使用して、すべてのデータファイルとトランザクションログを保存します。クラウドオブジェクトストレージは、高い可用性と耐久性を備えています。トランザクションは成功するか完全に失敗するかのいずれかです。また、トランザクションログはクラウドオブジェクトストレージ内のデータファイルとともに保存されるため、Databricks上のテーブルは、テーブルが格納されているクラウドオブジェクトストレージの耐久性保証を継承します。

Databricksにおける一貫性の実装

Delta Lake は最適同時並列制御を使用して、書き込み間のトランザクション保証を提供します。このメカニズムにおける書き込み動作には、以下の3つの段階が含まれます。

読み込み：（必要に応じて）テーブルの利用可能な最新バージョンを読み取り、どのファイルを変更する（書き換える）必要があるかを特定します。
- 追加専用の書き込みでは、書き込み前に現在のテーブルの状態が読み取られることはありません。スキーマ検証では、トランザクションログのメタデータが使用されます。
書き込み：テーブルの定義に使用されたディレクトリにデータファイルを書き込みます。
検証とコミット：
- スナップショットの読み取り以降に並列してコミットされた可能性のある他の変更と提案された変更が競合するかどうかを検証します。
- 競合がない場合、段階的な変更はすべて新しいバージョンのスナップショットとしてコミットされ、書き込み操作は成功します。
- 競合がある場合、書き込み操作は失敗し、並列変更の例外となります。この失敗は、データの破損を防ぎます。

最適同時並列は、データ上のほとんどの並列トランザクション間において競合はないものの、競合が発生する可能性があることを前提としています。「Databricksの分離レベルと書き込み競合」を参照してください。

Databricksにおける独立性の実装

Databricksでは、すべてのテーブルにおける書き込みと更新に対して、書き込みの直列化可能な分離がデフォルトで使用されます。スナップショットの分離は、すべてのテーブル読み取りに使用されます。

書き込みの直列化可能性と最適同時並列制御の連携により、書き込みの高スループットを実現します。テーブルの現在の有効な状態は常に利用可能であり、いつでもテーブルに対する書き込みを開始できます。同時並列読み取りは、メタストアとクラウドリソースのスループットによってのみ制限されます。

「Databricksの分離レベルと書き込み競合」を参照してください。

Delta Lakeにおける複数のテーブルを含むトランザクションのサポート

Delta Lakeは複数のテーブルを含むトランザクションをサポートしていません。単一のテーブルレベルでのトランザクションをサポートします。

Databricks の主キーと外部キーの関係は情報提供を目的としており、強制されません。「主キーと外部キーの関係を宣言する」を参照してください。

Delta Lakeによるマルチクラスターの書き込みサポートとは

Delta Lakeは、複数のクラスターによる書き込みが同じテーブルに対して同時に行われる際にデータ破損を防ぎます。書き込み操作の中には、同時実行中に競合するものもありますが、テーブルが破壊されることはありません。「Databricks上の分離レベルと書き込み競合」を参照してください。

注：

S3上のDelta Lakeには、他のストレージシステムには存在しない制限がいくつかあります。「S3におけるDelta Lakeの制限事項」を参照してください。