共计 5618 个字符，预计需要花费 15 分钟才能阅读完成。
小红书是年轻人的生存记录、分享平台，用户能够通过短视频、图文等模式记录生存点滴，分享生存形式。在 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 引擎。
