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

作者：李鹏霖(丁典)，小红书-研发工程师，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 级别的指标，例如：

1. DataFile.RECORD_COUNT,
2. DataFile.FILE_SIZE,
3. DataFile.COLUMN_SIZES,
4. DataFile.VALUE_COUNTS,
5. DataFile.NULL_VALUE_COUNTS,
6. DataFile.NAN_VALUE_COUNTS,
7. DataFile.LOWER_BOUNDS,
8. DataFile.UPPER_BOUNDS,
9. ...

复制代码

有了全部 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集群来执行，从而避免超大查询占用过多计算资源。这不仅减少了对其他查询的影响，也低落了查询超时的风险。

从性能监控数据来看，开启此优化功能后，整体集群的CPU利用率得到了有效控制。特殊是在大查询出现时，CPU的负载没有急剧攀升，避免了计算资源的过度斲丧。相对而言，P90响应时间在开启该优化后表现更为平稳，避免了因资源过载而导致的性能急剧下降。
项目收益

根据我们的丈量效果，从年初到现在， P90 响应时间提升了三倍，当前的查询响应时间大约可以控制在10秒以内 。

此外，通过优化存储方式，尤其是应用Iceberg的Parquet存储格式（如版本1.12），我们在存储效率上也获得了明显的提升。与原有的ClickHouse存量分离版本相比，采用Iceberg存储后，只管数据量和行数保持一致， 但实际存储空间减少了一半 。
未来规划

未来规划中，我们将探索结合 StarRocks 和 Paimon 的近实时湖仓分析架构，围绕公司业务需求，进一步优化近实时链路的处置处罚本领，并针对具有主键（PK）需求的湖上分析场景，制定更高效的优化方案。

直播回放：https://www.bilibili.com/video/BV18EC5YuEcA/?vd_source=1cb452610138142d1300dd37a6162a88
延伸阅读：
StarRocks 助力小红书离线数仓提效，提升百倍回刷性能！
StarRocks 在小红书自助分析场景的应用与实践

更多交流，联系我们：StarRocks

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。