©2020-2024 ioDraw All rights reserved,
Privacy Policy
<>概述
Drois 从早期的百度项目，到开源Apache
Doris，到商业化的StarRocks，到各大云服务商，陆续上线，作为新一代的OLAP解决方案，在应用场景上表现得非常好
整理对近期对Doris实时数仓建设的一些思考
<>背景
*
公司有很多业务线，每个业务线有自己的产品，沉淀了各自业务的数据，也使用了各种不同的存储介质，Mysql,Elasticsearch,Oracle,MongoDB
等等
* 公司希望将数据打通，对数据联合跨库分析，输出结果
* 至于实时数仓的需求，主要是目前很少有人能接受 T+1的数据
* 公司目前的数据量在PB级以下，Hadoop生态暂时不需要涉及，目前Doris也在持续迭代，期待越来越好
<>主体思路
* 使用Doris对各类数据源进行整合，实现数据层面的打通
* 建立研发的数据库设计使用标准，以及实时数仓的相应规范，数据分层
* 建立统一的数据指标管理，数据资产管理
<>步骤：
<>一、 使用Doris对各类数据源进行整合
* 数据整合形式主要分为 『建立外表』、『数据导入』
两种，我们在部份业务初期，并未使用数据导入方式，因为数据导入需要额外的组件及维护成本，并且业务初期，需求变更导致的表结构变更是常事，还有业务初期数据量不大。综合以上考虑，在业务初始
基本策略是『建立外表』，建立的外表，Doris能够将跨库的SQL语法自动拆解，转换为各种类型的存储介质需要的语法结构，然后在Doris中进行数据合并。如：基于Doris实现Mysql与Es的联表查询
*
当某张表达到了一定量级，业务的数据库不能满足分析需求，同时也是对业务库产生了影响，影响客户层面的正常使用，此时就有必要使用『数据导入』，将数据导入到Doris
基于Doris的能力进行针对性优化
* 为了避免从『建立外表』->『数据导入』变更带来的影响。表、字段、列类型 都不会改变，即业务不需要调整
* 『数据导入』我们使用Flink CDC 配合Doris提供的Flink Doris Connector , 将业务库的数据一比一实时的同步到数仓，即
增、删、改 行为的同步，Flink exactly once + 唯一模型 + 批量删除 实现两端数据的一致性，这是我们的数据分层中的原始数据层ODS层
* 单纯的将数据一比一复制过来，并不能对查询带来明显的性能提升，如果业务库资源不错，还有可能更慢。需要在表结构（如分区分桶，合适的字段类型）与物化视图上
作文章，做大吞与大并发的取舍,能够得到明显的性能提升
*
做到这一步后，如果希望有更高的查询性能要求，则需要对表结构进行变更，同时业务查询逻辑也需要配合做调整。做数仓的同鞋都知道，业务库的设计结构并不适合做分析，可能一个简单的指标输出，会跨个10-20张表也不是没可能，因此更进一步可以根据传统的维度建模理论，如星型模型，基于Flink对数据进行实时清洗，生成基于事实的不更新大宽表,和带常更新字段的维度表，分别使用Duplicate模型与Unique模型
*
做到这一步后因为对原始的表进行了便于OLAP场景的重新规划，减少了不必要的表连接，因此性能上会再一次得到提升，并且因为明细表使用了Duplicate，因此可以通过物化视图对数据进行预聚合，进一对对查询性能的提升
<>数仓建设不能一蹴而就，需要循序渐进，更高的查询性能要求，意味着更高的维护、开发成本 , 总结数据整合及优化历程是：
* 建立外表 - 实现跨库连表分析
* 数据导入 - 减少业务库性能压力
* 对数据导入的表进行表结构优化 - 增加查询性能
* 对数据导入的表建立物化视图 - 增加查询性能
* 维度模型规划维度表与事实表 - 增加查询性能
* 对通过建模生成的事实表做物化视图 - 增加查询性能
<>话外篇
* 在前面四步中，与业务的表结构是没有变化的，因此为了能对历史统计分析型系统做优化，我们开发Springboot
Starter插件，通过加注解和拦截器或配置的方式，将本来在业务库中执行的查询逻辑转发到数仓执行，将执行结果封装成业务需要的格式，业务代码逻辑基本不用调整，以一个比较小的代价优化历史系统
* 为了减少数据导入的成本，基于Flink CDC + Checkpoint + Exactly once + Flink Doris Connector
+ Doris批量删除方法 开发了mongodb-to-doris,mysql-to-doris 等Flink程序，抽象参数，实现复用
<>二、建立研发的数据库设计使用标准，以及实时数仓的相应规范，数据分层
* 在数仓建设过程中，最大的敌手是业务数据的不规范导致了一系列故障，数据不准等问题，如：
* 使用19位以上的雪花算法生成的ID, 在Doris中会发生精度丢失
* 脏数据，如时间字段发生在了2036年/1970年，没法建分区
* 明明在业务上有值的，硬是有几条为Null
* 无主键设计
* update_time,create_time 逻辑不对,有的代码维护，有的系统生成
* 这里叫has_delete,另一边叫is_validate
* 字段长度问题
* 消息中件间使用不规范，多个系统数据对不上 - 系统间数据如何保证一致性
* 命名结构不统一 sex,gender , update_time,update_date
* 属性值不统一，这边0表示男，那边0表示女
* 我一定要用mongo存个2M的二进制图片进去
* 这些上游的代码质量，数据质量问题，SQL查询，表结构设计等问题传递到下游数仓来，发生了一系列的灾难
* 因此建立实时数仓的同时，亦要去抓上游，把上游抓好，数仓这个下游就能轻松很多，有的时候不是你不够优秀，而是上游拉跨了
* 上游的优化思路可以是将每一个业务系统当成一个小型的数仓，每个小的数仓合并成一个大的数仓，统一规范，统一命名，统一标准，以一个人的视角来通盘设计 。
围绕这个思路建立相关的研发规范
<>话外篇
* 深入到业务中非常有必要
<>三、建立统一的数据指标管理，数据资产管理
*
实时数仓的建设不仅是数据的维护，也是企业数据资产的维护，汇聚了海量的业务数据，能否使这些数据产生价值，能否在老板有某个想法的时候快速响应，能否在客户有数据疑问的时候快速应答，能否在数据错误的时候快速定位
* 这块市面上已经有比较好用的云服务产品、开源项目等，能够协助来做这方面的工作
* 这是一个长期且需要耐心的工作