一句话结论
Liquid Clustering 在多数湖仓查询中延迟最低，但 ZOrdering 存在日期范围查询性能下降 78% 的隐蔽故障模式。
关键要点
- Liquid Clustering 在点查询、时间范围聚合和大规模聚合三项工作中延迟最低，适合查询模式多变的团队作为默认选项。
- 当查询谓词与 ZOrdering 聚类键精确匹配时，ZOrdering 文件剪枝效果最优，其性能可为 Liquid Clustering 的五倍。
- ZOrdering 将日期作为二级或三级键时，时间范围查询比简单日期分区表慢 78%，因为顺序日期值被分散到多个文件。
- 基准测试使用 5000 万条合成零售交易记录，数据偏度参数（如 Zipf α=1.2）基于生产环境遥测数据校准。
- 作者未测量写入放大和维护计算开销，Liquid Clustering 的增量方法理论上写入成本更低但缺乏实验验证。
背景与事实
这项基准测试源于作者在 TCS 英国分公司（民用航空航天领域）和 IBM（壳牌海事）设计 Delta Lake 平台时遇到的生产挑战，其中数据布局决策直接影响管道 SLA 合规性和云计算成本。测试使用包含 5000 万条记录的合成零售交易数据集，模拟 2019 至 2023 年的购买环境，数据模式包括均匀分布的 customer_id、跨年份的 txn_date、偏态分布的 region（向欧盟和北美倾斜）、右偏的 amount（模拟高价值异常值）以及 12 个产品类别。
测试对比了三种布局策略：按 txn_date 分区的 Delta 表、通过 OPTIMIZE 命令对 (customer_id, region, txn_date) 执行 ZOrder 的表，以及使用 CLUSTER BY 子句创建的 Liquid Clustering 表。工作负载覆盖四类场景：点查询、时间范围聚合、多列选择性过滤和大规模全表聚合。所有查询配置基于真实 Databricks 查询日志，在受控环境中执行。
结果揭示两个反直觉现象：第一，Liquid Clustering 在点查询中扫描的原始数据量比 ZOrdering 更多，却凭借希尔伯特曲线组织方式带来的文件内部顺序局部性，将磁盘寻道开销降至最低，实现 1.003 秒的最快延迟，比分区基线快 49%。第二，ZOrdering 在时间范围聚合中表现最差，耗时 1.845 秒，而简单的日期分区表仅需 1.038 秒，性能差距达 78%。根本原因是 ZOrdering 的聚类键将 txn_date 置于第三级，导致连续的日期值分散在不同文件中，破坏了分区机制天然提供的范围扫描效率。
在多列精确过滤场景中，当查询谓词与 ZOrdering 的聚类键组合完全匹配时，ZOrdering 仅读取 59.03 MB 数据、耗时 615 毫秒；而 Liquid Clustering 读取 639.95 MB 数据、耗时 2.967 秒，速度慢近五倍且扫描量多出十倍。这是因为 ZOrdering 通过固定列顺序实现高精度文件剪枝，而 Liquid Clustering 采用更广泛的局部性优化策略，以牺牲确定性剪枝为代价换取工作负载灵活性。
影响分析
对于中文开发者与数据平台从业者而言，这项测试的核心启示是：物理数据布局是湖仓工程中最深远却最被忽视的决策之一。此前，分区、ZOrdering 和 Liquid Clustering 的权衡多停留在概念层面，缺乏针对实际查询行为的实证数据。本测试填补了这一空白，为团队提供了可操作的决策框架：首先诊断热门查询是否始终基于相同的一到三个稳定列过滤。若答案为是，应仅对这些列使用 ZOrdering 并确保选择性最高的列排在首位；若查询模式多变或不可预测，则应将 Liquid Clustering 设为默认选项。
特别需要警惕的是 ZOrdering 在日期范围查询中的隐性故障模式。许多团队习惯对多列执行 ZOrdering 排序，若日期列未作为第一键，时间范围查询性能将遭受显著拖累，且这种退化往往不易察觉，因为基准测试通常不覆盖该场景。建议从业者在现有系统中审查所有 ZOrdering 表，检查日期字段在聚类键中的位置，必要时改用分区策略或调整键序。作者已在 GitHub 上提供 Python 决策辅助工具，帮助团队快速评估不同布局在自身工作负载下的表现。
适用边界
该结论基于合成数据集，参数虽经生产遥测校准，但无法完全模拟真实世界的复杂性。若生产环境存在显著的模式漂移、访问模式季节性变化或领域特有的数据偏斜，各布局的相对性能可能发生变化。此外，测试未覆盖写入放大和维护开销，对于数据高频追加或更新频繁的场景，Liquid Clustering 的增量维护优势需另行验证。在做出不可逆的模式决策前，必须使用自身代表性数据样本复现测试，重点关注最常用的三种查询模式在三种布局下的表现。
孤本观察
这次基准测试最值得关注的并非哪种布局"最快"，而是揭示了两个未在任何官方文档中记录的故障模式：ZOrdering 日期散列导致的范围查询退化，以及 Liquid Clustering 在精确匹配场景下的性能悬崖。这两个发现提示从业者，湖仓性能优化不能依赖通用最佳实践，而必须基于自身工作负载的实证测量。
常见问题
ZOrdering 在时间范围聚合查询中比日期分区表慢多少？
ZOrdering 耗时 1.845 秒，日期分区表仅需 1.038 秒，性能差距达 78%。
当查询谓词与 ZOrdering 聚类键精确匹配时，其性能相比 Liquid Clustering 如何？
ZOrdering 耗时 615 毫秒，Liquid Clustering 耗时 2.967 秒，ZOrdering 性能约为 Liquid Clustering 的五倍。
Liquid Clustering 在点查询中实现最快延迟的具体原因是什么？
凭借希尔伯特曲线组织方式带来的文件内部顺序局部性，将磁盘寻道开销降至最低，实现 1.003 秒的最快延迟。
基准测试使用的合成零售交易数据集包含多少条记录？
基准测试使用 5000 万条合成零售交易记录。
ZOrdering 导致时间范围查询性能下降的根本技术原因是什么？
ZOrdering 将 txn_date 置于第三级聚类键，导致连续日期值分散在不同文件中，破坏范围扫描效率。
来源：InfoQ 中文 AI