驳斥8个数据布局误区：为何 Liquid Clustering 优于分区

引言

数据布局是计算领域最古老的问题之一。

自 Hadoop 和 Hive 出现以来的 15 多年里，分区一直是物理组织数据以进行处理和分析的标准方式。然而，如今的数据湖仓（Lakehouse）需要服务代理、实时数据管道以及不断变化的查询模式，其变化速度远超人类手动重新分区的能力。

**Liquid Clustering** 是现代标准，客户已在各个规模上运行它，包括数十个生产环境中拥有 PB 级表的场景。在本文中，我们将探讨 为什么 Liquid Clustering 在数据湖仓中胜出。同时，我们将 揭穿 8 个常见的数据布局误区，分享 3 个成功案例——团队将分区表转换为 Liquid Clustering 的实践，预览未来功能，并展示如何 快速入门。

为什么 Liquid Clustering 在现代数据湖仓中胜出

Hive 风格的分区要求用户在创建表时就承诺一种物理数据组织方式，这种组织方式会体现在文件结构中。如果选择了一个基数过高的列，就会产生数十亿个微小文件；如果选错了列，查询可能会变慢而非变快。无论哪种情况，你都不得不重写整个表。这种情况非常普遍：根据我们的分析，Hive 风格的分区在超过 75% 的情况下会导致过度分区和小文件问题。

Liquid Clustering 将聚类键视为输入，由引擎利用这些键来指导最优的文件组织。聚类键可以随时更改，也可以通过 自动 Liquid Clustering 智能选择。基数不再是限制因素，且数据布局可以随时间演进，无需不必要的重写。

Liquid Clustering 的所有优势都源于上述原则：更好的倾斜处理能力、行级并发、无小文件问题、多维聚类以及更低的写放大。

分区导致的小文件和数据倾斜；Liquid 实现的良好文件大小和聚类效果

到 2026 年，数据布局应当成为表的一个实现细节，任何读写该表的引擎都能从中受益。随着代理进入数据湖仓，生成和消费的数据量比以往任何时候都多，这一点变得越来越重要。人类用户和代理都需要宽容的接口，避免 Hive 风格分区可能带来的副作用。

揭穿 8 个常见的数据布局误区

Liquid Clustering 于 2024 年 正式发布。此后，我们持续与大规模使用它的客户迭代优化。在此期间，一些关于 Liquid Clustering 和分区的常见误区仍然存在，今天我们就来逐一澄清。

误区 #1：分区更快，因为它可以剪枝目录而非文件

误区说法：使用分区时，Spark 或其他引擎可以跳过整个目录，而无需打开其中的任何文件。

现实情况：在 Delta、Iceberg 等现代开放表格式中，目录剪枝并不存在。例如，Delta 使用 事务日志 来跟踪每个数据文件，并记录每列的统计信息，剪枝操作是基于这些统计信息完成的，而不是基于目录结构。引擎在规划查询时从不列出目录。它读取事务日志，评估过滤条件与统计信息的匹配度，然后跳过不匹配的文件。Liquid Clustering 使用相同的机制。无论你的数据存储在 date=x/hour=y/ 还是扁平化的聚类文件目录中，引擎都是在文件粒度上进行剪枝。不存在所谓的“目录级捷径”。

误区 #2：在对低基数列进行过滤时，分区表现更好

误区说法：对于具有少量唯一值的列，分区可以实现完美的数据分离，并获得良好的文件大小。

现实情况：Liquid Clustering 会自动检测何时应用低基数优化。例如，如果你按 (date, user_id) 聚类，且 date 列基数较低，系统会尽量让每个文件只包含单个日期的数据。而对于高基数列（如 user_id），则会自动用于在每个日期的文件内进行更细粒度的排序，无需依赖 Z-Ordering 等其他排序技术。

我们在一个真实世界的数据仓库基准测试中对这一 Liquid 优化进行了性能测试，观察到以下改进：聚类耗时降低 35%，查询速度提升 22%。

此外，Liquid Clustering 在对高基数列进行聚类时，设计上优于分区，因为它始终尝试创建大小合适的文件。

误区 #3：Liquid Clustering 不支持仅元数据操作

误区说法：仅元数据操作是分区独有的功能。与分区边界对齐的 DELETE 操作只会更新表的元数据，而对分区列的聚合计算无需扫描文件即可完成。Liquid Clustering 无法实现这一点。

事实：Liquid Clustering 同样支持仅元数据操作，包括 DELETE、COUNT、DISTINCT 和 GROUP BY 查询。引擎利用与数据跳过相同的每文件最小/最大统计信息，判断查询结果是否可仅通过元数据计算得出。在我们的基准测试中，针对 Liquid 聚类表的仅元数据 DELETE 操作比全重写 DELETE 快了 约 90%。其他仅元数据聚合查询性能提升高达 27 倍。

误区 #4：Liquid Clustering 在 PB 级规模下表现不佳

误区说法：对 PB 级表执行 OPTIMIZE 可能耗时数小时，维护成本过高。

事实：我们对 OPTIMIZE 进行了多项重大改进，目前已有数十家客户在生产环境中使用 PB 级规模的 Liquid 聚类表。两年前，在某些情况下，10 PB 的 Liquid 表执行 OPTIMIZE 的第一阶段（规划）可能耗时长达 12 小时。此后我们投入大量时间将规划时间缩短至 23 分钟。OPTIMIZE 的第二阶段（执行）在中等规模 DBSQL 集群上速度提升了 5 倍。

误区 #5：Liquid Clustering 仅对部分读取器有益

误区说法：Liquid Clustering 仅对 Databricks 读取器访问 UC 管理的 Delta 表时有帮助。

事实：Liquid Clustering 是一种写入端优化。它决定了引擎如何组织文件以实现高效的数据跳过。其输出是带有最小/最大统计信息的标准 Parquet 文件，并写入 Delta/Iceberg 等开放表格式。任何兼容的读取器（如开源 Apache Spark、DuckDB 等）均可利用这些统计信息跳过文件。Liquid Clustering 支持外部/托管表以及 Delta / Iceberg 表，且无论使用何种读取器，其优势均适用。

误区 #6：分区对于并发 ETL 是必需的

误区说法：并发 ETL 需要写入边界。没有分区时，两个写入者更新同一张表可能会发生冲突，Delta/Iceberg 的并发控制机制会强制其中一个重试或失败。通过分区，每个写入者拥有表的一部分切片，从而确保两个流水线永远不会触及相同文件。

事实：基于分区粒度操作是旧版并发模型下的权宜之计。与仅提供文件级并发的分区不同，Liquid 提供 行级并发。即使两个写入者更新的是同一文件中的不同行，也不会产生冲突。这消除了团队分区表的主要原因之一：为避免串行化而维护写入边界。借助 Liquid Clustering，ETL 可轻松地对同一张表进行并发操作。

误区 #7：Z-Ordering 可弥补分区的不足

误区说法：分区负责处理分区列的过滤条件，而 Z-Ordering 则处理其余部分。通过运行 OPTIMIZE ZORDER BY，引擎会对数据进行排序，以优化那些不与分区方案对齐的过滤条件下的跳过效果。

事实：Z-Ordering 并不能拯救分区。事实上，它自身存在结构性问题。

• 第一是 聚类质量差。Z-Order 并未在整个表中保持真正的有序性。同一列的值可能分散在多个文件中，导致每文件的最小/最大范围更宽，查询跳过的文件数量少于使用 Liquid 时的情况。
• 第二是 不必要的重写。随着新数据不断写入，Z-Order 必须定期重新运行，每次运行都会重写大量旧数据（可能已经聚类良好），以恢复聚类质量。在持续摄入场景下，使用 Z-Order 维护数据良好聚类的成本会随表增长而上升。

Liquid 支持 增量聚类，包括在写入时触发，因此布局始终保持最优，无需不必要的重写。

误区 #8：分区是实现选择性数据覆盖的必要条件

误区说法：只有通过 动态分区覆盖 才能实现选择性覆盖数据。

事实：选择性覆盖在 Liquid 表上原生支持。Databricks 支持 REPLACE USING 和 REPLACE ON 两种 SQL 语法，可用于任意数据布局（Liquid 聚类、分区或普通非聚类表）的选择性数据覆盖。与需要 Spark 配置的动态分区覆盖不同，REPLACE USING 和 REPLACE ON 可用于任何计算资源：经典集群、SQL 数据仓库和 Serverless。该操作是原子性的，且可匹配任意你选择的列。

成功案例：从分区迁移到 Liquid Clustering

Arctic Wolf 的 3.8 PB 安全遥测表查询速度提升 7.7 倍

Arctic Wolf 运行一个超过 3.8 PB 的安全遥测表，每天摄入超 1 万亿条事件，威胁猎手依赖实时数据来检测活跃攻击。

在从分区迁移到使用预测优化的 Unity Catalog 管理表上的 Liquid Clustering 后，Arctic Wolf 观察到：

• 90 天查询时间从 51 秒降至 6.6 秒
• 文件数量从 400 万减少到 200 万
• 数据新鲜度从小时级提升至分钟级

Bolt 关键 CDC 表的读写性能提升

Bolt 最近尝试了 Liquid 转换（目前处于私有预览阶段），该功能通过 ALTER TABLE .. REPLACE PARTITIONED BY WITH CLUSTER BY 命令原地将分区表转换为 Liquid 格式。在将一个 TB 级别的 CDC 表转换为 Liquid Clustering 后，他们观察到以下读写性能提升：

• 写入吞吐量（行/秒）提升了 138%
• 查询响应时间最高降低 63%，9 个代表性查询的平均降幅达 21%

Liquid Clustering 显著减少了每次写入操作的工作量，使我们最关键的 CDC 表吞吐量大幅提升。读取性能也全面改善。最棒的是：我们在实时数据摄入的同时完成了从分区到 Liquid 的转换，且零停机。这正是我们在平台规模下所需要的性能和可靠性。—— Marcin，Bolt 平台高级工程师

在 PB 级内部工作负载上实现 5.9 倍查询加速

我们内部运行着一张 1.1 PB 的表，每天被查询数千次，主要由工程师用于生产排查和可观测性仪表盘。最初该表按日期和小时进行分区，假设时间范围扫描会占主导。但这一假设并不完整。虽然时间范围扫描确实常见，但表也频繁按 source 和 id 字段查询，导致引擎必须扫描相关日期和小时分区中的所有文件，只为找到少量行。

将 source 和 id 添加为分区不可行，因为它们的唯一值太多，会导致生成数十亿个微小文件。Liquid Clustering 消除了这种权衡，允许同时按时间以及额外标识列进行聚类，同时保持良好的文件大小。

| | 布局 | | --- | --- | | 之前 | 按 date, hour 分区 | | 之后 | 按 date, hour, source, id 聚类 |

基准测试显示，在 16 个代表性生产查询中取得了显著改进：

| 指标 | 之前（分区） | 之后（Liquid） | 改进幅度 | | --- | --- | --- | --- | | 墙钟时间 | 406 秒 | 70 秒 | 加速 5.9 倍 | | 读取字节数 | 3.5 TB | 0.48 TB | 减少 86% 的读取量 |

表本身也变得更小了。总大小从 1.1 PB 降至 0.8 PB，减少了 27%，且底层数据未做任何更改。聚类更优的文件压缩效率更高，而过度分区带来的“小文件税”也随之消失。

Liquid Clustering 的未来规划

优化 Liquid 到 Liquid 的连接：速度提升高达 51%，数据混洗减少 87%

目前，在 Liquid 表的聚类列上进行连接时，即使数据已按这些列组织，仍可能需要全量数据混洗。现在推出的共聚类连接（Co-clustered Joins，当前处于私有预览阶段）可自动消除这种混洗。在一个真实的数据仓库基准测试中，Liquid 到 Liquid 的连接比未启用优化的查询 快约 51%（28 分钟 → 14 分钟），并且 数据混洗量减少了 87%（1.2 TiB → 150 GiB）。

简化分区表向 Liquid 的转换

此前，将分区表转换为 Liquid Clustering 需要重写整个表，并可能引发下游破坏性变更（如使用 REPLACE TABLE），或采用双写加计划停机的方式切换。我们现在引入了一个新命令（当前处于私有预览阶段），使此转换过程更加简便，最大限度减少停机时间和重写操作。

开始使用 Liquid Clustering

创建带有 Liquid Clustering 的表：

或者，如果你正在使用带预测优化的 UC 管理表，请使用 自动 Liquid Clustering，根据你的工作负载和查询模式智能选择聚类键：

Liquid Clustering 是现代湖仓架构的理想布局。立即在你的下一个表上尝试，或联系你的客户经理，体验分区到 Liquid 转换及共聚类连接的私有预览功能！

别忘了参加 DAIS 大会！

• 通过智能存储与 Liquid Clustering 优化湖仓成本与性能