前言
之前写了点数据治理的大概定义，中间的工作中也接触到了一部分的数据治理（大概是）工作，最近在复习数仓建模的一些东西，正好结合做个整理备忘，按我自己理解的方式去看数据治理。
背景
数仓在大多数场景里都有运用到，这里按数仓分层的逻辑来讲点数据治理的东西。
叠甲
可能有些地方我理解有问题，不在数据治理工作中，就当是自己的工作总结吧，有人提出大的问题，我再改改。小问题就凑合看看，当一个参考。
1.ODS/DIM 层
原始数据层： 大部分做的是直接获取到各数据来源的基础数据，获取和存储也有很多方式，不做单独的说明。在大多数情况都是要求保持数据不变动，所以在治理这方面，主要在于数据提供方。后面数据价值的成功发掘必须依托于高质量的数据，所以保证ODS层的数据质量是很有必要的。
维度层： 两个层是最贴近数据来源的地方，就和ODS层放在一起讲，基本是用更符合业务逻辑的维度表去规范ODS层的数据质量。例如：偏移量、非空检查、值域检查、规范性检查、重复性检查、关联关系检查、离群值检查、波动检查等等。需要注意的是，优秀的数据质量模型的设计必须依赖于对业务的深刻理解。
实践中：平时经常遇到本来设计的要有数据，要和其他地方有联系的数据，结果不是缺就是和设计的有出入，这直接导致一个问题，要两方来适配。最有效的方式就是反馈给业务方，整体修改，保证数据提供有效，平时开发能严格按设计来做。理论上虽然是这样，但是在业务方来看“系统能正常跑就行” ==。
好吧，在大数据这边做处理的话，目前来说也只是做些缝缝补补，
- 做数据的拉取时，加一层判断，初步做一些数据量变化，和数据合理性的判断。
- 数据归集，做一定的逻辑分析，可以更明确的看到业务中的问题，反馈给业务方，保证数据的可用性，这个也算大数据这边的一个功能吧，只能看到啥数据有问题让他们改。
- 再有就是数据清洗的一些工作，实在无法修改的，不影响下游的数据，可以做一定的清洗，保证数据质量。
其实能做的还是反馈给上游，保证质量，在抽取之后做的处理都是被动的，也有失原有的数据特性。
2.DWD层
数据仓库明细层（事实层） 用于存储经过清洗和加工的明细数据。作用将ODS层数据根据业务主体要求，将ODS数据抽取到DW层，在保证和ods层颗粒度一致的情况，形成一份最详细的明细数据，同时此层还可以进行一定维度退化的方案。最终优化出数据质量更高的信息，形成一个既定的事实，不允许修改。
- 合理的表设计：在明细表以上都是可以按已有逻辑，自己设计的，在这里就可以做一些表层面的治理方法，覆盖最大化，有效数据利用明确化，还有后面的血缘也是要考虑进去。可以根据经验和实际业务来规范表设计方案，毕竟符合自己业务的才是好用的。
- 血缘追踪：数据被业务场景使用时，发现数据错误，数据治理团队需要快速定位数据来源，修复数据错误。那么数据治理需要知道业务团队的数据来自于哪个核心库，核心库的数据又来自于哪个数据源头。血缘在每一层都该做好设计，明细层的特性就是不可修改的事实，放在这层讲，其实是贯穿整个数仓层的。在元数据和数据资源清单之间建立关联关系，且团队使用的数据项由元数据组合配置而来，这样，就建立了数据使用场景与数据源头之间的血缘关系。 做好需要和数据资产的整理，在后期修改和使用方面就能省很多时间。
3.DWS层
轻度汇总层：对一些比较常用的数据进行一步汇总，统一粒度，比如数量，金额等，为上层的数据应用提供基础数据。
这里大多是做过度用，承上启下。做好数据清洗，血缘追踪能提高这里的可用性。
- 这里的数据治理要按主要业务来规范数据，保证数据可用，做好承上启下。
- 对数据敏感，聚合出更有效的数据出来，为业务分析师和决策者提供可直接使用的数据，生成报表和图表，以支持业务决策。
4.ADS层
应用层：单在数据库数仓里，主要是按具体业务逻辑来做的一些贴近接口的数据处理。之前做的数据，转化成可用于业务决策和数据分析的可用数据。然后从中抽离出各种“接口”，提供给不同的数据使用方，最终实现数据价值。
- 这层做的基本不算是数据治理，主要是按产品需求来做对应的开发，逻辑缜密感觉算一个吧。保证自己的代码，算法不背锅，前面的数据处理没问题，有啥都可以甩给业务数据提供方。
- 还有一个数据权限问题，保证哪些用户对特定数据的访问权。做好数据脱敏，管理规范等。
小结
上面说的很多数据治理都是贯穿整个数仓的，哪一步没有做好，后面回头排查都得再捋一遍，很多时候的开发过程就是一次次试错，没法保证绝对的准确。所以重点还是细心吧，代码一定要逻辑缜密，注释该写就写的详细，第二天就忘的很常见。找资料时还看到一些“合规性管理”，“数据生命周期管理”，“人员治理意识提升”之类的，这些暂时没怎么接触到，感兴趣的可以按这些去搜搜看。
