【大数据100分】刘晨：大数据怎能没有你--数据治理
主讲嘉宾：刘晨
主持人：中关村大数据产业联盟 副秘书长 陈新河
承办：中关村大数据产业联盟
嘉宾介绍：
刘晨：广州利为软件合伙人，从事数据治理软件产品研发与咨询服务。清华大学电子系本科、经管学院MBA。拥有数据治理领域六年以上从业经验。国际数据管理协会中国分会（DAMA China）核心工作组成员，国际信息和数据质量协会（IAIDQ）会员。译著有《DAMA数据管理知识体系指南》，编写《大型企业信息化工程项目管理实战》数据管理章节。
以下为分享实景全文：
主题汇报人：
刘晨：大家好，我是刘晨，来自于利为软件。我们是专注于提供数据治理的咨询和软件产品的创业公司。我个人从08年开始从事数据治理，加入利为之前服务于埃森哲。感谢联盟提供的机会，让我能将数据治理领域的理论、近几年个人的实践和思考与大家分享。
我的分享主要包括如下几个部分：
1. 基本概念；
2. 数据治理方法；
3. 数据治理实践；
4. 大数据与数据治理；
5. 书籍推荐
大数据时代的到来，让政府、企业看到了数据资产的价值，快速开始探索应用场景和商业模式、建设技术平台。这无可厚非。但是，如果在大数据拼图中遗忘了数据治理，那么做再多的业务和技术投入也是徒劳的，因为很经典的一句话：Garbage in Garbage out，数据质量没有保证。而保证数据质量，数据治理是必须的手段。
数据治理这个话题看似阳春白雪高大上，实际上是非常下里巴人接地气，或者说必须要顶天立地才能见实效。顶天是指，与信息化类似，数据治理也是一把手工程，没有高层推动、在业务与业务间、业务与技术间协调，数据治理无法落地；立地是指：一般是IT人员对数据问题有深刻体会，也是IT人员最先意识到数据治理的重要性，而且数据治理最终是在IT层面落地的。因此我今天谈的很多内容，有不少是与IT建设和运维相关，不一定能让各位业务专家、商业领导完全理解、引起共鸣，还请各位见谅。但也正因为此话题重要却又不易被理解，国外会将How to sell data governance to business作为一个专门话题来讨论，甚至已经出书专门阐述。
1. 基本概念
1.1 数据分类
言归正传，首先是基本概念部分，既然谈到数据，我们首先要看一下数据的分类。其实我有点担心提到“分类”这个词，因为每个人、每个角色分类的视角都是不同的，各有道理。我所提的数据分类，是指在企业信息化领域做数据治理通常的分类方式。有其他方式也欢迎提出来大家一起探讨。我们通常将数据分为：主数据、交易数据、参考数据、元数据和统计分析数据（指标）。上一张图来说明：
为什么要谈数据分类，因为对每类数据进行治理时，关注点、方法和效果都不同，需要区别对待。下面谈一点我个人的理解：
主数据关注的是“人”和“物”，主数据管理（MDM）是数据治理领域一个专门的话题，其主要目的是对关键业务实体（如员工、客户、产品、供应商等）建立统一视图，让客观世界里本是同一个人或物，在数据世界里也能做到唯一识别，而不是在不同系统、不同业务中成为不同的人或物。主数据管理在各行业企业已经有大量的实践，受限于时间，今天不单独展开，其核心管理思想是和后面要谈的数据治理方法一脉相承的；
交易数据关注的是“事”，交易数据没有形成单独的数据治理领域，由于交易数据是BI分析的基础，因此往往在数据质量管理中重点关注；
参考数据是更细粒度的数据，是对“人”“事”“物”的某些属性进行规范性描述的，对参考数据的管理一般会与主数据管理同时进行，或与BI数据质量管理同时进行，因为指标维度和维值直接影响到BI数据质量；
元数据是一个包罗万象的概念，其本质是为数据提供描述，所以任何数据都有元数据。数据治理领域的元数据，更多是指BI、数据仓库这个范畴内的元数据（国际上有Common Warehouse Meta-model规范），此外还有信息资源管理的元数据（如Dublin core协议）、地理信息元数据、气象元数据等等。正因为如此广泛，也造成了从业者对其有极高的预期以及实践后的极大失落。
多说两句元数据：我个人从事过4年左右元数据管理的产品设计和方案规划，但现在极少谈“元数据”，而是谈“数据定义”，谈数据必谈定义，但却又不将其作为专门一类数据来管理，在数据治理领域单独做元数据管理，收效甚微。
主要原因有两点：1.数据生产与数据管理脱节，元数据管理更多是在数据生产的事后进行元数据收集和应用展现，对数据生产起到的管控作用极小；2.工具自身问题：虽然很多工具都号称支持CWM规范，但元数据自动获取始终是技术难题，而且对于存储过程、自定义脚本很难自动解析和获取，就无法准确、完整展现细节的数据处理过程。
统计分析数据（指标），无需多言，目前BI系统建设的主要作用就是做各种指标和报表的计算和展示。指标往往是数据治理的重点，指标的数据流分析、指标数值的波动性、平衡性监控，几乎是各个企业做数据治理的必备应用。
1.2 数据治理
谈完数据分类，再来谈“什么是数据治理”。数据治理的英文是DataGovernance，不同软件厂商和咨询公司给出的定义也会有所不同，但本质都是相似的。我这里引用《DAMA 数据管理知识体系指南》一书给出的定义：数据治理是对数据资产管理行使权力和控制的活动集合（规划、监控和执行）。数据治理职能指导其他数据管理职能如何执行。可能有些抽象，有图有真相，下面这张图说明了数据治理与其他几个数据管理职能的关系：
可以看到数据治理贯穿在数据管理的整个过程中，重点关注的是有关数据的战略、组织、制度等高层次的话题，并通过制定和推行战略、组织、制度，将其他几个数据管理职能贯穿、协同在一起，让企业的数据工作能够成为一个有机的整体而不是各自为政。
有关Data Governance的中文翻译，国内最常见的翻法有两种：数据治理、数据管控。国内客户似乎更喜欢数据管控，因为这个词有力度、体现权威。我个人从实践层面的体会：治理与管控缺一不可，治理在前、管控在后，治理针对的是存量数据，是个由乱到治、建章立制的过程，而管控针对的是增量数据，实现的是执法必严、行不逾矩的约束。
为什么要做数据治理？下面是一份国际数据质量协会的调研结果可以参考。
从理论上来讲数据治理主要是三个目的：保证数据的可用性、数据质量和数据安全。而在实践层面，国内外谈到数据治理，其主要目的都是数据质量，对于数据安全，往往是有专门的团队和管理举措，从数据治理领域涉及的较少。我们下面的讨论也继承这种习惯，主要探讨数据质量这个目标。
概念探讨先告一段落，后面在探讨方法和实践的时候，会反过来对概念有更好的理解。
2. 数据治理的方法
在方法部分，我们主要讲三个内容：谁负责数据治理？治理或者管控对象是什么？技术工具有哪些？
2.1 组织架构
首先来谈谁负责数据治理，也就是组织架构，先上一张图。
从理论和国外实践来看，大型企业会建立企业级数据治理委员会，有业务部门领导、IT部门领导共同参与，让业务与业务之间、业务与技术之间能够有更充分的讨论沟通，从而对宏观的数据战略、制度达成共识。在企业级之下，还可以有部门级、项目级的委员会，负责某些局部的数据治理，在最基层面向某一个业务领域应该有相应的数据管理专员（DataSteward）。Steward实际上是管家的意思，但翻译成管家似乎不够严肃，因此采用了“专员”。Steward一词与Owner相对应，说的是虽然资产不是归Steward所有，但是他们替Owner代管，由此也衍生出Stewardship一词，表明代管、托管制度，这里面蕴含了一种兢兢业业、克己奉公的管家精神，何其难得！数据治理委员会、数据管理专员会制定出一系列数据相关的标准和制度，由数据管理服务组织（DMSO）去执行。从图中可以看到，DMSO实际上是信息化建设团队，他们负责数据仓库、数据集成等技术平台建设。
上面谈的是理论和国外，在国内的情况刚好相反，DMSO是主力军，因为大家普遍“重功能、轻数据，重技术、轻管理”，绝大部分企业是缺失左侧的委员会等管理角色的。据我的经验，国内大型银行在这方面做得相对领先，企业级数据治理委员会或者专职的部门去推动数据治理；能源行业对数据治理的接触和认同程度比较高，开展了不少数据治理项目，特别是在主数据管理方面。运营商更重视技术手段，数据治理体制机制有待建设、健全。整体而言，国内在企业层面成立数据治理委员会的不多，更多是将数据治理的工作放在“企业信息化领导小组”推动，由信息部门负责具体落实执行。而有些企业虽然信息化水平很高，但信息化建设未实现信息部门的归口管理，这对数据治理的推行带来了极大挑战，跨部门、跨系统的协同异常艰难。
陈新河：企业数据规划非常象15年前企业信息化的战略规划啊！15年前偏技术架构，目前偏业务架构吧！
2.2 治理/管控对象
这个部分主要是我个人实践经验的总结，可能和国外的一些理论不一样。我个人总结为“内容管控”和“过程管控”。此处我用了管控一词，体现一些管理的“力道”。
2.2.1 内容管控
先说内容管控，数据在信息系统中是以不同形态体现的，需要将每种形态管理好，才有可能管好最终的数据质量。上一张图来说明：
从宏观到微观，数据的形态体现为数据架构、数据标准和数据质量标准。
l 数据架构，包括了数据模型（概念模型、逻辑模型）以及数据的流转关系，一般在企业级和系统级会谈数据架构，主要对企业数据的分类、分布和流转进行规划、设计，确保新建系统、新建应用能够与现有系统保持一致和融合，避免产生信息孤岛，或者带来重复不必要的数据集成、数据转换。
l 数据标准，包括了数据项、参考数据、指标等不同形式的标准。举例来说，“客户类型”是一个数据项，应该有统一的业务含义，将客户归类为大客户、一般客户的规则是什么，数据项的取值是几位长度，有哪些有效值（如01，02，03）等。这方面有国际标准可以参考，如ISO11179，国内很多行业也制定了行业数据标准，如电子政务数据元、金融行业统计数据元等等。共同的问题是，标准定义出来之后，执行的情况怎么样？是否真正落实到IT系统了。
l 数据质量标准，包括数据质量规则以及稽核模型（即规则的组合应用）。数据质量规则一般会关注及时性、准确性、完整性、一致性、唯一性等，展开来谈还有许多内容，有的专家整理出12个数据质量维度，有定性的也有定量的。
IT部门应该牵头制定并且定期更新企业级的数据架构、数据标准和数据质量标准，作为新建系统和应用的指导约束。值得注意的是，在标准制定的过程中，要避免IT部门的闭门造车，一定要让业务部门充分参与进来。举一个例子，我个人作为技术人员参与一次数据架构的规划，需要设计数据的流转关系。我发现从技术角度看，数据从哪流向哪里似乎都是合理的，也都可以有相应的工具去支撑，似乎没有什么可以决策的依据。其实，这时就应该有业务的参与，因为业务职能、业务流程和业务部门间的职能边界划分，直接决定了数据来源和去向，IT部门更多是从技术层面考虑具体实现方案。
2.2.2 过程管控
下面说过程管控。这里谈的过程，是指信息系统建设过程。因为经过大量的实践我们发现，数据质量不佳主要原因之一是在信息系统建设的过程中忽视了对数据的管控，这就会造成数据的设计与需求不一致，开发与设计不一致，对数据质量要求考虑缺失，不同系统对数据的定义和技术实现不一致等等诸多问题。等待系统上线后再去解决这些问题，亡羊补牢，消耗资源。
其实，数据管理甚至IT行业都应该虚心向传统行业学习管理理念。比如制造业的质量管理是在产品生产线各个环节进行质量管控，有些理念也很有启发：QualityBy Design，质量是设计出来的，不是检查出来的；Quality check is a cost not benefit，质量检查是成本而非收益。我们公司最近完成了对工厂化的数据生产和管理模式的探索和初步实践，运行效率、开发维护效率和数据质量都有显著提升，找机会再分享，提供一张效果图有些感性认识。
下面是过程管控的示意图：
这张图的内容比较丰富，其核心内容是将“内容管控”中形成的各项标准规范注入到通过信息系统建设的生命周期中，通过对系统建设各个阶段交付物的管控确保标准规范得到遵从，从而保障数据的标准化和规范化。过程管控一方面依靠开发管理中的评审机制去落实，另一方面就是靠工具去固化一些标准和规范，做到自动化检查。在系统上线常态运行阶段，注重新的数据需求和数据问题的收集和处理，对标准规范进行优化。在信息化早期阶段ERP、CRM等操作型系统的建设是以功能和流程为中心，而后期BI、数据仓库、大数据平台等数据分析平台的建设是以数据为中心的，这就注定一些传统方式需要改变，应该更加注重对数据架构、数据标准、数据质量的管控，更加关注数据的生命周期，否则数据分析平台建设成功的概率不高。
2.2.3 技术工具
下面简单谈谈技术工具。先上一张图，这是国外对数据治理关键技术的调研结论。
可以看到元数据、主数据、数据质量是主要的技术手段。具体的产品功能不是今天要探讨的话题，我主要想谈一谈技术工具在数据治理工作中的定位。与ERP遇到的情况非常类似，国内的客户往往寄望于上一套技术工具就能包治百病的解决数据问题、提升数据质量。
而实际情况是，如果前面所说的组织架构、内容管控、过程管控等管理机制、技术标准不到位，仅仅上一套软件工具，起不到任何效果。以上软件工具的作用又是什么呢？核心作用在于知识的固化和提高数据治理人员的工作效率。比如：需要手工编写程序收集的元数据，工具帮你自动获取；需要人工识别或编写代码实现的数据质量检查，工具帮你自动识别问题；用文档管理的数据字典，工具帮你在线管理；基于邮件和线下的流程，工具帮你线上自动化。除此之外，数据治理的软件工具与其他软件工具一样，没有什么神奇之处，没有数据治理人员的参与和数据治理工作的推进，软件也只是看上去很美。这也是为什么数据治理咨询服务一直有其市场，以及为什么国内大部分单纯数据治理软件项目未能达到预期目标。
3. 数据治理的实践
今天分享的形式决定不能展开许多细节，以三个案例中的一些细节来帮助大家对数据治理的实操有些定性的认识。这个部分没有图片，需要辛苦大家从字里行间去体会。
第一个案例是运营商客户的系统级数据治理，主要的启示在于：组织架构对于推动数据治理的重要性。
运营商数据仓库建设已有多年，对元数据管理和数据质量管理一直高度重视。数据质量问题往往是在数据仓库发现的，而有很大比例问题是由于上游BOSS系统的升级或者数据错误传递到了数据仓库。例如，推出了新产品但数据仓库中尚未注册、SIM卡号位数升级但未通知数据仓库等等。这说明两个问题：业务人员与分析系统技术人员协同不够；业务系统与分析系统协同不够。因此，数据仓库的主管方尝试从集团推动BOSS和数据仓库的数据质量协同管理，通过几省试点的方式建立了跨系统的元数据血缘图、数据质量联动监控等一系列技术手段去解决问题。
但是，数据质量协同管理的工作终于试点、未能全国推广实施，其原因主要有三点：1. 组织上，BOSS系统和数据仓库没有实现归口IT管理、是由平级的两个处室管理；2. BOSS系统业务关键性高于数据仓库；3.此工作作为技术工作发起，没有去争取业务部门的支持、参与甚至牵头。由此可见，组织架构和管理机制不顺畅，会制约数据问题的解决，甚至会带来数据问题。
第二个案例是一个能源行业客户企业级的数据治理，主要的启示在于：数据治理既要大处着眼，更要小处着手，而且要善于找时机切入。
该客户通过信息化规划设计了企业级数据架构，通过主数据管理项目经过1年时间建立了企业级的主数据标准、实现了不同业务部门对不同领域数据认责（即承担数据管理专员的角色），又通过数据管控项目理顺了业务部门、信息化部门在数据管控工作上的职责，在项目管理办公室PMO设置了数据管控组对各项目数据统一管控，同时制定了制度、流程和技术标准。组织、制度和标准上都可谓是到位的，但是技术标准的落地工作一直不顺利。
举例来说，以ERP为首的套装软件实施团队对组织机构主数据的标准一直很抵触，不肯使用8位统一编码而是使用本地4位编码。这个问题的影响在只有ERP系统时并不明显，数据管控组也无法推动8位编码的应用。随着项目后期非套装软件的建设，系统间的集成需求丰富起来，如果不能统一编码标准，系统间无法集成。这时，非ERP系统都遵从标准使用统一8位编码，ERP项目组不得不让步，通过映射表的方式实现了4位与8位的编码映射，确保顺利集成。由此可见，组织架构、管理机制和技术标准建立好之后，其推行落地需要找时机，也需要数据治理人员的耐心和智慧，否则只能是纸上谈兵。
第三个案例是美国的一个案例，主要的启示在于：小处着手，可以非常非常小，这对国内客户喜欢大而全的思路是非常有益的互补。
这个企业也是受困于数据质量问题，希望通过数据治理来解决。但开始时并不知道如何实际操作数据治理，所以他们启动了一个“企业数据定义”的项目：用6个月的时间梳理现有系统的数据项，识别跨系统、跨业务的数据项作为数据治理的重点。数据项梳理完毕后，他们选择了7个数据项去重点治理。注意，只有7个数据项哦！国内客户一定会认为7个太少，不能当个事情来做。但美国这个企业就是围绕这7个数据项去调研相关的业务用户，发现他们的数据使用需求和问题，去分析与这些数据项相关的业务流程和数据流程。后来识别了40多项可以改进的内容，也为数据治理的全面开展积累经验，在此基础上制定了总体规划和实施路线。
这个案例我最大的体会是，行动远比规模重要，在非常小的局部快速见效、积累经验，再开展企业级的数据治理实施，可能比直接高举高打来的更为有效。
4. 大数据与数据治理
终于谈到了大数据。从前面的讨论来看，数据治理大的脉络并不复杂：对数据资产家底清晰、管理权责分明、建立配套标准规范、确保落地执行，由此去保障数据质量。虽然大数据的规模大、类型多、速度快，但数据治理的原则对于大数据也是同样适用的。
那么大数据的到来会给数据治理提出哪些新的要求呢？
我们首先来看《大数据时代》的作者的观点之一，他认为在大数据时代数据质量不再重要，因为人们需要的是整体趋势的分析而非精确结果。我个人不太同意此观点，而是认为对大数据而言数据质量更加重要。作者提的整体趋势分析仅仅是大数据的应用之一，而从精准营销、风险识别等应用场景来看，因为数据与运营结合的更紧密、要求数据粒度更细，任何一点错误都可能直接带来业务上的损失；而传统的指标应用，反而对运营环节没有如此直接的影响。因此，在大数据环境下对数据质量的需求是提升而非降低。
其次，Hadoop、Spark等大数据技术的应用，对数据治理的技术手段提出新的要求。传统模式下基于RDBMS进行管理，SQL是通用的数据访问方式。而在大数据环境中，Hadoop、MPP、RDBMS、Spark并存，如何在混搭的异构环境中实现对数据资产的可视化统一管控，避免大数据系统成为不可管理的黑盒子，这是传统行业应用大数据技术需要面对的关键问题之一。特别是大数据技术人才目前更多流向互联网企业，进入传统行业的少之又少，在人才可得性短期不能快速解决的情况下，需要依靠技术手段来确保传统企业IT人员能够对数据资产的可视、可控。
第三，数据安全，或者说数据隐私的重要性比以往有显著提升，这也需要在数据治理中加强对数据安全的重视。在传统应用场景中，数据由企业收集，在企业内部应用，数据所有权的问题并不突出。在大数据时代，数据要更多进行跨界整合、外部应用的商业模式创新，这其中就涉及到更多数据所有权、数据隐私的话题。用户信息究竟属于企业还是用户、在什么条件下企业可以拿来用于商业应用？这些问题的答案还在探讨当中，毋庸置疑的是，企业需要在数据治理过程中，需要更加注意数据安全、数据隐私相关的制度和政策。
先谈以上三点，有关大数据与数据治理的话题，估计2-3年内还会是持续丰富的，现在刚刚开始，我个人也是最近逐渐关注针对大数据的数据治理，很愿意与大家共同交流进步。
5. 书籍推荐
最后给大家推荐几本数据治理相关的书，茶余饭后可以换换思路。
中文版的目前有三本：
1. 《DAMA数据管理知识体系指南》，此书是国际数据管理协会（DAMA）出版，2012年我们中国分会的一些会员众包翻译完成，目前应该是数据管理领域最全面的一本专著了，非常适合提纲挈领的全面了解数据管理各项工作。
2. 《数据质量工程实践：获取高质量数据和可信信息的十大步骤》，作者是美国一位专家，我听过她的讲座，很务实，实操性比较强。国内有可能会觉得此书太细，但其实数据工作就是个细致的工作。刚才讲的那个美国案例，也是这位专家负责的。
3. 高复先老师的《信息资源规划：信息化建设基础工程》，对数据元素、数据标准等基础概念阐述很清晰，此书是在James Martin的信息工程基础上写成的，因此与国外的数据管理理论有比较好的相容性。
再推荐几本英文的：
4. “Information Quality Applied: BestPractices for Improving Business Information, Processes and Systems”
5. “Data Warehouse and BusinessInformation Quality”
4与5这两本书作者都是Larry English，应该是美国最资深的数据质量专家之一，刚才那本书的作者也是他的弟子。Larry成功的将制造业质量管理理念引入数据质量管理。这两本书非常有参考价值，内容稍有重复，可以选第1本，是2009年出版的。
6. “Big Data Governance: an Emerging Imperative”
7. “The IBM Data Governance Unified Process: Driving Business Value withIBM Software and Best Practices”。
6与7这两本书的作者都是 Sunil Soares，原来是IBM负责数据治理的lead，前两年离开自己创业做公司了。第1本我还没看过，第2本主要是结合IBM的软件产品一起讲的，不够中立，权当参考。
以上就是我今天要分享的内容了，如果有兴趣可以加我微信保持沟通。谢谢大家！
何鸿凌：模型驱动很赞。数据工厂的实践有进一步分享么？
刘晨：既然问到数据工厂，我就多介绍一点。目前国内客户做元数据管理和数据质量管理的不少，思路也比较趋同，首先是希望单凭工具解决问题，其次是基本上是在数据生产的事后进行数据管理，两者脱节。这会带来一系列的问题，数据生产与数据管理脱节，更严重的是数据管理根本没法影响数据生产，因为想着手做数据管理的时候，数据已经生成了！然后是，很多数据生产的处理逻辑使用存储过程和脚本去写的，形成一个个任务，而将数据资产淹没在任务当中。这就是数据资产、数据流淹没在任务流中，本来你要管理的是数据，可看到的都是一个个程序和任务，管理失焦！所以，现在的模式下，在技术层面都很难将数据管理好，更不用提管理机制、组织架构不到位。
所以，我们是借鉴了制造业的工厂和流水生产线的思路：面向数据资产去构建模型，这样保证了数据定义的规范性。而且数据定义（也就是元数据），是在系统开发过程中定义的，也就避免了事后管理带来的问题。模型定义完成后，再根据数据处理逻辑构建一条条数据流，也就是数据生产线。刚才有一张图的效果。
这个数据生产线会屏蔽掉底层的异构环境，无论是hadoop，db2，oracle，从数据开发和管理的角度来看，都体现为统一的数据生产线。这样就会给开发人员、运维人员、甲方的管理人员带来极大好处：数据资产可视了，也就更可控了。
黄明峰：很精彩！请教一下，政务的数据治理有突破吗？您怎么看待元数据？原来国信办主导的数据共享和交换体系有实际的价值吗？
刘晨：政务领域我接触的不多，接触过一些税务的合作伙伴。从我的感觉，他们还是沿用老的数据治理思路去做事情，元数据，数据质量。税务也制定过数据元标准，开发商反映落地情况不太好。对遗留系统的梳理有难度。
Felix：刘总刚才讲到：Hadoop、MPP、RDBMS、Spark并存，如何在混搭的异构环境中实现对数据资产的可视化统一管控，避免大数据系统成为不可管理的黑盒子，有什么解决方案？
刘晨：请您参考我刚才说的工厂化数据生产和管理的模式。
赵刚：Apache开源项目中对数据治理的工具还不多。你了解呢？
刘晨：有，确实不多。ApacheFalcon是一个，还在incubator阶段。
Felix：hadoop和spark，mpp都支持ganglia监控，也能算一种方案？
刘晨：是对hadoop环境下的数据进行模型化和流程的管理。
黄明峰：想继续听一下您对税务系统数据看法。
刘晨：税务这块我目前还没有更深的接触。但我认为梳理遗留系统的工作量是必须的。但如果不能在信息系统开发过程中做好事前和事中的数据管控，还会重走老路。
赵刚：informatica产品你怎么评价？
刘晨：informatica和ibm datastage，sap bo DI都是一个思路。从ETL衍生出独立的元数据管理，数据质量管理，业务术语管理。但问题都类似：元数据管理是事后的；数据质量管理分为data profiling和data cleansing，都是与ETL离线来做。可国内的数据清洗，习惯在ETL过程中去做。业务术语管理更是看上去很美，本质上与EXCEL没什么差别，推行的难度在于业务术语是IT人员不懂、业务人员不愿填。从ETL功能本身，那几个产品还是不错的。但目前也不能适应国内运营商的要求；一方面国内运营商数据量大，产品性能跟不上；另一方面开放性不够，不能做二次开发。所以运营商的ETL更多是ELT的方式，用脚本去处理数据，利用数据仓库的处理能力去做数据转换。从性能和数据处理角度，这样的方案没问题，但日积月累，脚本淹没了数据处理逻辑，数据管理就失控了。于是开始做元数据管理、数据质量管理，使用刚才说的事后管控的思路，效果不佳。我们见有的客户，一个脚本15000行。这里面处理了多少张表、有多少处理逻辑，没人能说清。开发商技术人员更替又比较频繁，最后那个脚本就没人敢动了。所以，现在我们特别建议在大数据平台、数据仓库建设之初，能够系统的考虑数据治理的问题，少走弯路。在项目开发流程、开发文档中，一定要加强对数据的要求。包括对数据需求的定义、数据模型、接口定义、集成关系、质量要求等等。这个内容在很多企业的项目管理流程中都是缺失的。
陈新河：联盟副秘书长；《软件定义世界，数据驱动未来》@刘晨再次感谢刘总的精彩分享！
原文发布时间为：2014-05-30
本文来自云栖社区合作伙伴“大数据文摘”，了解相关信息可以关注“BigDataDigest”微信公众号
