Azure Databricks 中的存档支持

项目
04/18/2024

重要

此功能在 Databricks Runtime 13.3 LTS 及更高版本中作为公共预览版提供。

Azure Databricks 中的存档支持引入了一系列功能，使你能够在包含 Delta 表的云对象存储上使用基于云的生命周期策略。

如果没有存档支持，对 Delta 表执行的操作可能会中断，因为数据文件或事务日志文件已移动到存档位置，在查询时不可用。存档支持引入了优化，尽可能避免查询已存档的数据，并增加了新语法来标识必须从存档还原以完成查询的文件。

重要

Azure Databricks 仅为 Azure 存档提供存档支持。请参阅关于通过生命周期管理优化成本的 Azure 文档。

存档数据的查询优化

Azure Databricks 中的存档支持针对 Delta 表优化以下查询：

查询	新行为
`SELECT * FROM <table_name> LIMIT <limit> [WHERE <partition_predicate>]`	自动忽略已存档的文件，并从非存档存储层中的数据返回结果。
Delta Lake 维护命令：`OPTIMIZE`、`ZORDER`、`ANALYZE`、`PURGE`	自动忽略已存档的文件，并对表的其余部分运行维护。
覆盖数据或删除数据的 DDL 和 DML 语句，包括：`REPLACE TABLE`、`INSERT OVERWRITE`、`TRUNCATE TABLE`、`DROP TABLE`	将目标已存档数据文件的事务日志条目标记为已删除。
`FSCK REPAIR TABLE`	忽略已存档的文件，只检查未达到生命周期策略的文件。

请参阅限制。

早期失败和错误消息

对于必须扫描已存档文件以生成正确结果的查询，配置 Delta Lake 的存档支持可以确保：

如果查询尝试访问存档中的文件，则会提前失败，从而减少浪费的计算并允许用户快速调整和重新运行查询。
错误消息通知用户查询失败，因为查询尝试访问已存档的文件。

用户可以使用 SHOW ARCHIVED FILES 语法生成需要还原的文件的报告。请参阅显示已存档的文件。

启用存档支持

可以通过手动指定基础云生命周期管理策略中配置的存档间隔来启用 Azure Databricks 中对 Delta 表的存档支持，如以下示例语法所示：

ALTER TABLE <table_name> SET TBLPROPERTIES(delta.timeUntilArchived = 'X days');

Delta Lake 不会直接与云帐户中配置的生命周期管理策略交互。如果更新云帐户中的策略，则必须更新 Delta 表的策略。请参阅更改生命周期管理转换规则。

重要

存档支持完全依赖于兼容的 Azure Databricks 计算环境，仅适用于 Delta 表。配置存档支持不会更改 OSS Delta Lake 客户端或 Databricks Runtime 12.2 LTS 及更低版本的行为、兼容性或支持。

显示已存档的文件

若要标识需要还原以完成给定查询的文件，请使用 SHOW ARCHIVED FILES，如以下示例所示：

SHOW ARCHIVED FILES FOR table_name [ WHERE predicate ];

此操作以 Spark 数据帧的形式返回已存档文件的 URI。

注意

在此操作期间，Delta Lake 只能访问事务日志中包含的数据统计信息（前 32 列的最小值、最大值、Null 计数和记录总数）。返回的文件包括需要读取的所有已存档的文件，以确定文件中是否存在满足谓词的记录。 Databricks 建议提供包含对数据进行分区、z 排序或聚类分析的字段的谓词（如果可能），以减少需要还原的文件数量。

限制

存在以下限制：

不支持不基于文件创建时间的生命周期管理策略。包括基于访问时间的策略和基于标记的策略。
不能在包含已存档文件的表上使用 DROP COLUMN。
REORG TABLE APPLY PURGE 发挥最佳工作状态，但仅适用于未存档的删除矢量文件和引用数据文件。 PURGE 无法删除已存档的删除矢量文件。
延长生命周期管理转换规则会导致意外行为。请参阅延长生命周期管理转换规则。

更改生命周期管理转换规则

如果更改云生命周期管理转换规则的时间间隔，则必须更新 delta.timeUntilArchived 属性。

如果存档前的时间间隔缩短（自文件创建后的时间缩短），则更新表属性后，Delta 表的存档支持将继续正常运行。

延长生命周期管理转换规则

如果存档前的时间间隔延长（自文件创建后的时间延长），则将 delta.timeUntilArchived 属性更新为新值可能会导致错误。更改数据保留策略时，云提供商不会自动将文件从已存档的存储中还原。这表示之前符合存档条件，但现在被视为不符合存档条件的文件仍会存档。

重要

为避免错误，请勿将 delta.timeUntilArchived 属性的值设置为大于最近已存档数据的实际存在时长。

假设存档的时间间隔从 60 天更改为 90 天：

当策略更改时，60 到 90 天以前的所有记录均已存档。
30 天内，不会存档任何新文件（当策略延长时，最早的非存档文件已存在 60 天）。
30 天后，生命周期策略会正确描述所有已存档的数据。

delta.timeUntilArchived 设置会根据 Delta 事务日志记录的文件创建时间跟踪设置的时间间隔。它对基础策略没有明确的了解。在旧存档阈值和新存档阈值之间的滞后期间，可以采取以下方法之一来避免查询已存档的文件：

可以将 delta.timeUntilArchived 设置保留为旧阈值，直到经过足够的时间，所有文件都已存档。
- 按照上面的示例，前 30 天内每天的数据将被视为已由 Azure Databricks 存档，但尚未由云提供商存档。这不会导致错误，但会忽略一些可以查询的数据文件。
- 30 天后，将 delta.timeUntilArchived 更新为 90 days。
可以每天更新 delta.timeUntilArchived 设置，以反映滞后期间的当前间隔。
- 虽然云策略设置为 90 天，但已存档数据的实际存在时长会实时变化。例如，在 7 天后，将 delta.timeUntilArchived 设置为 67 days 可准确反映存档中所有数据文件的存在时长。
- 仅当需要访问热存储层中的所有数据时，才需要此方法。

注意

更新 delta.timeUntilArchived 的值实际上不会更改存档的数据，只会更改被 Azure Databricks 视为已存档的数据。

通过