<>概述

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查询,表结构设计等问题传递到下游数仓来,发生了一系列的灾难
* 因此建立实时数仓的同时,亦要去抓上游,把上游抓好,数仓这个下游就能轻松很多,有的时候不是你不够优秀,而是上游拉跨了
* 上游的优化思路可以是将每一个业务系统当成一个小型的数仓,每个小的数仓合并成一个大的数仓,统一规范,统一命名,统一标准,以一个人的视角来通盘设计 。
围绕这个思路建立相关的研发规范
<>话外篇

* 深入到业务中非常有必要
<>三、建立统一的数据指标管理,数据资产管理

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

技术
今日推荐
阅读数 155
下载桌面版
GitHub
百度网盘(提取码:draw)
Gitee
云服务器优惠
阿里云优惠券
腾讯云优惠券
华为云优惠券
站点信息
问题反馈
邮箱:ixiaoyang8@qq.com
QQ群:766591547
关注微信