Azure Databricks 上的 ACID 保證為何？

根據預設，Azure Databricks 會針對所有讀取和寫入使用 Delta Lake，並以開放原始碼 Delta Lake 通訊協定所提供的 ACID 保證為基礎來建置。 ACID 代表不可部分完成性、一致性、隔離和持久性。

雖然許多數據處理和倉儲技術描述有 ACID 交易，但特定保證會因系統而異，而 Azure Databricks 上的交易可能會與您使用的其他系統不同。

注意

此頁面描述 Delta Lake 所支援之數據表的保證。其他數據格式和整合系統可能無法提供讀取和寫入的交易式保證。

所有 Azure Databricks 寫入雲端物件記憶體都會使用交易式認可，以建立以和_started_<id>_committed_<id>數據文件開頭的元數據檔案。您不需要與這些檔案互動，因為 Azure Databricks 會定期清除過時的認可元數據檔案。

Azure Databricks 上的交易範圍如何？

Azure Databricks 會管理數據表層級的交易。交易一律會一次套用至一個數據表。為了管理並行交易，Azure Databricks 會使用開放式並行控制。這表示對數據表的讀取或寫入沒有任何鎖定，而且死結是不可能的。

根據預設，Azure Databricks 會在寫入時提供讀取和可串行化隔離的快照集隔離。可寫入串行化隔離提供比快照隔離更強的保證，但它只會針對寫入套用更強的隔離。

參考多個數據表的讀取作業會在存取時傳回每個數據表的目前版本，但不會中斷可能修改參考數據表的並行交易。

Azure Databricks 沒有 BEGIN/END 可讓多個作業群組為單一交易的建構。修改多個數據表的應用程式會以序列方式將交易認可至每個數據表。您可以使用將資料表的插入、更新和刪除合併成單一寫入交易 MERGE INTO。

事務歷史記錄會控制認可不可部分完成性。在交易期間，數據檔會寫入備份數據表的檔案目錄。當交易完成時，會將新的項目認可至事務歷史記錄，其中包含交易期間寫入之所有檔案的路徑。每個認可都會遞增數據表版本，並讓讀取作業可以看到新的數據檔。數據表的目前狀態包含事務歷史記錄中標示為有效的所有數據檔。

除非事務歷史記錄檔記錄新版本，否則不會追蹤數據檔。如果交易在將數據檔寫入數據表之後失敗，這些數據檔將不會損毀數據表狀態，但檔案不會成為數據表的一部分。此 VACUUM 作業會刪除資料表目錄中所有未追蹤的數據檔，包括失敗交易中剩餘未認可的檔案。

Azure Databricks 會使用雲端物件記憶體來儲存所有數據檔和事務歷史記錄。雲端物件記憶體具有高可用性和持久性。因為交易成功或失敗，事務歷史記錄會與雲端物件記憶體中的數據檔並存，所以 Azure Databricks 上的數據表會繼承其儲存所在的雲端物件記憶體持久性保證。

Delta Lake 使用開放式平行存取控制來提供寫入之間的交易式保證。在此機制下，寫入會以三個階段運作:

讀取：讀取（如有需要）數據表的最新可用版本，以識別哪些檔案需要修改（也就是重寫）。
- 僅附加的寫入不會在寫入之前讀取目前的數據表狀態。架構驗證會利用事務歷史記錄中的元數據。
寫入：將數據檔寫入至用來定義資料表的目錄。
驗證並認可：
- 檢查建議的變更是否與讀取快照集之後可能同時認可的任何其他變更發生衝突。
- 如果沒有衝突，所有暫存變更都會認可為新版本的快照集，而寫入作業會成功。
- 如果發生衝突，寫入作業會失敗，並出現並行修改例外狀況。此失敗可防止數據損毀。

開放式並行存取假設數據上的大部分並行交易無法彼此衝突，但可能會發生衝突。請參閱 Azure Databricks 上的隔離等級和寫入衝突。

根據預設，Azure Databricks 會針對所有數據表寫入和更新使用可寫入串行化隔離。快照集隔離用於所有數據表讀取。

寫入串行化和開放式並行訪問控制會一起運作，以提供高寫入輸送量。數據表目前的有效狀態一律可供使用，而且可以隨時針對數據表啟動寫入。並行讀取只會受限於中繼存放區和雲端資源的輸送量。

請參閱 Azure Databricks 上的隔離等級和寫入衝突。

Delta Lake 不支援多數據表交易。 Delta Lake 支援數據表層級的交易。

Azure Databricks 上的主鍵和外鍵關聯性是參考性的，不會強制執行。請參閱宣告主鍵和外鍵關聯性。

當多個叢集同時寫入相同數據表時，Delta Lake 可防止數據損毀。某些寫入作業可以在同時執行期間發生衝突，但不會損毀數據表。請參閱 Azure Databricks 上的隔離等級和寫入衝突。

是，您可以從不同的工作區同時修改相同的 Delta 數據表。此外，如果某個程式是從工作區撰寫，其他工作區中的讀取器就會看到一致的檢視。