共计 4318 个字符，预计需要花费 11 分钟才能阅读完成。
小红书是年轻人的生存记录、分享平台，用户能够通过短视频、图文等模式记录生存点滴，分享生存形式。在 2017 年后，随着业务类型和用户体量的爆炸式增长，各类数据分析的需要以及利用零碎的数据需要疾速呈现，例如：商业智能剖析，数据利用报表，用户行为剖析、算法策略数据等。小红书大数据团队逐渐引入了多种 OLAP 剖析引擎来更好的满足需要。StarRocks 采纳了全面向量化的计算技术，是性能十分强悍的新一代 MPP 数据库。通过引入 StarRocks，小红书构建了全新的对立数据服务平台，大大降低了数据链路开发复杂性，晋升了高并发极速查问能力。
“作者：吴浩亮，
小红书大数据团队，数据仓库架构师”
OLAP 引擎在小红书的演进史
第一阶段 ，在 2017 年之前，数据总量还不是特地大，这个阶段应用 AWS 的 Redshift，此时数仓体系还没有齐全建设，很多数据需要的实现都是用短平快、烟囱式开发的形式来满足。数据 ETL、数仓模型到最初报表端展示，在 Redshift 中一站式实现。
但随着业务复杂度一直晋升，以及数据量的快速增长，这种模式很快遇到了瓶颈。次要有以下问题：
- Redshift 无奈在不影响线上查问性能的前提下弹性扩大，一旦波及到扩容，就会波及到数据重散布，从而影响集群的性能以及可用性。
- ETL 工作重大影响集群可用性。在 Redshift 中同时进行 ETL 工作的时候，会大量抢占资源，从而影响数据分析的效率，导致查问超时甚至因为集群负载过大后整个集群解体不可用。
- 没有良好的存算拆散，数据存储容量存在瓶颈，无奈满足随业务而快速增长的数据量存储需要。
第二阶段，随着数据仓库在 Hadoop/Hive 体系上搭建和欠缺，ETL 工作全副转移至 Hadoop 集群，这个阶段应用 Presto 实现 OLAP 剖析。Presto 人造和 Hive 共享元数据信息，且独特应用物理数据存储，即插即用。大量的对数仓表的灵便查问应用 Presto 实现。
第三阶段，业务实时性加强，对查问性能的要求一直升高，同时许多数据利用产生。这个阶段引入了 ClickHouse，用来建设性能更强悍，响应工夫更短的数据分析平台以满足实时性要求。
第四阶段，小红书大数据团队进行了实时数仓的整体设计和搭建，同时为对立对各业务团队提供数据接口而构建了数据服务平台，外接了多个外部或者 To B 服务的利用零碎。既须要做低延时的简单查问，同时对并发量也有很高的要求。这个阶段咱们又依据场景引入了 StarRocks，以满足以上各类需要。
小红书数据分析体系架构
小红书 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 在广告数据中心的利用实际
业务场景概述
广告业务的外围数据有两大块：一个是广告的曝光点击流，即所有广告单元的展点销信息；第二个是广告成果归因数据，比如说在小红书站内的订单转化，相干表单提交，笔记的点赞、珍藏、加关注等参加水平。
基于这些数据，依据不同的业务场景需要，实时汇总出相干业务统计指标，对外提供查问剖析服务。
原有解决方案
技术架构
在引入 StarRocks 之前，是用大量 Flink 工作进行写入 MySQL/Redis/HDFS/ClickHouse，以达到数据的落地。
Flink 中外围解决逻辑有几类：
- 前端用户广告展现信息事件流和后端算法举荐流双流关联并去重，欠缺广告信息。
- 接入反作弊，革除舞弊事件。
- 按不同业务场景需要汇总后果写入不同的数据库组件中。
技术痛点
原有架构次要有以下问题：
- 数据逻辑没有很好做归拢合并，保护工作量大，新需要无奈疾速响应。
- Clickhouse 的并发能力有余以及扩容复杂度在可见将来会成为整体广告零碎瓶颈。
- 因为 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 多正本，没有单节点问题，当有节点故障的时候也能够保障整个集群的高可用。另外，StarRocks 在大数据规模下能够进行在线弹性扩大，在扩容时无需下线，不会影响到在线业务，这个能力也是咱们十分须要的。
总结
小红书从今年年初开始调研引入 StarRocks，以后曾经有五个 StarRocks 集群在稳固运行中，其中有两个开始稳固提供线上服务，三个还在试运行。引入 StarRocks 后，实现了数据服务统一化，大大简化了实时数据处理链路，同时也能保障较高的查问并发和较低的响应提早要求，之后将用来晋升更多业务场景的数据服务和查问能力。最初，感激鼎石科技的大力支持，也冀望 StarRocks 作为性能强悍的新一代 MPP 数据库引领者越来越好！
