数据治理涵盖采集到输出报告的整个流程，是实战经验，数据质量评价标准，数据治理的目的是使用规范的方式减少埋坑，让后继者少踩坑。数据治理的核心是要将规范、组织和流程要落地形成文档，而且要清楚明了、能让人看懂认同，这样才方便一起去做。高大上不能落地，或者太抽象、难理解的东西也很推行。此外也要讲清楚这套东西落地后能给各方带来什么样的价值，可通过宣讲培训等方式去普及，相干方才有动力去做这件事。
概论
数据管理概论，结合具体的业务实际来讲
元数据
元数据管理是整个数据仓库中很关键的一环，尤其是埋点管理和血缘关系的获取（牛逼的算法）。数据可分为数据和元数据，其中数据就是一条条的记录，而元数据是描述数据的数据。可以分为以下三类（此处参考：数据资产管理白皮书3.0）。
元数据分类：
-
业务元数据
业务数据、指标定义、统计口径等
-
技术元数据
对象和数据结构的定义（若有抽象数据）、数据计算过程、调度依赖等
-
管理元数据
主要包括人员、权限职责和管理流程
元数据管理的主要内容：
- 上游是什么
- 下游是什么
- 历史长什么样子
- 是怎样定义的
- 父节点是谁
- 子节点是谁
元数据管理的职责：
-
数据采集
- 数据实体（系统、库、表、字段、负责人、数据量的描述）
- 数据实体加工处理过程中的逻辑
-
数据展示
- 将采集到的元数据分类存储之后，提供分类检索和展示功能
- 展示数据实体间的组合、流转关系
-
数据应用
- 主要是数据字典和数据血缘图
埋点管理
元数据管理的基础的基础是埋点管理，因为埋点数据是最原始的上报的，要求埋点管理详细记录每个埋点和开始和结束时间(若下线)、属性键的更新、属性值的增删改情况(严格杜绝不同的场景用同样的属性值)，最重要的是要详细标注事件的上报时机（尤其是曝光事件的上报时机）。
埋点管理可以细分为元素管理、事件管理和上报管理，不管哪种管理方式一定要做到做到可追溯，可在此基础追溯版本和修改历史。比如以下场景：
- 某个元素（页面、控件）是什么时候（版本）出现的，什么时候（版本）下线的
- 某个事件（属性）的增删改时间和版本
- 基于元素和事件的上报逻辑是否调整过等，调整的时间和版本信息是什么
元素管理
元素管理主要指页面、控件的处理，主要体现在界面上的变动，对用户是显性可见的
事件管理
事件管理主要处理事件的增减、事件属性的增减和修改；
上报管理
上报管理处理的是上报时机（实时或延时）、上报环境（2/3/4g，wifi等），以及其它自定义的上报策略（路径上报、独立上报还是心跳上报等）
生命周期
生命周期管理主要是指存储治理，是在数据从生产、使用、归档和删除整个生命周期进行有效的管理。
归档和备份的目的主要是为了提高数据安全和数据操作性能，而配置的备份和恢复是为了规避迁移问题。即使在项目初期，存储也不该野蛮的增长，提前做好存储的规划布局，后面会受益良多。
归档销毁
归档的本质是为了压缩数据，或者减少存储、或者提高查询性能。一是要做好归档的策略，此外良好的数据仓库体系结构也能很大程度上减少数据冗余，减轻归档的压力。
仓库数据
要对数仓数据有整体的概况，包含以下几点：
- 数仓表的访问次数（从ｊｏｂ的角度统计）
- 数仓表的最后更新时间
- 数仓表的存储状况和数据量增长状况等的数据盘点，增量预估
治理措施：
- ods/odl、dw/bdl、dm/sdl、da层的数据处理问题（这个地方几乎是空白的，全靠开发人与自身的素质）
- mid中间表的清理
- 临时表的清理
- 很久不使用的表的清理
拉链表数据的清理策略（待确定）：
- 快照型的拉链表，可以选择保留部分，比如每个月最后一天的。
- 历史链的拉链表，只保留最新的即可。
文件数据
- HIVE计算落地中间导出的文件数据的清理
中间导出文件的命名规范化,脚本名_${date}.data,最后再删除的时候可以用正则匹配的方式删除
- 同步过来的其它文件源数据
报表数据
牵涉到报表的mysql数据的存储问题，当数据量大的时候如何实现高效查询，处理冷热数据。此外还牵涉到报表数据的存储时限问题，核心数据永久保留，像分组数据、自定义查询数据等的保留时限并未做规定，应该是从日常的使用中总结出滚动删除的日期。此外报表数据的上下线也自动通知到相关的人员，这就要求在配置报表之初要配置相应的人员。
执行备份
在上一篇中介绍了数据的归档和销毁的管理，此外对数据的加工处理过程也是需要及时备份。这个处理过程牵涉到以下方面：
- 结构（hive表、mysql表、kylin模型和Cube等）
- 依赖关系（调度计划）
- 代码（统计代码）
- 运行环境（代码的执行环境）
备份的本质是一则是为了保证数据安全，主要体现在数据出问题的时候可以及时恢复、避免数据丢失等灾难；二则是为了提高数据吞吐性能，比如做主从备份、读写分离等。
任何单点的结构都是不可靠的。可能出问题的，最后一定会出现问题，要做好事前的预防，在可操作的基础上尽量减少问题出现的可能性，同时也要做好热备，一旦出现问题，要能快速的切换。
表结构
备份表的结构，有以下两种方式：
- 定期从库中导出表的结构(mysql表结构容易导出，但是hive的表结构好像不能一次性直接导出)
- 在建立数据仓库的同事维护mysql和hive两层表结构
在表结构存在之后，在脚本中操作相关的表时候，有以下两种方式：
- 先判断表是否存在，如果不存在，则创建对应的表然后操作，这个功能可以做成一个全局控制的，来判断是否进行相应的检查
- 表结构的定义单独存储，然后整体执行相关，这个可以做成自动化的程序。
运行环境
运行环境主要包括机器环境和计算脚本，机器环境包括以下：
- HIVE的客户端（此处主要牵涉到授权）
- MySQL服务器(版本、配置、函数和存储过程等)，若牵涉到内存表则更加麻烦
- Python等其它依赖程序，因为牵涉到流处理，牵涉到Python的版本和相应的依赖库
- 计算脚本中的环境变量和全局设置依赖等
计算脚本则包括以下：
- 全局配置global_var.sh和global_fun.sh的位置等（此处牵涉到环境变量）
- 全局配置中指向的环境（此处主要指MySQL结果的存储机器及账号授权情况）
此处就体现出了脚本鲁壮性的作用了。
