Liquid Clustering 号称四类负载赢三类，其实只测了三类

表该按日期分区、做 ZOrder，还是改成 Liquid Clustering？InfoQ 10 月 24 日刊出 Kushal Kumar Vishwakarma 的一篇基准，把三种布局放在同一份数据上比了四类查询。¹用 Databricks 的团队很值得读，但数字要逐行看。

同一份 5,000 万行，三种摆法

数据是约 5,000 万条合成零售交易。分区表按交易日期 txn_date 分目录；ZOrder 和 Liquid Clustering 用同样三个键：customer_id、region、txn_date。每条查询跑 5 次，关掉缓存，取耗时和读取量的中位数。²ZOrder 每多一个键，效果就弱一些；⁴Liquid Clustering 的 OPTIMIZE 是增量的，键也能随时改。³

三类查询，各有赢家

• 查一个客户（W1）：Liquid Clustering 1.003 秒，比分区快 49%。ZOrder 读得最少，却慢了 0.4 秒，读取量少不等于快。²
• 查一个月（W2）：日期在 ZOrder 键里排第三，结果比按日期分区慢 78%。¹如果你的 ZOrder 键里日期不在第一位，时间范围查询值得先测一遍。Liquid Clustering 读的数据和分区一样多，却快了约 37%。²
• 三列一起过滤（W3）：Liquid Clustering 唯一输掉的一类，慢近五倍、多读约十倍。¹分区和 ZOrder 只差 7 毫秒，这一类的教训是“别用 Liquid Clustering”。²

第四类“全表聚合”的数字，和第二类一模一样

原文的第四类负载是不带过滤、按地区汇总的全表聚合，结论也是 Liquid Clustering 最快（659 毫秒），ZOrder 最慢（1.845 秒），分区居中（1.038 秒）。¹但这三组耗时和读取量与只查一个月的 W2 逐项相同，7 月 15 日 Medium 初版就已如此。⁵文章和代码里都找不到 W4 单独运行的记录，这一项暂时不能当作比较依据。²

三种布局，一张表比清楚

Databricks 也建议新表都用 Liquid Clustering。³但真正的答案在自己的查询历史里，可以分四步：

1. 从查询历史里按过滤列给查询分组，挑出次数最多的三类；
2. 抽一份带着真实热点和偏斜的样本数据，按三种布局各建一张表；
3. 每条查询关掉缓存跑五次，取中位数，在查询画像里同时记下耗时和读取量；作者的代码在 GitHub 上，可以直接改；²
4. 补上文章没测的两项：全表聚合，以及每天写入后维护布局要花多少计算。