携手创作，共同成长！这是我参与「掘金日新计划 · 8 月更文挑战」的第16天，点击查看活动详情
实时数仓选型
基于上面的业务痛点，我们开始对实时数仓进行调研。当时调研了Doris, ClickHouse, TiDB+TiFlash, Druid, Kylin。
| OLAP引擎 | 优势 | 劣势 |
|---|---|---|
| Doris | 兼容MySQL协议支持Online Schema Change支持更新集群扩缩容自动化支持基于时间分区，冷热数据分离 | 开源较晚，目前还在孵化中 |
| ClickHouse | 单机性能强劲向量化引擎数据压缩空间大 | 不支持标准SQL集群扩缩容不能自动Rebalance对更新支持不好运维成本较高 |
| TiDB+TiFlash | 兼容MySQL协议向量化引擎业务数据和分析数据同步方便(内部Raft同步) | TiFlash不开源 落地公司较少架构主要面向TP场景 |
| Druid | 基于时间分区，聚合数据查询较快支持冷热数据分离 | 不支持明细数据存储不支持标准SQL |
| Kylin | 支持标准SQL查询支持预聚合社区发展较好 | 依赖较多明细查询支持较弱资源消耗较多 |
由于起初我们数据中台只有两名开发，而且存储相关的东西需要自行运维，所以我们对运维的成本是比较敏感的，在这一方面我们首先淘汰了Kylin和ClickHouse。
在查询方面，我们的场景大多为明细+聚合多维度的分析，所以Druid也被排除。
最后我们对聚合分析的效率方面进行对比，由于Doris支持Bitmap和RollUp，而TiDB+TiFlash不支持，所以我们最终选择了Doris来作为我们数据中台的主存储。
基于Apache Doris的数据中台2.0
架构升级
在完成了实时数仓的选型后，我们针对Doris做了一些架构上的改变以发挥它最大的作用，主要分为以下几个方面：
- Doris on ES
由于之前我们的实时数仓只有ES，所以在使用Doris的初期，我们选择了通过Doris创建ES外表的方式来完善我们的Doris数仓底表。同时也降低了查询成本，业务方可以无感知地使用数仓底表。
具体查询Demo，我们通过学生的基础信息Join各种练习信息，对学生数据进行补齐。
