各位对数据治理的看法？

理论上来说肯定是前期治理比较好，但是在现实的项目中，存在一个风险是否可控的问题，比如说项目前期没有对需求进行很好的规划，或者需求产生比较大的变更，所以说实话具体问题还得具体分析。收起

说起数据治理其实是一个很偏见的词，如果把数据抽象为对象来看是与人平等的，人也可以看做成“对象”，人的治理？很不舒服吧，做数据首先要尊重数据。数据本身要从三个层面来看待，第一是业务层面，第二是技术层面，第三是系统层面。第一从层业务层面来讲，例如A业务中生成的数据都是客观存在的A业务数据，对于B业务来说好不意义，那么B有资格把A业务数据删除掉么？对B来说是数据治理，但对于A业务来说是极其不公平事，所以无论在A业务还是B业务来说数据是业务过程中自然产生的，大家都应该尊重他，数据没有犯错，就像一个无辜的孩子，决定不了自己能不能来在这个世界上。
第二层面是技术层面，技术可能会在业务的范围能对数据做一些相对价值数据的考量来做数据筛选和清洗，就是所谓的ETL，无论是以往的DW还是现在的分布式，ETL都是技术的重中之重，治理数据我一直认为是技术人员的治理，一个负责的人喜欢数据技术那么他会对每一条数据都尽量做到精准，结构化过程中字段的选择会尤其上心，让数据可以充分发挥自身的价值，让数据展现在人们的眼前，不会让数据沉默在漆黑的数据库里，即使暂时没有起到作用的数据也会保存到安全的数据库中，等挖掘技术的成熟会依靠数据自身来发现新的业务场景，国外的FICO公司用信用卡消费推测保险行业的用户出险率，并且极高的准确率，这是跨行业的数据使用，在国内可能会让人想象不到，可人家做到了对数据的尊重，所以技术层面治理数据我认为是人价值观的自我治理。第三个是系统层面，往往有些廉价系统或操作不规范导致数据的缺失或字符串不全，这是很可悲的一件事，没有谁刚出生就希望自己是残疾，那么遇到这样的情况，公司的运营人员应该想一想了，如何把数据补全，技术人员任何可以完善系统，至于数据模型、方法论这些都是技术层面的小事，有空看几本书自然就会了。收起

回复 18# jielee


    每个人遇到的问题都不一样，我只是把我的想要探讨的问题说出来，至于您说的关联表的问题，源业务系统涉及到钱，这个在银行会涉及到运营、财务、客户所属分支机构，客户信息修改要走一些系列流程，关联表这种方式核心系统是不可能这么做的，否则的话您拿军官证存的钱我给您改成身份证万一改错了怎么办，前台入错了怎么办，您再拿军官证钱取不出来了，对于银行来说保证系统安全、稳定第一位，至于功能第二位，这种涉及客户变更是不可能在关键业务系统修改的。所以我探讨的看法是先用ECIF规范源系统的输入框，保证增量正确，全量信息如果实在处理不了，那么只能错着了。数据治理是由于IT系统建设多年、多厂商、多标准而产生的，我相信数据仓库只要建设到一定阶段大家都会遇到这类问题，数据质量关乎数据仓库的成败，如果基于数据仓库分析的结果由于数据错误而导致结果错误，高层会认为数据仓库没起到作用，对于数据仓库这类长期投资项目会产生很大影响。收起

回复 17# julian1983


    理论上可以，但是不好执行，而且这样容易引起基层人员对IT部门的反感，他们会认为IT部门系统没做好，我输入错了怎么不提示我，人之本性，嘿嘿收起

我觉得，在源头进行治理比较一劳永逸，结合您行新客户风险报送系统看，
当时许多问题数据，都是在源头进行修正的，然后后面跟着仓库、集市、应用系统，啥事都不干
这也是该项目为什么能得到银监会的表扬，同样的团队，在其他行做就不行。

虽然当时因为是业务牵头的需求，也算是他们自己的事，所以基本全是在源头修正的，
然后源头没法治理的，可能会是，源头系统没法改造了，没有维护人员，开发公司都黄了等等，
这种情况没办法，只有在后面单独治理，但是，说实话， 效果不好，每次出现
新的数据的时候，必须在后续系统进行处理，事情很多。

单纯的说数据治理，个人还是觉得源头好些。收起

回复 11# cuicuitiger


我怀疑，你是想让大家来认可你的一个想法，而不是在这个方面真的有问题可问。

至于你说的那个例子，在我所做的工作中，可以忽略不计的。

在同一个系统中，某人用了两个证件，A证件是军官证，B证件是身份证。
那么你怎么知道这是同一个人？姓名？家庭位址？老婆的身份证号？

只要你的规则具有通用性，就一定能建立一个对应表，表中可以把这个人的A、B证件号码关联起来。
然后，我基于这个对应表，把所有使用了B证件号码的地方，都换成A号码，不就行了。

你想在源头上治理，让大家都要用身份证，不要用军官证，也行，问题是，你说这话，好使不？

如果说这个就有效，基层人员马上就把用军官证的数据都改了。那么，以上说的都可以忽略。
如果这个话不好使，基层只有一半人员，甚至70%的人员都改了，另外30%的问题数据，你是不是要在统计分析时排除掉？

这个问题已经不再是技术问题，完全是业务问题……收起

是否有可能将源系统的数据质量工作纳入基层绩效考核的一个因素，引起一线人员的重视收起

回复 15# yaozw
目前看没有好的管理手段，前端系统也不会因为数据治理而进行大范围修改，比如数据字段类型或者数据长度。
我们当时管理层也针对数据质量发了很多文件，但是基层执行没有有效的执行保障，比如对公客户资产规模人员规模5000人，但是资产才400W，这明显不合理，基层人员就是少如入3个0，但是如果在有相应的技术规则验证，那么5000人的人员规模，就不可能是百万级的资产，那么系统会自动决绝此次录入要求业务人员重新校对。收起

目前我在验证的一个有效治理数据质量的手段就是采用技术限制，这个跑出了数据仓库的范围，我们目前在做客户整合，在数据仓库层面T+1模式的客户整合已经完成，发现了很多数据质量问题，都是源系统的问题，源系统也不会去更正，因为涉及层面太多，数据质量已经成为数据仓库发展的一个瓶颈，但是数据治理科技部门推不动，必须上升到全行层级，改造各源系统，这样的话成本太高，我就想在建设ECIF的时候少量改造源系统，主要是输入框限制，让这些源系统先连接ECIF，在ECIF进行验证，如果达不到标准就拒绝进行下一步，这样可以保证增量信息是正确的，这样就等于在源头治理了，存量数据采用各类规则做整合处理，如果实在处理不了那么只能错着了收起