【遇见Doris】基于Doris的有道精品课数据中台建设实践

我们本次想要和大家分享一下有道精品课数据中台的架构演进过程，以及Doris作为一个MPP分析型数据库是如何为不断增长的业务体量提供有效支撑并进行数据赋能的。

本文以我们在实时数仓选型的经验为切入点，进一步着重分享使用Doris过程中遇到的问题以及我们针对这些问题所做出的调整和优化。

1 背景

1.1 业务场景

根据业务需求，目前有道精品课的数据层架构上可分为离线和实时两部分。

离线系统主要处理埋点相关数据，采用批处理的方式定时计算。

而实时流数据主要来源于各个业务系统实时产生的数据流以及数据库的变更日志，需要考虑数据的准确性、实时性和时序特征，处理过程非常复杂。

有道精品课数据中台团队依托于其实时计算能力在整个数据架构中主要承担了实时数据处理的角色，同时为下游离线数仓提供实时数据同步服务。

数据中台主要服务的用户角色和对应的数据需求如下：

• 运营/策略/负责人主要查看学生的整体情况，查询数据中台的一些课程维度实时聚合数据

• 辅导/销售主要关注所服务学生的各种实时明细数据

• 品控主要查看课程/老师/辅导各维度整体数据，通过T+1的离线报表进行查看

• 数据分析师对数据中台T+1同步到离线数仓的数据进行交互式分析

1.2 数据中台前期系统架构及业务痛点

如上图所示，在数据中台1.0架构中我们的实时数据存储主要依托于Elasticsearch，遇到了以下几个问题：

1. 聚合查询效率不高

2. 数据压缩空间低

3. 不支持多索引的join，在业务设计上我们只能设置很多大宽表来解决问题

4. 不支持标准SQL，查询成本较高

2 实时数仓选型

基于上面的业务痛点，我们开始对实时数仓进行调研。当时调研了Doris, ClickHouse, TiDB+TiFlash, Druid, Kylin。

OLAP引擎	优势	劣势
Doris	1. 兼容MySQL协议 2. 支持Online Schema Change 3. 支持更新 4. 集群扩缩容自动化 5. 支持基于时间分区，冷热数据分离	1. 开源较晚，目前还在孵化中
ClickHouse	1. 单机性能强劲 2. 向量化引擎 3. 数据压缩空间大	1. 不支持标准SQL 2. 集群扩缩容不能自动Rebalance 3. 对更新支持不好 4. 运维成本较高
TiDB+TiFlash	1. 兼容MySQL协议 2. 向量化引擎 3. 业务数据和分析数据同步方便(内部Raft同步)	1. TiFlash不开源 2. 落地公司较少 3. 架构主要面向TP场景
Druid	1. 基于时间分区，聚合数据查询较快 2. 支持冷热数据分离	1. 不支持明细数据存储 2. 不支持标准SQL
Kylin	1. 支持标准SQL查询 2. 支持预聚合 3. 社区发展较好	1. 依赖较多 2. 明细查询支持较弱 3. 资源消耗较多

由于起初我们数据中台只有两名开发，而且存储相关的东西需要自行运维，所以我们对运维的成本是比较敏感的，在这一方面我们首先淘汰了Kylin和ClickHouse。

在查询方面，我们的场景大多为明细+聚合多维度的分析，所以Druid也被排除。

最后我们对聚合分析的效率方面进行对比，由于Doris支持Bitmap和RollUp，而TiDB+TiFlash不支持，所以我们最终选择了Doris来作为我们数据中台的主存储。

3 基于Apache Doris的数据中台2.0

3.1 架构升级

在完成了实时数仓的选型后，我们针对Doris做了一些架构上的改变以发挥它最大的作用，主要分为以下几个方面：

• Flink双写

将所有Flink Job改写，在写入Elasticsearch的时候旁路输出一份数据到Kafka，并对复杂嵌套数据创建下游任务进行转化发送到Kafka，Doris使用Routine Load导入数据。

• Doris on ES

由于之前我们的实时数仓只有ES，所以在使用Doris的初期，我们选择了通过Doris创建ES外表的方式来完善我们的Doris数仓底表。同时也降低了查询成本，业务方可以无感知地使用数仓底表。

具体查询Demo如下所示，我们通过学生的基础信息Join各种练习信息，对学生数据进行补齐。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-8EfscSVU-1657613660399)(https://mmbiz.qpic.cn/mmbiz_png/eGOhXuI8cBaIICKSooLqodKFbicIsr9ZbWia3SPBU6bt0htmPn7IOLVEbGMtmh9oAYCk12KkezR8icTVEk3AaicRRg/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1)]

• 数据同步

原来我们使用ES的时候，由于很多表没有数据写入时间，数据分析师需要每天扫全表导出全量数据到Hive，这对我们的集群有很大压力，并且也会导致数据延迟上升，我们在引入了Doris后，对所有数仓表都添加 eventStamp, updateStamp, deleted这三个字段。

1. **eventStamp：**事件发生时间

2. **updateStamp：**Doris数据更新时间，在Routine Load中生成

3. **deleted：**数据是否删除，由于我们很多实时数仓需要定时同步到离线数仓，所以数据需要采取软删除的模式

数据对下游同步时可以灵活的选择eventStamp或者updateStamp进行增量同步。

数据同步我们采用了多种方式，通过Hive表名后缀来决定不同同步场景：

1. **_f：**每天/每小时全量同步，基于Doris Export全量导出

2. **_i：**每天/每小时增量同步，基于Doris Export按分区导出/网易易数扫表导出

3. **_d：**每天镜像同步，基于Doris Export全量导出

• 指标域划分/数据分层

将Elasticsearch中的数据进行整理并结合后续的业务场景，我们划分出了如下四个指标域：

根据上面的指标域，我们基于星型模型开始构建实时数仓，在Doris中构建了20余张数仓底表以及10余张维表，通过网易易数构建了完整的指标系统。

• 微批生成DWS/ADS层

由于我们多数场景都是明细+聚合数据的分析，所以我们基于Doris insert into select的导入方式，实现了一套定时根据DWD层数据生成DWS/ADS层数据的逻辑，延迟最低可以支持到分钟级，整体的多层数仓表计算流程如下图：

对于明细数据在TiDB或者ES的，我们选择了在Flink中进行窗口聚合写入到下游Doris或者ES中。而对于明细数据只在Doris单独存在的数据，由于我们大部分使用了异步写入的方式，所以数据无法立即可读，我们在外围构建了支持模版化配置的定时执行引擎，支持分钟/小时级别的扫描明细表变更写入下游聚合表，具体模版配置如下图：

需要对监听的源表以及变更字段进行配置，在配置的interval时间窗口内多个源表进行扫描，然后将结果进行merge后生成参数，根据配置的threshold对参数进行拆分后传入多个insert sql中，并在每天凌晨进行T+1的全量聚合，修复微批计算的错误数据。

具体的计算触发逻辑如下图：

• 数据血缘

我们基于拉取Routine Load和Flink数据以及服务上报的方式实现了数据中台完善的数据血缘，供数据开发/数据分析师进行查询。

由于我们的Flink开发模式为提交jar的形式，为了获取到任务的血缘，我们对每个算子的命名进行了格式化封装，血缘服务定时的拉取/v1/jobs/overview数据进行解析，我们将不同算子的格式命名封装为以下几种：

• Source：sourceTypeName [address] [attr]

• Sink：sinkTypeName [address] [attr]

具体的血缘服务逻辑如下图所示：

通过血缘服务内部的解析后，批量地将血缘数据拆分成了Node与Edge存储到了NebulaGraph中，前台服务进行查询即可获得如下图所示的一条完整血缘：

3.2 数据中台2.0架构

基于围绕Doris的系统架构调整，我们完成了数据中台2.0架构

• 使用网易易数数据运河替换Canal，拥有了更完善的数据订阅监控

• Flink 计算层引入 Redis/Tidb 来做临时/持久化缓存

• 复杂业务逻辑拆分至 Grpc 服务，减轻 Flink 中的业务逻辑

• 数据适配层新增 Restful 服务，实现一些 case by case 的复杂指标获取需求

• 通过网易易数离线调度跑通了实时到离线的数据同步

• 新增了数据报表/自助分析系统两个数据出口

4 Doris带来的收益

1. 数据导入方式简单，我们针对不同业务场景使用了三种导入方式

• **Routine Load：**实时异步数据导入

• **Broker Load：**定时同步离线数仓数据，用于查询加速

• **Insert into：**定时通过DWD层数仓表生成DWS/ADS层数仓表

2. 数据占用空间降低，由原来Es中的1T左右降低到了200G左右

3. 数仓使用成本降低

• Doris支持MySQL协议，数据分析师可以直接进行自助取数，一些临时分析需求不需要再将Elasticsearch数据同步到Hive供分析师进行查询。

• 一些在ES中的明细表我们通过Doris外表的方式暴露查询，大大降低了业务方的查询成本。

• 同时因为Doris支持Join，原来一些需要查询多个Index再从内存中计算的逻辑可以直接下推到Doris中，提升了查询服务的稳定性，加快了响应时间。

• 聚合计算速度通过物化视图和列存优势获得了较大提升。

5 上线表现

目前已经上线了几十个实时数据报表，在线集群的P99稳定在1s左右。同时也上线了一些长耗时分析型查询，离线集群的P99稳定在1min左右。

同时我们基于Doris完成了标准化数仓的构建，在数据开发上跑通了一套完整的流程，使我们数据需求的日常迭代更加迅速。

6 总结和规划

Doris的引入推进了有道精品课数据分层的构建，加速了实时数仓的规范化进程。数据中台团队在此基础上一方面向全平台各业务线提供统一的数据接口，并依托于Doris生产实时数据看板，另一方面定时将实时数仓数据同步至下游离线数仓供分析师进行自助分析，为实时和离线场景提供数据支撑。

对于后续工作的开展，我们做了如下规划：

1. 基于Doris明细表生成更多的上层聚合表，降低Doris计算压力，提高查询服务的整体响应时间

2. 基于Flink实现Doris Connector，实现Flink对Doris的读写功能

3. 开发Doris on ES支持嵌套数据的查询

---

最后感谢百度Palo(Doris)团队的鼎力支持，为我们提供了很多技术上的帮助，在问题的解决上也十分迅速，为我们数据中台的飞速发展提供了可靠的支持。