ACID對Databricks有什麼保證?

如何在Databricks上確定事務的範圍?

Databricks在表級管理事務。事務總是一次應用於一個表。為了管理並發事務，Databricks使用了樂觀並發控製。這意味著對表的讀寫沒有鎖，不可能出現死鎖。

默認情況下，Databricks提供讀取和快照隔離write-serializable隔離上寫道。可寫序列化隔離提供了比快照隔離更強的保證，但它僅將這種更強的隔離應用於寫。

引用多個表的讀操作返回訪問時每個表的當前版本，但不會中斷可能修改引用表的並發事務。

數據庫沒有開始/結束允許將多個操作分組為單個事務的構造。修改多個表的應用程序以串行方式將事務提交到每個表。可以將針對表的插入、更新和刪除組合到單個寫事務中合並成．

Databricks如何實現原子性?

事務日誌控件提交原子性。在事務處理期間，數據文件被寫入支持表的文件目錄。當事務完成時，一個新條目被提交到事務日誌中，其中包括事務期間寫入的所有文件的路徑。每次提交都會增加表的版本，並使新的數據文件對讀操作可見。表的當前狀態包括事務日誌中標記為有效的所有數據文件。

除非事務日誌記錄新版本，否則不跟蹤數據文件。如果事務在將數據文件寫入表後失敗，這些數據文件不會破壞表狀態，但這些文件不會成為表的一部分。的真空操作將刪除表目錄中所有未跟蹤的數據文件，包括來自失敗事務的剩餘未提交文件。

Databricks如何實現持久性?

Databricks采用雲對象存儲技術存儲所有數據文件和事務日誌。雲對象存儲具有較高的可用性和持久性。由於事務要麼完全成功，要麼完全失敗，並且事務日誌與雲對象存儲中的數據文件一起存在，因此Databricks上的表繼承了雲對象存儲的持久性保證。

Databricks如何實現一致性?

Delta Lake使用樂觀並發控製在寫操作之間提供事務保證。在這種機製下，寫操作分為三個階段:

1. 讀:讀取(如果需要)該表的最新可用版本，以確定需要修改(即重寫)哪些文件。

   • 僅追加的寫操作在寫入前不讀取當前表狀態。模式驗證利用來自事務日誌的元數據。

2. 寫:將數據文件寫入定義表的目錄。

3. 驗證和提交：

   • 檢查建議的更改是否與自讀取快照以來可能已並發提交的任何其他更改衝突。

   • 如果不存在衝突，則將所有階段性更改作為一個新的版本快照提交，寫入操作將成功。

   • 如果存在衝突，則寫入操作失敗，並發修改異常。此失敗可防止數據損壞。

樂觀並發性假設數據上的大多數並發事務之間不會發生衝突，但衝突是可能發生的。看到數據庫上的隔離級別和寫入衝突．

Databricks如何實現隔離?

Databricks默認對所有表的寫和更新使用可寫序列化隔離。快照隔離用於所有表讀取。

寫可串行性和樂觀並發控製一起工作，為寫提供高吞吐量。表的當前有效狀態總是可用的，並且可以在任何時候對表開始寫操作。並發讀僅受metastore和雲資源吞吐量的限製。

看到數據庫上的隔離級別和寫入衝突．

Delta Lake是否支持多表事務?

Delta Lake不支持多表事務。Delta Lake支持表格的水平。

Databricks上的主鍵和外鍵關係是信息性的，不是強製的。看到聲明主鍵和外鍵的關係．

Delta Lake支持多集群寫是什麼意思?

Delta Lake可以防止多個集群並發寫入同一個表時發生數據損壞。一些寫操作可能在同時執行期間發生衝突，但不會損壞表。看到數據庫上的隔離級別和寫入衝突．