数据治理-个人感想

1、数据治理是技术无关的，前期决定好怎么做，技术实现可以后续在商量（不仅仅是数据治理，所有的业务开发都是要理清楚业务之后才能考虑技术实现）。

2、数据治理是从上而下的，为什么？因为数据治理囊括了企业所有的信息系统，需要各个信息系统的业务开发团队的支持。而为了能够得到各个团队的配合，需要企业高层制定规章制度或KPI，对各个业务开发团队施加KPI上的压力。如果没有来自高层的施压，在和各个业务开发团队合作中，数据治理对于对方来讲是给他们增加工作量的事，对方本能的会排斥这件事。所以在合作的过程中，会提出各种借口拖延或者拒绝数据治理的工作。此时，来自高层的施压，会让他们较为配合数据治理工作。所以数据治理也需要领导对这件事有所认知。

3、数据治理过程中会存在业务和治理冲突的问题，这个冲突不仅仅是上述给对方增加工作量的冲突，还有业务市场层面上的冲突。即是业务开发部门为了应对市场需要，需要加班加点上线功能抢占市场。此时如果有治理工作进来，公司领导也会在权衡利弊下要求治理工作暂时让步，如果所有业务开发部门都这样做，那么治理的工作就没有意义，也没有成效。这也是为什么数据治理大多数都只有苦劳，没有功劳的原因之一。

4、数据治理的目标是提升数据质量。数据质量的提升个人认为来源于对数据的管控。这个管控是指“对数据设立标准和规范，在数据生产过程中，需要严格按照标准和规范来进行数据的生产”，生产这一动作存在于业务系统、数仓系统。

5、大多数企业在进行数据治理之前，就已经存在了海量的数据。在对数据定义标准和规范之前，需要准确的识别出哪些数据需要这样做，因为并不是所有的数据都需要定义标准和规范。在识别出需要管控的数据后，再针对存量数据和增量数据分别展开标准化、规范化的定义和改造。

6、在对数据进行标准化、规范化改造后，还需要持续的监督数据。需要定期对数据进行是否符合标准、规范的检核（数据质量检核）。检核的过程中发现了问题或者某一数据的标准发生变化，就需要通知对该数据有所使用的上下游业务团队，这一步也称为“影响分析”。

7、与“影响分析”相对应的还有“血缘分析”，即在数仓中，某一数据被加工利用的整条链路。不管是业务系统还是数仓系统，数据发生标准上的变化，都可以通过血缘关系查找到使用该数据的上下游业务，然后及时的通知到相应的业务团队。

8、数据治理被称为是脏活累活，个人认为有如下几点原因：

8.1、和业务部门合作的难题。来自部门之间的竞争，或是部门之间的推诿。

8.2、领导对于数据治理和业务市场的利益权衡，数据治理是花钱的事，业务部门是赚钱的事。

8.3、数据治理的成效很难量化，因为数据质量的好坏和治理是否存在关系，这一点不好判断。

8.4、业务部门长期繁重工作，无暇顾及数据治理工作，会让数据治理项目组进展缓慢，领导看到情况后会问责。