Databricks过滤与分区列关联字段时的查询性能问题咨询

问题1：上述理解是否正确？ #

你的理解完全正确。
Delta Lake默认会收集每个数据文件前32个列（可通过配置spark.databricks.delta.stats.collecting.maxColumns调整收集范围）的最小值、最大值、空值计数三类统计信息，统一存储在Delta事务日志中。即便你查询时只使用非分区列timestamp做过滤，Databricks SQL也会先读取事务日志里所有文件的timestamp统计信息，直接过滤掉max(timestamp) < 过滤下界或者min(timestamp) > 过滤上界的无效文件，实现数据跳过，不需要扫描全表数据，完全可以获得可观的性能收益。
唯一需要注意的前提是：timestamp字段属于Delta表统计信息的收集列范围内，没有被手动排除统计。

问题2：和直接使用分区列过滤相比，通过上述方式跳过文件的性能损耗大概是多少？ #

两者的性能差异仅存在于元数据处理阶段，实际数据扫描的开销是完全一致的，具体损耗和表的总文件数直接相关：

• 若表的总文件数在万级以内，性能损耗几乎感知不到，通常在10ms~100ms区间，远低于实际数据扫描的开销
• 若表的总文件数达到十万级甚至更高，遍历所有文件统计信息的开销会涨到数百ms到数秒区间，但依然远低于扫描全量数据的成本

而直接使用分区列date过滤的逻辑更轻量：Delta事务日志中直接存储了分区值和对应文件的映射关系，过滤时直接做分区值匹配即可，几乎没有额外元数据处理开销。

问题3：Databricks是否会将所有文件的min/max统计信息存储在内存中，还是每次查询都需要读取对应文件获取该信息？ #

首先可以明确：不需要读取实际数据文件获取统计信息，所有文件的min/max统计信息都固化存储在Delta表的_delta_log目录下的事务日志文件中。
Databricks运行时会将访问过的Delta表的事务日志缓存到驱动节点内存中，只要表没有发生新的写入提交，后续所有查询都会直接复用内存中缓存的统计信息，不需要重复读取事务日志文件。如果表有新的更新提交，只会增量读取新增的事务日志片段更新缓存，不会全量重新加载。

内容的提问来源于stack exchange，提问作者epa095