跳过数据

注意

在 Databricks Runtime 13.3 及更高版本中,Databricks 建议对表布局使用液体聚类分析。 群集与 Z 排序不兼容。 请参阅对表使用 liquid 聚类分析

当您将数据写入 Delta Lake 或托管 Apache Iceberg 表时,系统会自动收集数据跳过统计信息。 Azure Databricks在查询时使用每文件统计信息(最小值和最大值、null 计数和总记录),以跳过不相关的文件并加快查询速度。

你必须为 ZORDER 语句中使用的列收集统计信息。 请参阅什么是 Z 排序?

指定统计信息列

对于 Unity 目录 外部表,统计信息默认收集在表架构中定义的前 32 列。 对于 Unity Catalog 托管表,文件跳过统计信息会通过预测性优化进行智能选择,且不受 32 列的限制。 预测优化会自动运行 ANALYZE,用于收集统计信息的命令。 Databricks 建议为所有 Unity Catalog 托管表启用预测优化,以简化数据维护并降低存储成本。 请参阅 Unity Catalog 托管表的预测性优化

如果不使用预测优化,可以通过设置下表属性之一来修改将统计信息集合限制为 32 列的行为:

表属性 支持的 Databricks Runtime Description
dataSkippingNumIndexedCols 所有支持的 Databricks Runtime 版本 增加或减少收集统计信息的列数。 这取决于列的顺序。
dataSkippingStatsColumns Databricks Runtime 13.3 LTS 及更高版本 指定为其收集统计信息的列名的列表。 取代了 dataSkippingNumIndexedCols

可以在创建表时或使用 ALTER TABLE 语句设置表属性。 请参阅 表属性参考。 下面的示例修改了默认的统计信息收集行为,以便在指定的列上收集统计信息:

Delta Lake

ALTER TABLE table_name SET TBLPROPERTIES('delta.dataSkippingStatsColumns' = 'col1, col2, col3')

Iceberg 表

ALTER TABLE table_name SET TBLPROPERTIES('iceberg.dataSkippingStatsColumns' = 'col1, col2, col3')

更新这些属性不会自动重新计算现有数据的统计信息。 相反,在表中添加或更新数据时,它会影响将来的统计信息收集行为。 统计信息不用于当前统计信息列列表中不包含的列。

在 Databricks Runtime 14.3 LTS 及更高版本中,如果更改表属性或更改用于统计信息的指定列,则可以手动使用以下命令重新计算表的统计信息:

ANALYZE TABLE table_name COMPUTE DELTA STATISTICS

注意

在统计信息收集期间会截断长字符串。 可以选择从统计信息集合中排除长字符串列,尤其是在这些列不经常用于筛选查询时。

什么是 Z 排序?

注意

Databricks 建议对所有新表使用液体聚类分析。 不能将 ZORDER 与液体聚类结合使用。 请参阅对表使用 liquid 聚类分析

Z 排序是并置同一组文件中的相关信息的方法。 Azure Databricks 数据跳过算法会自动利用这种共局域性。 此行为可减少需要读取的数据量。 要对数据进行 Z 顺序排序,请在 ZORDER BY 子句中指定排序的列:

OPTIMIZE events
WHERE date >= current_timestamp() - INTERVAL 1 day
ZORDER BY (eventType)

如果希望在查询谓词中常规使用某一列,并且该列具有较高的基数(即包含多个非重复值),请使用 ZORDER BY

可以将 ZORDER BY 的多个列指定为以逗号分隔的列表。 但是,每个额外列的有效性都会下降。

Databricks 建议不要对未收集统计信息的列使用 ZORDER BY ,因为它无效,并且使用了不必要的计算资源。 数据跳过需要列级统计信息,例如最小值、最大值和计数。 可通过对架构中的列重新排序来对某些列配置统计信息收集,也可增加从中收集统计信息的列数。

注意

  • Z 排序不是幂等的,但其目标是成为一种增量操作。 无法保证经过多次运行后,Z 排序所需的时间会缩短。 但是,如果未向仅按 Z 排序的分区添加新数据,则该分区的另一个 Z 排序没有任何影响。

  • Z 排序旨在生成在元组数量上分布均衡的数据文件,但在存储大小方面不一定均衡。 尽管文件大小与元组数量相关,但在某些情况下,这种相关性可能并不成立,从而导致优化任务耗时出现偏差。

    例如,如果 ZORDER BY日期 和最近记录的宽度(例如数组或字符串值)都比过去大得多, OPTIMIZE 作业的任务工期和生成的文件大小可能会偏斜。 但是,这只是命令本身的问题 OPTIMIZE ;它可能对后续查询没有任何负面影响。