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

我们本次想要和大家分享一下有道精品课数据中台的架构演进过程，以及Doris作为一个MPP分析型数据库是如何为不断增长的业务体量提供有效支撑并进行数据赋能的。 本文以我们在实时数仓选型的经验为切入点，进一步着重分享使用Doris过程中遇到的问题以及我们针对这些问题所做出的调整和优化。 1 背景 1.1 业务场景 根据业务需求，目前有道精品课的数据层架构上可分为离线和实时两部分。 离线系统主要处理埋点相关数据，采用批处理的方式定时计算。 而实时流数据主要来源于各个业务系统实时产生的数据流以及数据库的变更日志，需要考虑数据的准确性、实时性和时序特征，处理过程非常复杂。 有道精品课数据 站长交易 中台团队依托于其实时计算能力在整个数据架构中主要承担了实时数据处理的角色，同时为下游离线数仓提供实时数据同步服务。 运营/策略/负责人主要查看学生的整体情况，查询数据中台的一些课程维度实时聚合数据 辅导/销售主要关注所服务学生的各种实时明细数据 品控主要查看课程/老师/辅导各维度整体数据，通过T+1的离线报表进行查看 数据分析师对数据中台T+1同步到离线数仓的数据进行交互式分析 1.2 数据中台前期系统架构及业务痛点 聚合查询效率不高 数据压缩空间低 不支持多索引的join，在业务设计上我们只能设置很多大宽表来解决问题 不支持标准SQL，查询成本较高 2 实时数仓选型 基于上面的业务痛点，我们开始对实时数仓进行调研。当时调研了Doris, ClickHouse, TiDB+TiFlash, Druid, Kylin。 由于起初我们数据中台只有两名开发，而且存储相关的东西需要自行运维，所以我们对运维的成本是比较敏感的，在这一方面我们首先淘汰了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数仓底表。同时也降低了查询成本，业务方可以无感知地使用数仓底表。 数据同步 原来我们使用ES的时候，由于很多表没有数据写入时间，数据分析师需要每天扫全表导出全量数据到Hive，这对我们的集群有很大压力，并且也会导致数据延迟上升，我们在引入了Doris后，对所有数仓表都添加 eventStamp, updateStamp, deleted这三个字段。 eventStamp：事件发生时间 updateStamp：Doris数据更新时间，在Routine Load中生成 deleted：数据是否删除，由于我们很多实时数仓需要定时同步到离线数仓，所以数据需要采取软删除的模式 数据对下游同步时可以灵活的选择eventStamp或者updateStamp进行增量同步。 数据同步我们采用了多种方式，通过Hive表名后缀来决定不同同步场景： _f：每天/每小时全量同步，基于Doris Export全量导出 _i：每天/每小时增量同步，基于Doris Export按分区导出/网易易数扫表导出 _d：每天镜像同步，基于Doris Export全量导出