导读：

StarRocks 4.0 已正式发布！这一版本将优化能力从查询层延伸至数据层，通过全新的 Global Shuffle Ingestion、Spill-Aware Writes、Compaction API 与 Local Sort 等特性，让数据在写入的同时即完成优化。面对 Apache Iceberg 等开放格式中"小文件过多、查询延迟高"的挑战，StarRocks 4.0 将数据仓库级的治理理念引入 Lakehouse 架构，实现了从写入、组织到维护的全链路提速。

本文将带你了解这些关键机制如何让 Lakehouse 变得真正 Query-Ready。

在 Apache Iceberg 表中，数据的写入方式往往并未针对查询性能进行优化。持续不断的微批写入会产生成千上万个小文件；也很难做到让数据在写入后的第一时间就能被快速查询。

结果是：查询变慢、资源占用激增，成本也随之持续攀升。

为什么仅靠查询优化无法解决性能问题

查询优化可以不断地进行剪枝、缓存和向量化处理------但再聪明的优化器，也无法扭转"小文件风暴"带来的性能损耗。在实际使用中，性能不稳定往往源于以下几个原因：

• 在分布式、并发、多分区写入过程中，小文件迅速倍增；

• 数据写入时未经过排序，削弱了剪枝与 I/O 合并效果；

传统的事后合并虽有助于缓解问题，但过程复杂、触发不及时，常常错过数据刚刚写入的关键窗口。

让数据湖具备数据仓库级的治理能力

在传统数据仓库中，几乎不会出现"小文件过多"或性能波动的问题。因为数据在写入存储前，通常已经经过合并和排序等优化处理；同时，后台还会有轻量级服务持续维护系统的稳定与高效。

我们将这一理念引入 Apache Iceberg，构建了两层优化机制。

1. Ingestion-first（写入优先）

在数据写入前，系统会智能路由以避免写入冲突；在落盘前，数据经过缓冲与合并，最终以更大、更整洁的文件写入存储。这意味着------数据一旦落地，即可被查询，无需等待漫长的合并或维护任务。

2. Compaction service

后台服务持续运行，不断将小文件合并为适合查询的文件，并保持分区均衡。服务具有限流、跳过热点、即时可用等机制，能够在需要时快速完成数据整理。

借助这两层机制，Iceberg 表的运行特性更接近数据仓库表：

• 高负载下写入依然稳定；

• 新写入的数据可立即查询；

• 后台合并优化，确保查询性能始终如一。

StarRocks 如何让这一理念落地

StarRocks 是一款为 Apache Iceberg 等开放格式而生的高性能 SQL 引擎，专注于低延时与高并发查询。

无论是实时数据看板，还是大规模的用户侧分析场景，StarRocks 都能以强大的查询性能为支撑，让"速度"成为用户体验的核心竞争力。

StarRocks 4.0 新特性

在 4.0 版本中，StarRocks 的优化不再局限于查询执行层，而是进一步下沉到数据层------从写入、组织到维护，实现全链路优化。

全局 Shuffle 写入机制

全新的 Global Shuffle Ingestion 机制能够在集群节点间智能分配数据写入，避免后端之间的冲突。每个节点只负责部分分区，从而生成更少但更大的文件，避免"小文件"泛滥。这一机制显著降低了元数据开销，并在高分区场景下大幅提升查询扫描效率。

感知溢出的写入机制（Spill-Aware Writes）

在内存压力增大时，StarRocks 不再被动提前刷写数据，而是尽可能将数据缓存在内存中，并在需要时自动将其溢写到磁盘或对象存储。

这一机制避免了因防止 OOM 而过早生成小文件的问题，使数据文件更接近理想大小，即使在上千分区的复杂写入场景下，仍能保持稳定、高效的性能表现。

Compaction API

在需要进行数据维护时------例如经历大量微批写入之后------StarRocks 4.0 引入了全新的 Compaction API。

它复用了写入阶段的同一套 Shuffle、Spill 与 Sort 逻辑，可按需快速完成文件合并。

借助这一机制，用户无需借助外部工具，即可直接在 StarRocks 内完成数据布局的修复与优化。

本地排序

在文件层面，StarRocks 现已支持在写入阶段完成数据排序。每个文件内部保持有序，更便于剪枝优化，无需额外的排序任务即可显著降低查询延时。

数据在写入的同时即完成优化，可直接支撑快速、稳定、可预测的查询体验。

Benchmarks

我们针对 Apache Iceberg 表进行了多组写入测试，对比 StarRocks 4.0 与 3.4 版本在不同负载下的表现。

测试涵盖 100、500 和 1000 个分区的典型场景，指标包括写入延时、文件数量与平均文件大小。

主要结果如下：

• 大规模写入稳定性显著提升：旧版本在超过 100 个分区时常出现 OOM 错误；而 4.0 版本可稳定支持多达 1000 个分区的写入，无任何失败。

• 写入延时大幅降低：在 100 分区下，写入时间缩短一半以上；在 500 分区下，延时减少约 75%，端到端数据新鲜度显著提升。

• 文件数量骤减：新的写入路径生成的文件更少、体量更大。在 100 分区测试中，文件数从 17 万余个降至仅 259 个；在 500 分区下，则从 23 万多个降至 596 个。

A Query-Ready Lakehouse

Apache Iceberg 为现代 Lakehouse 架构带来了开放性与治理能力，但要实现高性能，仅有开放格式还不够------还需要像数据仓库那样，对底层文件进行有序的管理与优化。

在 StarRocks 4.0 中，这种"仓库级的严谨"已被融入系统内核：

数据落地即具备可查询状态，写入过程稳定高效，合并维护可按需即时完成。

由此，StarRocks 让 Lakehouse 兼具数据仓库的速度与可预测性，同时保留开放架构的灵活与自由。