共计 2843 个字符，预计需要花费 8 分钟才能阅读完成。
撰文 / 李荣谦
编辑 / Ryan
起源：有道技术团队（ID: youdaotech）
0 序言
本期文章中，有道精品课技术团队将和大家分享有道精品课 数据中台的架构演进过程 以及 Doris 作为一个 MPP 剖析型数据库是如何为一直增长的业务体量提供无效撑持并进行数据赋能的。
本文以咱们在实时数仓选型的教训为切入点，进一步着重分享应用 Doris 过程中遇到的问题，以及咱们针对这些问题所做出的调整和优化。
1 背景概述
1.1 业务场景
依据业务需要，目前有道精品课的数据层架构上可分为 离线 和实时 两局部。
离线零碎次要解决埋点相干数据，采纳批处理的形式定时计算。而实时流数据次要来源于各个业务零碎实时产生的数据流以及数据库的变更日志，须要思考数据的准确性、实时性和时序特色，处理过程非常复杂。
有道精品课数据中台团队依靠于其实时计算能力在整个数据架构中次要承当了实时数据处理的角色，同时为上游离线数仓提供实时数据同步服务。
数据中台次要服务的 用户角色 和对应的 数据需要 如下：
- 经营 / 策略 / 负责人 次要查看学生的整体状况，查问数据中台的一些课程维度实时聚合数据；
- 辅导 / 销售 次要关注所服务学生的各种实时明细数据；
- 品控 次要查看课程 / 老师 / 辅导各维度整体数据，通过 T + 1 的离线报表进行查看；
- 数据分析师 对数据中台 T+1 同步到离线数仓的数据进行交互式剖析；
1.2 数据中台后期零碎架构及业务痛点
如上图所示，在数据中台 1.0 架构中咱们的实时数据存储次要依靠于 Elasticsearch，遇到了以下几个问题：
- 聚合查问效率不高
- 数据压缩空间低
- 不反对多索引的 join，在业务设计上咱们只能设置很多大宽表来解决问题
- 不反对规范 SQL，查问老本较高
2、实时数仓选型
基于下面的业务痛点，咱们开始对实时数仓进行调研，调研了 Doris、ClickHouse、TiDB+TiFlash、Druid、Kylin，思考到查问性能、社区倒退、运维老本等多种因素，咱们最初 抉择 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 数仓底表，同时也升高了查问老本，业务方能够无感知的应用数仓底表。
>>>> 数据同步
原来咱们应用 Es 的时候，因为很多表没有数据写入工夫，数据分析师须要每天扫全表导出全量数据到 Hive，这对咱们的集群有很大压力，并且也会导致数据提早回升，咱们在引入了 Doris 后，对所有数仓表都增加 eventStamp, updateStamp, deleted 这三个字段。
- eventStamp：事件产生工夫
- updateStamp：Doris 数据更新工夫，在 Routine Load 中生成
- deleted：数据是否删除，因为咱们很多实时数仓须要定时同步到离线数仓，所以数据须要采取软删除的模式。
数据同步咱们采纳了多种形式，通过 hive 表名后缀来决定不同同步场景：
- _f：每天 / 每小时全量同步，基于 Doris Export 全量导出
- _i：每天 / 每小时增量同步，基 于 Doris Export 按分区导出 / 网易易数扫表导出
- _d：每天镜像同步，基于 Doris Export 全量导出
>>>> 指标域划分 / 数据分层
将 Elasticsearch 中的数据进行整顿并联合后续的业务场景，咱们划分出了如下 四个指标域：
依据下面的指标域，咱们基于星型模型开始构建实时数仓，在 Doris 中构建了 20 余张数仓底表以及 10 余张维表，通过网易易数构建了残缺的指标零碎。
>>>> 定时生成 DWS/ADS 层
基于 Doris insert into select 的导入形式，咱们实现了一套定时依据 DWD 层数据生成 DWS/ADS 层数据的逻辑，提早最低能够反对到分钟级。
>>> 数据血统
咱们基于 Routine Load 和 Flink 实现了数据中台欠缺的数据血统，供数据开发 / 数据分析师进行查问。
3.2 数据中台 2.0 架构
基于围绕 Doris 的零碎架构调整，咱们实现了 数据中台 2.0 架构：
- 应用网易易数数据运河替换 Canal，领有了更欠缺的数据订阅监控
- Flink 计算层引入 Redis/Tidb 来做长期 / 长久化缓存
- 简单业务逻辑拆分至 Grpc 服务，加重 Flink 中的业务逻辑
- 数据适配层新增 Restful 服务，实现一些 case by case 的简单指标获取需要
- 通过网易易数离线调度跑通了实时到离线的数据同步
- 新增了数据报表 / 自助剖析零碎两个数据进口
数据中台 2.0 架构的数据流转 如下图所示：
咱们对数据中台整体架构进行梳理，整体构造 如下图所示：
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 左右。
同时，也造成了一套欠缺的开发体系使数据需要的日常迭代更加迅速。
6、总结布局
Doris 的引入推动了有道精品课数据分层的构建，减速了实时数仓的规范化过程，数据中台团队在此基础上一方面向全平台各业务线提供对立的数据接口，并依靠于 Doris 生产实时数据看板，另一方面定时将实时数仓数据同步至上游离线数仓供分析师进行自助剖析，为实时和离线场景提供数据撑持。
对于后续工作的发展，咱们做了如下布局：
- 基于 Doris 明细表生成更多的下层聚合表，升高 Doris 计算压力，进步查问服务的整体响应工夫。
- 基于 Flink 实现 Doris Connector，实现 Flink 对 Doris 的读写性能
- 开发 Doris On Es 反对嵌套数据的查问。
最初，感激各业务方对数据中台的反对，目前数据中台还在迅速倒退中，欢送气味相投的敌人退出咱们。
