数据仓库【数据治理】

一、数据治理的概念

    国际数据管理协会（DAMA）给出的定义：数据治理是对数据资产管理行驶权力和控制的活动集合。

    数据治理的最终目标是提升数据的价值，数据治理非常必要，是企业实现数字战略的基础，它是一个管理体系，包括组织、制度、流程、工具。本文重点从一个数据开发的角度上对数据治理做相应的措施。

    数据治理就是通过有效的手段对数据开发的全生命流程进行管控数据规范化、提升数据质量的所有活动，都是为了提升数据资产、提升数据价值。数据治理的最终目的是为了解决机器资源（存储资源跟计算资源）、人力资源，沉淀数据资产。

二、数据治理的痛点

1. 数据孤岛：由于新老系统升级、业务系统迁移等，造成多业务系统生产数据，跨业务线、业务部门数据共享性差，导致对无法对数据整体性评估，导致严重的数据孤岛问题。
2. 数据标准不一致：每个系统都有自己的一套标准，且不统一，比如字段明明不统一、字段单位不一致，异常值处理差异化，导致数据同名不同义，同义不同名。
3. 数据质量问题：数据的完整性、准确性、一致性得不到满足，很多元数据缺失，系统数据中存在很多数据质量问题。
4. 数据影响分析困难：当数据出现问题，不知道上游源头数据表有几个、那几个出现了问题；不知道对下游有没有影响，影响有多大，无法及时反馈给业务方，无法及时有效的评估数据的影响范围及价值。
5. 数据管理：数据采集混乱、重复采集；开发流程不统一、元数据不规范；上线流程不规范，造成数据整体的管理是混乱的。
6. 数据安全：数据权限混乱，不知道谁在何时何地访问，遇到问题，无法有效追责；数据机密信息未做分层管理，导致机密信息泄露。

三、数据治理方案

    本文主要聚焦于数据仓库开发相关的数据治理。在整个数据仓库开发的过程中，自始至终都会包含两个部分，一部分是数据仓库内部的自身建设；一方面是对接外部的数据需求。两者在整个数据仓库架构设计、开发落地中都是相辅相成的。

    在数据仓库建设初期，数仓公共层、标准层没有建设完成，为了快速响应业务需求，会直接从ods层表直接开发，数据开发的规范化、标准化未能及时落地，会造成很多后期需要优化的任务作业以及表；开发中期，新的业务需求跟初期设计的模型进行不断地融合，需要对数据模型不断地优化设计；在数仓开发后期，我们会对数据存储大、小文件多、占用计算资源多、计算时间长的任务进行集中优化。

一、按照开发流程来说，我们将数据分为以下几个阶段：

1. 事前阶段： 1. 制定开发规范2. 制定指标词根词素，规范指标命名3. 制定开发流程4. 制定数据验证规范
2. 事中阶段： 1. 严格按照开发规范进行开发，代码CodeReview，代码走查2. 上线流程制定checklist，从需求对接到任务上线做全流程关键节点记录3. 上线前数据核对、业务方数据核对、按要求数据回溯4. 数据质量按照强弱规则进行监控
3. 事后阶段： 1. 定期跟踪分析数据存储空间、计算时长、计算资源分析2. 定期跟踪任务执行看是否有数据倾斜、做sql优化

二、按照治理策略方面，可以分为以下：

1. 粗治理 1. 临时表处理：最好创建临时表的时候设置ttl为30天2. 无访问信息的表：统一管理元数据、adhoc以及调度3. 无下游依赖的表：需要依赖调度系统
2. 细治理 1. 任务：任务时长大于90分钟，是否可以做任务拆分、优化；2. 表：表访问的PV、UV；上下游依赖、近30天访问，做线下处理；3. 人：个人资产、应用统计评估，无效资产下线。4. 存储：数据存储大、小文件多的分别Top10，挨个进行分析。数据存储大的可以按照业务实际情况对TTL进行按需调整；小文件多的表进行小文件合并，甚至做下线调整。5. 计算：计算时间长、占用计算资源多的Top10，是否存在数据倾斜，有则进行优化，没有则是否可以转到白名单。

三、按照治理方向，可以分为以下几点：

1. 数据源治理 1. 管理：避免配置大量重复数据源2. 监控：数据量和数据质量3. 数据同步
2. 数据质量治理 1. 数据准确性：强、若规则监控2. 数据及时性：SLA基线设置3. 上下游变动通知：表结构、枚举值、下游约定
3. 元数据治理 1. 业务元数据：描述数据背后的业务含义，主题定义、业务描述、标准指标、标准维度；2. 技术元数据：数据源元数据、ETL数据、数据仓库元数据、数据应用元数据；3. 管理元数据：数据管理部门、管理责任人、数据安全等级等
4. 数据模型治理 1. 数据分层：ods、dwd、dws、dm、ads2. 数据主题划分及命名空间约定3. 统一指标和字段命名4. 公共处理逻辑沉淀5. 核心模块与扩展模块分离6. 层次调用约定7. 模型优化：维度建模，一致性维度、一致性事实，构建总线矩阵

总结

    数据治理是要贯穿整个数据仓库的设计开发全流程的，数据治理也不是能一步到位的，在我们不断对业务了解、数据了解、需求了解后，不断的优化迭代，设计开发出适合自己业务的数据仓库才是最好的。数据治理是一个不断雕刻的过程，有点类似代码重构，只有不断的将数据跟业务融合，才能不断的提升数据服务，体现数据仓库价值。