万亿级别数据量的秒级实时分析，小红书 OLAP 引擎的进化和自研之路

小红书是年轻人的生活记录、分享平台，用户可以通过短视频、图文等形式记录生活点滴，分享生活方式。最近几年，随着业务类型和用户体量的爆炸式增长，各类数据分析的需求以及应用系统的数据需求快速出现，例如：商业智能分析，数据应用报表，用户行为分析、算法策略数据等。

小红书大数据团队逐步引入了多种 OLAP 分析引擎以及自建引擎来更好的满足需求。当前 Flink+Starrocks 和 Flink+Clickhouse(自建版)已成为小红书构建统一实时数据服务的核心技术方案，大大降低了数据链路开发复杂性，提升了高并发极速查询能力。

第一阶段

在 2017 年之前，数据总量还不是特别大，这个阶段使用 AWS 的 Redshift，此时数仓体系还没有完全建立，很多数据需求的实现都是用短平快、烟囱式开发的方式来满足。数据 ETL、数仓模型到最后报表端展现，在 Redshift 中一站式完成。但随着业务复杂度不断提升，以及数据量的快速增长，这种模式很快遇到了瓶颈。主要有以下问题：

• Redshift 无法在不影响线上查询性能的前提下弹性扩展，一旦涉及到扩容，就会涉及到数据重分布，从而影响集群的性能以及可用性。

• ETL 任务严重影响集群可用性。在 Redshift 中同时进行 ETL 任务的时候，会大量抢占资源，从而影响数据分析的效率，导致查询超时甚至因为集群负载过大后整个集群崩溃不可用。

• 没有良好的存算分离，数据存储容量存在瓶颈，无法满足随业务而快速增长的数据量存储需求。

第二阶段

随着数据仓库在 Hadoop/Hive 体系上搭建和完善，ETL 任务全部转移至 Hadoop 集群，这个阶段使用 Presto 完成 OLAP 分析。Presto 天然和 Hive 共享元数据信息，且共同使用物理数据存储，即插即用。大量的对数仓表的灵活查询使用 Presto 完成。

第三阶段

业务实时性增强，对查询性能的要求不断升高，同时许多数据应用产生。这个阶段引入了 ClickHouse，用来建设性能更强悍，响应时间更短的数据分析平台以满足实时性要求。

第四阶段

小红书大数据团队进行了实时数仓的整体设计和搭建，同时为统一对各业务团队提供数据接口而构建了数据服务平台，外接了多个内部或者 To B 服务的应用系统。既需要做低延时的复杂查询，同时对并发量也有很高的要求。这个阶段我们又根据场景引入了 Starrocks 引擎，以满足以上各类需求。

第五阶段

小红书大数据团队在 Clickhouse 的基础上自研了 Redck 引擎。小红书作为一个内容分享平台，用户的行为特征数据分析是最具价值同时也是最具挑战的，日常存在大量的功能表现、流量漏斗、用户路径、实验分析、属性分布等分析场景。而这些场景，都对平台同时具备实时，秒级响应分析万亿行级别数据的能力有着很高的要求。基于这些实际业务需求，我们利用 Clickhouse 天然的 Mpp 特性，加上自主开发的元数据管理，存算分离架构，冷热数据分层，实时数据写入等特性，构建了小红书自己的用户行为分析平台，提供高效快速的人群行为分析、实验分析洞察能力。

小红书 OLAP 体系现状

小红书的整个数据分析体系，由数据采集、数据存储加工/数据共享和应用层组成。

数据采集

服务器日志或者 App 日志通过 Flume 收集埋点日志，数据同时分发到离线存储 S3 和实时存储 kafka；线上业务数据库通过 Canal 实时采集 MySQL binlog 等信息。

数据存储加工

离线数据处理：利用 Hive/Spark 高可扩展的批处理能力承担所有的离线数仓的 ETL 和数据模型加工的工作。实时数据处理：Flink 完成实时侧数据的 ETL（包括维度丰富，双流 Join，实时汇总）；离线表通过调度平台同步到 ClickHouse/Starrocks，我们 Flink 实现了 ClickHouse 和 Starrocks 的 sink connector，落地到 Starrocks 或 ClickHouse。

数据共享

数据共享层的主要提供对外服务的底层数据存储,离线或者实时的数据写入相关的数据库组件中，面向多种服务，不同场景提供查询能力。数据共享层主要有 TiDB/Hbase/ClickHouse/Starrocks。通过 Starrocks 和 ClickHouse 提供的高速 OLAP 查询能力，在应用侧承接了报表平台，提供即席分析的平台，对开发侧提供数据接口，以及实现多个数据产品（比如流量分析平台，用户标签平台）。

应用层

应用层主要为面向管理和运营人员的报表，具有并发、延迟、需求更新频繁等要求，面向数据分析师的即席查询，要求支持复杂 sql 处理、海量数据查询等能力。

各 OLAP 分析工具选型比较

Clickhouse

优点：

• 很强的单表查询性能，适合基于大宽表的灵活即席查询。

• 包含丰富的 MergeTree Family，支持预聚合。

• 非常适合大规模日志明细数据写入分析。

缺点：

• 不支持真正的删除与更新。

• Join 方式不是很友好。

• 并发能力比较低。

• MergeTree 合并不完全。

Starrocks

优点：

• 单表查询和多表查询性能都很强，可以同时较好支持宽表查询场景和复杂多表查询。

• 支持高并发查询。

• 支持实时数据微批 ETL 处理。

• 流式和批量数据写入都能都比较强。

• 兼容 MySQL 协议和标准 SQL。

缺点：

• 周边生态比较不完善。

• 部分 SQL 语法不支持。

TiDB/TiFlash

优点：

• 支持更新/删除。

• 兼顾了 OLTP 的需求。

• 支持 Flink ExactlyOnce 语意，支持幂等。

缺点：

• 查询性能弱，无法较好支持 OLAP 查询场景。

• 不支持实时预聚合。

• TiFlash 暂时不支持所有的 SQL 写法以及函数。

业务场景概述

广告业务的核心数据有两大块：一个是广告的曝光点击流，即所有广告单元的展点销信息；第二个是广告效果归因数据，比如说在小红书站内的订单转化，相关表单提交，笔记的点赞、收藏、加关注等参与程度。基于这些数据，根据不同的业务场景需求，实时汇总出相关业务统计指标，对外提供查询分析服务。

原有解决方案

技术架构

在引入 Starrocks 引擎之前，是用大量 Flink 任务进行写入 MySQL/Redis/HDFS/ClickHouse，以达到数据的落地。Flink 中核心处理逻辑有几类：

• 前端用户广告展示信息事件流和后端算法推荐流双流关联并去重，完善广告信息。

• 接入反作弊，清除作弊事件。

• 按不同业务场景需求汇总结果写入不同的数据库组件中。

技术痛点

原有架构主要有以下问题：

• 数据逻辑没有很好做归拢合并，维护工作量大，新需求无法快速响应。

• Clickhouse 的并发能力不足以及扩容复杂度在可见未来会成为整体广告系统瓶颈。

• 因为 Flink 层逻辑散落，由大量小的 Flink 任务构成，因此导致整个架构无法满足高可用要求，只要任何一个任务出现问题，都会影响线上业务。

基于 Flink+Starrocks 的解决方案

因此我们希望对原有体系进行优化，核心思路是利用一个 OLAP 引擎进行这一层的统一， 对 OLAP 引擎的要求是比较高的：

• 能支撑大吞吐量的数据写入要求。

• 可以支持多维度组合的灵活查询，TP99 在 100ms 以下。

• 有实时汇总上卷的能力，提高查询性能，支持 qps 达到上万的要求。

• 通过 Binlog 实时同步 MySQL 的数据，并及时对数据进行封装。

• 比较好的支持多表关联。

经过大量调研，Starrocks 比较契合广告数据中心的整体要求。基于 Starrocks 本身高效的查询能力，支持高 QPS 的特性，可以为广告的算法策略、广告实时计费、广告平台实时的数据报告提供一体化服务。 新架构具备以下优点：

• 结构清晰，Flink 专注于数据的清洗，业务逻辑计算从 Flink 迁到 Starrocks 内实现，Starrocks 就是数据业务逻辑的终点。

• 可以维护统一的数据口径，一份数据输入，一套广告统计口径输出。

• 在底层实现 Starrocks 主备双活，更好的支持高 QPS 场景。

数据表设计数据模型设计

Starrocks 本身提供三种数据模型：明细模型/聚合模型/更新模型。对小红书广告业务来说，三种数据模型各尽其用：

• 广告曝光点击流写入聚合模型，按照业务所需要的维度，如广告主、广告类型、创意，广告单元，搜索词，地域，用户属性等设计聚合的所有维度，根据所需要的指标进行聚合。

• 广告侧后端有很多的线上 MySQL，通过 Starrocks 更新模型接入 MySQL 进行实时的表更新。

• 在 Hadoop 离线数仓中还定期统计了一些数据报告同步到 Starrocks 中，这些数据使用了 Starrocks 的明细模型。

数据分区/分桶

Starrocks 提供的数据分区功能，可以很好的提升广告场景下查询的性能。例如，广告侧查询常见的一种查询场景，是查询过去某一段时间内的数据，我们可以在 Starrocks 中根据时间进行分区，过滤掉不必要的分区数据。另外，广告查询会根据广告主进行筛选，我们将广告主 ID 作为排序键的最前列，就可以快速定位到广告主的数据，Starrocks 还支持按照广告主 ID 进行 Hash 分桶，减少整个查询的数据量进行快速定位，这对高并发场景也具有非常大的意义，尽量减少了查询语句所覆盖的数据范围，提高了并发能力。

物化视图

我们利用 Starrocks 物化视图能够实时、批量构建，灵活增加删除以及透明化使用的特性，建立了基于广告主粒度、基于用户特征粒度、基于广告单元粒度、基于具体创意粒度的物化视图。基于这些物化视图，可以极大加速查询。

数据导入

实时的数据导入分为两种：

• 有 ETL 处理需求的，会利用 Flink 进行 ETL 逻辑转化，使用 Flink Starrocks Connector 写入 Starrocks。

• 在实时数仓公共层的，配置 Routine Load 任务，将数据 10s 一个 batch 写入 Starrocks 表中。

离线数据报告导入 Starrocks：

在 Starrocks 提供的原生的 Broker Load 基础上在小红书数仓的调度平台上封装了导数模版，通过界面化配置的方式，将离线数仓的表导入到 Starrocks 中。

数据查询

在我们的查询场景中，广告主业务查询服务对查询并发度要求很高。Starrocks 采用的是 MPP 查询架构，底层数据按照 Range 和 Hash 两级分片，非常适合广告主业务的查询场景。

内部做的线上查询压测结果，每个 FE 能到 2000 左右的 QPS，整个集群能提供上万的 QPS，TP99 的查询在 100 毫秒以下。

系统运维

广告数据中心是非常核心的一个线上服务，因此对高可用及灵活扩容能力有非常高的要求。Starrocks 引擎本身支持 fe/be 多副本，没有单节点问题，当有节点故障的时候也可以保证整个集群的高可用。另外，当前体系结构在大数据规模下可以进行在线弹性扩展，在扩容时无需下线，不会影响到在线业务。

在此基础上，我们同时建设了主备双活链路，使用 consul 进行连接管理，一旦出现单条链路失效，可以一体化切换所有线上查询服务，在日常开发新需求上线时，也可以保持备用链路上线运行，主备对比校验，再进行主链路升级，做到业务上线对下游无感知。

在实时体系构建在 Flink+Starrocks 整体框架后，实现了数据服务统一化，大大简化了实时数据处理链路，同时也能保障较高的查询并发和较低的响应延迟要求，当前已经作为小红书数据中台的核心架构，为广告投放平台聚光平台的重构和业务迭代，电商商家端 Ark 系统和鹰眼系统的迭代和稳定运行提供了底层架构的支撑，之后的将来也会用来提升更多业务场景的数据服务和查询能力。

马尔科，小红书大数据组工程师。

当前我们正在广招大数据处理方面感兴趣的同学，分别有实时数仓开发，Flink 开发，OLAP 引擎开发的多个角色。

欢迎感兴趣的朋友发送简历至：

REDtech@xiaohongshu.com；

并抄送至：

marco@xiaohongshu.com；

bade@xiaohongshu.com。