Doris 实时数仓建设实践

概述

Drois 从早期的百度项目，到开源Apache Doris，到商业化的StarRocks，到各大云服务商，陆续上线，作为新一代的OLAP解决方案，在应用场景上表现得非常好

整理对近期对Doris实时数仓建设的一些思考

背景

1. 公司有很多业务线，每个业务线有自己的产品，沉淀了各自业务的数据，也使用了各种不同的存储介质，Mysql,Elasticsearch,Oracle,MongoDB 等等
2. 公司希望将数据打通，对数据联合跨库分析，输出结果
3. 至于实时数仓的需求，主要是目前很少有人能接受 T+1的数据
4. 公司目前的数据量在PB级以下，Hadoop生态暂时不需要涉及，目前Doris也在持续迭代，期待越来越好

主体思路

1. 使用Doris对各类数据源进行整合，实现数据层面的打通
2. 建立研发的数据库设计使用标准，以及实时数仓的相应规范，数据分层
3. 建立统一的数据指标管理，数据资产管理

步骤：

一、 使用Doris对各类数据源进行整合

1. 数据整合形式主要分为 『建立外表』、『数据导入』 两种，我们在部份业务初期，并未使用数据导入方式，因为数据导入需要额外的组件及维护成本，并且业务初期，需求变更导致的表结构变更是常事，还有业务初期数据量不大。综合以上考虑，在业务初始 基本策略是『建立外表』，建立的外表，Doris能够将跨库的SQL语法自动拆解，转换为各种类型的存储介质需要的语法结构，然后在Doris中进行数据合并。如：基于Doris实现Mysql与Es的联表查询
2. 当某张表达到了一定量级，业务的数据库不能满足分析需求，同时也是对业务库产生了影响，影响客户层面的正常使用，此时就有必要使用『数据导入』，将数据导入到Doris 基于Doris的能力进行针对性优化
3. 为了避免从『建立外表』->『数据导入』变更带来的影响。表、字段、列类型 都不会改变，即业务不需要调整
4. 『数据导入』我们使用Flink CDC 配合Doris提供的Flink Doris Connector , 将业务库的数据一比一实时的同步到数仓，即 增、删、改 行为的同步，Flink exactly once + 唯一模型 + 批量删除 实现两端数据的一致性，这是我们的数据分层中的原始数据层ODS层
5. 单纯的将数据一比一复制过来，并不能对查询带来明显的性能提升，如果业务库资源不错，还有可能更慢。需要在表结构（如分区分桶，合适的字段类型）与物化视图上 作文章，做大吞与大并发的取舍,能够得到明显的性能提升
6. 做到这一步后，如果希望有更高的查询性能要求，则需要对表结构进行变更，同时业务查询逻辑也需要配合做调整。做数仓的同鞋都知道，业务库的设计结构并不适合做分析，可能一个简单的指标输出，会跨个10-20张表也不是没可能，因此更进一步可以根据传统的维度建模理论，如星型模型，基于Flink对数据进行实时清洗，生成基于事实的不更新大宽表,和带常更新字段的维度表，分别使用Duplicate模型与Unique模型
7. 做到这一步后因为对原始的表进行了便于OLAP场景的重新规划，减少了不必要的表连接，因此性能上会再一次得到提升，并且因为明细表使用了Duplicate，因此可以通过物化视图对数据进行预聚合，进一对对查询性能的提升

数仓建设不能一蹴而就，需要循序渐进，更高的查询性能要求，意味着更高的维护、开发成本 , 总结数据整合及优化历程是：

1. 建立外表 - 实现跨库连表分析
2. 数据导入 - 减少业务库性能压力
3. 对数据导入的表进行表结构优化 - 增加查询性能
4. 对数据导入的表建立物化视图 - 增加查询性能
5. 维度模型规划维度表与事实表 - 增加查询性能
6. 对通过建模生成的事实表做物化视图 - 增加查询性能

话外篇

1. 在前面四步中，与业务的表结构是没有变化的，因此为了能对历史统计分析型系统做优化，我们开发Springboot Starter插件，通过加注解和拦截器或配置的方式，将本来在业务库中执行的查询逻辑转发到数仓执行，将执行结果封装成业务需要的格式，业务代码逻辑基本不用调整，以一个比较小的代价优化历史系统
2. 为了减少数据导入的成本，基于Flink CDC + Checkpoint + Exactly once + Flink Doris Connector + Doris批量删除方法 开发了mongodb-to-doris,mysql-to-doris 等Flink程序，抽象参数，实现复用

二、建立研发的数据库设计使用标准，以及实时数仓的相应规范，数据分层

1. 在数仓建设过程中，最大的敌手是业务数据的不规范导致了一系列故障，数据不准等问题，如：
   1. 使用19位以上的雪花算法生成的ID, 在Doris中会发生精度丢失
   2. 脏数据，如时间字段发生在了2036年/1970年，没法建分区
   3. 明明在业务上有值的，硬是有几条为Null
   4. 无主键设计
   5. update_time,create_time 逻辑不对,有的代码维护，有的系统生成
   6. 这里叫has_delete,另一边叫is_validate
   7. 字段长度问题
   8. 消息中件间使用不规范，多个系统数据对不上 - 系统间数据如何保证一致性
   9. 命名结构不统一 sex,gender , update_time,update_date
   10. 属性值不统一，这边0表示男，那边0表示女
   11. 我一定要用mongo存个2M的二进制图片进去
2. 这些上游的代码质量，数据质量问题，SQL查询，表结构设计等问题传递到下游数仓来，发生了一系列的灾难
3. 因此建立实时数仓的同时，亦要去抓上游，把上游抓好，数仓这个下游就能轻松很多，有的时候不是你不够优秀，而是上游拉跨了
4. 上游的优化思路可以是将每一个业务系统当成一个小型的数仓，每个小的数仓合并成一个大的数仓，统一规范，统一命名，统一标准，以一个人的视角来通盘设计 。 围绕这个思路建立相关的研发规范

话外篇

1. 深入到业务中非常有必要

三、建立统一的数据指标管理，数据资产管理

1. 实时数仓的建设不仅是数据的维护，也是企业数据资产的维护，汇聚了海量的业务数据，能否使这些数据产生价值，能否在老板有某个想法的时候快速响应，能否在客户有数据疑问的时候快速应答，能否在数据错误的时候快速定位
2. 这块市面上已经有比较好用的云服务产品、开源项目等，能够协助来做这方面的工作
3. 这是一个长期且需要耐心的工作