小红书基于 StarRocks 构建广告数据中心的实践

小红书是年轻人的生活记录、分享平台，用户可以通过短视频、图文等形式记录生活点滴，分享生活方式。在 2017 年后，随着业务类型和用户体量的爆炸式增长，各类数据分析的需求以及应用系统的数据需求快速出现，例如：商业智能分析，数据应用报表，用户行为分析、算法策略数据等。为了满足业务需求，小红书使用过多种 OLAP 数据分析系统。StarRocks 采用了全面向量化计算技术，是性能非常强悍的新一代 MPP 数据库。通过引入 StarRocks，小红书构建了全新的统一数据服务平台，大大降低了数据链路开发复杂性，提升了高并发极速查询能力。

作者：季钱飞，

小红书数据流团队负责人

小红书 OLAP 演进史

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

第二阶段，基于 Hadoop 生态构建了小红书的数仓体系，基于 Hive 和 Presto 构建数据分析平台。

第三阶段，随着数据实时性的要求越来越高，业务方对整个数据分析的性能要求也越来越高，所以在 2019 年左右引入了 ClickHouse。通过 ClickHouse 强悍的分析能力，构造了一个准实时的交互式的分析平台，来支撑公司内包括用户行为分析、实验平台等一系列的场景。

第四阶段，随着实时数仓体系的设计和建设不断的推进，越来越多内部包括外部的数据应用也对数据分析要求越来越高。除了要求超低延迟的响应要求，同时还可能有比较高的 QPS 要求，ClickHouse 在这方面就不能够很好的满足业务的需求。所以在 2020 年底的时候，我们尝试了 StarRocks，并且目前已经在公司内多个业务场景中落地推广。

业务背景

小红书的广告场景大概可以分为两类，一种是搜索广告，一种是效果广告。搜索广告主要会利用实时计算出来一些统计指标，来对广告的部分召回进行推荐。

效果广告主要是会根据用户的一些展点销的信息，统计出的实时指标，再结合一些投放的实验进行智能广告的投放。同时，广告平台会根据各种业务的统计指标，产生实时或者离线的数据报告，供广告主进行分析运营使用。

初试 StarRocks：搜索广告场景

历史架构与痛点

搜索业务场景主要包括三个方面的业务特征：第一个是要计算的特征的数量特别多，并且组合维度也非常的灵活。第二个是统计指标的时间粒度跨度非常广，可能有小时级别、6 小时、12 小时，也有一天、两天甚至一个月的这种时间力度。第三个是所有的维度组合统计的时间粒度，它的变更在后续可能会非常的频繁。

在之前的架构中，主要是通过一个 Flink Java 程序去实现的。在这个 Java 程序当中，实现了所需要的所有维度组合时间粒度统计。这种架构现在来看其实是有很明显的弊端的：首先整个架构的灵活性是非常差的。如果要做一些变更，不仅需要进行一些开发和测试，还涉及到上线发版停服的问题。第二个因为所有的业务逻辑加工都是在这个 Java 代码中实现的，整个开发过程当中非常容易出错。所以开发完成之后，对数据质量的校验要花非常多的时间，导致整个业务变更的周期也会拉得很长。第三个是整个架构的扩展性是比较差的。随着维度增长，整个 Flink 集群的性能和稳定性会受到比较大的影响。

当前架构

经过一系列的分析调研以及充分的测试，综合考虑稳定性和性能上的优势，我们决定基于 StarRocks  在搜索广告场景下做一次完整的 POC。通过引入 StarRocks，将整个搜索广告数据流的链路设计如图所示：

通过 Flink 将这种前端的实时广告打点信息，通过 Flink SQL 做了一些字段补全之后写入到 StarRocks，然后基于 StarRocks 创建多个逻辑视图，用来统计各个需要的特征指标。后面通过调度平台，定期将这些特征指标再缓存到 RedKV（也是小红书内部实现的一个分布式的 Redis 系统），下游的业务系统就可以直接进入 RedKV 进行数据的消费使用。

在这套数据链路设计完之后，在表结构设计的时候也经过了一些考量和选择。最开始想的是因为数据维度组合是非常的灵活不确定的，就希望在数据经过 ETL 写入 StarRocks 时，按照我们业务方的需要进行转换，然后能够动态的去调整。

所以我们设计了一套动态表结构，这个表结构里面主要会包含两列，一个是叫 Metric Name 就是维度名称，还有一个是维度值。在进行数据写入到 StarRocks 时，我们在 Flink 中做了一个动态列转行的操作。

如上图所示，在这个原始表中有三种特征：性别、城市和年龄。下游业务消费可能需要两种维度的组合，比如一个是性别，还有一个是性别和城市的组合。那么这 3 条数据经过 Flink 列转行之后，会生成下面的 5 条数据。

这样一个动态表结构的设计是有一些好处的。首先这样能够充分利用 StarRocks 的预聚合的能力，下游在指标获取的时候直接转化成点查，同时整个数据写入之后，实时性会更好。但是这个链路的缺点也是比较明显的。一是整个 Flink 的写入程序是相对比较复杂的。第二是在这个过程当中，数据膨胀也是比较厉害的，尤其在维度带有搜索词的场景中，数据膨胀非常严重。第三是随着维度的增加，也会影响整个 Flink 的程序的性能和稳定性，整个架构的扩展性也会受到影响。所以在包含搜索词的场景中，我们就考虑通过一种静态表的结构来实现业务统计的需求。通过这个静态表，Flink 端只要做简单的 ETL 把明细数据写到 StarRocks 就行了。通过这种方式可以大大简化入库程序，同时也有效避免了数据膨胀的问题，但是这个方式带来的风险就是下游需要基于明细表去按照自己的需求做统计分析，它的性能能不能满足业务的需求。

在搜索这个场景开发完成之后做了一系列的测试，发现基于 StarRocks 明细数据做统计分析的性能是非常好的，完全能够满足我们的业务需求。现在线上有三种时间力度的统计：分钟级别、小时级以及天级，在这三种粒度的时间范围内的统计都能够很好的满足我们的业务需求。

基于这样一个新的数据链路，我们在接到业务变更之后，会经过以下几个操作步骤：首先基于明细表，创建一个新的逻辑视图；然后在数据交换平台上配置一个新的逻辑视图到 RedKV 的导数链路，配置完之后，任务调度平台会根据配置，定期的去实现导数。当这个数据到 RedKV 之后，业务下游的数据应用就可以直接使用。

上线效果

在做完这样一个 POC 之后，短期内就上线了 20 多个特征维度的指标，以及 10 多个时间粒度的指标。而且通过 StarRocks 我们统一了整个指标计算的口径，大大提升了数据的质量。在上线了这么多指标，这么长时间内没有出现任何的数据质量问题。

同时基于这样一个新的链路，业务的发版再也不需要对 Flink 任务进行变更、停服、发版操作。整个的需求从开发、验证、上线，大大缩小了周期，现在可以在小时级别完成这样一个变更操作。同时，利用 StarRocks 的动态扩容能力，可以很好的去适应业务或维度的快速增长。

全面推广：广告数据中心

历史架构与痛点

考虑到上一阶段搜索广告业务的上线的效果是比较理想的，所以我们在想是不是可以有更多的业务场景来尝试 StarRocks。于是我们就想到了此前使用 ClickHouse 来构造的数据应用或平台，但是又存在一些问题的场景，可以尝试用 StarRocks 来改造。我们的广告数据中心其实就是 ClickHouse 的重度使用者，并且在过去一段时间也暴露出了一些使用上或性能稳定性上的问题，所以就进一步的对现有的广告的数据链路做了一个详细的系统分析。

目前广告数据中心主要的数据来源，分为两大块。一个是实时广告的展示、点击数据流，也就是包含了广告数据的展点销的信息。第二个是我们实时广告的转化归因数据，比如说小红书内的广告转化，笔记的互动、点赞、转发的参与程度等等。

在过去的数据链路建设当中，为每一个业务需求去开发一个独立的 Flink 任务。这些 Flink 任务产生的数据，有的是要回流到线上的 MySQL 当中，进一步提供线上服务，还有的可能就是落入 HDFS。但是最终这些数据都需要再回流到 ClickHouse 当中，为广告主提供这些数据的报告和分析。因为业务场景多，数据交换链路多，所以整个的数据链路是非常复杂的，运维成本也非常的高，同时变更代价也会很大，周期比较长。另外有些功能比如 MySQL 线上数据实时同步到 ClickHouse 就没办法很好的支持。

因为以上的这些链路复杂的原因，所以整个系统的可用性没办法得到有效的保障。所以我们也希望通过架构上的优化来降低整个链路的复杂性，同时来提升整个链路的可用性。所以我们就考虑通过 StarRocks 来解耦数据 ETL 和下游数据业务加工逻辑的平台。

当前架构

通过 StarRocks 的引入，在 Flink 侧做的事情就比较简单，主要负责这些实时和离线数据的载入，然后通过 StarRocks 来为下游的这些广告算法策略、实时计费，还有投放端的数据报告，提供一个统一的数据加工分析平台。改造之后的数据链路就如图所示：

在这个链路当中，数据载入会包括两方面：第一个是实时的数据载入，在这里面我们主要还是用 Flink SQL 来完成的。有两方面的考虑，一是通过 StarRocks Connector 来实现 Exactly Once 语义，保证数据不丢不重。同时，跟小红书内的数据交换平台集成，可以很方便的去管理这些实时载入的任务。第二个是离线报表的数据载入，我们这里选择的是 Broker Load 载入方式，因为相比于 Stream Load，开启向量化的数据导入之后，Broker Load 的性能大概有 10 倍的提升。可以很好的满足我们这种数据报告高 SLA 的要求。

在表模型选择上，这个业务当中，90%以上的表都是聚合表。除了聚合表之外，我们还用了明细表模型。主要的使用场景就是用来展示这种 T + 1 的离线报表数据。虽然它是明细表，配合导数的后置数据质量校验工具，可以有效的保障数据的正确性。如果涉及到大量的历史数据的 Backfill， 也有非常好的表现。

另外就是 Unique 模型表的使用。我们在将 MySQL 维度表实时同步到 StarRocks 中时，主要采用的是这种模式。在引入 StarRocks 之前，当时我们是起了一个定时调度任务，每 3 分钟去删除 ClickHouse 里面的维度数据，然后再从 MySQL 里面全量的导入一遍。这个方式也运行了很长的一段时间没出过问题，直到有一天业务方提了一个表变更的需求。当我们在做变更的时候，正在删 MySQL 的维度数据，然后又触发了 ClickHouse 的一个 bug，就是当多个 DDL 在进行操作的时候，可能会从这死锁。所以在那个时候我们就出现了一段时间的数据的不可用，导致广告主那边看到的数据报告是不准确的。现在使用 StarRocks 引擎，我们通过 Flink 实时消费 MySQL 的 Binlog，然后直接插入到一个 Unique 表当中。这样的数据链路一方面大大提升了数据更新的时效性，另外一方面也提升了整个架构的可靠性。

上线效果

广告数据中心建设到现在已经上线了很长一段时间了，目前每天会有超过百万次的查询分析，然后在高峰的时段查询的 QPS 达到数几百条，当然这远远没有达到 StarRocks 的性能上限。我们做过一个性能测试，单 FE 的 QPS 能达到 2000，单集群的 QPS 能达到 10000 以上，可以有效地支撑我们未来的业务增长。并且整个查询的延迟是非常低的，我们整体的 P99 的查询耗时在 200 毫秒以内，绝大部分时候都在 100 毫秒以内。

系统高可用

当然，广告数据中心除了性能之外，整个系统的可用性也非常重要，因为是核心的系统。通过 StarRocks 简化了数据链路之后，在可用性上可以操作的空间也比较大了。目前线上做了主备双链路的建设，包括 Flink 任务，还有 StarRocks 集群。

这个双链路有几方面的好处：第一个是在业务做变更的时候，对下游的服务是无感知的。比如要做一个字段的变更，现在操作流程就变成了先将下游的业务系统切到备库上，然后对主库做变更，变更完了之后，把系统切回到主库，再做备库的这样一个变更。同时借助 StarRocks 弹性扩展的能力，如果业务量或是请求量有增加，也可以动态的去扩容来满足需求。基于这样一个双链路，还可以做一个数据的自校验，来保证整个数据的质量。同时将两个 StarRocks 的集群注册到 Consul 里面，配合上数据库团队提供的 Myhub Client，能够实现服务的自动发现，同时也可以在上面做一个健康检查，当出现故障之后能够实现秒级的自动故障切换。

另外一个就是 StarRocks 提供了一套高效的运维管理平台，通过这套平台一方面可以提高我们日常的运维效率，可以有效地避免一些人为操作带来的故障或事故，同时还提供 Query Profile 的功能。如果发现有一些慢查询，通过 Query Profile 可以有效地指导我们进行 Query 的调优，进而去保障整个系统的稳定性。

未来规划

对于未来，首先可以持续的在公司内部进行一些业务的推广，包括电商、社区业务的数据中心的建设等。第二个就是我们可以尝试用 StarRocks 替代现在报表系统底层的 OLAP 引擎。另外一方面，因为 StarRocks 目前开放了源代码，我们也希望更多的参与到整个社区的产品和生态的建设当中。从我们使用下来的角度来看，还有几个方面可以继续优化：第一个是在性能优化上还是要持续的投入，比如说千亿这样一个量级的数据分析的性能优化上，还需要进一步的提升。然后在 Stream Load 的数据导入上，性能还是要进一步的优化。另外一方面，因为小红书整体的架构都是建设在公有云之上的，所以我们也希望跟社区一起去建设一套存算分离的云原生 OLAP 引擎。