数据仓库—数仓治理
本文目录
数据治理
统一流程参考模型
为什么要治理
DMBOK的数据治理框架
数仓治理
治理的分类
数据源治理
数仓模型治理
数据服务治理
上下游约定
数仓评价(如何评价一个数据仓库的好坏)
数据准确性
时效性
覆盖性
建构层次清晰
数据准确一致
性能指标
成本指标
易用性指标
需求响速度
稳定性
总结
知识星球
数据仓库系列文章(部分已出，持续更新)
数仓架构发展史 数仓建模方法论 数仓建模分层理论 数仓建模—宽表的设计 数仓建模—指标体系 数据仓库之拉链表 数仓—数据集成 数仓—数据集市 数仓—商业智能系统 数仓—埋点设计与管理 数仓—ID Mapping 数仓—OneID 数仓—AARRR海盗模型 数仓—总线矩阵 数仓—数据安全 数仓—数据质量 数仓—数仓建模和业务建模
数据治理
元数据管理 数据质量 数据模型 安全管理 主数据管理 数据生命周期
数据治理（Data Governance），是一套持续改善管理机制，通常包括了数据架构组织、数据模型、政策及体系制定、技术工具、数据标准、数据质量、影响度分析、作业流程、监督及考核流程等内容。
统一流程参考模型
为什么要治理
不论是金融行业、通讯行业、地产行业、传统制造业以及农业，其信息化的发展基本都遵循了“诺兰模型”。笔者认为企业信息化大致经历了初期的烟囱式系统建设、中期的集成式系统建设和后期的数据管理式系统建设三个大的阶段，可以说是一个先建设后治理的过程。
数据质量层次不齐
“数据资产化”的概念已经被大多数人理解和接受。不论是企业、政府还是其他组织机构，对于的数据资产的管理越来越重视。然而，数据并不等于资产，也就是说不是所有数据都是数据资产，数据中也有垃圾数据。我们需要治理的是能够为企业创造价值的数据资产，而不是全部数据。
数据交换和共享困难
企业信息化建设初期缺乏整体的信息化规划，系统建设大多都是以业务部门驱动的单体架构系统或套装软件，数据分散在这些架构不统一、开发语言不一致、数据库多样化的系统中，甚至还有大量的数据存放在员工的个人电脑中，导致在企业内部形成了一个个的“信息孤岛”。 这些“孤岛”之间缺乏有效的连接通道，数据不能互联互通，不能按照用户的指令进行有意义的交流，数据的价值不能充分发挥。只有联通数据，消除这些“信息孤岛”，才能实现数据驱动业务、数据驱动管理，才能真正释放数据价值。
打通各个业务线之间的数据建设，很多公司都是统一建设
缺乏有效的管理机制
许多企业都认识到了数据的重要性，并尝试通过生产系统的业务流来控制数据流，但由于缺乏有效的管理机制和某些人为的因素，在数据流转过程中，存在数据维护错误、数据重复、数据不一致、数据不完整的情况，导致了产生了大量的垃圾数据。数据产权不明确，管理职责混乱，管理和使用流程不清晰，是造成数据质量问题的重要因素。
存在数据安全隐患
近年来，随着大数据的发展，诸如此类的数据安全事件多不胜数。数据资产管理上，正在由传统分散式的人工管理向计算机集中化管理方向发展，数据的安全问题愈来愈受到人们的关注。
发现问题严重滞后
影响不清晰
数据变更对下游的影响不清晰，无法确认影响范围
DMBOK的数据治理框架
DMBOK是由数据管理协会（DAMA）编撰的关于数据管理的专业书籍，一本DAMA 数据管理辞典。对于企业数据治理体系的建设有一定的指导性
注：DAMA 是数据管理协会的简称，是一个全球性数据管理和业务专业志愿人士组成的非营利协会，致力于数据管理的研究和实践。
数据控制：在数据管理和使用层面之上进行规划、监督和控制。
数据架构管理：定义数据资产管理蓝图。
数据开发：数据的分析、设计、实施、测试、部署、维护等工作。
数据操作管理：提供从数据获取到清除的技术支持。
数据安全管理：确保隐私、保密性和适当的访问权限等。
数据质量管理：定义、监测和提高数据质量。
参考数据和主数据管理：管理数据的黄金版本和副本。
数据仓库和商务智能管理：实现报告和分析。
文件和内容管理：管理数据库以外的数据
元数据管理：元数据的整合、控制以及提供元数据。
数仓治理
节约机器资源(存在很多废弃的逻辑和表，占用了大量的存储资源和计算资源) 节约人力资源(降低了开发和维护的成本) 数据资产沉淀
这个是一个长期的工作，类似于代码重构
治理的分类
粗治理
临时表的处理 无访问信息的表(统一管理元数据和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 结构
数据服务治理
报表治理
接口治理
上下游约定
由于数仓的特性和定位，它就需要强依赖上游的业务系统，当然也会有一些下游系统，所以定好上下游的规范，变更的通知机制是非常有必要的。
上游约定
对于数仓来说，最重要的就是数据了，数仓中的数据，主要来源是业务系统，就是公司各种业务数据，所以数仓需要不断的将业务系统数据同步到自身平台来，所以一旦上游业务系统发生变化，数仓也要同步变化，不然，这种同步操作很可能失败。
表结构变更
上游的表结构经常会发生变化，新增字段、修改字段、删除字段（除非真的不用这个字段了，通常会选择标识为弃用）。 表结构最好要维护清楚，表名、字段名、字段类型、字段描述，都整理清楚，不使用的字段要么删除，要么备注好，当业务频繁发生变化或者迭代优化的时候，很容易出现，我写了半天的代码，最后发现表用的不对，字段用的不对，这就尴尬了。 对于这种变化，人工处理的话，就是手动在数仓对应的表中增加、修改字段，然后修改同步任务；这个最好可以搞成自动化的，比如，自动监控上游表结构的变更，变化后，自动去修改数仓中的表结构，自动修改同步任务。
枚举值
业务系统中会有很多的常量，用来标识一些状态或者类型，这种值经常会新增，数仓中会对这些值做些处理，比如转换成维度，会翻译成对应的中文，而实际上这种映射关系，我们是不知道的，只有业务开发才知道，所以最好可以让他们维护一张枚举值表，我们去同步这张表。
create_time & update_time
正常来说，create_time，当这条记录插入后，就不会再变了，但是某种情况下，哈哈，开发同学会去更新它；update_time，当这条记录变化后，这个时间也要变，有的开发同学不去更新它 所以在做增量操作的时候，一定和开发说好这两个字段的定义和使用场景。
is_delete & is_valid
有些场景下，我们需要删除某些数据，一般不会物理删除，会通过一个字段来做逻辑删除，请和开发同学沟通好，使用固定的一个字段，并确认该字段双方的理解是一致的，不然后面又很多坑
下游约定
对于数仓来说，一般的邮件、报表、可视化平台都是下游，所以当我们在数仓中进行某些重构、优化操作的时候，也需要通知他们。 主要就是对数仓模型做好维护，表的使用场景、字段描述等。对上游的要求，自己也要做好，因为自己也是上游。
数仓评价(如何评价一个数据仓库的好坏)
其实对整个数仓而言，我们关注的就三个点，准确性、时效性、稳定性
面试官说这些都是一些原则，比较虚，有没有可衡量的指标？就是一个数据仓库建好了，用这些指标评价它好不好，有不好的要指出来，指导它改进。
指标项
失败的离线任务个数 没有按时完成的任务个数 ODS 同步超时的任务个数
数据准确性
对外的报表提供反馈机制，对数据准确性进行跟踪 数检平台的整个平台的数据准确性进行监控(到后期能不能利用机器学习去监控，否则你要定制大量的规则)
时效性
针对数仓的对外提供的数据能否满足失效性的需求 监控数仓任务的运行时长进行优化 能否快速响应业务的数据需求
覆盖性
我们主要指的是对数据域的覆盖情况
建构层次清晰
纵向的数据分层，横向的主题划分，业务过程划分，让整个层次结构清晰易理解
数据准确一致
定义一致性指标、统一命名规范、统一业务含义、统一计算口径，专业的建模团队
性能指标
通过统一的规划设计，选用合理的数据模型，清晰统一的规范，并且考虑数据的使用场景，使得整体性能更好
需要持续不断的业务逻辑重构，是整体的sql 水平上升，提倡优化精神
成本指标
避免烟囱式的重复建设，节约计算、存储、人力成本。
易用性指标
复杂逻辑前置，降低业务方的使用门槛
通过冗余维度和事实表，进行公共计算逻辑下沉，明细与汇总共存等为业务提供灵活性
需求响速度
数仓建设的好，底层设施完善，报表开发人员就可以快速响应业务方的需求，跟上业务方快速试错、快速尝试的节奏
稳定性
稳定性影响了时效性，也就是决定了我们的数据能不能按时产出，衡量稳定性的方式，我们可以使用三个9，或者四个9，甚至是用每天失败的任务数除以总的任务数，我们的主要目标是得出一个相对合理的指标，从而不断的去优化它。
总结
数据治理和代码重构一样，是一个慢活，但是它不能不做，因为数据治理可以提高整个数仓的管理效率，从而更好的服务业务 数据治理需要一些数据去指导，同理它的成果需要从数据方面去衡量，所以在整个过程中需要数据去证明它的价值与意义 数仓本身也需要自身的指标去衡量，我们可以通过数据治理，使得数仓的指标得到改善，这样我们也可以证明数据治理的意义。
知识星球
其实知识星球我以前就建立了，当时觉得自己没有那么多的精力维护，不能很好的帮助有需要的同学们，所以一直没有开放。最近很多同学私聊我学习路线，个人精力也是有限，并不能及时解答所有同学的问题。
通过调查，大部分同学表示愿意加入知识星球，我也觉得这样让大家的提问更加有层次和意义，而不是问一些比较肤浅和不太合适的问题，有问题也能自己先查询一下，这样更好的交流和解答疑问，提升时间利用率。
这里生成了50张5折优惠券，先到先得，领完为止（星球人数每增加50人，价格上涨10元）。