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

李鹏霖（丁典）小红--研发工程师 StarRocks Contributor & Apache Impala Committer StarRocks 01项目背景02湖上分析架构03案例分享04项目收益05未来规划 STARROCKS SUMMIT ASIA2024 湖上分析架构 湖上分析架构 STARROCKS SUMMIT ASIA2024 POC测试报告 STARROCKS SUMMIT ASIA 2024 Data SkippingData Skipping Types.NestedFieLd LOWER_BOUNDS =optional(125,"lower_bounds"MapType.ofRequired(126, 127, IntegerType.get(), BinaryType.get()),"Map of column id to Lower bound");Types.NestedFieLd UPPER_BOUND5 =optional(128,"upper_bounds",MapType.ofRequired(129, 130, IntegerType.get(), BinaryType.get())"Map of column id to upper bound"); 参考： https://en.wikipedia.org/wiki/Z-orderhttps://github.com/apache/iceberg/blob/main/api/src/main/java/org/apache/iceberg/DataFile.java STARROCKS SUMMITASIA2024 智能选择Z-Order排序键 STARROCKS SUMMIT ASIA2024 StarRocks x Iceberg JoIN StarRocks x Iceberg JOIN 排序列选取算法 算法描述该算法用于筛选数据集排序列，对满足以下条件的列进行处理或分析： 唯一值数量要求：数据集中唯一值的数量（NDV）应不少于15。 频次比例要求：列的查询使用频率（Ratia=列的使用次数/该表的查询总次数）应不小于0.15。 文件数量要求：在每个分区中，文件数量应超过10个。 频次排名要求：关注频次最高的前三个列。 查询占比：是否值得去排序 STARROCKS SUMMIT ASIA2024 DataSkip效果 某流量占比较高的数据集，自这张表创建以来，随着业务的变化，分析需求也在不断更新和进化。比如最初，这张表可能只包合店铺ID、用户ID、商品ID等基本信息；但随着时间推移，新的需求不断加入，例如增加了直播间ID、用户进入直播间之前浏览的笔记ID等信息，以满足更为细化的分析需求。 为了适应这些变化，我们会根据分析师的使用习惯和工+1阶段的反馈，动态调整数据的排序方式。具体来说，我们会调整zorder排序任务中的srtrr列，从而确保未来的数据能根据近期用户的使用习惯进行优化排序。这一优化过程不会影数据集查询的30% (JSON 优化后： 参考: https:/iceberg.apache.org/docs/latest/spark-procedures/#rewrite_data_files STARROCKS SUMMITASIA2024 DataSkip效果 STARROCKS SUMMIT ASIA 2024 StarRocksOLAPParquetT+1I/OJoinStarRocksDataCache2.5在数据湖分析场景中，StarRocks作为OLAP查询引擎，需要对对象存储中的Parquet文件进行扫描。以小红书自助分析平合为例，数据通常是T+1产出的，频繁访问相同司的数据会带来重复的网络I/O开销，导致带宽资源无法充分用于Join操作（多表数据集】。为了解决这一问题，我们引入了StarRocks的Datacache功能，该功能自2.5版本起提供。 StarRocksDataCacheOSSStarRocksBEP9020%StarRocksDataCache通过将外部存储系统（如OsS）中的原始数据按照特定策略切分成多个块，并将这些块缓存到StarRocks的本地BE节点，从而避免了重复的远程数据拉取开销。这一优化显著提升了热点数据的查询和分析性能，集群的P90性能提升约20%。 cache_blockStarRocks注：cache_block的位置与节点数量密切相关，如进行扩缩集群操作，StarRocks将重新拉取缓存，之前的缓存会因为淘汰算法而失效。 参考:https:ffdocs.starrocks.iofzhfdocsfdatasourcefdata_cache STARROCKSSUMMITASIA2024 MIN_OF_DataCacheReadBlockBufferCounter: 132DataCacheReadBytes: 65.282 GBMAX_OF_DatacacheReadBytes:330.414 MBMIN_oF_DataCacheReadBytes:12.780 MBDataCacheReadDiskBytes:63.747 GBMAX OF DataCacheReadDiskBytes:326.164 MBMIN_OF_DataCacheReadDiskBytes: 12.780 MBDataCacheReadMemBytes:1.535 GBMAX_OF_DataCacheReadMemBytes: 10.720 MBMIN_OF_DataCacheReadMemBytes: o.@oo BDataCacheReadCounter: 267.878K (267878)MAX_oF_DataCacheReadCounter: 1.323K (1323)MIN_OF_DataCacheReadCounter: 52DataCacheReadTimer: 412.764msMAX_0F_DataCacheReadTimer: 872.947msMIN_OF_DataCacheReadTimer:4.083msDataCacheSkipReadBytes: 0.0oo BDataCacheSkipReadCounter:DataCachewriteBytes:0.000 BDataCachewriteCounter:- DataCachewriteFailBytes:0.000 BDataCachewriteFailCounter:DataCachewriteTimer: OnsExprFi1terTime: 4s153msMAX_oF_ExprFilterTime:6s867mSMIN_oF_ExprFilterTime:239.014msInputstreamAppI0BytesRead: 69.893 GBMAX_0F_AppI0BytesRead:352.832 MBMIN_oF_AppIOBytesRead:13.530 MBAppI0Counter: 650.433K (650433) STARROCKS SUMMITASIA2024 DataCache:关闭 DataCache:打开 大查询优化策略 尽管平台通常会对数据集的查询分区（如按天分区）和数据量设置一定限制，例如在超过某个时间范围后，用户无法在前端选择这些数据。 但随着公司某些业务方向的增长，每个分区的数据量可能会急剧增加，如某业务下的数据集，从年初单分区一百亿数据量线性增长到当前单分区两百多亿。作为一个成熟的自助分析平台，必须具备一个兜底的策略。 为应对这一挑战，我们在StarRocks中为Iceberg表实现了EXPLAINESTIMATE功能。该功能会在实际查询之前预估查询的数据量。如果数据量超过某个预设的阅值，系统会将查询请求分级路由到一个规模较小的starRocks集群或Spark集群慢慢查。这样可以避免某些超大查询占用过多计算资源，从而影响到其他本应快速响应的数据集查询，甚至导致查询超时。 参考： https://iceberg.apache.org/docs/latest/api/#scanninghttps://clickhouse.com/docs/en/sql-reference/statements/explain#explain-estimate STARROCKS SUMMIT ASIA2024 大查询优化策略 优化前： 优化后： 项目收益 查询性能（P90)提升3倍到10s内-磁盘存储节省1倍 StarRocks x Paimon starRocksxPaimon构建极速实时湖仓分析架构 PK接下来将结合公司的业务场景，探索近实时链路和具有PK需求的湖上分析场景的优化方案。 ApachePaimon StarRocks 参考： https://paimon.apache.org/docs/master/concepts/overviewhttpstffdocs.starrocks.iofzh/docs/data_source/catalog/paimon_catalog! STARROCKS SUMMIT ASIA2024 感谢观看！滋 Thank you!