发布于2026-08-20 阅读(0)
扫一扫,手机访问
李荣谦有道精品课数据中台团队 数据中台实时数仓负责人
我们本次想要和大家分享一下有道精品课数据中台的架构演进过程,以及Doris作为一个MPP分析型数据库是如何为不断增长的业务体量提供有效支撑并进行数据赋能的。
本文以我们在实时数仓选型的经验为切入点,进一步着重分享使用Doris过程中遇到的问题以及我们针对这些问题所做出的调整和优化。
1 背景根据业务需求,目前有道精品课的数据层架构上可分为离线和实时两部分。离线系统主要处理埋点相关数据,采用批处理的方式定时计算。
而实时流数据主要来源于各个业务系统实时产生的数据流以及数据库的变更日志,需要考虑数据的准确性、实时性和时序特征,处理过程非常复杂。
有道精品课数据中台团队依托于其实时计算能力在整个数据架构中主要承担了实时数据处理的角色,同时为下游离线数仓提供实时数据同步服务。
数据中台主要服务的用户角色和对应的数据需求如下:


如上图所示,在数据中台1.0架构中我们的实时数据存储主要依托于Elasticsearch,遇到了以下几个问题:
基于上面的业务痛点,我们开始对实时数仓进行调研。当时调研了Doris, ClickHouse, TiDB+TiFlash, Druid, Kylin。

由于起初我们数据中台只有两名开发,而且存储相关的东西需要自行运维,所以我们对运维的成本是比较敏感的,在这一方面我们首先淘汰了Kylin和ClickHouse。
在查询方面,我们的场景大多为明细+聚合多维度的分析,所以Druid也被排除。
最后我们对聚合分析的效率方面进行对比,由于Doris支持Bitmap和RollUp,而TiDB+TiFlash不支持,所以我们最终选择了Doris来作为我们数据中台的主存储。
3 基于Apache Doris的数据中台2.0在完成了实时数仓的选型后,我们针对Doris做了一些架构上的改变以发挥它最大的作用,主要分为以下几个方面:
将所有Flink Job改写,在写入Elasticsearch的时候旁路输出一份数据到Kafka,并对复杂嵌套数据创建下游任务进行转化发送到Kafka,Doris使用Routine Load导入数据。
由于之前我们的实时数仓只有ES,所以在使用Doris的初期,我们选择了通过Doris创建ES外表的方式来完善我们的Doris数仓底表。同时也降低了查询成本,业务方可以无感知地使用数仓底表。

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

原来我们使用ES的时候,由于很多表没有数据写入时间,数据分析师需要每天扫全表导出全量数据到Hive,这对我们的集群有很大压力,并且也会导致数据延迟上升,我们在引入了Doris后,对所有数仓表都添加 eventStamp, updateStamp, deleted这三个字段。
数据对下游同步时可以灵活的选择eventStamp或者updateStamp进行增量同步。
数据同步我们采用了多种方式,通过Hive表名后缀来决定不同同步场景:

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

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

由于我们多数场景都是明细+聚合数据的分析,所以我们基于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数据进行解析,我们将不同算子的格式命名封装为以下几种:
具体的血缘服务逻辑如下图所示:

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

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

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中,提升了查询服务的稳定性,加快了响应时间。
聚合计算速度通过物化视图和列存优势获得了较大提升。
目前已经上线了几十个实时数据报表,在线集群的P99稳定在1s左右。同时也上线了一些长耗时分析型查询,离线集群的P99稳定在1min左右。


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

Doris的引入推进了有道精品课数据分层的构建,加速了实时数仓的规范化进程。
数据中台团队在此基础上一方面向全平台各业务线提供统一的数据接口,并依托于Doris生产实时数据看板,另一方面定时将实时数仓数据同步至下游离线数仓供分析师进行自助分析,为实时和离线场景提供数据支撑。
对于后续工作的开展,我们做了如下规划:
最后感谢百度Palo(Doris)团队的鼎力支持,为我们提供了很多技术上的帮助,在问题的解决上也十分迅速,为我们数据中台的飞速发展提供了可靠的支持。

Apache Doris(Incubating) 一款基于大规模并行处理技术的交互式SQL分析数据库,由百度于2018年贡献给 Apache 基金会,目前在 Apache 基金会孵化器中。
Doris官方网站:http://doris.incubator.apache.org/master/zh-CN/
Doris Github:https://github.com/apache/incubator-doris
Doris Gitee镜像:https://gitee.com/baidu/apache-doris
Doris开发者邮件组:如何订阅
Doris微信公众号:
售后无忧
立即购买>office旗舰店
售后无忧
立即购买>office旗舰店
售后无忧
立即购买>office旗舰店
售后无忧
立即购买>office旗舰店
正版软件
正版软件
正版软件
正版软件
正版软件
1
2
3
4
5
6
7
8
9