【Friday BI Fly】数据治理实战应用、企业级模型规划和管理、元数据管理微信直播记录
周五BI飞起来，天善商业智能BI社区每周五下午举办问答社区在线答疑活动，每周五晚上举办行业、厂商工具、技术相关的微信在线直播活动。
2016年04月08日 Friday BI Fly 微信直播主题 – 数据治理实战应用、企业级模型规划和管理、元数据管理。
主持人：加入本群的同学们，感谢大家参加由天善智能举办的 Friday BI Fly 活动，每周五微信直播，每周一个话题敬请关注。
本次微信直播讨论内容：
1、数据治理实战应用
2、企业级模型规划和管理
3、元数据管理
本期嘉宾介绍
BAO胖子
春宇老师 15年BI经验，涉足医药，电力，快消品，信息服务等行业的BI老兵。
个人专栏：http://www.flybi.net/people/shaocy
博客专栏：http://www.flybi.net/blog/rayshawn
BAO胖子教程：数据仓库建模指南系列教程 【结合大量项目实践的长篇教程、持续更新中、国内首发】
老头子
Oracle11g OCP、BI产品经理，有非常丰富的开发和技术实战经验，擅长企业级数据仓库模型设计和技术架构的设计、项目管理以及大数据量的Oracle SQL性能调优及模型调优。
服务客户有华为运营商、华为IT、联想等企业，曾作为产品经理带领30 人以上的实施团队实施BI项目、主要负责需求管理、模型设计和oracle技术支持以及培训。
个人专栏：
博客专栏：
老头子视频：Oracle 数据库入门教程
贾岩
逆光老师，做了十年的信息化项目，从事BI行业近八年时间，主要从事系统集成，集团信息平台数据的整合与建设工作。
对于集团数据平台建设有深刻理解，从事过ETL开发，报表开发，以及数据库管理等工作。目前主要做系统运维工作。
个人专栏：
博客专栏：
逆光视频：INFORMATICA入门开发实战视频教程
主持人：时隔3个月之久，天善智能Friday BI Fly每周五微信直播交流活动又跟大家见面了，大家是不是跟我一样期待呢！！！看看大家的热情就知道了。
下面我们就赶快进入正题吧，别让朋友们久等了，我们首先请贾岩老师来给大家分享第一个话题1：数据治理实战应用。
贾岩
很高兴参与今天的微信直播，今天主要和大家分享一些个人的经验和看法。
首先谈一下数据治理，数据治理话题比较大，因为往大了说这是一个系统性的工程，往小了说就是数据质量。所以理论性的东西比较多，但是理论很多都是没有严格执行，所以导致很多企业数据质量并不是很好。
多数大型企业都会有数据治理，但是很多都只是为了完成任务而做，所以还是出现了很多问题。
通常随着公司信息化建设不断推进，公司各应用系统数据日益丰富，数据已成为公司重要资源，数据利用水平不断提高，为公司领导及各业务部门及时全面掌握生产经营情况以及科学分析决策提供了重要依据。
数据治理：以数据梳理、数据管理、 数据质量、数据应用四方面为主线，实现公司各单位数据管理更集中、数据服务更全面、 数据利用更高效、数据质量更可靠。
但是在实际操作中，需要一些有业务经验的人员，整理出所需要的数据信息，这也是一项量大而且繁琐的工作。其实这也类似于我们的需求整理，我给大家截2个图，大家看看
其实在数据治理之前，我们要梳理我们的数据，前期工作量大而繁琐：
1. 梳理并建立公司数据资源库，为企业级数据资源的共享利用奠定良好基础，也就是要建立自己的数据中心；
2. 其次我们也要有健全数据管理机制，从制度与流程、组织与人员、技术与工具等方面支撑数据资源的统一管理，确保企业级数据资源集中融合、规范有序；
3. 建立数据质量持续提升的管理机制，按照“业务部门负责数据质量考核，信息部门提供技术支撑”的原则，有效促进公司数据质量提升；
4. 完善数据应用体系，加强各业务系统数据共享开放，深化数据查询分析及辅助决策功能，实现公司数据资源全方位、大范围、深层次的分析与利用。
其实每一项要求或者说规定，我们看着很简单，但是执行起来也存在一定难度，很多时候业务部门人员责任心不够，数据质量把关不严格，就会导致产生很多质量很差的数据。
上面每一条我们乍一看说的都很好，但是执行起来，效果就不一样了。
所以数据的质量，是需要多方面配合完成的，也需要每一个人能够认真负责。在数据源头就保证数据质量。
例如：时间：2016-1-1，2016-1--1, 2016-1-1--
类似于这样没有规律的数据，虽然不多，但是却会造成大量的转换工作。
所以我们要：
1、制定数据中心职责分工、数据使用、数据源变更、数据质量、安全管理、运维管理等方面的管理办法，并颁布执行；
2、数据中心管理办法有效执行，并留有佐证材料（管理办法正式发文文档、按管理规范产生的各类流程单据或其他举证材料）
不管管理如何严密，其实都是有漏洞的，更多的是要靠每一个人的责任心。
之间我参与过大型企业数据中心的的数据治理工作，设立了很多的机制，也设定了
1、 综合查询指标覆盖率
2、 综合查询指标完整率
3、 明细数据接入率
4、 历史数据接入率
5、 日数据接入及时率
等等考核的内容，并且把这些内容涵盖到了数据资源管理系统里。每周，或者每个月都会生成一个数据质量的评分表。但是系统只能考核数据的完整性，及时性，但是对于伪造数据，人为修改的，是分辨不出来的。考核到最后有的也变成了一个造假的工作。
数据治理没有一个很明确的定义，或者说一个很有体系的工作，所以个人建议，很多事情也要落实到个人。
1. 确定需要梳理的业务应用系统，明确负责人；
2. 召开业务应用数据梳理工作会议，各业务应用负责人制定详细的数据梳理工作计划；
数据治理是一个比较头疼的问题，尤其是数据质量，以上也只是个人的一些经验和感想，以及一些建议的处理办法。
好的，今天有关数据治理的分享，我就讲到这里，一会儿我们会有Q&A环节，希望大家踊跃参加，谢谢大家。
主持人：感谢贾岩老师给我们带来这么精彩的分享，其中有些部分我非常的有共鸣，数据治理必须要有健全的数据管理政策与制度，并且需要我们每个人认真负责的去落地，否则我们的数据质量是非常堪忧的。大家有关于数据治理这个话题，有什么疑问的，可以跟贾岩老师交流，我们现在进入自由讨论时间，我们自由讨论10-15分钟，请大家有问题的抓紧时间，这么好的机会，大家抓住了。
自由讨论环节
问题1：我想问一下逆光老师，你们以前定义的数据质量考核指标有哪些，能不能说一下指标是怎么定义的？
逆光：说实话，就是大家提出一些建议，然后领导拍板@邱明伟 ，通常就是我说的，完整性，及时性，以及数据质量这三个方面。然后根据自己企业情况，把这三个方面细化，细化之后，每一项进行评分。
邱明伟：恩，还有准确性。
问题2：@逆光 对于混乱的数据使用Excel公式改变格式还是手工修改？
逆光：@硕 一般通过测试，我们都是用ETL转换，因为数据抽取是一个长期的，不能总该，另外就是加强业务人员的责任心，统一规范。还有个办法，也可以考虑用Excel做模板，导入导出的方式。
问题3：@逆光 数据质量，数据标准，元数据管控 这三个如何实施？
逆光：@吃柚不吃橙 这么说吧，我们先制定标准，收集业务指标基本信息，包括：指标名称、计量单位、数据精度、数据频度、统计口径、数据要求接入时间等指标项，然后在考虑数据质量。
吃柚不吃橙：之前你说过重点还是要落实到人，我认为要成立一个数据治理委员会，委员会的成员是个个业务部门老大。
逆光：重要的是有奖惩机制最好了，否则很多老大也不重视这个事。
硕：落实不到人没用
逆光：@硕 对，而且还要对人有奖惩机制，不过我们现在做这个事还是有难度。
硕：@逆光 难度太大，除非录入人员归自己管理。有生杀大权。
逆光：@硕 其实是互惠互利的工作，通常业务部门要提交报表，报表的数据由IT部门来做，这也是业务部门的要害，可以抓住。
问题4：那企业招实习生干数据挖掘和这个整理数据的工作相关吗
逆光：@alla 招，可以给有经验的打下手，因为有时是需要力工的。
问题5：就目前市场，都是有什么数据治理的工具呢？@逆光
逆光：@snow 不知道诶，我们原来是自己开发的数据资源管理工具，也只是为了考核数据中心的。
问题6：如果企业没有直接的数据质量稽核管理，也就没有了数据质量预警，经常导致历史数据质量延迟发现，导致目前数据质量及联影响，也就经常会有追数各种重复性的修复工作，但领导层又不重视数据治理，没有开展任何数据质量监管的计划，有什么好的规避方法么？
逆光：@巩庆昌 没有什么好办法，只能自己多干点，或者可以通过变通的方式来搞，比如建立一个数据的视图区，确定数据稳定再加载。
问题7：@逆光 请问从实践来看，企业的数据治理是否应该由IT部门主导呢？
逆光：@大连-教育-王东 分企业，有些企业IT部门处于弱势，有些企业处于强势，其实你数据梳理出来是给业务部门看的，建议业务部门牵头更好一点。
王东：@逆光 结论就是必须强势部门主导，对吧？
逆光：@大连-教育-王东 需求部门主导，因为IT部门不会去对业务有需求，而且和你说，你要让业务部门重视数据，，要让他们知道数据的重要性。
问题8：我们这边经常出现原系统的数据质量差导致ETL报错的问题，有什么好的解决办法吗？
逆光：@邱明伟 这个真没有，乱输入是没办法，只能不断测试，或者和业务部门沟通。
问题9：@逆光 数据中心定时采集a业务系统的数据，但是数据中心又是数据的提供者，b业务系统部分数据去需要实时知道a业务系统的变化？怎么解决呀？
逆光：@海辉 你错了，数据中心永远不是数据的提供者。只是数据的传递者。通过建立视图区，以前我们这样做过。
主持人： 由于时间关系，我们的讨论不得不到此为止了，我们后面还有两个话题要分享，如果大家还有什么疑问，请把问题提到我们的问答社区 http://www.flybi.net，我们的嘉宾会在活动之后详细回答大家的问题。
好的，接下来，我们开始第二个话题的讨论 2、企业级模型规划和管理，有请老头子来给大家分享第二个话题的内容。
老头子：
大家好，我是老头子，今天和大家一起讨论关于模型规划和管理。
在做这件事之前，首先要搞清楚的是：我们是IT部门或数据管理部门，职能是服务业务，帮助业务快速发展，那么最先要搞清楚的是我们的sponsor最迫切的需求是什么，他们为什么会同意拿出这么一大堆钱来研发这么一套系统？
无论是业务驱动架构，还是架构驱动业务，BI要想在初期能够活下去，最先要做的就是获得sponsor的认可，为业务人员解决燃眉之急，所以一切规划和管理都是围绕业务当前最紧急的需求作为出发点，或者说业务当前最想要解决的痛点作为出发点去延伸。
首先来我们看两种搭建模式，业务驱动和架构驱动。如果我们把数据仓库比作房子、业务比作住户。那么业务驱动顾名思义就是我先告诉你我想要什么样的房子，你再按照我的思路搭建。
但是很多时候用户并不知道他们想要的是什么，有可能他只有个大概的思路，比如我要三室一厅，但我最迫切的是希望先有一个卫生间，解决我当前最着急的卫生问题（人有三急）。那么显而易见我们在搭建数据仓库的时候首先要把卫生间给做出来。然后再不断的完善这间房。
而架构驱动就是我们有一个资深建造师和设计师，我们知道当前最流行的样式，我先做个样图给你看看，OK没问题再开始搭建房屋。
很明显这两者都有不同程度的瑕疵，那么我们平时多是两者结合，首先业务驱动获取最紧急需求，解决业务燃眉之急，然后再根据行业专家、资深架构师与业务人员的磨合去尝试搭建数据仓库，引导用户告诉用户什么样的数据才是最应该关注的。
如果前期顺利那么我们面临的将是在初期搭建的树根的基础上如何开枝散叶，成为一个企业级的数据仓库。
首先要知道我们前期搭建的“卫生间”是否是EDW的主干，如果不是我们需要识别哪部分才是这间房的“承重墙”。
我所提倡的数据仓库搭建是业务和架构同步驱动。IT作为主导，引导业务用户。这里我要说下为什么要IT主导，因为很多时候大部分业务所理解的BI还停留在ERP、CRM的阶段，他们认为的东西有一部分是不适合放入BI系统的，比如搜索、实时监控，但随着BI用户的层级范围越来越广，越来越多的运维人员开始使用BI系统，这就另当别论了。
所谓规划、管理，都是为了平衡业务与IT之间的期望和矛盾：IT过于迁就业务，导致架构混乱；业务过于迁就IT，导致BI没有价值。
这里我贴个图吧，这张图是之前做的参考方案，其实BI的东西整体去看基本都是这些东西，那么我们的规划、管理，就是在这个图完成之前，如何让他健康的成长。
那么我不建议在BI初期就做的需求有：实时监控、搜索功能、过于复杂的实体关联，大体说下原因：
实时监控：这个很容易打击业务对BI的信心。
搜索功能：容易引发后期性能问题，给自己挖坑。
过于复杂的实体关联：这种需求很容易为了实现需求而导致架构混乱。
在我们的架构/模型建设中，性能是我们在实现需求的同时，时时刻刻都要提醒自己的重点，和业务体验也是密不可分的，如何在满足业务要求的同时搭建一个性能优良的EDW不是一个人可以完成的，一个资深架构师，一个业务专家这是你必不可少的左膀右臂。
此外主题的划分、主数据、元数据的管理都是完善数据仓库的过程中需要思考的。
关于元数据管理，春宇老师会在第三部分和大家分享讨论，我们可以一起讨论，如果有不同观点希望能有一些碰撞，这样才能提高我们自身。这个话题的分享就到这里，谢谢大家。
主持人：感谢老头子的分享，通过生动形象且浅显易懂的例子给我们讲解了数据仓库模型如何规划与管理，下面我们有请贾岩老师也针对第二个话题来做一下讨论，等贾岩老师分享完，我们会针对第二个话题有个统一的提问时间，有请@逆光。
逆光
其实建模工作偏业务性，要了解行业才能更好的建模所需要的模型，但是也有很多是根据客户实际需求，和系统情况来设计，但是总体来说，了解行业的业务知识，对于建模更有帮助。
所以其实一个建模工作者，一定是最行业有深入了解的，能够为客户提供所需要的，而不是由客户来提需求。
但是我们现在很多项目，都是根据一些建模规则+客户需求，随便建立一些模型，满足展现要求就算了。
因为一个行业的项目毕竟有限，这里面也有一些利益的驱使，所以我个人更推介业务知识丰富的建模，这样才能做出更好的模型，支持更专业的报表，所以建模我不多讲，就多一些简单概念性东西，建议每个从业者，懂得技术的同时，尽量也多学学业务。
从数据仓库的定义中可以发现，数据仓库的业务特点，这些特点不仅仅停留在概念，也对数据模型的设计产生了重要影响。
1、数据仓库的数据组织是面向主题的，而不是面向报表，操作型数据库的数据组织面向事物处理，业务系统之间各自分离，数据仓库按照一定主题域进行组织。
主题是一个抽象概念，是用户使用数据仓库进行决策时所关心的重点方面，典型主题域包括顾客消费行为，产品销售情况，生产事务，材料采购。
2、数据仓库要实现对数据的集成与数据的同构性
实现同构性是一个比较复杂的工作，涉及大量数据转换，在数据获取阶段要确保所有的数据来源是一致的，或者经过一定处理后数据是一致的。如果来源不一致，我们就要把数据来源信息也包含在数据仓库中，以便后续数据转换中对不同来源的数据进行分区。
3、数据仓库数据的相对稳定与为实现应用而进行的实时读写操作
操作型数据库数据一般是实时更新的数据仓库一般是会被长期保留的，但是也存在有变化的情况，例如绩效分析，评价，有时可能一年后才会有结果，所以也需要在建模时考虑好只读和可写入对象之间的关系。
关于设计原则，基本有过经验的基本也都了解，而且建模不是会使用一个建模工具就可以的，模型也涵盖了设计者的智慧：
1， 星型结构，实现简明的数据设计模式
2， 数据参照完整性，保证数据一致性
3， 利用索引，提高查询处理速度
4， 先去索引，后加索引，提高数据装载效率
5， 校验数据，保证数据的高质量
数据仓库最关键的是查询，最耗时的是数据加载，数据表结构简单，数据源质量高，数据参照完整性好，那么数据加载肯定快，另外就是索引，一般装载前把索引去掉，完成加载后重新创建，这样也有利于提高数据加载效率。
另外，也有一些工具，不知道大家是否有了解，包括永洪，帆软之类的，其实整体的趋势开始偏向于成熟套装软件。
为什么ERP系统里面有很多功能或者流程是定死的，因为很多时候他所提供的就是客户所需要的，当然对于中国来说，很多要定制化开发，但是看看我们的金蝶之类的软件，国内很多软件产品功能是可以满足客户的。
BI的产品也一样，以后逐渐的会淘汰全部DIY的时代，里面会自带很多客户本身需要的分析报表，当然也有保留一些可以定制化的东西，这就是我前面提到的，如何可以把握提供的分析就是客户想要的，甚至超出了客户的想象，这就需要业务知识，甚至要比客户更懂才行，更高级的服务就是，不需要客户动脑，动手，傻瓜式分析。
个人的一点看法，仅供参考，谢谢大家。
主持人：感谢贾岩老师和老头子老师，下面我们进入自由讨论环节了，大家对第二个话题有任何疑问的，请提出来，老头子和贾岩老师会跟大家做详细讲解。有问题的提问题，需要休息的也可以休息一下，咱们的活动已经进行了一个多小时，想必大家也有点累了。
休息期间发红包咯
抢完红包接着学习，还有好多小伙伴等着提问呢
自由讨论环节
问题1：@老头子 搜索功能指的是什么?解决什么问题？
老头子：全库全表搜索某个值。
巩庆昌：类似明细查询是吗@老头子
老头子：比如，我前台报表的一个条件要去匹配a表里的5个字段 都没有 再匹配B表里的5个字段 再没就匹配C表里的。出现这种情况一般是：业务也不知道这个应该以哪个表为准；或者业务系统过于混乱导致的。
问题2：为什么实时监控这个很容易打击业务对BI的信心而不是帮助？
老头子：@春天在心里 因为实时监控很容易出现生产上的各式各样的问题，不是我们想做好就能立马做好的，尤其是初期，即便很成熟的EDW，也只能做伪实时，通过一天多调等方式。
春宇：只有一部分数据做实时，不过现在电商领域实时很成熟了，都是bigdata的平台。
Caoyan：监控与预警建议后期做。
内心召唤：预警为什么要后期做呢？数据都有了，应该很容易实现啊。
问题3：实时监控是指哪方面的监控？指标监控？
春天在心里：访问网站的监控吧。
老头子：有指标监控，有汇总监控。
春天在心里：预警监控的话 比如今天流量比昨天下滑了不少，一般是超过多少比例才报警，这个比例如何计算的？
巩庆昌：这里说的实时监控应该是跟业务源系统实时交互，数据抽取加载，继而分析完成决策。
老头子：@春天在心里 这个一般是要看业务KPI 根据他们的阈值来算
邱明伟：@老头子，星环科技貌似有实时的EDW方案，所有的计算都在流里面处理的。
春宇：星幻科技提供的产品叫什么？
老头子：实时这个东西，即便在大数据平台，也是伪，我见过2种方式：一是根据行为提前分析，然后根据用户某个触发事件实时推送。二是较少的逻辑整合和处理。复杂的基本别想实时了。如果还是简单的数据同步那么实时是很简单的，困难在于数据整合和复杂业务逻辑计算。
问题4：问个最小的问题，何谓阈值，能否举个形象的例子，一般是要看业务KPI 根据他们的阈值来算。
老头子：@春天在心里 阈值就是他们的预警线 超过或低于多少就会xxx的一个数字。
春宇：人体温35.5 - 37度正常，这俩就是阀值。KPI根据实际情况而定，有的按+-20%来计算阀值之类的。
主持人：老头子迫不及待的要跟大家分享他今年新推出的一门课程，下面几分钟是老头子的广告时间，好多人一听到广告就反感，老头子很委屈的，你要知道，课程是
免费的，免费的，免费的，重要的事情说三遍！
老头子做这套课程可谓是良苦用心，希望更多的朋友参与进来，有更好建议的一定要直言不讳，这样不仅大家从中学习到很多，我们的课程也会越来越好，两全其美，何乐而不为！
老头子：我打个小广告吧，下面是我今年的首要任务《Oracle入门与学习方法》：
。
这里我想说下我做这套视频的初衷：
我自身是0基础直接在工作中使用Oracle的，所以深知起步的困难，也知道因为没有系统学习过Oracle，即便想查阅资料都无从下手的痛苦。这套视频的目的是希望我能作为一个引路人，将大家引入到Oracle的大门处，顺利迈入门槛，并交给大家学习的方法和途径，然后自己继续修行前进。
市面上的课程很多，免费的相对系统的课程却寥寥无几，我希望将自己的所掌握的知识和经验进行传播、传承，这样才有意义，这也是我第二个录此视频的动力。
此视频旨在帮助想要学习或巩固学习的Oracle初学者，课程面向的人群包括但不限于：
1、有一定计算机基础的学生（不限于大学生）；
2、有数据库基础期望转型Oracle工作的程序猿；
3.、Oracle从业者，但技术点单一，希望拓展学习的朋友。
学习后能达到什么效果？
1. 初步了解Oracle数据库，可以从事Oracle相关初级工程师工作；
2. 掌握持续学习的方法，有能力自学更深层次的知识；
3. 知道如何寻找解决工作、学习中遇到的问题。
主持人：好的，广告之后我们继续后面的分享吧。今天嘉宾的分享都非常给力，讨论也非常激烈，不知不觉已经过去了近两个小时了，我们接下来要进行第三个话题的分享了，3、元数据管理，有请我们的春宇老师。
春宇老师今天其实是有事冲突了，在百忙之中还抽出时间给大家做分享，可见春宇老师是非常热心的，也非常愿意跟大家交流，前面几期的微信直播活动也多次出现春宇老师的身影，春宇老师也为大家准备了数据仓库建模方面的课程，非常受欢迎，2016-1-18日上线，到2016-3-30日，73天的时间，学员数已突破1000人。课程地址：，里程碑！高质量数据仓库建模课程突破1000人！，大家可以来一睹春宇老师的风采！
春宇
不好意思，因为我刚才有事冲突，第一个话题《数据治理》没有赶上。其实也准备了一些内容，分享给大家。
大家好, 今天我们简单聊一下数据治理. 数据治理这个话题非常大，我们不可能通过短短的两个小时把所有内容都涵盖，我今天讲的重点是如果一个企业要启动一个数据治理的进程，都需要做什么事。
那么什么是数据治理呢？
首先有一个大前提，就是企业对于数据的战略态度是什么。企业把数据作为一种特殊的重要的资产来看待，并由此希望能有效的管理这种特有的资产时，就需要配备的专门的人员、制定相应的流程、规章制度以及采用一些数据相关的技术去辅助管理，这种组织和安排就是数据治理。数据治理通常是长期的过程。
那么一般什么情况下会去启动数据治理这种项目呢？都是哪些需求促使企业要做数据治理呢？
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，跟踪风险管理信息的质量。
除了上面的内容，数据治理还包括更深入的内容，包括：
主数据治理、分析治理、安全和隐私，以及信息生命周期治理等等。
数据治理是非常庞大的课题，今天我们暂时只讲这么多。
主持人：由于时间关系，我们先进入第三个话题的分享，有关于数据治理还有疑问的，等第三个话题分享完之后再提问，春宇老师会一并给大家解答。也可以把问题发布到天善智能问答社区，各位嘉宾会在活动之后给大家详细回复。
下面有请春宇老师 给我们开始第三个话题 —— 3、元数据管理的分享。
春宇
元数据管理这个大家谈的比较多，做起来的比较少，而且很多人对元数据的一些概念也不是很清楚，我先描述一下元数据的内容，也就是元数据都要管哪些东西。
元数据管理是我最爱谈及的话题之一，因为本人商业智能相关的绝世武功一直都没学好，而绝世武功的目录一直都背的不错。而元数据，真的很像绝世武功的目录。
不知道谁定义的元数据，和数据仓库商业智能等等长篇大论的定义迥然不同，它简直简短得不能再简短：The data about data。好吧，我第一次看见这定义时，真心还是不懂，谓之玄而又玄。待经过一些学习探索之后发现这定义还是很棒的，更准确的或许应该是The information abut data。
看上面的经典DIKW金字塔，Metadata发生于 Data 和 Information之间，它是用于描述Data的东西，Metadata + Data就构成了Information。还是不懂是不是？
给个例子： Rainbow 2011/07/06
如上两个，均是Data，单纯看他们，我们是无法猜出它们的含义的，但如果：
而这里，“名字”和 “生日”分别是用来描述Rainbow和 2011/07/06，它们使 Rainbow和2011/07/06具有了含义，从中我们获得的信息 “一个叫Rainbow的孩子，生日是2011年7月6日”。”名字“和”生日“就是元数据。
下面这张图很有趣，它以关系型数据库为例，解释了三个术语。
1. 数据。在图中就是Data Instance，这里给出一个人的名字以及他的相关信息：Mr. John PublicJr.
2. 模型。在图中对应Model，给出了在数据库模型中，为了描述上面的 人 的数据，构造了怎样的元数据 模型：有三个实体，分别是Person，Name和Address。这Model对应的内容，就是我们今天的课题：元数据
3. 元模型。这个其实是我们今天要讲的重点，它是用来装 模型 的框架，因为是关系型数据库，因此元模型对应的内容就是 DataModel(数据模型），LogicalEntity（逻辑实体）和Relationship（关系），其实还应该有Attribute（属性），Constraints（约束）等等关系型数据库中的概念。
而我们学习元数据，其实应该先去了解不同类型的元数据对应的元模型，而元模型作为元数据的框架再去填充元数据的内容。
接着说元数据，元数据按照功能主要分为三类：
1. Business Metadata
2. Technology Metadata
3. Operational Metadata
而对于BI系统而言，这三类元数据，横亘整个BI全部生命周期，且在DB，ETL，Report各个领域均扮演极其重要的角色。可以说元数据管理是数据质量，以及信息治理的基础。如下经典，请铭记于心：数据不会自己管理自己。而我们需要通过元数据去管理他们。
BusinessMetadata
那么什么是BusinessMetadata？
广义来讲，所有用于描述业务各种逻辑的信息都可称为Business Metadata。这包括但不仅仅限于如下信息：
商业术语：BusinessGlossary, 包括名词和详细定义
术语分类：Taxonomies，对于上述的商业术语的逻辑归类，可构成Glossary Tree
业务规则：BusinessRule
业务流程：BusinessProcess，包括Activity, Input,Output, Supplier, Consumer, 等等
首先，商业术语（Business Glossary）, 提醒大家注意，这里的Metamodel，也就是装载 商业术语 元数据的框架。
接下来，术语分类
还有，业务规则
这些其实也是：
TechnologyMetadata
接下来什么是TechnologyMetadata？
广义来讲，所有在计算机系统中的各类数据的描述均可称为Technology Metadata。以BI系统为例，这包括但不仅仅限于如下信息：
系统：System
接口：Interface
实体/表：Entity/Table
属性/字段：Attribute/Column
数据转换：DataTransforming
......
# TechnologyMetadata是我们讲解的重点
Technology各个工具以及平台的情况：
1. DataRepository
Data Modeling:Table/Column等详细信息
可使用工具如ERWIN，PowerDesigner, Infosphere Data Architect等等，几大主流数据建模工具之前的元数据可以项目export/import，会有少量问题但基本可以重用。
Oracle，DB2， MSSQLServer等均有自己的数据字典，可以反向生成为数据模型文件。数据库的数据字典不会记录如前面描述的详细的元数据信息，因此需要Designer在做Model的时候整理元数据，或以comment的形式保存至Data Model中，或自定义元数据模型将相关信息保存。而几大Data Model软件都以文件的方式保存(PD具有一定的Repository功能，但功能也不够丰富），因此如果我们要做元数据管理，也应该将Model的信息结构化的保存到Metadata Repository中。一些Matadata Repository也能够支持数据模型的导入。
2. ETL
数据转换规则
最常使用的还是EXCEL表，IBM的InfosphereFacttrack具备此类功能，但也只可记录简单的Mapping信息，对于在ETL程序中的复杂实现还是无能为力。还好Infosphere系列能够记录数据血缘。
Informatica等工具未曾尝试，当下未知。
数据质量规则
Datastage,Informatica均支持数据质量管理，定义数据质量规则集合
3. Report &Analytics
语义层
Business Object的Universe
Cognos的FrameworkModel
OBIEE的语义层
将物理模型翻译成最终使用者容易理解的商业模型，屏蔽复杂的关联关系逻辑，增加维度的定义以及维度之间的关系等。
OperationalMetadata
接下来：OperationalMetadata指的是在DB, ETL，Report等所有过程中，如日志、安全、审计、血缘等等信息。通常他们可以用来解答如下问题：
1. Job运行成功了还是失败了？有哪些出错或警告信息？
2. 上次Job中哪些数据库表，或者文件被读取/修改了？
3. XX Job在最近几次运行中读取多少条记录，修改多少条记录，引用多少条记录，平均速度如何？
4. XX Job什么时间开始，什么时间结束的？
5. Job运行在哪个服务器上？
6. 一共多少张报表上个星期发布了？
7. 多少个Schedule报表运行成功了？
8. 报表运行成功后发送了多少封邮件给不同用户？
9. XX报表的平均访问频率是多少？什么时间访问的最多？
......Operational Meta种类繁多，在此不一一赘述，需结合实际项目应用做详细的规划。
不做元数据管理的危害
1. 系统难于理解
大公司林林总总的系统上千级别，而各个系统均只考虑当下不考虑未来，经年累月之后会发现系统无法理解。后面则会带来大量的项目风险，开发成本，时间成本，等等多种问题，也会造成很多有创意的新的idea没法办法展开。总之，后患无穷。
2. 信息无法整合
基于上面的问题，系统无法理解，当需要做信息整合时完全无从下手。
3. 知识无法传递
系统的知识保存在架构师的头脑中，或者上帝的头脑中，当精英人员流失会造成知识无法传递，系统无法更新升级也无法指导未来的信息集成。
4. 信息质量问题
元数据质量不高，几乎一定会带来后期的信息质量问题。同一含义的字段采用不同的名字，不同含义的字段采用相同名字，等等问题会带来大量数据不一致问题。
5. 阻碍企业发展
元数据以及数据质量问题甚至会影响到企业的发展，信息系统为企业提供有力的支撑，如果底层数据存在大量问题，很多企业的运行无法正常展开。可以想象如果Amazon如果数据质量不能支持精准的推荐，就不会有Amazon的今天。
6. 无法重用
Information as Service很大程度上需要对企业通盘的信息规划的考虑，完善的元数据是其基础。
7. 影响项目开发质量和效率
几乎要从头分析源系统的结构，并且没有可重用的元数据。会造成开发效率低下且开发质量没有办法保证。
8. 数据难于追溯
没有数据血缘的追溯，当修改一张基表时，根本无法获知其下游影响了多少表, ETL Job以及报表。而报表中某一个项目数据出错，也很难判断在什么环节数据出了问题。
9. 系统难于优化
如果没有Operational Metadata，很难对系统的运行状况作精准的分析并做出有效的优化措施。
元数据管理的策略，通常是需要建立元数据仓库，这个一般都是依托于某些元数据管理工具，我也只用过IBM的infosphere套系，原则上来说，所有的data about data都应该进metadata repository，包括服务器，文件，web service, etl jobs, 业务术语列集，也包括报表，同时ETL 工具还能够捕获一些日常operation的log，也可以整合的元数据库里，再有就是对data的profling分析，比如row counts, null的比例，字符的pattern，与其他表的关联关系（假如你没有建外键的话，自动根据名字匹配，你也可以手动指定）等等。
infosphere套系有几个产品都可以做为元数据管理工具来使用，我相信informatica之类的也差不多，一个是蓝图工具，包括blueprint director和infospheredata architect。blueprint director这种东西我没见过其他公司有，大概就是画各个系统数据架构蓝图的东西。还有就是infospheredata architect，这个和erwin ,powerdeisnger是一样的东西。再有就是infosphereanalyzer，这种的就是data profling的分析工具，查看当前系统现状的，但这种东西非常耗费系统资源，我们都不能在PRD环境直接跑。此外还有fasttract，这个是做data mapping的，做ETL用的，还有asset magement，这个是用来导入各种元数据基本信息的，比如cognos 报表，BO语义层，也可以导入pdm等等，再就是workbench，有不少功能，还能做datalineage分析，内容比较繁杂，基本上思路就是用一个库去存储上面我说的各类信息，尤其对于数据血缘这种分析，大企业非常需要，当一个表的结构发生变化，我能知道下游有多少应用受到影响。
好了，元数据的内容很宽泛，暂时先讲到这。
主持人：好的，感谢春宇老师。大家对元数据管理有疑问的，包括第一个数据治理的话题有疑问的，现在都可以提问了。
自由讨论环节
问题1：@春宇 血缘分析有什么好工具？
春宇：data lineage分析难点在于对程序的解析，然后把解析后的结果结构化。
邱明伟：SQL能解析吗？
春宇：因为datastage,cognos都是IBM自己的产品，因此workbench通过这种办法去解析SQL，但复杂的SQL好像不太好用。
邱明伟：恩，datastage我知道他有自己的元数据库。
春宇：另外的思路就是半自动化的处理，比如你建一套表，在系统上线的时候，无论ETL还是Report，都需要开发者提供mapping信息，作为系统工程的一部分，也有一些工具能够解析SQL，价格也不贵，datastage job都可以。但cognos有些复杂查询也搞不定，如果再跨一个cube就更难了，所以元数据管理是应该集成在系统工程中的。也就是说做开发设计的时候，版本更替的时候，就需要把元数据的变化check in到元数据库中。
问题2：@春宇 informatica的血缘分析工具必须在建设阶段使用才能得到血缘关系
春宇：@内心召唤 我这边用INFOsphere,也不是所有都能解析。
问题3：@春宇，有什么SQL解析的工具吗
内心召唤：@春宇 普元的工具据说可以，有接触吗？
邱明伟：不行的，他们是SQL要按照一定的规则来写才可以。
杨宝军：sql解析是补救方式，关键是开发工具本事带元数据管理功能
邱明伟：但是datastage好像不会保存历史数据哦，我们项目组是用datastage开发的，目前JOB解析这块已经基本搞定了, 现在就是SQL这块比较麻烦。
春宇：元数据管理需要另外开发额外的程序去配合使用，比如，用workbench其实你可能不爽。你可以直接读metadata repository。SQLparser，要花点钱，几百刀，java写的。
内心召唤：@邱明伟 informatica肯定有
邱明伟：SQLparser，这个是sql解析的工具啊
春宇：嗯
春宇：用过多withstatement的解析比较麻烦
老头子：一般是解析xml，Datastage自己也可以解析xml，可以开发个作业自己解析自己的文件，然后提取出SQL来试试。
邱明伟：with结构的加上meterialize的hint，不要让他做视图展开。
主持人：再次隆重介绍一下三位老师的视频课程（www.hellobi.com）：
BAO胖子教程：数据仓库建模指南系列教程 【结合大量项目实践的长篇教程、持续更新中、国内首发】
老头子视频：Oracle 数据库入门教程
逆光视频：INFORMATICA入门开发实战视频教程
这么多免费的资源，让大家利用碎片化的时间就可以学习，非常感谢各位老师的付出，也感谢天善给大家提供这样的平台，今天分享的内容大家没来得及听的，后续我们都会整理成文字版发布到天善智能公众号以及中，敬请关注!
今天的微信直播活动到这里就结束了，喜欢天善智能的朋友们请继续关注我们，每周五晚8:30，我们不见不散哦！
每周 Friday BI Fly 微信直播参加方式，加个人微信：liangyong1107 并发送微信：行业+姓名，参加天善智能微信直播。
天善智能是一个专注于商业智能BI、数据分析、数据挖掘和大数据技术的垂直社区平台，旗下包括问答社区、在线学院和招聘平台三个网站。
问答社区和在线学院是国内最大的商业智能BI 和大数据领域的技术社区和在线学习平台，技术版块与在线课程已经覆盖 商业智能、数据分析、数据挖掘、大数据、数据仓库、Microsoft BI、Oracle BIEE、IBM Cognos、SAP BO、Kettle、Informatica、DataStage、Halo BI、QlikView、Tableau、Hadoop 等国外主流产品和技术。
天善智能积极地推动国产商业智能 BI 和大数据产品与技术在国内的普及与发展，合作成员包括：帆软软件、Smartbi、永洪科技、ETHINKBI、TASKCTL、奥威 Power-BI、上海海启路科技、上海亦策等。