猿辅导公司的数据中台部门为猿辅导、斑马、猿编程、小猿搜题、猿题库、南瓜科学等各个业务线的产品、运营、研发提供标准化的数据集(OneData)和统一数据服务(OneService)。OLAP 平台作为数据中台的一个核心部分，为各个业务线提供统一标准化的、可复用的、高可靠的数据服务，支持各个业务线人员进行快速灵活的查询和分析，是连接前台和后台的桥梁。

我们引入了性能强悍的新一代 MPP 数据库：StarRocks，来构建 OLAP 平台。基于 StarRocks，我们统一了实时数据分析和离线数据分析。当前 StarRocks 有 3 个集群，每天百万级有效查询请求，p99 延迟 1s，用于广告投放渠道转化、用户成单和续报、直播质量监控等多个数据场景，支持各业务线进行更加快速灵活的查询和分析，全面提升数据分析能力。

作者：申阳

猿辅导数据中台，大数据研发工程师 

平台选型的业务背景

业务特点和需求

猿辅导作为互联网教育行业赛道中的领先品牌，每日有海量数据生成，为实现科技助力教育，十分重视数据在公司发展中发挥的作用，需要不断解决在数据建设上遇到的诸多挑战。

在互联网教育数据体系中，不仅仅要关注用户活跃、订单收入，也很看重渠道推广转换率和用户续报率。这些指标存在不同的维度和不同的计算口径，以及多样化的业务系统接入模式，给我们 OneService 的底层设计带来了挑战。另一方面，数据时效性需求逐渐增强，离线 T+1 的数据已经越来越无法满足驱动业务的需求，数据逐步实时化也成为不可逆转的行业发展趋势。

在这样的背景下，我们的 OLAP 平台需要同时支持实时和离线数据写入，以支持不同时效的查询需求；需要支持复杂、多样的数据查询逻辑，以满足各种不同的业务场景的数据分析需求；需要能够进行快速的在线扩展，以支持业务快速发展带来的数据规模增长。

对 OLAP 引擎的需求

总结起来，我们对于 OLAP 的需求大概包括以下几点：

• 数据查询延迟在秒级/毫秒级；

• 同时高效支持大宽表和多表 join 查询，以支持复杂查询场景；

• 需要支持高并发查询场景；

• 同时支持流式数据和批式数据摄入，支持实时/离线数据 ETL 任务；

• 支持标准化 SQL，大幅度降低用户使用成本；

• 具有高效的精准去重能力；

• 较好的在线扩展能力，较低的运维管理成本。

技术选型和优劣势对比

OLAP（On-line Analytical Processing，联机分析处理）是在基于数据仓库多维模型的基础上实现的面向分析的各类操作的集合，强调数据分析性能和 SQL 执行时间。

在当今，各类 OLAP 数据引擎可谓百花齐放，可以分为 MOLAP ( Multi-dimensional OLAP )、ROLAP ( Relational OLAP ) 和 HOLAP ( Hybrid OLAP ) 三类。

MOLAP 引擎的代表包括：Druid，Kylin 等，本质是通过空间和预计算换在线查询时间。在数据写入时生成预聚合数据，这样查询的时候命中的就是预聚合的数据而非明细数据，从而大幅提高查询效率，在一些固定查询模式的场景中，这种效率提升可谓非常明显。但是他的缺点也来自于这种预聚合模型，因为它极大的限制了数据模型的灵活性，比如在数据维度变化时的数据重建成本非常高，而且明细数据也丢失了。

ROLAP 引擎的代表包括：Presto，Impala，GreenPlum，Clickhouse 等，和 MOLAP 的区别在于，ROLAP 在收到查询请求时，会先把 query 解析成查询计划，执行查询算子，在原始数据基础上进行诸如 sum、groupby 等各种各类计算，查询灵活，可扩展性好，往往使用 MPP 架构通过扩大并发来提升计算效率。这种模型的引擎优点是灵活性好，但是对于一个大查询/复杂查询它的性能是不稳定的，同时可能造成冗余的重复计算，消耗更多资源。

HOLAP 引擎是 MOLAP 和 ROLAP 的融合体，对于聚合数据的查询请求，使用类似于 MOLAP 的预计算数据模型。对于明细数据和没有预聚合的数据场景下使用 ROLAP 的计算方式，比拼资源和算力，这样即使没有明确的场景要求下，也可以实现最优化的查询性能，适应性更好。这方面做的比较好的系统主要有 StarRocks。

在团队的小伙伴们一系列调研和论证之后，首先排除了无法提供低延迟查询性能的引擎，比如 Presto 等，其次我们同时需要兼顾复杂业务场景支持能力，易用性和生产运维成本最低化，因此在这些维度上对比了 Druid、ClickHouse、Kylin 和 StarRocks。

StarRocks 作为一个 MPP 架构的 HOLAP 引擎，保证了数据模型的灵活性和查询性能，Rollup 和物化视图功能使用了 MOLAP 引擎的预计算思想，在一些场景上通过空间换时间的方式极大地提高数据查询效率。最终我们选择 StarRocks，一方面是因为 StarRocks 查询性能强悍，同时兼容 MySQL 协议极大降低了用户的使用门槛；另一方面它可以在高并发和高吞吐的不同场景下都表现出较好的适用性，和数据中台流批一体的 OneService 发展思路不谋而合。

应用场景

我们基于 StarRocks 构建了实时和离线统一的 OLAP 平台，交互查询和 BI 报表应用在数据中台的应用层发挥了巨大作用，为各个业务线的主管/产品运营同学的运营策略、广告投放策略等提供了可靠支持。

基于 StarRocks，我们构建的全新数据架构如下：

下面简单介绍几个典型的应用场景：

实时直播质量监控

我们使用 StarRocks 在直播质量分析相关系统中提供支持。这部分是直播引擎的研发同事十分关心的一些指标，直接关系到直播上课中的服务质量，一般是分钟级/亚分钟级的时效性要求。场景包括：网络质量、宏观丢包率、高峰时段可用率、音视频可用率等。

离线数据交互查询和 BI 报表

在数据架构升级前，离线 T+1 数据最终落地到 MySQL 上进行交互式查询和 BI 报表展示，查询的 Query 多是单表查询，维度组合较为灵活。但是随着业务增长和数据规模扩大，MySQL 的查询性能逐渐遇到瓶颈，无法支持一些多维度数据的查询场景，同时运维成本也越来越重。

在架构升级过程中，我们引入了 StarRocks 计算引擎作为 BI 数据的落地层。由于 StarRocks 兼容 MySQL 协议，数据应用层可以通过 JDBC 直接连接，因此在迁移过程中几乎没有成本，而数据摄入和查询效率得到了几倍到几百倍的提升，为各个业务线的主管/产品运营同学提供了可靠的决策支持。

准实时用户成单和续报数据

我们在订单/续报等核心数据场景中，T+1 的离线数据已经无法为业务提供最有力的决策支撑，越来越多需要当天数据的场景和报表需求。这里的主要挑战是：

• 跨团队合作、跨源、跨库的数据场景。

• 数据有时效性要求，查询响应要快。

• 对线上业务没有侵入性，屏蔽影响。

我们的解决方法是，导入 Hive 历史存量数据+订阅 binlog 增量数据通过 flinkSQL 实时灌进 StarRocks 中，同时针对不用的业务需求场景做表结构设计和查询优化。

实时推广投放策略

对于广告投放类的效果数据，我们会需要分钟级或更高的时效性要求，因为数据的变化可能直接影响到投放效果的评估和投放策略的变化。

我们同样用 flinkSQL 订阅业务 DB 的 binlog，最终落地到 StarRocks，作为 BI 报表和业务系统的统一数据产出口径。

实践心得

集群监控

目前我们关注的核心集群监控指标包括：

• FE 节点失联

• BE 节点失联

• BE 磁盘坏盘

• BE CPU 平均使用率过高

• FE Master 的内存水位过高

基于 Query 级别的监控主要有：

• 大查询告警，例如 ScanBytes、ScanRows

• 超过 2 分钟的慢查询告警

• 用户连接数过多

• 用“select 1”查询探活整体服务的可用性

打通生态

在早期使用时，StarRocks 当时和其他大数据开源生态的适配能力还有不足，因此我们做了一些改造性工作。

Flink Connector

我们目前实时的摄入任务大部分都是通过 Flink 来实现。我们基于 Stream Load 实现了 flink connector，线上使用性能良好，数据批次的时效性一般控制在分钟/半分钟级别。

离线数据摄入

对于离线数据的摄入，基本是 T+1 的时效，在凌晨调度中完成。

我们主要是使用 Stream Load 和 Broker Load 两种方式，我们在仓库 ETL 调度框架中对于两种 Load 分别进行了封装，区别是：

• 数据量不大/需要加工计算的，先落地本地磁盘文件，然后通过 Stream Load 导入 StarRocks

• 数据量较大的，先写入 Hive 临时表，然后 Broker Load 导入 StarRocks

Presto StarRocks Catalog

我们使用 Presto 查询 StarRocks 的时候主要是针对于一些需要跨源查询的场景，比如 StarRocks 中的实时同步数据与 Hive 中的历史数据通过一定条件 join 并最终产出小时级的数据报表。

这里遇到的问题是 Presto 原生的 MySQL Catalog 无法读取 StarRocks 元数据，主要原因是 information_schema 中元数据的类型和 Presto 数据类型需要适配，我们最终通过重新实现的 Presto StarRocksCatalog 来解决。

StarRocks 审计平台

另外我们也打造了 StarRocks DDL 工单审计平台，帮助用户能够更好的建立正确的表结构。

审计平台会监控大查询和慢查询，这些对集群性能影响较大的查询，通过告警机器人的方式通知到用户，督促大家去做查询的优化。

基于审计日志数据治理

之前常见遇到的一个问题是：BE CPU 被吃光了/磁盘 IO 打满

不同的 case 都可能导致这个现象：

• 某一个大查询 scan 数据量太多、耗时较长直接吃掉所有 io

• 表 buckets 过多导致 scan 所有盘

• 大查询频繁提交等

这类问题排查起来较为困难，除了手动杀掉查询，好像没什么好的处理办法。另一方面大量的导入操作(compaction)是否也会造成 cpu 和 io 的压力。

目前的解决方案就是通过审计日志和 BE 服务日志来监控查询和写入，对于有问题的请求及时处理避免对集群性能影响的进一步扩大。

我们通过 filebeat 采集了 fe.audit.log 日志，并最终导入到 ES 中，基于 ES 做 query 的分析和监控。

目前监控主要是：大查询和慢查询，这些对集群性能影响较大的查询，通过告警机器人的方式通知到用户，督促大家去做查询的优化。并实现了大查询/慢查询的告警，监控和明细分析。

未来展望和规划

应用场景

后续我们计划基于 StarRocks 做更多的场景实践探索：

• 基于 Bitmap 的多维分析/BI 自助工具

• 通用事件分析平台（支持明细+聚合）

运维建设

在组件运维层面的工作包括：自动化运维，建设回归测试框架、自动化集群扩缩容脚本、自动化集群升级脚本等，降低人工操作成本。

平台推广

在数据中台的平台化建设中也少不了 StarRocks 的参与，包括：

• 技术分享，最佳实践和用户培训；

• 统一元数据平台，打通不同引擎的 DDL、权限/租户管理等功能；

• 用户自助 BI 工具，屏蔽引擎细节，用户简单操作的可视化报表平台。

总结

通过引入 StarRocks 计算引擎，我们实现了流式数据、批式数据融合的一站式数据存储和查询引擎，对外提供语义一致和易用的数据服务。可以说 StarRocks 为猿辅导数据中台的标准化数据集(OneData)和统一数据平台服务(OneService)能力奠定了一个稳固的基础，支持各业务线进行更加快速灵活的查询和分析，全面提升数据分析能力，也为未来的数据平台化建设提供了更多可能性。

最后，十分感谢 StarRocks 鼎石科技团队专业的支持服务，希望我们能一起把 StarRocks 建设得更好。