小红书湖仓架构的跃迁之路

作者：李鹏霖(丁典)，小红书-研发工程师，StarRocks Contributor & Apache Impala Committer

本文整理自小红书工程师在 StarRocks 年度峰会上的分享，介绍了小红书自助分析平台中，StarRocks 与 Iceberg 结合后，如何实现极速湖仓分析架构。

与原有架构相比，湖上分析架构的 P90 查询性能提升了 3 倍，目前查询 响应时间 稳定在 10 秒以内。 同时，采用 Iceberg 存储格式后，尽管数据量和行数保持不变，但实际存储空间相较原有 ClickHouse 存算分离版本减少了一半。

RedBI 自助分析是小红书数据平台下的一款可视化、即席查询分析工具，专为分析师设计。它支持通过简单的拖拽操作完成数据分析，并在秒级返回查询结果，核心特点可以总结为： 灵活、快速、自助 。

下图为自助分析平台的原始架构，其核心是小红书内部自研存算分离版本的 ClickHouse。通过存算分离和智能缓存，不仅延长了数据集的生命周期，还能根据业务使用习惯将热点数据缓存在本地，从而实现接近存算一体架构的查询性能。

在数据分析流程中，分析师首先与数据仓库团队讨论数据需求。根据需求，数据仓库团队会创建相应的数据集，并在小红书的大数据研发管理平台 Dataverse 上开发 Hive2CK 类型的 ETL 任务。

Hive2CK 任务是一种基于 Spark 的数据处理任务，主要从上游的 Hive 表中获取数据。处理后的数据会先写入 OSS（对象存储服务），然后通过 ClickHouse 将这些文件加载至其系统中，根据用户的使用习惯将热点数据缓存至本地，确保最终提供给用户查询。

原架构痛点

首先，随着业务需求的快速增长和分析师使用习惯的不断变化，最初基于与数据仓库团队沟通制定的索引策略逐渐失效，导致数据集的查询性能出现明显下降。现有架构没有灵活的机制来根据分析需求和使用习惯动态调整排序键与索引，因此导致 查询性能下降 。

其次，ClickHouse 在支持 Join 操作方面存在一定限制。尽管可以为部分数据集建立 Colocate Join，但其桶数与集群节点绑定的方式，使得扩容或缩容时，节点数和桶数之间的依赖关系增加了操作复杂度。此外，维度表无法复用，Join Key 的绑定程度过高，使得不同数据集之间的 Join 操作灵活性受限。

最后，数据的访问方式也存在一定局限。目前的数据访问只能通过 ClickHouse 查询，缺乏更灵活的方式，尤其在一些场景下，某些数据需要根据不同的分析需求进行读取。如果继续依赖 ClickHouse 来读取这些数据，可能会对线上服务产生影响，导致系统在处理多样化需求时，性能和效率遭遇瓶颈。

这些问题不仅影响了查询性能，也限制了平台的扩展性和自助性，迫切需要找到一套有效的解决方案来应对当前架构的挑战。

湖上分析架构

随着原架构暴露出的性能瓶颈和灵活性限制，我们开始寻求更加高效的解决方案。在此背景下，RedBI 自助分析平台的架构进行了重大升级，采用了新的湖上分析架构。

首先，原有的 Hive2CK 替换为 Hive2Iceberg，数据存储格式转为 Parquet。与 ClickHouse 存储格式相比，这种转变不仅在支持各自最优压缩算法的前提下，实现了更高的压缩率， 实际应用中的压缩比提升了近一倍 。此外，StarRocks 作为 OLAP 查询引擎，具备了出色的扩缩容能力和快速的响应速度。

与此同时，依托 StarRocks 的 DataCache 功能，查询性能不再依赖于网卡 I/O。通过将热点数据缓存至本地 BE 节点，避免了频繁的远程数据拉取，进一步提升了查询的稳定性和响应速度。

在年初立项前，我们对湖上分析架构进行了 POC 测试。测试集选取了当时自助分析中排名前十的热门数据集，并模拟了 N 天内的实际查询场景。测试结果表明，与原有架构相比， 湖上分析架构的 P90 查询性能实现了 3 倍的提升。

排序键保鲜能力

为了应对随着时间推移数据集查询性能下降的问题，我们设计了一套湖上分析数据集智能优化的解决方案。

扩展 StarRocks 的审计日志插件，新增了 Iceberg ScanReport 的关键信息（如 nonPartFilterCols、resultDataFiles 和 dataInBytes）。
结合审计日志数据与表统计信息，预估用户的使用习惯，智能选择排序列。
针对新增分区数据，通过异步 ZOrder 排序任务优化非分区列的 DataSkip 效果，从而实现排序键和索引的持续优化。

提升数据集的自助性

针对多表分析场景（如自助分析人群包维表和笔记维表），当前，分析平台采用了 Broadcast Join / InSubQuery 的方式进行处理，这相较于传统的 Colocate Join 具有显著的性能优势。由于 Broadcast Join 不依赖于节点绑定，它使得扩容与缩容变得更加灵活，能够根据业务需求动态调整，而不受固定节点数的限制。

为了进一步提升数据集的自助性，我们引入了灵活配置的 JoinKey 策略。原则上，只要能够避免数据倾斜，任何字段都可作为 JoinKey。不过，考虑到当前集群规模与平台性能要求，我们对可进行 Shuffle Join 的维表数量做出了限制，最多支持与主表进行关联的 四个维表 ，以避免影响其他数据集的快速响应。

取数灵活

湖上数据集的存储与查询完全分离，赋予了更高的灵活性。用户可以直接通过 SQL 在公共 OLAP 资源池中进行启发式和探索式查询，既满足了多样化需求，又避免了对特定引擎或集群的依赖。

Data Skipping

关于排序的优化：

当我们在 DLF （Data Lake Formation）中检测到大部分拖拽查询都集中在某一列时，可以采用 线性排序 来提升效率。而对于两列或三列的场景，可以进一步考虑多维排序。需要注意的是，排序列通常不会超过三列，这样既能保证查询性能，又避免了复杂度过高的问题。

Z-Order排序：

Z-Order（也称为Z-Order Curve）是一种空间填充曲线，用于将多维数据映射到一维数据中。Z-Order 本质上是一种对多维数据进行排序的方式，它通过将多个维度的坐标交替地排列在一起，从而形成一个线性索引。

Z-Order 通过将数据点在多维空间中的坐标进行交替二进制编码，然后根据这些编码来排序。例如，在二维空间中，假设一个点有两个维度（x, y），我们可以将 x 和 y 的二进制位交替排列，形成一个新的值。对于更高维度的数据，Z-Order 会扩展此方法。在二维情况下，如果一个点的坐标是 (x, y)，而 x 和 y 的二进制表示分别为：

x = 3 → 011
y = 5 → 101

那么，Z-Order 会将这两个二进制值交替取各位形成成：

z = 0, 1, 1, 0, 1, 1

Z-Order 的关键在于它可以对多维数据进行有效的线性排序，这种排序在某些查询模式下具有很好的性能表现，尤其是范围查询。

DataFile （ Parquet file）非分区列 min-max 索引

Iceberg 具备“DataFile（Parquet 文件）非分区列的 Min-Max 索引”功能，具体表现为：

无需打开具体的 Parquet 文件，用户即可通过 Iceberg 元数据访问该索引。
在经过上述排序后，Parquet 文件内部数据将呈现有序结构。结合 Min-Max 索引特性，Iceberg 能在前端（FE）执行谓词下推，从而显著提升数据湖分析的性能。

上图展示了 Iceberg 的整体结构，元数据文件中的 ManifestFile 包含了大量 DataFile 级别的指标，例如：

DataFile.RECORD_COUNT,
DataFile.FILE_SIZE,
DataFile.COLUMN_SIZES,
DataFile.VALUE_COUNTS,
DataFile.NULL_VALUE_COUNTS,
DataFile.NAN_VALUE_COUNTS,
DataFile.LOWER_BOUNDS,
DataFile.UPPER_BOUNDS,
...

有了全部 DataFile 中非分区列的 min-max 索引数据，就可以做谓词下推。在 OLAP 引擎创建查询计划时，通过 org.apache.iceberg.Scan#planFiles 接口，根据 WHERE 子句中的谓词和 min-max 索引数据进行 DataFiles 级别的过滤，从而显著提升查询性能。

参考：

https://github.com/apache/iceberg/blob/main/api/src/main/java/org/apache/iceberg/TableScan.java

https://github.com/apache/iceberg/blob/main/api/src/main/java/org/apache/iceberg/DataFile.java

智能选择 Z-Order 排序键

为解决 ClickHouse 索引键保鲜度较低 的问题，我们设计了一种基于用户行为记录的智能排序键选择与更新机制，应用于 自助分析平台 ，并通过 Z-Order 排序 提升查询效率。上图红框展示了这一机制的核心流程。

具体实现步骤如下：

StarRocks 审计日志插件： 记录每个查询中每个表的下推的非分区列信息，以及 planFiles 接口返回的迭代器中涉及的 DataFiles 总 Bytes 等信息。
数据湖管理平台 (DLF)： 通过分析审计日志，智能推断出自助分析数据集中的表的候选排序列。根据这些列的NDV（不同值数量）做一层筛选，最终系统会自动在 Dataverse 平台创建和更新rewrite_zorder_dataFiles 任务。
Dataverse 平台 ：具有任务血缘能力，确保在上游 hive2iceberg 任务完成后，自动触发 rewrite_zorder_dataFiles 任务。
异步执行： rewrite_zorder_dataFiles 任务的执行是异步的，依赖于 Iceberg 的原子提交（atomiccommit）机制，分析师用户不感知整个优化过程。

StarRocks x Iceberg JOIN

在自助分析场景中，用户对数据集自助性的需求不断提升，尤其是在 JoinKey 灵活选择 上。StarRocks 支持成熟的 Shuffle Join 和 Broadcast Join 能力，不受分桶数或集群节点扩缩容的影响，能够快速扩展原数据集的 JoinKey。用户只需审批通过，即可在 分钟级 内完成新 JoinKey 的上线配置。

在项目中期阶段，湖上数据集的覆盖率已经达到 50%。然而，由于大多数数据集是从 ClickHouse 迁移而来的单表数据，且当时机型无法满足 DataCache 的使用需求，分析任务仍依赖从 OSS 读取 Parquet 文件。这种情况下，随着用户需求从单表分析转向多表数据集配置，Shuffle Join 的使用频率激增，网卡带宽逐渐成为性能瓶颈。

为解决这一问题，我们首先针对规模较大的多表数据集，选择采用 Iceberg 分桶表（10 桶） 的方式优化数据分布。同时，在 StarRocks 中引入对 Iceberg 分桶表的 Colocate Join 和 Bucket Join 支持，减少 Shuffle Join 对网卡带宽的依赖，从而缓解性能压力。在这一阶段，我们优先缓解网卡带宽瓶颈，待机型满足要求后，再逐步引入 DataCache ，通过本地磁盘读取替代从 OSS 读取数据的方式。

随着 DataCache 的引入，网卡带宽几乎完全腾出来用于 Shuffle Join 和 Broadcast Join，这不仅提升了性能，也保留了对 JoinKey 的灵活扩展能力。即使在使用分桶表时，仍能够兼顾 Shuffle Join 的扩展性，无需考虑集群节点数量的问题， 提高数据集自主性 。

排序列选取算法

在数据湖管理平台中，为提升查询性能和优化数据存储结构，排序列的筛选显得尤为重要。以下是排序列选取算法的具体规则和条件：

唯一值数量 (NDV)

排序列的候选字段需要具备足够的区分度。因此，算法会筛选唯一值数量（NDV）不少于 15 的列，以避免因低区分度而导致的排序效果较差。

频次比例

某列的查询使用频率，即列的使用次数与该表的查询总次数的比值，应不少于 0.15。这一条件确保排序列是用户查询的核心字段，有助于优化高频使用场景。

文件数量

数据分区中文件数量的丰富性是影响排序效果的另一个因素。候选列所在的分区，文件数量应超过 10 个，以确保排序后的数据能覆盖更多文件。

频次排名

为进一步提高排序列的筛选精度，算法优先关注查询频次排名前 3 的列。这种方式能够快速锁定用户最常查询的字段，最大化排序优化的收益。

查询占比

最后，通过分析列在整体查询中的占比，判断其是否值得进行排序。如果某列的查询占比较低，即便符合其他条件，也可能会被排除在排序列之外，从而避免无效优化。

查询性能优化

Data Skip 效果

随着业务需求的变化，某流量占比较高的数据集经历了多轮迭代和扩展。从最初包含店铺 ID、用户 ID、商品 ID 等基本字段，到逐步加入直播间 ID 和用户浏览笔记 ID 等信息，该数据集的字段不断丰富以满足日益复杂的分析需求。

为了应对这种动态变化，我们通过调整 Z-Order 排序任务中的排序列（sort_order），实现对数据的动态优化。具体来说，根据分析师的使用习惯和 T+1 阶段反馈，及时调整排序方式，使得新增数据可以更贴近近期用户的查询模式。值得注意的是，这一优化完全异步进行，不会影响历史数据，用户也无需感知优化过程即可受益。

优化完成后，该数据集的某些常用查询模式显著受益，占整体查询的比例达到 30%。从优化后的统计图表可以看到，Data Skip 技术在减少数据扫描量上效果明显，当前每日扫描数据量与优化后的 Data Skip 数据量形成了鲜明对比。

Data Cache

在数据湖分析场景中，StarRocks作为OLAP查询引擎，需要高效地扫描存储在对象存储（如OSS）中的 Parquet 文件。以小红书自助分析平台为例，频繁访问相同的数据会导致重复的网络I/O开销，尤其是在数据是 T+1 产出时。此时，带宽资源往往不能充分用于多表数据集的Join操作。为了优化这一问题，StarRocks 自 2.5 版本引入了 DataCache 功能。

StarRocks DataCache 通过将外部存储系统中的原始数据切分成多个数据块，并将这些块缓存到StarRocks本地的BE节点，从而减少了重复的远程数据拉取开销。这样，热点数据可以被缓存到本地，显著提升了查询和分析的性能。根据测试数据， 集群的 P90 查询性能提升约 20% 。需要注意的是，缓存的块位置与节点数量紧密相关。当集群进行扩缩容操作时，部分缓存会失效，导致一些数据块不再有效。

为了解决扩缩容后缓存失效的问题，当前的解决办法是安排在夜间进行扩缩容，并在扩缩容完成后重新运行当天的查询。这样，数据缓存会重新分布，并确保缓存的有效性。这一策略保证了在集群扩缩容后，DataCache功能能够快速恢复。

在我们的实际场景中，针对线上的两个典型查询案例进行了分析，截取了查询的执行Profile，结果显示，DataCache的命中率相当高，几乎达到理想状态。这个效果的原因主要有以下几点：

首先，由于数据集大多属于T+1级别的数据，上午生成的数据在下午一般不会发生变化。这样一来，用户查询的数据集基本保持一致，查询模式趋于稳定。这种情况下，DataCache能够高效缓存热点数据，减少了重复的数据拉取，显著提升了查询性能。

其次，每天的查询习惯大致相同，尤其是同一天内，用户查询的需求往往会集中在相似的时间段和数据范围。因此，数据缓存策略能够在用户查询峰值时，提供足够的缓存支持，从而减少了带宽消耗，并加速了查询响应。

通过对比开启和关闭DataCache时的监控数据，我们可以在Grafana中清晰地看到，开启DataCache后，网卡流量显著降低，节省的带宽几乎达到了2到3倍。

大查询优化策略

在面对大查询带来的性能瓶颈时，我们实施了大查询优化策略，以确保自助分析平台能够在数据量激增的情况下，继续保持高效的查询响应能力。

随着某些业务的快速增长，新数据分区的数量急剧增加，导致某些查询涉及的单个分区数据量大幅上升。例如，某些数据集的单分区数据量从年初的100亿，已经增长至目前的200多亿。这种数据量的增长可能会导致查询过慢，甚至影响系统的整体性能，特别是在没有有效优化的情况下。

为了应对这一挑战，我们为StarRocks中的Iceberg表实现了 EXPLAIN ESTIMATE 功能。该功能能够在实际查询之前估算查询的数据量。如果预估结果显示查询的数据量超过某个设定的阈值，系统会智能地将查询请求引导到一个规模较小的StarRocks集群，或者是Spark集群来执行，从而避免超大查询占用过多计算资源。这不仅减少了对其他查询的影响，也降低了查询超时的风险。