猿辅导xDorisDB：构建统一OLAP平台，全面升级数据分析能力？

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

引进性能强的下一代MPP数据库:DorisDB，构建OLAP平台。基于DorisDB，统一了实时数据分析和离线数据分析。目前，DorisDB有三个集群，每天百万级有效查询请求，p99延迟1s，用于广告投放渠道转换、用户订单和更新、直播质量监测等多个数据场景，支持各业务线更快、更灵活的查询和分析

一、平台选择的业务背景

1.业务特点和需求

猴子指导作为网络教育行业课程的领先品牌，每天生成大量的数据，为了实现科技辅助教育，重视数据在公司发展中发挥的作用

在网络教育数据系统中，不仅要重视用户的活跃、订单收入，还要重视渠道的转换率和用户的持续率。这些指标有不同的维度和不同的计算口径和多样化的业务系统访问模式，给OneService的基础设计带来了挑战。另一方面，数据的时效性需求逐渐增强，离线top1的数据越来越不能满足驱动业务的需求，数据的实时化也成为不可逆转的行业发展趋势。

在这样的背景下，我们的OLAP平台需要支持实时和离线数据的填写，支持不同时效的查询需求，支持复杂多样的数据查询逻辑，满足各种业务场景的数据分析需求

2.对OLAP发动机的需求

总结起来，我们对OLAP的需求大致包括以下几点:

数据查询延迟到秒级/毫秒级的

同时有效地支持宽度表和多表join查询，支持复杂的查询场景

需要支持高并发查询场景

同时支持流动数据和批准数据的摄入，支持实时/离线数据ETL任务

支持标准化SQ化，大大降低用户的使用成本。

3.技术选型与优缺点对比

OLAP是基于数据仓库多维模型实现的各种操作集合，强调数据分析性能和SQL执行时间。

今天，各种OLAP数据引擎可以说是百花齐放，分为MOLAPMulti-dimensionalOLAP)、ROLAPRelationaloLAP)和HOLAP(HybridoLAP)三种。

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

(2)ROLAP发动机的代表Presto、Impala、GreenPlum、Clickhouse等，与MOLAP的不同之处在于，ROLAP在收到查询请求时，首先将query分析为查询计划，执行查询算子，根据原始数据进行sum、groupby等各种计算该模型的发动机优点是灵活性好，但大查询/复杂查询性能不稳定，同时可能引起冗馀的重复计算，消耗更多资源。

(3)HOLAP引擎是MOLAP和ROLAP的融合体，对于聚合数据的查询要求，使用与MOLAP相似的预算数据模型。在明细数据和未预收集的数据场景中使用ROLAP的计算方式，比较资源和计算能力，即使没有明确的场景要求，也能实现最佳化的查询性能，适应性更好。在这方面制作的比较好的系统主要有DorisDB。

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

DorisDB作为MPP架构的HOLAP引擎，保证了数据模型的灵活性和查询性能，Rollup和物化视图功能使用了MOLAP引擎的预算思想，在一些场景中通过空间交换时间的方式大大提高了数据查询效率。最终选择DorisDB是因为DorisDB的查询性能很强，与MySQL协议的兼容性大幅度降低了用户的使用阈值，另一方面，在高并发和高吞吐量的不同场表现出良好的适用性，与数据中台流一体化的OneService的发展构想不一致。

二、应用场景

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

基于DorisDB，我们构建的新数据结构如下:

以下简要介绍一些典型的应用场景:

1.实时直播质量监测

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

2.线下数据互动查询和BI报表

在数据架构升级前，线下top1数据最终落地到MySQL进行互动查询和BI报表展示，查询的Query多为单表查询，维度组合灵活。但随着业务增长和数据规模的扩大，MySQL的查询性能逐渐成为瓶颈，不能支持多维数据的查询场景，同时运输成本也越来越重。

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

3.准实时用户订单和更新数据

我们在订单/更新等核心数据场景中，TT1的离线数据不能为业务提供最有力的决策支持，需要当天的数据场景和报告需求这里的主要挑战是

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

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

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

我们的解决办法是引进Hive历史库存数据，通过flinkSQL实时输入DorisDB，优化不使用的业务需求场景的表结构设计和查询。

4.实时推进投入战略

广告投入类的效果数据需要分级或更高的时效性要求。因为数据的变化可能会直接影响投入效果的评价和投入战略的变化。

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

三、实践经验

集体监视

目前我们关注的核心集体监视指标是

FE节点失去联系

BE节点失去联系

BE磁盘坏盘

BE的CPU平均使用率过高

FE电脑存储水平过高

BE节点失去联系

BE磁盘坏盘

BE的CPU平均使用率过高

FE电脑存储水平过高

基于QE电脑存储水平的监视水平的监视主要是

(1)FlinkConnector

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

(2)离线数据摄入

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

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

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

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

(3)Presto DorisDB Catalog

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

这里遇到的问题是Presto原生的MySQLCatalog不能读DorisDB元数据，主要原因是information_schema中元数据的类型和Presto数据的类型需要适应，我们最终通过重新实现的Presto推荐DorisDBCatalog来解决。

(4)DorisDB审计平台

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

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

3.基于审计日志数据治理

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

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

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

表buckets过多导致scan所有盘

大查询频繁提交等

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

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

我们通过filebeat收集fe.audit.log日志，最终导入ES，根据ES进行query的分析和监视。

现在的监视主要是大的查询和慢的查询，这些对集团性能有很大影响的查询，通过警告机器人通知用户，促进了查询的最佳化。并实现了大查询/慢查询的告警，监控和明细分析。

四、未来展望和规划

1.应用场景

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

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

通用事件分析平台(支持明细 聚合)

2.运维建设

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

3.平台的普及

在数据中台的平台化建设中，DorisDB的参与也是必不可少的。

技术共享、最佳实践和用户培训

统一元数据平台，通过不同发动机的DDL、权限/租户管理等功能

用户自助BI工具，屏蔽发动机细节，用户简单操作的可视化报告平台。

通过引入DorisDB计算引擎，我们实现了流量数据、批量数据融合的一站式数据存储和查询引擎，提供语义一致、易于使用的数据服务。DorisDB为猿辅导数据中台的标准化数据集和统一数据平台服务能力奠定了坚实的基础，支持各业务线更快、更灵活的查询和分析，全面提高数据分析能力，为未来数据平台化建设提供了更多可能性。

最后，感谢DorisDB鼎石科技团队的专业支持服务，希望能一起更好地建设DorisDB。(作者:申阳猿指导数据中台，大数据开发工程师)