InfoQ

Article: When Should You Use Liquid Clustering? Benchmarking Lakehouse Layout Strategies

6.9内容质量
Article: When Should You Use Liquid Clustering? Benchmarking Lakehouse Layout Strategies

TL;DR · AI 摘要

When Should You Use Liquid Clustering? Benchmarking Lakehouse Layout Strategies - InfoQ InfoQ Homepage Articles When Sho...

核心要点

  • 主题聚焦：Article: When Should You Use Liquid Clustering?
  • 来源：InfoQ，建议结合原文判断细节。
  • AI 分析暂不可用，本条为保底评分与摘要。
#AI#编程#云计算#安全#产品
打开原文

何时应使用 Liquid Clustering？湖仓一体布局策略基准测试 - InfoQ

InfoQ 首页 Articles 何时应使用 Liquid Clustering？湖仓一体布局策略基准测试

AI、机器学习与数据工程

从 Token 到 Features：构建 AI 辅助工程的成本归因架构（10 月 29 日网络研讨会）

何时应使用 Liquid Clustering？湖仓一体布局策略基准测试

2026 年 10 月 12 日 9 分钟阅读

作者：

  • Kushal Kumar Vishwakarma

审阅者：

  • Renato Losio

#### 关注我们

YouTube

232K 粉丝

LinkedIn

26K 粉丝

Instagram

新

RSS

19K 读者

X

57.1k 粉丝

Facebook

21K 点赞

Bluesky

收听本文 -

0:00

音频准备就绪

您的浏览器不支持音频元素。

正常

1.25x

1.5x

喜欢

新下拉阅读列表

  • 阅读列表

关键要点

  • 没有一种存储布局在湖仓一体分析中是普遍最优的：最佳选择取决于工作负载，因为错误使用 Liquid Clustering、ZOrder 或 Partitioning 会显著影响成本和延迟。
  • ZOrder 存在隐藏的故障模式。当日期列作为二级或三级聚类键时，时间范围查询的性能显著劣于简单日期分区表。
  • 扫描字节数是一个具有误导性的性能指标。尽管扫描的原始数据量多于 ZOrder，Liquid Clustering 在点查询上仍能实现最低延迟。
  • 对于查询模式多样或不断演变的团队，应将 Liquid Clustering 作为默认选择。在大多数工作负载中，Liquid Clustering 的性能优于 ZOrder，同时消除了手动 OPTIMIZE 作业和周期性全表重写的操作负担。
  • 在确定任何布局策略之前，请自问：”我的主要查询是否始终过滤相同的两到三列？如果答案是肯定的，请对这些列使用 ZOrder。否则，请选择 Liquid Clustering。

引言

没有一种存储布局在湖仓一体分析系统中是普遍最优的。在 Delta Lake 上对四种工作负载类型的基准测试中，Liquid Clustering 在点查询、时间范围聚合和大规模聚合中实现了最低延迟。对于查询模式多样或不断演变的团队，应将 Liquid Clustering 作为默认选择。ZOrder 仅在稳定且高度选择性的多列谓词工作负载中表现更好，且过滤列与聚类键完全匹配。Partitioning、ZOrdering 和 Liquid Clustering 在磁盘上组织数据的方式存在根本性差异；理解这些权衡是为您的工作负载选择合适方案的关键。我的两个发现尤其引人注目，因为它们与这些布局通常的描述相悖，且可能是当前生产系统中悄然退化的问题。

ZOrder 在日期范围上的隐藏故障模式

当日期列作为 ZOrder 聚类表达式中的二级或三级键时，时间范围查询的性能显著劣于简单的日期分区表，在此基准测试中慢了 78%。顺序日期值分散在多个文件中，破坏了分区提供的免费范围扫描效率。如果您的团队在多列上进行了 ZOrder 聚类且日期不是首要键，这几乎肯定会影响您的时间范围查询性能。

Liquid Clustering 在多列过滤器上的精度差距

当查询谓词精确匹配一组稳定的过滤列时，ZOrder的文件剪枝接近最优，而Liquid Clustering在扫描十倍数据量时速度可能慢近五倍。Liquid Clustering更广泛的局部性优化以确定性剪枝为代价换取工作负载灵活性。这种权衡在查询狭窄且可预测时会成为明显缺陷。

#### 相关赞助商

#### 相关赞助商

2026年12月15-16日。探讨资深从业者如何在生产环境中运行代理、评估、模型服务和AI辅助工程，包括哪些失败案例和发生了哪些变化。立即注册。

这些结果具有重要意义，因为物理数据布局是湖仓工程中最关键且最常被忽视的决策之一，而分区、ZOrdering和Liquid Clustering之间的权衡通常以概念性描述为主，而非实际测量。

大多数已发表的比较要么来自Databricks自身，要么从第一性原理推导权衡关系，而未测量实际查询行为。本次基准测试背后的问题直接源于我在TCS UK（民用航空航天）和IBM（Shell Maritime）构建Delta Lake平台时遇到的生产挑战，其中布局决策直接影响流水线SLA合规性和云计算成本。

在确定布局策略前，我的实践建议是：使用自己数据的代表性样本，针对前三种查询模式分别在分区、ZOrder和Liquid Clustering三种配置下运行。下述结果来自受控基准测试，该测试在包含5000万条记录的数据集上，通过真实Databricks查询配置文件，对四种分析工作负载类型的所有三种布局策略进行了比较，这些结果可能与我一样让你感到意外。

#### 实际应用中的含义

综合来看，这些结果勾勒出一个基于工作负载类型的清晰决策框架：

| 工作负载类型 | 最佳布局 | 原因 | |------------------|------------|------------------------------| | 点查询 | Liquid Clustering | 优越的文件内局部性减少寻道开销 | | 时间范围聚合 | 顺序局部性优于ZOrder的分散日期值 | | 多列选择性过滤 | ZOrder | 精确的文件剪枝扫描数据量减少10倍 | | 大规模聚合 | Hilbert曲线局部性在全扫描工作负载中胜出 |

本文最具行动价值的洞察可能是一个看似简单的诊断问题：在确定任何布局策略前，从业者应自问：我的核心查询是否始终在相同的两到三列上进行过滤？这个问题的答案本身就能决定组合分区是否能带来实质性收益或引入不必要的复杂性。

如果答案是肯定的且这些列已知且稳定，请在这些列上精确使用ZOrder，确保最选择性列优先列出。如果答案是否定的，或查询模式可能演变，请将Liquid Clustering作为默认方案。Liquid Clustering在四种工作负载类型中有三种表现更优，并消除了手动OPTIMIZE调度的操作开销。GitHub上提供了一个Python编写的决策辅助工具。

以下章节将阐述这些建议的方法论、结果和分析，为希望在应用前验证发现的读者说明"如何"和"为何"。

实验设置

以下是分析中使用的数据集、布局配置、工作负载和结果：

数据集

/

一个包含五千万条记录的合成事务数据集被生成，用于模拟零售购买环境，其结构如下：

code
customer_id   INT         均匀分布，范围 12,000,000
txn_date      DATE        跨度 2019-2023
region        STRING      分类：EU, US, APAC, LATAM（偏向 EU/US）
amount        FLOAT      右偏分布，模拟高价值异常值
product_cat   STRING    分类，12 个分类

均匀分布与偏态分布的混合是经过精心设计的，参数校准基于生产环境追踪中实际观察到的访问频率模式。具体而言，选择 Zipf α = 1.2 的偏态参数以及 80/20 热点分区划分，是为了匹配真实工作负载中查询量的分布情况。这些数值并非随意选择，而是源自生产环境遥测数据，其中前 20% 的客户分段始终占约 80% 的查询流量，确保合成数据集能反映现实世界的热点分区和需求偏态。

布局配置

code
分区表
df.write.format('delta').partitionBy('txn_date').saveAsTable('lc_partitioned')

ZOrder 表
spark.sql('OPTIMIZE lc_zorder ZORDER BY (customer_id, region, txn_date)')

Liquid Clustered 表
spark.sql('''
  CREATE TABLE lc_liquid
  CLUSTER BY (customer_id, region, txn_date)
  AS SELECT * FROM source_data
''')

工作负载

所有查询均可在 GitHub 上找到。

结果

#### W1: 点查询

Liquid Clustering 在 1.003 秒内实现了最低延迟，尽管扫描的原始数据量多于 ZOrder，但比分区基线快了 49%。这是第一个反直觉的结果，表明读取更多字节反而带来了更好的性能。解释在于文件内的顺序局部性。Liquid Clustering 的 Hilbert 曲线组织方式更有效地将相关 customer_id 值定位在文件内，减少了磁盘寻道开销并提高了扫描吞吐量。ZOrder 通过文件剪枝减少了读取字节数，但访问更多文件的开销抵消了这一优势。

| 布局 | 运行时间（中位数） | 数据读取量 | 备注 | |------------|------------------|------------|--------------------| | 分区表 | 1.972s | 737.47 MB | 基线 | | 分区表 | 1.437s | 369.09 MB | 50% 数据量更少，但更慢 | | Liquid Clustering | 1.003s ✓ | 784.86 MB | 最佳延迟 |

#### W2: 时间范围聚合

Liquid Clustering 再次以 659 毫秒的最低延迟取得最佳表现。ZOrder 相对于分区基线表现不佳：ZOrder 用时 1.845 秒，而分区方案仅需 1.038 秒，慢了 78%。ZOrder 的聚类键是 (customer_id, region, txn_date)，使 txn_date 成为三级键。这会将连续日期值分散到多个文件中，破坏了简单分区方案本可免费提供的日期范围扫描效率。如果团队在多个列上使用 ZOrder 且日期不是首要键，这几乎肯定会影响时间范围查询性能。

1s 038ms | 449.69 MB | 日期分区帮助 1s 845ms | 306.80 MB | 比分区慢 78% 659ms ✓ | 449.19 MB

图 1a. 范围聚合，分区表。来源 [此处](链接) 图 1b. 范围聚合，ZOrder 表。来源 [此处](链接) 图 1c. 范围聚合，Liquid Clustered 表。来源 [此处](链接)

#### W3: 多列选择性过滤

This workload produced the sharpest reversal. ZOrder achieved 615 milliseconds and read only 59.03 megabytes. Liquid Clustering took 2.967 seconds and read 639.95 megabytes, nearly five times slower and scanning ten times more data. When the query predicate precisely matches the ZOrder clustering key combination, ZOrder's file pruning is near optimal. Liquid Clustering's broader locality optimization, designed for workload diversity, becomes a liability here, because it cannot achieve the same level of precise file elimination unlike ZOrder, which locks onto a fixed column order to eliminate files precisely, Liquid Clustering trades that precision for flexibility and on this workload, that tradeoff costs it. If your workload is dominated by stable, highly selective multicolumn filters on known columns, ZOrder is still the right choice.

622ms

128.09 MB

Moderate pruning

615ms ✓

59.03 MB ✓

Optimal pruning

2.967s

639.95 MB

5x slower worst case

图2a。多列过滤分区表。来源：此处

图2b。多列过滤有序表。来源：此处

图2c。多列过滤液态聚类表。来源：此处

#### W4: 大规模聚合

对于整个数据集按区域进行SUM聚合（使用与W2相同的查询，但未在全数据集上应用谓词过滤以明确基准数值），液态聚类再次实现了最低延迟（659毫秒），而ZOrder最慢（1.845秒）。在全表扫描工作负载中，文件剪枝没有优势；性能决定因素转向文件内读取效率和任务调度，这两方面都更有利于液态聚类的希尔伯特曲线局部性。

可接受

无剪枝优势最慢

讨论

所有四个工作负载的结果都由相同的两种机制解释：文件剪枝效率（布局避免读取的数据量），以及文件内局部性（读取数据被扫描的效率）。ZOrder和分区主要在剪枝方面竞争。液态聚类主要通过希尔伯特曲线组织在局部性方面胜出，即使它读取的字节数比ZOrder更多。当查询精确匹配稳定聚类键时，剪枝占主导地位，ZOrder胜出（W3）。当查询不匹配，或必须进行全表扫描时，局部性占主导地位，液态聚类胜出（W1, W2, W4）。ZOrder的日期范围失效模式（W2）是剪枝与局部性权衡的另一面。将日期设为三级键会牺牲日期分区提供的免费顺序局部性，而无法获得足够的剪枝优势来弥补。

注意事项

这些基准测试使用合成数据集以确保可重复性并避免暴露客户数据。实际生产数据集包含额外复杂性、模式漂移、访问模式季节性和领域特定偏斜，这些因素可能改变每种布局的相对性能。此处呈现的发现应作为方向性指南，并在做出不可逆的模式决策前，需根据您自己的工作负载配置进行验证。

此外，我没有测量I/O的写放大成本以及维护每种布局时新数据到达带来的计算开销。液态聚类的增量方法在写入时间成本上低于ZOrder的周期性全表重写，但这一点未经过实验测量，需要单独研究。

结论

No single storage layout is universally optimal for lakehouse analytical systems. Liquid Clustering outperforms on latency for point lookups, range scans, and large aggregations, and should be the default for teams with diverse or evolving workloads. ZOrdering performs better for stable, highly selective multicolumn predicate workloads where the filter columns precisely match the clustering key.

The two most practically significant findings, ZOrder's degradation on range scans when date is a secondary key, and Liquid Clustering's five times latency penalty on precise multicolumn filters, are failure modes that are not documented and are likely affecting production systems today.

Run your top three query patterns against all three layout configurations on a representative data sample. The results may surprise you.

main wrapper for authors section

About the Author

section title

main wrapper for each author

#### Kushal Kumar Vishwakarma

Show more

Show less

#### This content is in the AI, ML & Data Engineering topic

##### Related Topics:

  • Architecture & Design
  • AI, ML & Data Engineering
  • Performance Evaluation
  • Clustering & Caching
  • Infrastructure
  • application performance management
  • Query
  • Performance
  • Data Storage
  • Benchmark
  • Data Lake
  • Related Editorial
  • Popular across InfoQ OpenTelemetry Makes Kubernetes Attributes Processor Stable as Observability Schema Matures Akka Tests Spec-Driven AI Delivery across 65 Open Source Projects Github Migrates Copilot Runtime to Rust with AI-Assisted Rewrite Survey Finds AI-Generated Code Increases Debugging and Failure Rates and Creates a Comprehension Gap The Minimum Viable Manager: Building Trust, Feedback, and Alignment Cloudflare Traces Turns the Proxy Layer into OpenTelemetry Spans, with New Volume-Based Pricing

The InfoQ Newsletter

A round-up of last week’s content on InfoQ sent out every Tuesday. Join a community of over 250,000 senior developers. View an example

We protect your privacy.