数据治理到底能不能干？

为什么是脏活、累活？

1. 源数据

烟囱式开发：

业务繁多、数据库多而乱，系统与系统之间错综复杂

数据库种类：

架构经历多次变迁，切换不完全，需要从Mysql、oracle、hbase甚至excle表中跨库、跨实例、跨种类才能获得有效业务数据

数据结构混乱：

同一字段，类型、命名都不一致

文档缺失：

无数据库文档或文档陈旧

2. 变迁

系统版本升级：

每一次升级都只是掩盖之前的错误，数据治理需要从源头

人员变更：

梳理过程中的大部分问题最终答案：

“不清楚，原来维护人已离职”

数据流转：

数据从源头经过很多次不规范的同步

3. 存量

各自为政：

各业务部门已有自己的统计逻辑和报表，同一指标汇总维度又不一致，梳理、治理、输出还要尽量不影响已有报表结果

半途而废：

前任都知道数据治理、统一出口的重要性，但只完成一部分就放弃了。

问题在于“完成的一部分”有人还在用

怎么开始？

1. 方法论

统一定义：

对个性化的数据指标统一规范定义

标准建模：

建立数据公共层对模型架构进行标准规范设计和管理

规范研发：

将建模方法体系贯穿在整个数据研发流程

工具保障：

通过研发一系列的工具保障方法体系的落地实施

2. 统一方法策略：统一归口、统一出口

 

 

图片来源：阿里巴巴 OneData

 

 

3. 统一业务归口

1.模型

规范化模型分层、数据流向和主题划分，从而降低研发成本，增强指标复用性，并提高业务的支撑能力。

2.规范

规范是数仓建设的保障。为了避免出现指标重复建设和数据字段难以理解的情况

(1)词根

词根是维度和指标管理的基础，划分为普通词根与专有词根，提高词根的易用性和关联性。

普通词根：

描述事物的最小单元体

专有词根：

具备约定成俗或行业专属的描述体，如：

-USD。

(2) 表命名规范

通用规范

表名、字段名采用一个下划线分隔词根（示例：clienttype->client_type）。

每部分使用小写英文单词，属于通用字段的必须满足通用字段信息的定义。

表名、字段名需以字母为开头

表名、字段名最长不超过64个英文字符。

优先使用词根中已有关键字（数仓标准配置中的词根管理)

在表名自定义部分禁止采用非标准的缩写

表命名规则

表名称 = 所处分层 + 业务主题 + 子主题 + 表含义 + 更新频率 + [分表：_0、_10]

(3) 指标命名规范

结合指标的特性以及词根管理规范，将指标进行结构化处理。

A. 基础指标词根，即所有指标必须包含以下基础词根：

基础指标词根	英文全称	Hive数据类型	MySQL数据类型	长度	精度	词根	样例
数量	count	Bigint	Bigint	10	0	cnt
金额类	amout	Decimal	Decimal	20	4	amt
比率/占比	ratio	Decimal	Decimal	10	4	ratio	0.9818

B.日期修饰词，用于修饰业务发生的时间区间。

日期类型	全称	词根	备注
日	daily	d
周	weekly	w
月	monthy	m
季度	quarterly	q	Q1 ~ Q4

C.聚合修饰词，对结果进行聚集操作。

聚合类型	全称	词根	备注
平均	average	avg
周累计	wtd	wtd

E.基础指标，单一的业务修饰词 + 基础指标词根构建基础指标 ，例如：交易金额 - trade_amt

F.派生指标，多修饰词+基础指标词根构建派生指标。派生指标继承基础指标的特性，例如：新增门店数量-new_store_cnt

(4) 清洗规范

确认了字段命名和指标命名之后，根据指标与字段的部分特性，我们整理出了整个数仓可预知的24条清洗规范：

数据类型	数据类别	Hive类型	MySQL类型	长度	精度	词根	格式说明	备注
日期类型	字符日期类	string	varchar	10		date	YYYY-MM-DD	日期清洗为相应的格式
数据类型	数量类	bigint	bigint	10	0	cnt	活跃门店

3. 统一数据出口

数仓建设保证数据质量以及数据的使用，对数据资产管理和统一数据出口之前：

统一指标管理，保证了指标定义、计算口径、数据来源的一致性

统一维度管理，保证了维度定义、维度值的一致性

统一数据出口，实现了维度和指标元数据信息的唯一出口，维值和指标数据的唯一出口

4. 数据资产沉淀

 

 

词根、命名归档

指标定义说明、指标树归档

维度、维度树、数据类型

计算逻辑统一，如：

利润、成本等形成标准计算公式

5. 流程改善

建立运维监控体系

开发流程(仅包含数据模型及 ETL )，关键节点维度、指标及计算逻辑确定

 

 

6. 标准化规范化数据流向

避免大量的烟囱式开发、重复生成明细表或轻度汇总表、分层引用等不规范性及数据链路混乱

 

标准化数据流向图

 

标准的数据流向进行开发：

即ODS–>DWD–>DWS–>APP 或 ODS–>DWD–>DWM–>APP

新业务数据流：

遵循ODS->DWD->APP或者ODS->DWD->DWS->APP两个模型数据流

寄语：一旦开始数据治理，不要半途而废

 

 

来源：志明与数据