首先打两个广告，请大家积极参与老头子的课程，是非常棒的Oracle入门教程
http://www.hellobi.com/course/58
另外介绍一下我的课程： 高质量数据库建模
课程地址：http://www.hellobi.com/course/54
大家好, 今天我们简单聊一下数据治理. 数据治理这个话题非常大，我们不可能通过短短的两个小时把所有内容都涵盖，我今天讲的重点是如果一个企业要启动一个数据治理的进程，都需要做什么事。
那么什么是数据治理呢？
首先有一个大前提，就是企业对于数据的战略态度是什么。企业把数据作为一种特殊的重要的资产来看待，并由此希望能有效的管理这种特有的资产时，就需要配备的专门的人员、制定相应的流程、规章制度以及采用一些数据相关的技术去辅助管理，这种组织和安排就是数据治理。数据治理通常是长期的过程。
那么一般什么情况下会去启动数据治理这种项目呢？都是哪些需求促使企业要做数据治理呢？
1. 在满足法规的要求上存在一定困难， 不得不去做数据治理。
这个最典型的例子SOX法案，因为当年安然和环球电信的财务丑闻促使国家颁布一些强制的法规去约束上市公司。在各个行业还有不同的行业规范，尤其金融保险这种领域。比如银行的新资本协议等等，对管理数据的广度、深度和时间长度以及数据准确性完整性等等都有很明确和严格要求。
2. 管理高层关注用于决策的信息的质量。
这个也非常重要了，如果你弄个报告数据都不准，那管理层也没法依据提供的报告做决策。
3. 管理层需要的信息需要大量人工处理才能做出回应。
这个在很多企业里面也是很常见的，经常是领导打个电话，要个数，结果那边吭哧吭哧弄好几天才弄出来，然后数还不见得准。
4. 单一事实存在多个版本，然后各有各的统计口径，也没法区分谁对谁错，也没法做对比。
5. 信息可信度缺失，弄一堆报表，数据不准。用户对数据失去信任，然后还是自己想办法算。
6. 没有数据负责人，这种做BI的感触最深，源系统数据不准，你也不知道找谁负责。出了问题也没人想办法解决。
7. 对信息的理解和使用缺失，这个很多都是元数据管理的锅，国内短平快类型的项目尤其严重，设计一堆表过几个月没人知道各个表各个字段都什么含义，没有文档，没有数据字典，也不遵循命名规则，只能瞎猜。这种情况数据质量非常容易出问题，而且出了问题也很难解决。
8. 内部审计，数据安全管理缺失。这个我真有个故事可说，早年在国内某著名消费品公司做咨询服务的时候，有几张可以说是绝对是商业机密的报表一年被人查看下载1000多次，这个查看的ID是他们企划总监的，而这个企划总监自己表示，几乎从来没登陆过。这个其实就是内部安全审计的严重问题。
以上林林总总，都可以是数据治理项目启动的起因。那么数据治理项目实施的时候是怎样的过程呢？
各家咨询公司有各家的套路，但基本上都差不多。
第一步：检查，定位业务问题
这个就类似去医院体检一样，按照各个检查的项目检查一遍，检视企业当前数据各个方面的状况，定位数据相关问题以及对业务带来的影响。
我们也知道，去医院体检的时候我们也有很多检查的项目，比如血常规，X光，心电图，血压，B超等等。那么我们做数据治理的评估都评估什么啊？
因此啊，我们得有个数据治理的框架，如下图所示，这个是IBM的数据治理框架。其实这种框架也是大同小异，DAMA也有，Teradata也有，埃森哲肯定也有，基本内容都差不多。
也就是说，我们要去调查研究框架里面各个单元的内容，然后来给企业打分。
那么通过哪些方式呢？主要是通过直接访谈，问卷调查，文件分析，系统探索这么几个方面。通常来说直接访谈占的比重最大，一般要访谈的人物就是各个级别的业务负责人，计算机专家等等，访谈有的时候要分好几轮，先是直接访谈问问概况，然后获取相关的联系人信息以及文件，系统访问权等等，再去做一些homework，脉络清楚了再进行更深入的访谈。此外还有问卷调查，包括访谈式的问卷，会问一些比较开放式的问题，也包括一些评估类的问卷比如优先级，自我评估打分之类的内容。文件分析就要看一些技术文档，包括设计文档，数据字典等东西，还有一些规章制度的文件之类的东西。此外，有的时候还得花时间去看看系统。这种咨询项目通常都是多人协作的方式进行，大家在开始之初都有明确的分工，以及每天都要内部开会去对齐，出的报告要一致，很早就有template可以去遵循。
然后随着调查的深入，去慢慢总结发现的问题，比如出下面样子的报告：
第二步：评估
当搜集够了足够的内容以后，需要对整个企业的数据治理现状进行评估打分，这个怎么弄呢？有一套成熟度模型去参照。
然后按照成熟度模型对各个单元进行打分，比如下面的例子：
按各个单元模块，数据架构，数据治理，元数据管理等等分别打分，然后和企业的预期进行对比。
同时也可以和先进企业进行对标，比如去找一些行业标杆参照。
第三步，路线图，提出行动建议
搞清楚差距了，就需要做规划怎么来奋起直追。一般就是根据前面找出的各类问题，寻找相应的解决方案，并且按照重要性和紧迫程度进行排序，分短期计划，中期计划，长期计划进行规划，届时启动相应的项目.
通常来说，对于咨询项目而言，到这里就基本结束了，而对于企业而言，数据治理的活动仅仅是刚刚开始。
如果确定开展数据治理工作，那么后续要做的事情主要包括：
1. 首先一定要获得高层的全力支持
因为数据治理是自顶向下的运动，是管理“数据管理者”的活动，如果没有高层的支持以及充分授权，是根本没有办法开展下去的。所以经常会有高级领导会名义上的挂帅以强调对数据治理的重视。
2. 构建数据治理团队
数据治理组织需要建立一种章程来治理其操作，确保它拥有足够的成熟度来在关键形势下担当决胜者。数据治理组织最好在一种 3 层格式下操作。顶层是数据治理委员会，它由依靠数据作为企业资产的关键职能和业务领导组成。中间层是数据治理工作组，它由经常会面的中层经理组成。最后一层由数据照管社区组成，它负责每天的数据质
量。
3. 创建数据字典 并理解关键数据
业务词汇的有效管理可帮助确保相同的描述性语言适用于整个组织。数据字典或业务术语库是一个存储库，包含关键词汇的定义。它用于在组织的技术和业务端之间实现一致性和达成一致。例如，“客户”的定义是什么？客户是某个进行购买的人还是某个考虑购买的人？前员工是否仍然分类为“员工”？词汇“合作伙伴”和“经销商”是否同义？这些问题可通过创建一个通用的数据字典来回答。一旦实现，数据字典可应用到整个组织，确保业务词汇通过元数据与技术词汇相关联，而且组织拥有单一、共同的理解。如今很少有应用程序是独立存在的。它们由系统和“系统的系统”组成，包含散落在企业各个角落但整合或至少相互关联的应用程序和数据库。关系数据库模型实际上使情况更糟了，它使业务实体的存储分散化。但是所有一切是如何关联的？数据治理团队需要发现整个企业中关键的数据关系。而关系型数据库的产品的多样性，再加上NOSQL等各种非关系型数据库的发展，造成当下数据更难管理。而如果一个企业里面有非常多的数据库，指望数据治理团队去创建所有数据字典是不现实的，因此也就需要数据治理团队去制定规章制度，以及定义数据字典的标准，去要求各个系统的开发设计团队，按照标准创建数据字典。
这个时候，其实是需要画企业信息蓝图的，对于整个企业的系统、应用所产生的数据，以及数据的流转能够有整体的描述。
4. 创建元数据库
元数据是关于数据的数据。它是有关任何数据工件（比如其技术名称、业务名称、位置、被认为的重要性和与企业中其他数据工件的关系）的特征的信息。在查询阶段，数据治理计划将从数据字典生成大量业务元数据和大量技术元数据。此元数据需要存储在一个存
储库中，所以它可以在多个项目之间共享和利用。
5. 定义度量指标
数据治理需要拥有可靠的度量指标来度量和跟踪进度。数据治理团队必须认识到当您度量某个东西时，性能就会改进。因此，数据治理团队必须挑选一些关键性能指标 (KPI) 来度量计划的持续性能。例如，一家银行将希望评估行业的整体信贷风险。在这种情况下，数据治理计划可以选择空的标准行业分类代码的百分比作为 KPI，跟踪风险管理信息的质量。
除了上面的内容，数据治理还包括更深入的内容，包括：
主数据治理、分析治理、安全和隐私，以及信息生命周期治理等等。
数据治理是非常庞大的课题，今天我们暂时只讲这么多。
此外，我介绍的元数据管理的部分，请去下面的链接
http://www.flybi.net/blog/rayshawn/629
