Azure Databricks での ACID 保証とは

  • [アーティクル]

Azure Databricks は、既定ですべての読み取りと書き込みに Delta Lake を使用し、オープン ソースの Delta Lake プロトコルによって提供される ACID の保証に基づいてビルドします。 ACID は、atomicity (アトミック性)、consistency (一貫性)、isolation (分離性)、durability (持続性) を表します。

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

多くのデータ処理およびウェアハウス テクノロジでは ACID トランザクションの存在について記述していますが、具体的な保証はシステムによって異なり、Azure Databricks でのトランザクションは、読者が扱ったことがある他のシステムとは異なる場合があります。

注意

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

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

Azure Databricks でトランザクションのスコープはどうなるか

Azure Databricks では、テーブル レベルでトランザクションを管理します。 トランザクションは常に、一度に 1 つのテーブルに適用されます。 同時実行トランザクションを管理するために、Azure Databricks ではオプティミスティック同時実行制御を使用します。 つまり、テーブルに対する読み取りまたは書き込みにロックがなく、デッドロックが発生する可能性はありません。

Azure Databricks では既定で、読み取りにはスナップショット分離が、書き込みには WriteSerializable 分離が提供されます。 WriteSerializable 分離では、スナップショット分離よりも強力な保証が提供されますが、その強力な分離は書き込みのみに適用されます。

複数のテーブルを参照する読み取り操作では、アクセス時点の各テーブルの最新バージョンが返されますが、被参照テーブルを変更する可能性がある同時実行トランザクションは中断されません。

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

Azure Databricks で原子性はどのように実装されるか

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

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

Azure Databricks で持続性はどのように実装されるか

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

Azure Databricks で整合性はどのように実装されるか

Delta Lake では、オプティミスティック同時実行制御を使用して、書き込み間のトランザクションが保証されます。 このメカニズムでは、書き込みは次の 3 つの段階で動作します。

  1. 読み取り: 変更する (つまり、書き換える) 必要があるファイルを識別するために、使用可能な最新バージョンのテーブルを読み取ります (必要な場合)。
    • 追加のみの書き込みは、書き込みの前に現在のテーブルの状態を読み取りません。 スキーマの検証では、トランザクション ログのメタデータが利用されます。
  2. 書き込み: テーブルの定義に使用されるディレクトリにデータ ファイルを書き込みます。
  3. 検証とコミット:
    • 提案された変更が、読み取られたスナップショット以降に同時にコミットされた可能性がある他の変更と競合するかどうかを確認します。
    • 競合がない場合、ステージされている変更はすべて新しいバージョン管理されたスナップショットとしてコミットされ、書き込み操作は成功します。
    • 競合がある場合、書き込み操作は同時変更例外で失敗します。 このエラーにより、データの破損を防ぎます。

オプティミスティック同時実行では、データに対するほとんどの同時実行トランザクションは互いに競合しないものと想定しますが、競合が発生する可能性はあります。 Azure Databricks での分離レベルと書き込みの競合に関するページを参照してください。

Azure Databricks で分離はどのように実装されるか

Azure Databricks では、すべてのテーブル書き込みと更新に WriteSerializable 分離が既定で使用されます。 すべてのテーブル読み取りにはスナップショット分離が使用されます。

書き込みのシリアル化可能性とオプティミスティック同時実行制御の連動により、高い書き込みスループットを実現します。 テーブルの現在の有効状態をいつでも確認でき、いつでもテーブルに対して書き込みを開始できます。 同時読み取りは、メタストア リソースとクラウド リソースのスループットにのみ制限されます。

Azure Databricks での分離レベルと書き込みの競合に関するページを参照してください。

Delta Lake では複数テーブルのトランザクションをサポートしているか

Delta Lake では、複数テーブルのトランザクションはサポートされていません。 Delta Lake では、"テーブル" レベルのトランザクションをサポートします。

Azure Databricks の主キーと外部キーの関係は情報であり、適用されません。 「主キーと外部キーのリレーションシップを宣言する」 を参照してください。

Delta Lake がマルチクラスターの書き込みをサポートするとはどういう意味か

Delta Lake は、複数のクラスターで同じテーブルに同時に書き込みが行われる際のデータの破損を防ぎます。 一部の書き込み操作は同時実行中に競合する可能性がありますが、テーブルは破損しません。 Azure Databricks での分離レベルと書き込みの競合に関するページを参照してください。

異なるワークスペースから Delta テーブルを変更することはできるか

はい、同じ Delta テーブルを別々のワークスペースから同時に変更できます。 さらに、1 つのプロセスでワークスペースから書き込みを行っている場合に、他のワークスペースのリーダーには一貫したビューが表示されます。