各位对数据治理的看法？

数据治理，应该包含两方面的内容：一是对原有的数据进行清理、修复、转换等，使之达到现有的应用要求；二是根据现有要求和未来应用的趋势，制定相关的标准，用来规范新系统在数据方面的建设。这两点都会涉及对源系统数据的治理和数据仓库的数据整合。一般情况下，不会出现单纯对源系统数据进行治理的情况，因为成本较高、风险较大；而单纯在数据仓库上进行整合的方式也是不建议的，因为并非所有数据都能够按现有要求进行整合，必须源头改造，且源头数据规则持续混乱会造成数据仓库的管理难度增加，一旦源系统有风吹草动，数据仓库就会受到较大影响。因此，对于数据治理，理想的方案是从源系统着手，但现实中应结合自身情况进行方案制定。一般情况下，对于新的系统建设，数据标准、数据模型要趁早规范，让数据越来越高质量；而对于历史数据，则结合应用进行选择性的治理。收起

我认为，提出这个问题的，很可能是外行人。不管他是IT公司元老，还是数据分析专业的硕士博士，或者是业务部门高管。

只要他提了这个问题，就说明他是个外行。


数据分析的基础，是业务数据。也就是说，你在准备分析时，数据已经生成，你如何在源头限制数据质量？
而且在实际操作中，业务系统的研发者，与数据分析系统的研发者，很可能不是同一公司，
即便在甲方内部，业务产生的部门，与数据利用的部门，很可能也不同。
你有什么资格，要求对方为你治理数据？

其次，数据治理（ETL中叫清洗，或其他概念）也只能是数据分析的前提，而不应该后期做。
因为，你的数据分析，应该是基于已经清洗过的数据来进行的。如果你对100万数据进行分析，只要有10条错误数据（比如极大数据），如果不加处理，就可能导致你的整个分析结果不再具有直观性、可读性。收起

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

回复 2# jielee


    这方面我可不是个外行，数据仓库本身是不能完全解决数据质量问题，比如：有效证件问题，一个人的有效证件可以军官证、身份证、护照等，那么在客户整合过程中怎么处理，如果在数据仓库级别处理会造成一个结果，数据仓库是一个人，但是在核心或者其他业务系统里认为这是2个人。目前我认为比较好的方式是在建设ECIF的时候处理，在建设ECIF的过程中，对源系统进行尽量少的改造，采用技术手段控制源系统的数据质量，数据仓库必须真实性的反应源系统的数据质量问题并且不修正，必须是源系统修正（我们在数据仓库中发现信贷客户采用不同有效证件办的贷款，运营也认为是1个人，但是信贷系统就不修正，数据仓库也没办法）收起

我觉得首先需要理解一下什么叫数据治理，他并不等同于数据清理，它其实对前端的业务系统和后端的分析系统都是很有利的，为的就是定义好标准，从管理，技术上形成一套，检测，考核，完善数据的机制收起

回复 2# jielee


您好！实际工作中，老系统的数据质量问题是难以避免的。比如身份证号15位和18位的问题，基础数据的数据质量不高，后面的数据分析价值也会打折扣。您同意么？收起

回复 18# jielee


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

技术上：检测出身份证号码不符合要求的数据。
管理上：安排客户经理通知用户来升位，并给予一定的考核要求。

不要着眼于眼前的分析，要从长期来看整个数据质量是否在提升，这个过程就是数据治理过程。收起

回复 4# yaozw


这个说法没错，

但是在实际操作中，针对不同的需求，会有不同的治理规则。

比如楼上说的，身份证号，15或18位。
如果一个人的身份证，登记了15位，你通知他来升位，他也没来。
在业务系统中，保证数据真实性是必须的，所以你不能手工给他计算或虚拟一个18位的身份证号填进去。
但在进行数据分析时，要求数据是统一、整齐的，基于此，你完全可以把18位压缩到15位，或者通过特定的规则，将所有15位的升位到18位，并基于此进行统计分析。收起

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