数据仓库—数仓治理

原创

wx60dacb4325b51 2022-04-19 10:46:40 ©著作权

文章标签 大数据 java 数据仓库人工智能数据库 文章分类 数据仓库大数据

©著作权归作者所有：来自51CTO博客作者wx60dacb4325b51的原创作品，请联系作者获取转载授权，否则将追究法律责任

本文目录

数据治理

统一流程参考模型
为什么要治理
DMBOK的数据治理框架

数仓治理

治理的分类
数据源治理
数仓模型治理
数据服务治理
上下游约定

数仓评价(如何评价一个数据仓库的好坏)

数据准确性
时效性
覆盖性
建构层次清晰
数据准确一致
性能指标
成本指标
易用性指标
需求响速度
稳定性

总结
知识星球

数据仓库系列文章(部分已出，持续更新)

数仓架构发展史
数仓建模方法论
数仓建模分层理论
数仓建模—宽表的设计
数仓建模—指标体系
数据仓库之拉链表
数仓—数据集成
数仓—数据集市
数仓—商业智能系统
数仓—埋点设计与管理
数仓—ID Mapping
数仓—OneID
数仓—AARRR海盗模型
数仓—总线矩阵
数仓—数据安全
数仓—数据质量
数仓—数仓建模和业务建模

数据治理

元数据管理
数据质量
数据模型
安全管理
主数据管理
数据生命周期

数据治理（Data Governance），是一套持续改善管理机制，通常包括了数据架构组织、数据模型、政策及体系制定、技术工具、数据标准、数据质量、影响度分析、作业流程、监督及考核流程等内容。

统一流程参考模型

数据仓库—数仓治理_人工智能

image-20201205183104040

为什么要治理

数据仓库—数仓治理_数据库_02

image-20201205183119801

不论是金融行业、通讯行业、地产行业、传统制造业以及农业，其信息化的发展基本都遵循了“诺兰模型”。笔者认为企业信息化大致经历了初期的烟囱式系统建设、中期的集成式系统建设和后期的数据管理式系统建设三个大的阶段，可以说是一个先建设后治理的过程。

数据质量层次不齐

“数据资产化”的概念已经被大多数人理解和接受。不论是企业、政府还是其他组织机构，对于的数据资产的管理越来越重视。然而，数据并不等于资产，也就是说不是所有数据都是数据资产，数据中也有垃圾数据。我们需要治理的是能够为企业创造价值的数据资产，而不是全部数据。

数据交换和共享困难

企业信息化建设初期缺乏整体的信息化规划，系统建设大多都是以业务部门驱动的单体架构系统或套装软件，数据分散在这些架构不统一、开发语言不一致、数据库多样化的系统中，甚至还有大量的数据存放在员工的个人电脑中，导致在企业内部形成了一个个的“信息孤岛”。
这些“孤岛”之间缺乏有效的连接通道，数据不能互联互通，不能按照用户的指令进行有意义的交流，数据的价值不能充分发挥。只有联通数据，消除这些“信息孤岛”，才能实现数据驱动业务、数据驱动管理，才能真正释放数据价值。

打通各个业务线之间的数据建设，很多公司都是统一建设

缺乏有效的管理机制

许多企业都认识到了数据的重要性，并尝试通过生产系统的业务流来控制数据流，但由于缺乏有效的管理机制和某些人为的因素，在数据流转过程中，存在数据维护错误、数据重复、数据不一致、数据不完整的情况，导致了产生了大量的垃圾数据。数据产权不明确，管理职责混乱，管理和使用流程不清晰，是造成数据质量问题的重要因素。

存在数据安全隐患

近年来，随着大数据的发展，诸如此类的数据安全事件多不胜数。数据资产管理上，正在由传统分散式的人工管理向计算机集中化管理方向发展，数据的安全问题愈来愈受到人们的关注。

发现问题严重滞后

影响不清晰

数据变更对下游的影响不清晰，无法确认影响范围

DMBOK的数据治理框架

DMBOK是由数据管理协会（DAMA）编撰的关于数据管理的专业书籍，一本DAMA 数据管理辞典。对于企业数据治理体系的建设有一定的指导性

注：DAMA 是数据管理协会的简称，是一个全球性数据管理和业务专业志愿人士组成的非营利协会，致力于数据管理的研究和实践。

数据仓库—数仓治理_数据库_03

image-20201205183235954

数据控制：在数据管理和使用层面之上进行规划、监督和控制。

数据架构管理：定义数据资产管理蓝图。

数据开发：数据的分析、设计、实施、测试、部署、维护等工作。

数据操作管理：提供从数据获取到清除的技术支持。

数据安全管理：确保隐私、保密性和适当的访问权限等。

数据质量管理：定义、监测和提高数据质量。

参考数据和主数据管理：管理数据的黄金版本和副本。

数据仓库和商务智能管理：实现报告和分析。

文件和内容管理：管理数据库以外的数据

元数据管理：元数据的整合、控制以及提供元数据。

数仓治理

节约机器资源(存在很多废弃的逻辑和表，占用了大量的存储资源和计算资源)
节约人力资源(降低了开发和维护的成本)
数据资产沉淀

这个是一个长期的工作，类似于代码重构

治理的分类

粗治理

临时表的处理
无访问信息的表(统一管理元数据和adhoc 以及调度)
无下游依赖的表(得有调度系统)

细治理

专项性质的治理方案，主要针对有人负责的项目

运行时间长的任务
存储空间空间过大的表

数据源治理

据源，顾名思义就是数据的来源，互联网公司的数据来源随着公司的规模扩张而呈递增趋势，同时自不同的业务源，比如埋点采集，客户上报等。

数据源管理

配置了大量的重复数据源

数据源监控

可以监控数据量和数据质量

数据同步

数据同步是指不同数据存储系统之间要进行数据迁移，比如在hdfs上，大多业务和应用因为效率的原因不可以直接从HDFS上获取数据，因此需要将hdfs上汇总后的数据同步至其他的存储系统，比如mysql
sqoop可以做到这一点，但是Sqoop太过繁重，而且不管数据量大小，都需要启动MapReduce来执行，而且需要Hadoop集群的每台机器都能访问业务数据库；阿里开源的dataX是一个很好的解决方案。

数仓模型治理

数据划分及命名空间约定

表的命名就涉及到数据域的划分，因为表的命名需要将数据域囊括进去

根据业务划分数据并约定命名，建议针对业务名称结合数据层次约定相关命名的英文缩写，这样可以给后续数据开发过程中，对项目空间、表、字段等命名做为重要参照。
按业务划分：命名时按主要的业务划分，以指导物理模型的划分原则、命名原则及使用的ODS project。例如，按业务定义英文缩写，阿里的“淘宝”英文缩写可以定义为“tb”。
按数据域划分：命名时按照CDM层的数据进行数据域划分，以便有效地对数据进行管理，以及指导数据表的命名。例如，“交易”数据的英文缩写可定义为“trd”。-** 按业务过程划分**：当一个数据域由多个业务过程组成时，命名时可以按业务流程划分。业务过程是从数据分析角度看客观存在的或者抽象的业务行为动作。例如，交易数据域中的“退款”这个业务过程的英文缩写可约定命名为“rfd_ent”。
表命名规范需清晰、一致，表命名需易于下游的理解和使用
下线表的统一命名

常规表的命名

分层前缀[dwd|dws|ads|bi]_业务域_主题域_XXX_粒度
业务域、主题域我们都可以用词根的方式枚举清楚，不断完善，粒度也是同样的，主要的是时间粒度、日、月、年、周等，使用词根定义好简称。

中间表

中间表一般出现在Job中，是Job中临时存储的中间数据的表，中间表的作用域只限于当前Job执行过程中，Job一旦执行完成，该中间表的使命就完成了，是可以删除的（按照自己公司的场景自由选择，以前公司会保留几天的中间表数据，用来排查问题）。

统一指标和字段命名

相同的字段在不同表中的字段名必须相同。
核心指标要进行逻辑收口以及在元数据上进行维护

公共处理逻辑下沉及单一

底层公用的处理逻辑应该在数据调度依赖的底层进行封装与实现，不要让公用的处理逻辑暴露给应用层实现，不要让公共逻辑在多处同时存在。

核心模型与扩展模型分离

建立核心模型与扩展模型体系，核心模型包括的字段支持常用核心的业务，扩展模型包括的字段支持个性化或是少量应用的需要。在必须让核心模型与扩展模型做关联时，不能让扩展字段过度侵入核心模型，以免破坏了核心模型的架构简洁性与可维护性。

层次调用约定

应用层应优先调用公共层数据，必须存在中间层数据，不允许应用层跨过中间层从ODS层重复加工数据。
一方面，中间层团队应该积极了解应用层数据的建设需求，将公用的数据沉淀到公共层，为其他团队提供数据服务
另一方面，应用层团队也应积极配合中间层团队进行持续的数据公共建设的改造。必须避免出现过度的引用ODS层、不合理的数据复制以及子集合冗余。

垃圾的数仓就会出现大量的跨层调用，所以可以通过跨层调用ods 表率来衡量数仓的建设

组合原则

将维度所描述业务相关性强的字段在一个物理维表实现。

相关性强是指经常需要一起查询或进行报表展现、两个维度属性间是否存在天然的关系等。例如，商品基本属性和所属品牌。

数据拆分

对于维度属性过多，涉及源较多的维度表（例如会员表），可以做适当拆分

数据的水平和垂直拆分是按照访问热度分布和数据表非空数据值、零数据值在行列二维空间上分布情况进行划分的。

核心表

拆分为核心表和扩展表。核心表相对字段较少，刷新产出时间较早，优先使用。扩展表字段较多，且可以冗余核心表部分字段，刷新产出时间较晚，适合数据分析人员使用。

数据冗余

数据记录数较大的维度表（例如商品表），可以适当冗余一些子集合，以减少下游扫描数据量

sql 规范

任务注释

name: 任务名和表名保持一致
description：任务描述，该任务的主要内容
target：目标表名，一般一个任务只输出一个目标表
author：创建者，和创建日期，
modify：内容变更记录，变更人，变更日期，变更原因，这个从版本控制中也可以找到，但是这些这里更直观一些。

sql 模板

sql 的写法，sql 结构

数据服务治理

报表治理

接口治理

上下游约定

由于数仓的特性和定位，它就需要强依赖上游的业务系统，当然也会有一些下游系统，所以定好上下游的规范，变更的通知机制是非常有必要的。

上游约定

对于数仓来说，最重要的就是数据了，数仓中的数据，主要来源是业务系统，就是公司各种业务数据，所以数仓需要不断的将业务系统数据同步到自身平台来，所以一旦上游业务系统发生变化，数仓也要同步变化，不然，这种同步操作很可能失败。

表结构变更

上游的表结构经常会发生变化，新增字段、修改字段、删除字段（除非真的不用这个字段了，通常会选择标识为弃用）。
表结构最好要维护清楚，表名、字段名、字段类型、字段描述，都整理清楚，不使用的字段要么删除，要么备注好，当业务频繁发生变化或者迭代优化的时候，很容易出现，我写了半天的代码，最后发现表用的不对，字段用的不对，这就尴尬了。
对于这种变化，人工处理的话，就是手动在数仓对应的表中增加、修改字段，然后修改同步任务；这个最好可以搞成自动化的，比如，自动监控上游表结构的变更，变化后，自动去修改数仓中的表结构，自动修改同步任务。