数据治理的目的是为了让数据更加准确，降低后续数据清洗的难度，节约成本，加强把控，好处是说不完的，但这实际开发中所遇到的问题却比好处要复杂，你可能考虑到所有的问题，但却无法预估问题解决的难度。
前不久读了一篇关于主数据治理的书，书里面有些理论给了我些许启发，比如提到数据治理的阶段，治理后所带来的各种优点，让我写文档的时候有很大的帮助，只不过工作中我感觉数据治理的难度很高，如果按照书中的说法，没有好的方法，耗费的时间，拉通的人力，足够让普通公司因此破产。
文中所得
数据治理的阶段
书中将数据治理的阶段分为五个阶段（初始级，可重复级，已定以级，已管理级，优化级，创新级）。
按照我的理解，初始级其实就是没有专门数据治理的情况，数据分析没有，或者是粗放式，凭借业务自己的理解开展工作，决策层完全依赖业务自身水准；可重复级就是有了初步的规范，这是目前市面上大部分大中型公司的现状，这不是我特意压低，而是实际就是如此，不说现在蓬勃发展的技术领域，单说数据领域，还是业务引导数据，不是数据推动业务，因为从各个业务系统回流的数据很多时候都只能适用于本身的营销和产品优化，不适用其他业务系统。
已定义级是大家现阶段追求的目标，经过长时间摸爬滚打，数据中的A就是A，你业务系统来个a，告诉我a是A，但是我可以有证据有信息的告诉你A!=a，不应该把a放在A里面，应该给a放在其他位置；已管理级是我的数据是标准，我可以拿着我的定义和各个系统的人沟通，他们这个月哪里好，哪里不好，数据的反应是真实的，应该把数据作为一把利剑，数据是材料，我们是打铁的。
最后的优化级则是个中间过程，这个我认为不应该单独分层，其实每一个层级都应该是优化级，如果真的想到了已管理级再到优化，请背一下大数据的四个V；最后的创新级那就是牛逼哄哄的了，你打开中国统计局，那个标准就可以了。
数据治理的优点
数据治理的优点，这玩意有点像画饼充饥，干数据开发的人都懂的什么叫没有使用的数据叫垃圾，书中很明确的表示了数据治理的成果是隐晦的，如果没有强有力的推动，那数据治理的优点就是0，不过数据治理如果有了一定成效，好处确实不少。
从营销上说，交叉销售是不是很重要，我明明有几百万到几千万的用户，知道他们的消费能力，知道他们的住址，知道他们的联系方式，却还得为了一款新的产品掏出几千万甚至几个亿来宣传；从采购上说，如果我是买冰淇淋的，我的囤货是不是可以更少，优化我的铺货；从IT部门说，我不是很理解一个业务部门三年换四个三方，如果我有数据，并且我是审计，我会好好和他们沟通。
从客户关系来说，渠道的经销商哪些好，哪些有风险；诸如此类，优点是需要通过点点滴滴的集市层来累加的。
数据治理的方法
书中对于数据治理的方法我感觉有些泛泛，也可能是我个人水平还没有到，书中核心是通过主数据治理来实现整体的数据治理，将数据治理的框架分为五个域，不同的人员负责不同的域，然后从元数据，主数据，数据质量一层层按照分析，设计，执行，评估来推动，理解下来就是调研实际情况确定概念模型，设计逻辑模型，出物理模型，评估数据。
自我思考
数据治理是一个长期的过程，也应该是一个明细的过程，从数据治理上来说，字段首先是有含义的，如何保证字段中的数据是符合含义的，又如何保证这些符合含义的数据格式是相同的，单一个字段，如果依靠主数据，是不太可能实现的，可如果要是一个字段一套清洗，难度和耗费的时间会很大；字段中空值是为什么空，清洗过度？ODS存在空值问题？
可是如果一个个字段去清洗，预算就先给你喊停，这个时候上面提到的分析-设计-执行-评估就派上用场了，理论指导现实，我们需要分析字段哪些是可以作为主数据字段，受到集团或者不同事业部把控的，哪些是需要着重设计不同清洗规则的；哪些是需要设置报警的，然后就开始执行，最后就是评估。
考虑完所有的字段就好了吗？自然不是，还需要考虑元数据，其实元数据是第一个需要考虑的，只不过高屋建瓴比一步步搭积木要难很多，所以可以在开发中考虑，元数据就是上面提到的字段名称，字段含义，单说一个省份，在交易模型，物流模型，员工模型里面都是不同的含义，如何取名，如何定义，一个开发理解了1+1=2，另外一个理解了2-1=1，又一个理解了2=1，bug就出来了。
实际问题
首先是开发人员的理解把控，不是技术层面的理解不同，而是要避免双方理解的不一致，需要有专门的审核机制和审核时间，这个在实际开发中很难办到，因为在产出都不是明确的情况下，很难有预算会把这部分算进去；
然后就是目前的外包机制，书中有提到请专门的解决方案专家或者项目组进行数据治理，从成本和效果上来说都是很好的选择，可数据治理的长期性也预示着成本和效果之间的把控很难，你没有办法要求在砍了一半预算的前提下要求乙方完成之前预期的效果，也没有办法衡量乙方多少事情是需要付钱的，多少是被白嫖的。
最后就是业务系统的压力了，如果有个部门是专门为找你茬或者减少你预算设立的，而且他们的发展还需要你的帮助，你会乐意吗？答案显而易见，专门的协调者是不能少的，不能畅想未来，却没有时间和人力去调研现状。
治理目的
数据治理的目的我理解其实就是为了一件事情，专业的话是打破数据孤岛，通俗的话就是让看起来互不相容的数据串联起来，从最初的制造到最后的售卖应该是一个环形，没有数据治理前或许能够将这个环形连上，只是道路是歪斜的，而有了数据治理可以让道路一马平川。
收益付出
看数据治理的收益是需要记录每个数据类型项目的开发成本和难度的，波动的折线图是比数字更有说服力的，现在的一次性沟通成本能够减少未来多次的沟通；降低报错问题出现的频率，中台的运维中应该有因为发散或者是数值类型错误导致的报错，这些工作在数据治理后会得到优化；反馈给业务的数据，不能说数据反馈到业务，数据类型的项目就等于了回报，业务根据这些数据产出的价值减去他之前没有这些数据产出的价值有一部分也是数据治理的效益。
上面主要是收益，那么付出呢？作为负责人，你可能会接受无止尽的加班，不知道和你对接的人什么时候有时间，你会面对很多突如其来的问题：同事的职位变动；预算的变动；上面的责问；业务的催促等等。作为开发，你会面临各种问题，永远没有结束的问题，沟通不到位，想甩开烂摊子离职的冲动，没有时间优化的代码。
我给出的办法就是预留时间，拆分问题，解决问题，解决重要且紧急的，沟通不重要但是紧急的，确定重要但是不紧急的，拒绝不重要而且不紧急的。
上面的数据治理不涉及数据集成，数据存储等等，仅仅针对数据开发阶段，别问我为什么不说，因为我接触太少。
