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 对所有表写入和更新使用写可序列化隔离。快照隔离用于所有表读取操作。

写可序列化和乐观并发控制共同为写入操作提供高吞吐量。始终会提供表的当前有效状态，可以随时开始对表进行写入。并发读取仅受元存储和云资源的吞吐量限制。

Delta Lake 不支持多表事务。 Delta Lake 支持 table 级别的事务。

Azure Databricks 上的主键和外键关系是信息性的，不是强制性的。请参阅声明主键和外键关系。

多个群集同时写入同一个表时，Delta Lake 可以防止数据损坏。某些写入操作在同时执行期间可能会发生冲突，但不会破坏表。请参阅 Azure Databricks 上的隔离级别和写入冲突。

是，你可同时从不同的工作区修改同一个 Delta 表。此外，如果从某个工作区编写一个进程，则其他工作区中的读者将看到一致的视图。