数仓体系化建设知识点

发表于 更新于 分类于

针对数仓建设中涉及到的名词性内容进行梳理

基本架构

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
数据管理
    元数据管理
    数据质量管理
    数据标准规范
    数据指标管理
    数据安全
    数据地图
    数据门户

数据源
    日志数据
    埋点数据
    ...

数据采集
    Cannal
    Debezium
    MaxWell
    Flume
    DataX
    ......

数据计算
    实时
    离线
    机器学习

数仓分层
    ODS贴源数据层
    DWD事实明细宽表
    DWS轻粒度汇总层
    ADS高粒度汇总层
    DIM公共维表

任务调度
    Azkaban
    Crontab
    DolphinScheduler
    ......

运维监控
    Prometheus
    Grafana
    ......

模型架构原则

分层原则

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
不能为了分层而分层,分层没有最好的,只有合适的
    数据结构需要清晰
    数据血缘可以追踪
    减少重复数据开发
    数据关系条理清晰
    屏蔽原始数据影响

ODS(Operational Data Store)
    原封不动接入原始数据
DWD(Data Warehouse Detail)
    保持与ODS一样的数据粒度,提供一定的数据质量保证
    将数据清理整合规范化,脏数据/垃圾数据/规范不一致/状态定义不一致/命名不规范数据都进行处理
    为了提高明细层的易用性,会采用高一些维度退化手法,减少事实表和维表的关联
DWS(Data WareHouse Servce)
    进行轻度汇总,粒度比明细数据稍粗,基于不同的粒度构建数据
    基于DWD数据,整合汇总成分析某一个主题域的服务数据
ADS(Application Data Store)
    提供给数据产品,数据分析使用的数据,存放在ES,PG,Redis等系统供线上系统使用
    报表数据就是在这一层
DIM(Dimension)
    高基数维度数据:用户资料表,商品资料表,数据量可达千万或亿级别
    低基数维度数据:配置表,枚举值对应的中文含义,数据量在个位数或几千几万

主题域划分原则

1
2
3
4
5
6
按业务或业务过程划分
    业务指功能模块/业务线,业务过程指业务活动事件,下单,支付,退款
    
按数据域划分
    数据域是指面向业务分析,将业务过程或者维度进行抽象的集合
    业务过程被概况成一个个不可拆分的行为事件

模型设计原则

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
高内聚,低耦合
    主题内部高内聚,不同主题间低耦合
    明细层按业务过程划分主题
    汇总层按实体+活动划分不同分析主题
    应用层根据应用需求划分不同应用主题

核心模型和扩展模型分离
    核心模型包括的字段支持常用的核心业务
    扩展模型包括的字段支持个性化或少量的应用需要
    不能让扩展模型的字段过度侵入核心模型,会破坏核心模型的架构简洁性和可维护性

公共处理逻辑下沉及单一
    越是底层公用的处理逻辑就越应该在数据调度依赖的底层进行封装与实现
    不要让公用的处理逻辑暴露给应用实现
    不要让公共逻辑多处同时存在
    
成本与性能平衡
    适当的数据冗余可换取查询和刷新性能
    不宜过度冗余数据复制

数据可回滚
    处理逻辑不变,不同时间多次运行数据结果确定不变

公共开发规范

层次调用规范

1
2
3
4
5
6
7
8
9
稳定业务按照标准的数据流向进行开发,ODS->DWD->DWS-ADS
非稳定业务或探索性需求,ODS->DWD->ADS / ODS->DWD->DWS->ADS

规则
当出现DWD->ADS,说明主题域未覆盖全,应该把DWD数据落入DWS中
避免DWS中使用DWD又使用DWS表
避免DWS生成DWS表
DWS,ADS禁止使用ODS表,ODS表只能被DWD使用
禁止出现反向依赖,DWS依赖ADS表

数据类型规范

1
2
3
4
5
6
规则
金额: double或使用decimal(28,6)控制精度,明确单位分还是元
字符串: string
id类: bigint
时间: string
状态: string

数据冗余规范

1
2
3
4
规则
冗余字段要使用高频,下游3个或以上使用
冗余字段引入不应造成本身数据产生过大的延后
冗余字段和已有字段的重复率不应过大,原则上不应超过60%

NULL字段处理规范

1
2
维度字段,需设置-1
指标字段,需设置0

指标口径规范

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
就一个原则,主题域内,指标口径一致,无歧义

指标梳理
    将需求梳理到所有指标进行梳理,明确口径
    如果存在指标名相同,口径不一致,先判断是否进行合并
    如需同时存在,命名上必须能区分开
    
指标管理
    原子指标
        选择原子指标的归属产线,业务板块,数据域,业务过程
        选择原子指标的统计数据来源于该业务过程下的原始数据源
        录入原子指标的英文名称,中文名称,概述
        填写指标函数
        系统根据指标函数自动生成原子指标的定义表达式
        系统根据指标定义表达式以及数据源表生成原子指标SQL
    派生指标
        在原子指标的基础上选择了一些维度或者修饰限定词

数据表处理规范

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
增量表
    新增数据,增量数据是上次导出之后的新数据
    记录每次增加的量,不是总量
    只报变化量,无变化不用报
    每天一个分区
全量表
    每天所有的最新状态数据
    全量数据,有无变化都报
    每次上报数据都是所有数据
    只有一个分区
快照表
    按日分区,记录截止数据日期的全量数据
    有无变化都报
    每次上报数据都是所有数据
    一天一个分区
拉链表
    记录截止数据日期的全量数据
    记录一个事物从开始到当前状态的所有变化的信息
    拉链表每次上报都是历史记录的最终状态,是记录在记录在当时时刻的历史总量
    当前记录存的是当前时间之前所有历史记录的最后变化量
    只有一个分区

表的生命周期管理

1
2
3
4
5
6
7
8
9
按历史数据等级划分,等级越重要,生命周期越长
按表类型划分
    事件型流水表
    事件型镜像表
    维表
    Merge全量表
    ETL临时表
    TT临时表
    普通全量表

数仓各层开发规范

ODS层设计规范

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
同步
    一个系统源表只允许同步一次
    全量初始化同步和增量同步处理逻辑要清晰
    以统计日期和时间进行分区存储
    目标表字段在源表不存在时要自动填充处理

表分类与生命周期
    ODS流水全量表
        不可再生的永久保留
        日志按留存要求
        按需设置保留特殊日期数据
        按需设置保留特殊月份数据
    ODS镜像全量表
        按天存储
        历史变化保留
        最新数据存储最大分区
        历史数据按需保留
    ODS增量数据
        按天存储
        有对应全量表,建议只保留14天数据
        无对应全量表,永久保留
    ODS临时ETL表
        按需保留,用完即删
        最多7天

数据质量
    全量表必须配置唯一性字段标识
    对分区空数据进行监控
    对枚举类型字段,进行枚举值变化和分布监控
    ODS表数据量级和记录数环比监控
    ODS全表必须要有注释

DIM层设计规范

1
2
3
4
5
6
7
8
9
10
11
设计准则
    一致性
        公共维度在不同物理表中的字段名,类型,内容必须一直
    维度组合与拆分
        两个维度必须具有天然的关系,商品的基本属性和所属品牌
        无相关性,将杂项维度构建成一个集合杂项维度
        行为维度,经过计算的度量,但下游当做维度处理,点击量0-1000,1001-10000等,做聚合分类
        数据记录较大的维度,可以适当冗余一些子集

存储及生命周期管理
    按天分区,历史数据的保存周期按最大访问跨度来定

DWD层设计规范

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
存储及生命周期管理
    按天分区,历史数据的保存周期按最大访问跨度来定

事务型事实表设计准则
    基于需求的分析设计事务型事实表,针对下游较大的业务过程和分析指标需求,基于某个事件过程构建事务性事实表
    一般选用事件的发生日期或时间作为分区字段,便于扫描和裁剪
    冗余子集原则,有利于降低后续IO开销
    明细层事实表维度退化,减少后续使用JOIN成本

周期快照事实表
    周期快照事实表每行汇总了发生在某一标准周期的多个度量事件
    粒度是周期性的,不是个体的事务
    通常包含许多事实,任何与事实表粒度一致的度量事件都是允许的

累积快照事实表
    多个业务过程联合分析而构建的事实表
    用于分析事件时间之间的间隔周期
    少量的且当前事务型不支持的统计

DWS层设计规范

1
2
3
4
5
6
7
8
9
10
11
12
13
14
基本原则
    一致性,提供与查询明细粒度数据一致的查询结果
    避免单一表设计,不在同一表存储不同层次的数据
    聚集粒度可不同,不需要保持与原始明细粒度数据一样的粒度

基本步骤
    确定聚集维度,日期,商品类别,买家,卖家等
    确定一致性上卷,按月还是按天,按类目还是按商品汇总
    确定聚集事实,交易额,交易数量等

公共DWS设计原则
    数据公用性,是否被频繁用于数据分析
    不跨数据域,归属于订单数据域的汇总,不应该被聊天数据域引用
    区分统计周期,在表名上就应该进行说明,_1d一天,_td截止当天,_7d七天

数仓命名规范

词根设计规范

1
2
3
4
5
6
7
8
9
完整的数仓建设包含数据治理
表命名更多是对元数据描述的一种体现,命名规范越完善,从表名获取到的信息就越多
词根,可以用来统一表名,字段名,主题域名等

这个规范是因人而异的,不是一定要按照哪个标准来
如:
分层_数据产生团队_业务_主题域_自定义表信息_周期
分层: ods,dwd,dws,ads,dim
周期/数据范围: d(天),w(周),m(月),i(增量),u(更新),f(全量),l(拉链)

表名设计规范

1
2
3
4
5
6
7
8
9
10
11
12
这个是需要我们进行一步步完善的

常规表
    分层前缀[dwd|dws|ads]_部门_业务域_主题域_XXX_更新周期|数据范围

中间表/临时表
    中间表的命名规范一般来讲尽可能作为临时表看待
    如果出现强依赖,就应该归属到常规表中去
    tmp_常规表规范

维度表
    dim_维度信息

指标设计规范

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
公共规则
    所有单词小写
    单词之间下划线分隔
    可读性优于长度
    禁止使用SQL关键字
    数量字段后缀_cnt
    金额字段后缀_amt
    天分区dt,格式统一(yyyyMMdd / yyyy-MM-dd)
    小时分区hh(00-23)
    分钟分区mi(00-59)
    布尔类型is_业务,不允许空值

指标规则
    数量:cnt
    金额:amt
    比率:ratio
    天:d
    周:w
    平均:avg
    周累计:wtd

元数据管理

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
在hive时,我们通常有一个很头疼的问题
    即使我们对表名进行一系列的标准化规范,但是在使用时,仍然依靠的是人脑的记忆,或者desc查看表信息
    而且在有人修改过表之后,对这些信息无感知

采集
    收集数仓数据库数据表的元数据,注释信息,字段信息,数据量信息
管理及版本
    并且能够通过统一的门户进行表结构修改,对修改操作进行记录,并维护版本信息,这样就能确定到具体的负责人,并且及时恢复
告警
    也可以在元数据发生变动时提供预警操作,主要针对上游数据源结构发生改变
    
上面说的一些,是数据方面的一些管理,业务层面也有

在数仓里,除了基本的纵向的层以外,横向的业务也很重要
数仓总线->数据域->数据维度->指标
这方面尽量的手动的维护一下,并不需要频繁的变动
数仓总线是对数据域数据维度两者的一个概览图,其主要作用是让新人可以第一时间了解到整个数仓有多个模块,每个模块中又有多少业务需求
数据域的划分可以理解为工作划分,对应的工作有对应专业的人去做,划分原则就是尽可能不相互干扰
数据维度,根据业务场景以及可用的数据源,确定汇总粒度,尽可能选取最细粒度,根据粒度定义维度,其实最细的粒度就是最低层次的维度
指标的管理可以说是重中之重,在开发过程中没有谁说自己没和产品经理互掐过
将收集后的指标口径,以及计算逻辑进行统一管理

针对表,业务构建一个元数据管理平台(表数量级没到千级别手动维护也行),这样能带来什么样的好处
    1.表的快速定位
    2.维度信息清晰
    3.各开发人员分工明确
    4.追溯问题清晰

数据质量管理

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
并不是单单源数据需要进行数据质量管理,而是从数据生成到消亡这整个生命周期内会出现的质量问题,都需要有一套完善的管理体系

影响数据质量因素
    技术
        在使用数据处理各技术组件时出现异常造成的数据质量问题
    业务
        使用应用系统操作流程出现异常导致数据质量问题
    人为
        由于人为操作异常导致数据质量问题

怎么去做好数据质量管理
    定义好数据监控规则,对表基础信息指定模板化规则,并且支持自定义规则
    监控数据生成过程,监测ETL流程,对清洗数据进行定时检查
    及时告警并进行review
    对数仓任务进行评分

数据质量流程步骤
    提出质量需求
    提炼规则
    构建规则库
    执行检核
    问题检核
    分析报告
    落实处理
    知识库体系形成

数据质量检验标准
    数据完整性
    数据准确性
    数据合理性
    数据一致性
    数据及时性

数据指标管理

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
指标管理为什么怎么重要?数据指标体系必要性
    开发报表不扯皮,可以直接对着统一的指标管理平台进行讨论,也可以了解同一个指标的演变历程

开发需求常常出现的问题
    相同指标名称,口径不一致
    相同口径,指标名称不一致
    不同限定词,描述相同事实过程的指标,部分口径不一致
    指标口径描述不一致
    指标命名难理解
    指标数据来源及计算逻辑描述不清楚

数据指标的构成
    业务维度描述
        指标名称:是什么指标?GMV,LTV,PV,UV
        指标作用:基于什么产生的
        指标分类:同一事件设立的多个指标,用户域,广告域
        指标展现方式:数据展现的形式,表,接口,图形
    技术维度描述
        数据来源:基于什么数据,表,日志文件
        数据算法:指标计算逻辑
        数据更新频率:指标多久统计一次,天,小时
        数据存储方式:存储中间值还是最终值

数据服务管理

1
2
3
4
5
6
7
8
9
想一下,假如每一个报表接口都需要后端去单独做一层自定义开发,功能仅仅是取一些统计好的数值,工程量有多大,而且极其不好管理

建立统一的数据服务,将数据结构标准化,交互的接口提供统一的可视化管理页面,开发人员可以通过可视化管理API,降低接口理解难度,易于维护

参考:
magic-api
    https://gitee.com/ssssssss-team/magic-api
rocket-api
    https://github.com/alenfive/rocket-api