devgo.cn在湖仓（Lakehouse）架构里，数据在磁盘上怎么摆，直接决定了查询快不快、云账单高不高。但这个问题恰恰是很多团队最不重视、也最说不清的一环。分区（Partitioning）、ZOrder、Liquid Clustering 这三种布局策略，各有各的组织逻辑，选错了代价不小。最近一篇基于 Delta Lake 的实测基准，用 5000 万条记录、四种典型查询负载，把三者的真实差距量化了出来，结果有几个反直觉的地方，值得每个做数据平台的人看看。
先说结论：没有一种布局是万能的。Liquid Clustering 在点查、时间范围聚合、大聚合三类负载上都是最优解；ZOrder 只在一种场景下胜出——查询条件稳定、且过滤列恰好和聚类键精确匹配的多列过滤。而传统分区表，在时间范围查询上依然有它的价值。
最让我意外的是 ZOrder 的一个隐藏失效模式。当日期列在 ZOrder 聚类表达式里排在第二或第三位时，时间范围查询的性能会比简单的按日期分区表慢 78%。原因是 ZOrder 会把顺序的日期值打散到不同文件里，破坏了分区表天然带来的范围扫描效率。如果你的团队在多列上做了 ZOrder 而日期不是第一键，那时间范围查询的性能大概率已经受了影响，只是可能没人意识到是布局的锅。
另一个反直觉的点是“扫描字节数”这个指标会骗人。在点查场景下，Liquid Clustering 扫描的原始数据比 ZOrder 更多，但延迟反而最低，比分区基线快 49%。原因在于 Liquid Clustering 用 Hilbert 曲线（一种把多维数据映射到一维、保持空间邻近性的曲线）组织数据，让相同 customer_id 的值在文件内部更集中，减少了磁盘寻道开销。ZOrder 虽然通过文件剪枝（pruning，即跳过无关文件）减少了读取量，但访问更多文件带来的开销抵消了这个优势。
当然，Liquid Clustering 也不是没有短板。当查询谓词精确匹配一组稳定的过滤列时，ZOrder 的文件剪枝接近最优，Liquid Clustering 可能慢近 5 倍，扫描的数据量多 10 倍。它的更广泛的局部性优化（locality optimization，即让相关数据尽量靠近存储）牺牲了确定性剪枝，换来了工作负载的灵活性。这个权衡在查询窄而可预测时，就成了劣势。
这个基准的测试环境也值得一提。数据集是合成的零售交易数据，5000 万条记录，字段包括 customer_id、txn_date、region、amount、product_cat。分布参数不是随便拍的，而是根据生产环境的遥测数据校准的，比如 Zipf α=1.2、80/20 分区热点，模拟了真实工作负载中前 20% 客户段贡献约 80% 查询流量的情况。测试在 Databricks 上用真实查询 profile 跑，分四种负载：点查、时间范围聚合、多列选择性过滤、大聚合。
综合来看，决策框架其实很清晰：点查用 Liquid Clustering，时间范围聚合用 Liquid Clustering，多列选择性过滤用 ZOrder，大聚合用 Liquid Clustering。但比这个表格更有价值的，是一个简单的诊断问题：你的 Top 查询是否一致地过滤在同样的两到三列上？如果答案是“是”且这些列稳定，那就对这几列做 ZOrder，把选择性最强的列放第一位；如果答案是否定，或者查询模式可能演变，那就默认用 Liquid Clustering。它赢了三类负载，还省去了手动 OPTIMIZE 调度的运维负担。
这个思路能直接用到你自己的场景里。无论你用的是 Delta Lake、Iceberg 还是 Hudi，布局策略的选择逻辑是相通的。建议在定方案前，拿自己的 Top 3 查询模式，在分区、ZOrder、Liquid Clustering 三种配置上各跑一遍，用代表性数据样本验证，而不是听厂商宣传或凭直觉。另外要注意，ZOrder 的多列键顺序很关键，日期列千万别放在非首位；而 Liquid Clustering 虽然省心，但在查询模式极其稳定且窄的场景下，性能代价可能超出预期。物理数据布局是湖仓工程里影响最大、却最少被讨论的决策之一，值得你花一个下午认真测一测。
内容与图片版权归原作者所有 · 原文: https://www.infoq.com/articles/liquid-clustering-lakehouse-layout/?utm_campaign=infoq_content&utm_source=infoq&utm_medium=feed&utm_term=global