吃粽子、赛龙舟、喝雄黄
一年一度的端午节又到啦，在这佳节之际，祝福所有的朋友端午安
康、万事如意、财源滚滚啦～
上篇文章是基于快手的直播场景和大家聊了聊数据质量的话题，收
到了很多朋友的好评。今天趁着过节，赶紧再更新一篇，巧的是该
篇文章也是出自快手的实际落地方案。今天咱聊一聊数据治理这个
大话题，欢迎各位铁子批评指正。
摘要：今天分享的主要内容是模型规范在数据治理中的地位以及快手在模型规范上的具体落地方案。通过本文，希望兄弟们能收获一二。
分享时间：2021年6月14号
内容分享：孙老师
内容整理：皮卡丘
主要内容：
1、 数仓模型简介
2、数据模型规范简介
3、快手数据治理的背景
4、快手模型规范治理实践
5、快手数据治理体系思考
一、数仓模型简介
前言：作为在数据仓库混迹多年的老炮儿，这个问题肯定难不倒兄弟们。但为了贴合今天主题，再跟兄弟们聊一聊。如有表达的不准确的，希望各位兄弟批评指正。
正文：数据仓库建模包含了几种数据建模技术，其主要是Inmon（范式建模）、ER（ER建模）、Kimball（维度建模）。
1.1、Inmon（范式建模）：
Inmon建模的方式是自下而上的，那么什么是自下而上呢？我的理解是先打好广而全的数据基础，考虑当下业务场景中的所有可能，基于范式建模的理念去设计数据仓库，然后基于各种业务场景去开发数据集市以及BI应用。
1.2、ER（ER建模）：
E-R图的定义: ER模型，全称为实体联系模型、实体关系模型或实体联系模式图（ERD）是一种逻辑模型。
E-R的使用方法 ：
E-R图为实体-联系图，提供了表示实体型、属性和联系的方法，用来描述现实世界的概念模型。实体关系图表示在信息系统中概念模型的数据存储。
实体：现实生活中任何可以被认知，区分的事物（长方体）
联系：实体之间的关系，可以一点一，一对多，多对多（菱形）
属性：实体的某一特性称为属性（椭圆形）。
1.3、Kimball（维度建模）：
kimball的方式是自上而下的，这种方式就不用考虑很大的框架。
针对某一个数据域或者业务进行维度建模，得到最细粒度的事实表和维度表。形成适用于某一个数据域、业务的数据集市之后，再集成各个数据集市为数据仓库。
这其中的要点就是保持各集市之间的一致性维度和一致性事实，不然在集成为数据仓库的时候很麻烦，会无法确认各个集市之间的数据具有关联性、通用性。
kimball的这种范式就是开发速度比较快，相对比较省事，但是后续维护会比较麻烦。
其中kimball 建模又分为星形模型、雪花模型、星座模型：
星形模型：是最常用的维度建模方式，下图展示了使用星形模式进行维度建模的关系结构：
PS：可以看出，星形模式的维度建模由一个事实表和一组维表成，且具有以下特点：
维表只和事实表关联，维表之间没有关联；
每个维表的主码为单列，且该主码放置在事实表中，作为两边连接的外码；
以事实表为核心，维表围绕核心呈星形分布；
雪花模型：是对星形模式的扩展，每个维表可继续向外连接多个子维表。下图为使用雪花模式进行维度建模的关系结构：
PS：星形模型中的维表相对雪花模型来说要大，而且不满足规范化设计。
雪花模型相当于将星形模型的大维表拆分成小维表，满足了规范化设计。
然而这种模型在实际应用中很少见，因为这样做会导致开发难度增大，而数据冗余问题在数据仓库里并不严重。
星座模型：也是星型模式的扩展。基于这种思想就有了星座模式：
PS： 前面介绍的两种维度建模方法都是多维表对应单事实表，但在很多时候维度空间内的事实表不止一个，而一个维表也可能被多个事实表用到。在业务发展后期，绝大部分维度建模都采用的是星座模型。
1.4、数据模型的作用：
数据模型是在业务需求分析之后，数据仓库工作开始时的第一步。良好的数据模型可以帮助我们更好地存储数据，更有效率地获取数据，保证数据间的一致性。
1.5、模型设计的基本原则：
高内聚和低耦合
核心模型与扩展模型分离
公共处理逻辑下沉及单一
成本与性能平衡
数据可回滚
一致性
命名清晰可理解
二、数据模型规范
前言：数据模型规范是整个数据治理工作中的重中之重，也是比较难做的一部分工作。基于目前正在做的项目，从架构部分到公共规范和大家聊一聊数据模型的规范。
正文：以下将从架构、公共部分规范两方面阐述数据模型规范
2.1、数据模型架构规范：
数据层次划分：
ODS：Operational Data Store，操作数据层，在结构上其与源系统的增量或者全量数据基本保持一致。它相当于一个数据准备区，同时又承担着基础数据的记录以及历史变化。其主要作用是把业务数据引入到大数据存储中
CDM：Common Data Model，公共维度模型层，又细分为DWD和DWS。它的主要作用是完成数据加工与整合、建立一致性的维度、构建可复用的面向分析和统计的明细事实表以及汇总公共粒度的指标
DWD：Data Warehouse Detail，明细数据层
Data Warehouse Summary，汇总数据层
Application Data Service，应用数据层
PS：具体仓库的分层情况需要结合业务场景、数据场景、系统场景进行综合考虑。
数据仓库架构：
该数据分类架构在ODS层分为三部分：数据准备区、离线数据和准实时数据区。在进入到CDM层后，由以下几部分组成：
公共维度层：基于维度建模理念思想，建立整个企业的一致性维度
明细粒度事实层：以业务过程为建模驱动，基于每个具体业务过程的特点，构建最细粒度的明细层事实表。您可以结合企业的数据使用特点，将明细事实表的某些重要维度属性字段做适当的冗余，即宽表化处理
公共汇总粒度事实层：以分析的主题对象为建模驱动，基于上层的应用和产品的指标需求，构建公共粒度的汇总指标事实表，以宽表化手段来物理化模型
2.2、公共规范：
层次调用约定：
应用层优先调用公共层数据，必须存在中间层数据，不允许应用层跨过中间层从ODS层重复加工数据。
中间层需要积极了解应用层数据的建设需求，将公用的数据沉淀到公共层，为其他层提供数据服务。应用层需要积极配合中间层持续改造公共层。必须避免出现过度的引用ODS层、不合理的数据复制以及子集合冗余。
ODS层数据不能被应用层任务引用，中间层不能有沉淀的ODS层数据，必须通过CDM层的视图访问。CDM层视图必须使用调度程序进行封装，保持视图的可维护性与可管理性；
CDM层任务的深度不宜过大；
原则上一个计算刷新任务只允许一个输出表；
CDM汇总层应优先调用CDM明细层。在调用可累加类指标计算时，CDM汇总层尽量优先调用已经产出的粗粒度汇总层，以避免大量汇总直接从海量的明细数据层计算；
CDM明细层累计快照事实表优先调用CDM事务型事实表，以保持数据的一致性产出；
避免应用层过度引用和依赖CDM层明细数据，需要针对性地建设好CDM公共汇总层
项目命名规范：
ODS层项目名称以ods为后缀，例如 ods_；
中间层项目名称以cdm为后缀，例如 cdm_;
应用层项目中，数据报表、数据分析等应用名称以bi为后缀，例如 bi_；而数据产品等应用名称以app为后缀，例如 app_
数据类型规范：
CDM数据公共层如果是引用ODS层数据，则默认使用ODS层字段的数据类型。其衍生加工数据字段按以下标准执行
金额类及其它小数点数据使用DOUBLE类型；
字符类数据使用STRING类型；
ID类和整形数值使用BIGINT类型；
时间类型数据使用STRING类型（如果有特殊的格式要求，可以选择性使用DATETIME类型）；
状态使用STRING类型；
空值处理原则：
汇总类指标的空值：空值处理，填充为零；
维度属性值为空：在汇总到对应维度上时，对于无法对应的统计事实，记录行会填充为-99（未知），对应维表会出现一条-99（未知）的记录；
三、快手数据治理的背景
前言：从本章节开始介绍快手基于模型规范在数据治理工作上的落地实践方案。
正文：快手数据治理工作的背景、定义及落地方案
为什么需要数据治理：
数据治理的定义：
数据治理如何让落地：
数据规范的重要性：
四、快手模型规范治理实践
前言：所有的方法论只有落地了才会得到验证，而落地又是一件很难的事。在数据治理这项工作中，快手一直秉持着 “数据质量是生命线” 的原则，所以在这件事上有着自己的执着。
正文：模型是数据治理很好的切入点，控制模型的质量可以大大减少数据质量的问题。
模型不规范带来的问题：
PS：这些问题，统统都是数据仓库面临解决的问题。所以，数仓在企业中是多么的重要，不言而喻了吧，兄弟们。
模型规范治理之路：
模型规范的思考：
模型分层规范：
指标定义规范：
指标管理流程规范：
案例实践：
数据孤岛治理：
指标一致性管理：
公共模型稳定性治理：
模型产出时效性治理：
五、快手数据治理体系思考
前言：正所谓学而不思则罔，思而不学则殆。在昂首阔步的同时也要低头多思考，这样才能保证在正确的方向上不断前行。
正文：带着思考进入到另一个高度，快手同样也在不断努力。
整体框架：
度量体系：
六、写在最后
数据治理的话题太大了，今天咱们只是摘取了其中的一小部分来聊一聊，后续有机会的话再输出几篇和兄弟们分享。如有表达的不到位或者不准确的，希望兄弟们留言，咱一起讨论学习。
路漫漫其修远兮，吾将上下而求索。加油~
往期回顾
更多精彩
作业帮实时数仓架构中的Doris是如何发挥神威的，一文玩儿透
点个在看你最好看
551
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
