猿辅导公司的数据中台部门为猿辅导、斑马、猿编程、小猿搜题、猿题库、南瓜迷信等各个业务线的产品、经营、研发提供标准化的数据集(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 StarRocks Catalog来解决。

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建设得更好。