根据业务需求，目前有道精品课的数据层架构上可分为离线和实时两部分。离线系统主要处理埋点相关数据，采用批处理的方式定时计算。而实时流数据主要来源于各个业务系统实时产生的数据流以及数据库的变更日志，需要考虑数据的准确性、实时性和时序特征，处理过程非常复杂。有道精品课数据中台团队依托于其实时计算能力在整个数据架构中主要承担了实时数据处理的角色，同时为下游离线数仓提供实时数据同步服务。
数据中台主要服务的用户角色和对应的数据需求如下：
- 运营/策略/负责人主要查看学生的整体情况，查询数据中台的一些课程维度实时聚合数据
- 辅导/销售主要关注所服务学生的各种实时明细数据
- 品控主要查看课程/老师/辅导各维度整体数据，通过T 1的离线报表进行查看
- 数据分析师对数据中台T 1同步到离线数仓的数据进行交互式分析
如上图所示，在数据中台1.0架构中我们的实时数据存储主要依托于Elasticsearch，遇到了以下几个问题：
- 聚合查询效率不高
- 数据压缩空间低
- 不支持多索引的join，在业务设计上我们只能设置很多大宽表来解决问题
- 不支持标准SQL，查询成本较高
2 实时数仓选型
基于上面的业务痛点，我们开始对实时数仓进行调研。当时调研了Doris, ClickHouse, TiDB TiFlash, Druid, Kylin。
OLAP引擎 | 优势 | 劣势 |
Doris | 1. 兼容MySQL协议2. 支持Online Schema Change3. 支持更新4. 集群扩缩容自动化5. 支持基于时间分区，冷热数据分离 | 1. 开源较晚，目前还在孵化中 |
ClickHouse | 1. 单机性能强劲2. 向量化引擎3. 数据压缩空间大 | 1. 不支持标准SQL2. 集群扩缩容不能自动Rebalance3. 对更新支持不好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数仓底表。同时也降低了查询成本，业务方可以无感知地使用数仓底表。
