元数据管理与数据质量平台.docx
《元数据管理与数据质量平台.docx》由会员分享，可在线阅读，更多相关《元数据管理与数据质量平台.docx（19页珍藏版）》请在冰豆网上搜索。
元数据管理与数据质量平台
1.1.1数据质量管理架构
数据质量问题一直是困扰数据仓库发挥积极作用的重要因素，在数据仓库建设之初就应当从战略角度对数据质量体系进行规划。
1.1.1.1数据质量基础定义
1.1.1.1.1完整性
数据的完整性：
为实现业务目的而设计组织的数据模型是否完全，是否覆盖各个方面。
例如：
对一个业务，一个客户，一个产品，一个营销活动，一个客户的性质等进行缺失考察。
例如，客户名称有姓无名等，客户档案是否齐全，是否客户所有业务都包含在等。
完整性破缺主要发生在实体或对象的属性上和整个数据缺失两种情况。
完整性列表：
数据完整性，例如属性数据是否残缺，数值类型数据是否有空数据
业务完整性，例如是否有些业务没有包含在，是否涵盖所有生产系统和必要的外部数据（例如竞争数据，保监会数据），是否覆盖所有客户（例如是否覆盖全部客户）
设计完备性，设计是否完善
模型的完备性
数据字典完备性
映射关系完备性
业务规则是否完备
元数据完备性
加工层次完整性，加工过程中重要的中间数据是否保存，例如，有月统计数据，考察日数据是否存在？
粒度完整性，重要经营指标各个粒度数据应该完善
1.1.1.1.2有效性
指数据包含了一个有效的数据格式或值
1.1.1.1.3一致性
数据的一致性是一个长期的困难。
建立数据仓库的核心目的之一也是争取解决这个问题。
一致性定义为各个系统数据的统一，定义为数据仓库系统数据定义的统一。
一致性还表现在定义和口径的一致性。
数据库一致性，设计上是否有多种存储并存，各类统计口径是否统一
冗余和星型模型以与非第三式一致性保证措施
和源数据一致性
1.1.1.1.4唯一性
唯一性定义为系统数据定义的唯一性。
由于数据仓库技术不一定受第三式约束，可能具有相当的冗余，但数据冗余不能违反定义的唯一性原则。
对于哪些既存在于关系数据库又在多维数据库中表现的数据和指标要特别注意，因为极容易由于生成的时间差造成不一致。
唯一性至少应当向系统的用户说明最终的数据评判标准，数据的冗余和评判应当是元数据管理的重要容。
1.1.1.1.5正确性
数据正确是决策的关键，数据不正确，数据仓库项目就等于失败。
但数据的正确性难以通过自身检查。
应该对重要数据和重要统计设立正确性检查。
主要方法是:
Ø数据自身统计检验
Ø纵向对比检验
Ø数据间按逻辑交叉检验
Ø横向对比校验
主要检查的容：
ETL过程正确性
加工过程正确性
数据整合正确性
模型正确性
展现正确性
查询正确性
核对过程是否充分
1.1.1.1.6准确性
数据的正确性基础上才有意义讨论准确性。
准确性包括精度和近似规则。
精度：
系统定义的数据必须满足的精确性要求。
例如，客户生日，可以精确到年，或月，或日；全局收入统计或许到万元即可，也许到角分。
1.1.1.1.7可用性
数据的可用性不是一个简单数据质量问题，而是系统质量问题，所有质量因素都可能影响到可用性。
数据的可用性主要体现在使用的效率上
1.1.1.1.8时效性
1.1.1.1.9清晰性
数据的清晰性考验系统元数据的精度。
元数据必须清晰定义每一个数据的来龙去脉。
必须没有歧义。
1.1.1.1.10充足性
数据的充足性定义在保证数据正确性和准确性基础上是否能对主要业务专题提供足够的数据进行足够精度的分析需求。
例如，进行时间序列分析通常需要至少36个连续时间单位的数据，是否能够提供这个时间序列。
数据积累是否足够广泛，例如设计上虽然包含了足够宽广的业务领域，但每项业务的数据是否真的收集到了足够多，
数据积累是否足够时间，充足性的特殊情况，是否收集了足够时间长度的数据
元数据和字典数据的充足性，描述性是否足够
1.1.1.2数据质量保证框架
1.1.1.2.1战略
战略–从企业战略方向主动的考虑数据质量状况。
战略的意义：
Ø提供了战略上的、可操作的数据质量保障方向
Ø识别企业数据的关键因素
Ø指明数据质量的围
战略的围：
Ø策略：
包含以下方面的容，
✧任务定义
✧与业务的关系
✧切入点
✧约束条件
✧可行性
Ø关键方法：
包含以下方面，
✧方向
✧使规化
✧保障策略被顺利执行的手段
Ø变更管理：
为了适应企业变更而采取相应的数据质量管理变更机制
1.1.1.2.2组织
组织–为了达成企业的数据质量目标，从企业行政管理以与职能设置上进行考虑。
组织指的是如何组织相应的人员、设立相应的数据质量机构对数据质量进行管理，包含以下方面：
Ø组织机构规划
Ø人员与其职责设计
Ø制定考核制度
1.1.1.2.3管理
管理–对于企业中元数据以与业务规则的维护上予以管理
管理包含以下畴：
Ø定义完整的元数据集
Ø定义无二义性、易于理解的业务规则
Ø建立一个健壮的、高可扩展的数据模型
1.1.1.2.4架构
架构–从整体上（数据、应用程序、技术架构）对改进数据质量予以考虑
架构的建立应从以下方面进行考虑：
Ø数据架构
Ø应用程序架构
Ø基础架构
1.1.1.2.5过程
过程–过程的改进
过程关注的是数据质量管理的过程，应从以下方面进行考虑：
Ø数据质量管理的实施过程
Ø过程控制点以与控制路线
Ø（错误或异常的）补救措施
1.1.1.2.6验证
验证–定义数据质量的评测标准并按所制定的标准对其进行验证，只有确立相应标准，数据质量的控制才具有现实意义。
验证包含以下容：
1.1.1.2.6.1数据的重要程度，可以从以下方面进行判断：
✧对日常操作的影响
✧对一般业务的影响
✧对财务上的影响
✧对客户服务的影响
✧对决策的影响
1.1.1.2.6.2数据质量维度--数据质量问题域汇总
序号
数据质量问题
细目
备注
1
完备性
是否涵盖所有生产系统和必要的外部数据
是否涵盖所有业务
是否覆盖所有客户
是否覆盖所有产品
系统设计完备性
数据字典完备性
映射关系完备性
业务规则是否完备
元数据完备性
2
完整性
数据完整性
业务完整性
数据模型完整性
加工层次完整性
粒度完整性
3
充足性
对问题域的解决方案是否有足够的数据作为分析基础
数据积累是否足够广泛
数据积累是否足够时间
元数据和字典数据的充足性
4
正确性
ETL过程正确性
加工过程正确性
数据整合正确性
模型正确性
展现正确性
查询正确性
核对过程是否充分
5
准确性
数据精度是否足够
近似模型是什么
6
一致性
数据库一致性
主键，外键完整性
冗余和星型模型以与非第三式一致性保证措施
和源数据一致性
7
逻辑性
逻辑严密性
是否有严密的逻辑约束
数据逻辑关系
表表间关系
8
职业道德和法律
结果不可修改特性
9
数据质量保证体系
数据出错处理和防预案
10
分析质量
报表质量
查询质量
接口数据质量
非生产数据质量
例如市场竞争数据
1.1.1.2.7沟通
沟通–关注使用数据信息的相关责任者之间的沟通，要充分关注数据质质量组织机构中的员工、不同的团体以与单位之间的相互沟通。
1.1.1.2.8执行
执行–指组织中的每个成员都应改遵守数据质量管理所制定的要求、决定 。
1.1.1.3数据质量持续改进过程
Ø发起–按照制定的规获取相应的项目资源、支撑工具以与制定工作计划。
Ø定义–定义详细的过程、数据、组织的划分以与质量元素、标准与测算方法。
Ø评估–对现存数据与业务环境进行评估，以便识别项目对数据、过程、系统以与组织架构所造成的影响。
Ø清洗/改进/评测–改进现有数据的数据质量，并采取措施修改业务环境，避免类似错误继续发生。
Ø强调循环改进
1.1.2元数据管理架构
国有资产管理支持系统数据仓库数据源广泛，数据消费者群体跨度也很广，各种指标、维度、统计口径等元数据相关的问题必然是项目面临的巨大挑战之一。
1.1.2.1元数据基本概念
元数据（MetaData）是关于数据的数据。
当人们描述现实世界的现象时，就会产生抽象信息，这些抽象信息便可以看作是元数据;元数据主要用来描述数据的上下文信息。
通俗的来讲，假若图书馆的每本书中的容是数据的话，那么找到每本书的索引则是元数据。
元数据之所以有其它方法无法比拟的优势，就在于它可以帮助人们更好的理解数据，发现和描述数据的来龙去脉，特别是那些即将要从OLTP系统上升到DW/BI体系建设的企业，元数据可以帮他们形成清晰直观的数据流图。
元数据的概念虽然在国刚刚被人们熟悉起来，但在国外他已经历了较长的发展历史。
从上世纪60年代，人们认识到元数据的需要，到数据字典、CASE工具的应用，以与上世纪90年代数据仓库体系中元数据存储库的出现，直到现阶段国外企业以元数据为驱动的IT系统建设的方法论流行。
企业对于元数据的价值越来越有深刻的体会。
元数据按其描述对象的不同可以分三大类:
技术元数据、业务元数据和管理元数据。
技术元数据主要用是用来描述数据实体和数据处理过程中的技术细节和处理规则。
比如我们所熟知的表结构、ETL映射关系等，这类元数据主要是系统建设的技术人员使用。
业务元数据主要是对IT系统的数据实体和数据处理的业务化描述，包括业务规则、业务术语、统计口径、信息分类等。
我们经常提与的KPI定义和报表统计规则等就属于此类元数据。
业务元数据主要的使用者是业务人员和公司决策人员。
管理类元数据主要是对项目管理、IT运维、IT资源设备等相关信息的描述。
这类元数据主要是企业IT部门的管理人员使用。
利用此类元数据可以进行工作分配、网络资源等方面的管理。
元数据的管理方式有三种:
集中式、分布式和混合式。
集中式的管理方式是把原有系统中的元数据抽取出来，用一个独立的系统来集中管理。
此类管理方式优点是:
可高效存取信息、独立于被集成的系统和具备存储附加元数据的能力;缺点是:
由于额外的执行和维护降低了ROI和实时性。
分布式管理方式是不具备独立的元数据存储库，系统实时的连接到原有的系统。
这种方式的优点是:
适时性比较好和能保证元数据的质量;缺点是:
过度依赖于集成系统和不能存储附加元数据。
混合式元数据管理既有独立的元数据存储库又可实时的连接到原有的系统。
混合式管理方式克服了集中式和分布式管理的各自缺点，同时集成了前两种管理方式的优点，既能适时的捕获和反映原有系统元数据的情况，又能让用户扩展和定义附加的元数据。
元数据管理目前遵循的规为CWM（CommonWarehouseModel）。
该规是由OMG组织制定的，此规目的是能在不同的系统之中可以自由、便捷的交换元数据。
CWM核心的技术有三个:
UML（UnitedModelingLanguage）、MOF（MetadataObjectFacility）和XMI（XMLMetadataInterchange）。
UML主要用来定义元模型;MOF用来提供操作元数据接口;XMI用来定义交换元数据的机制。
1.1.2.2元数据管理的五种状态
Ø第一级:
随机状态（Ad-hoc）
行为特征在这一级上，对元数据的管理是随机的。
元数据由某个人或某一组人员在局部产生或获取，并在局部使用。
在大多数时间里，元数据是隐匿在信息中，比如存储于诸如Word、Excel等形式的办公文档，这些文档使用的术语仅局部的用户能知道其确切含义。
人们通过与“责任人”直接通信或通过信息会话来获取这些知识。
在局部环境工作数月或数年后，人们使这些元数据以与对它的理解在化，使对这种信息有习惯性的理解。
在这一阶段，元数据通过组织机构缓慢的传播或根本不传播，这取决于局部小组与其他小组间的通信量的大小，这些元数据可能永远“待”在该局部小组或某个人那儿。
如果这样的小组或个人调离，则这种元数据信息可能永远丢失。
人元数据知识保留在人的大脑中。
在这种环境中，知道（或不知道）与谁交谈对于理解元数据成为一件十分重要的事。
处理元数据要通过与“责任人”的交谈才能共享。
新来者需要通过他们的日常工作来学习元数据。
外部人员难以理解元数据，他们必须与“责任人”交谈才能得到他们想要的东西。
因为元数据在局部产生或抓取并在局部使用，所以通常也只能在局部修改，这种修改通常也不会通知公司里其他的组织。
技术可以用各种不同的工具来生成元数据。
绝大部分是面向个人电脑的应用软件。
例如，ERWin可用于数据库建模，Rational用于为对象建模、Excel用于生成商品列表等。
这些工具都没有设计成可以交换信息，因此，只能在当地的文件系统中保存所生成的元数据。
Ø第二级:
可发现
行为特征在元数据管理的这一级上，可以发现在不同企业之间的元数据。
像第一级的情况一样，元数据仍然在局部产生和抓取，然而，它处于可发现状态，这样的元数据在企业一级显露，使得每一个对它有兴趣的人都能随时了解“什么已经存在”。
元数据仍然可以在局部级上维护，然后更新中央知识库，但它们仍然使用不同的命名法。
结果，一样的名字被用于表示意义不同的事情，而同一件事情则使用了几个不同的名字。
尽管如此，相比之下，从不同来源来的数据和数据的含义已经具有了更多的透明度。
对于商业用户，如果他们需要，现存的技术可为他们提供有关数据的来源和怎样对数据进行计算的信息。
人人们开始感知到共享元数据信息的重要性。
业务分析员、数据拥有者和应用开发者现在自觉地将元数据信息加载到中央知识库中。
处理元数据知识经由中央数据库进行共享。
凭借对中央知识库地理解，人们能够发现在其他应用系统中的数据。
然而，由于使用术语的不同，人们互相之间需要交流，以便弄清某些元数据的含义。
而且，由于元数据的更新不受任何方式的控制，使得这种更新没有告示或贴切的分析。
技术有一些元数据管理工具可用于共享来自数据源的元数据，并能把来自不同建模工具的逻辑元数据导入到元数据知识库中。
AGRochade、Unicon、MetaMatrix是该类产品的一些例子。
然而，除了以商业含义来定义数据表格的栏目名之外，这些工具没有一个能很好地抓取元数据。
Ø第三级:
管理控制
行为特征这一级对元数据的修改进行集中管理。
局部业务单元或开发小组如不通知其他的元数据保管者和用户，就不再能按照自己的想法对元数据进行修改。
在一个地方发起的元数据的修改将传播给其他地方。
有各种工具和方法可用于不同业务单元之间交换元数据。
为了整合不同数据源中的数据，仍然必须用手工进行数据的映射，以解决不同数据源的数据整合。
但是，这种映射在一个中央知识库上进行维护和管理。
人数据拥有者、应用开发人员、用户和其他的数据保存者现在比以往任何时候更清楚元数据管理的重要性。
人们遵循有关元数据管理的“监督”处理操作规程。
在对元数据进行修改前，他们就分析这种修改将会产生的影响。
他们认识到元数据的共享将使组织的运作更有效，并使他们的生活更轻松。
处理建立了监督体系结构（谁是数据和应用的拥有者），监督资产（数据仓库、数据集市、命名标准）和流程（何时开始更新、如何更新）。
技术有几个工具经常被用于元数据的监督处理。
SchemaLogic是一种新兴的工具，通常被用于帮助监督处理发现业务的词汇与其分类。
还有一些软件提供商正在相互竞争，以填补这一空间，但还没有一家能提供商用的产品。
Ø第四级:
优化
行为特征在对元数据实施集中存储并通过监督体制对元数据进行管理后，企业会发现，通过标准化和整合可以实施有意义的优化。
为了优化各业务单元之间的各种冲突和各个副本，人们开发了一个企业数据模型和词汇表。
人们可以将这些标准模型和词汇表用于各种新的应用。
时机成熟时，可以把各种老的应用迁移到这些模型上。
人在这一级，人们坚持不懈地探索优化的途径。
人们协同工作，通过在数据的入口点确认数据的有效性来提高数据的质量。
通过确定各业务实体的权威数据源，使数据的映射达到最小化。
数据开始从一个业务单元平滑地流到另一个业务单元，而不用担心昂贵的数据集成成本。
处理首先，生成企业数据模型，并在中央知识库进行维护。
第二，对数据模型中定义的每一个实体确定权威数据源或企业应用的主参照数据，然后将业务的上下文信息和含义与这些数据源进行关联。
在整个组织中对业务的词汇表进行标准化。
鼓励应用开发小组使用这些标准化的术语，来生成、传播和表示信息。
技术目前，仅有少数几个能帮助企业实施优化的工具。
而且，每一个工具只能完成其中一到两个任务，还没有哪个工具能做企业优化所需的所有事情。
Ø第五级:
自动化
行为特征在这一级，元数据管理是自动进行的。
当在逻辑层次发生元数据更新时，它们将被传播到物理层次。
反之，当在物理层次发生更新时，逻辑层次将被更新，以反映这种更新。
在元数据中的任何变化也将触发业务工作流，以处理其他各个业务系统所需的相对应的任何修改。
由于各个应用系统遵照一样的词汇表，它们之间的关系可以通过知识本体进行推断，所以，各应用系统之间数据格式的映射自动产生。
人人们把元数据管理作为常规业务的组成部分。
就像电信网对业务的支持一样，元数据成为组织运作中一种关键的、普遍存在的、无形的资产。
元数据管理变成业务处理的一个主要组成部分，而且，整个业务运作都要依赖于它。
事实上，如果元数据管理实施得很好，人们可以无需关心它在何处。
在自动化级，元数据管理成为一种使能器，而不被视为一种障碍。
处理在这一级，元数据管理的处理较为理想。
绝大多数处理是自动完成的。
人们从手工和程序处理过程中解放出来。
他们在元数据判定上可以工作得更有效。
当业务变化时，由知识工人对企业数据模型、词汇表和知识本体进行维护。
这样一种改变立即会在各个应用中反映出来。
例如，假如一个新产品被引进，把它加到企业词汇表和知识本体中，这一情况将自动地被传播给金融系统、制造业系统和营销系统。
使得每个应用系统无需花费昂贵的代价，去完成相应的修改。
技术各个应用必须使用企业数据模型、词汇表和知识本体来获取、传播和表示数据。
人们开发了各种代理，将数据从一种格式翻译成另一种格式。
为了实现这些功能，当前正在展开知识库表示和知识集成方面的许多研究。
1.1.2.3元数据管理工具基本功能
元数据管理典型的应用有:
ETL映射分析、血统分析/影响分析和差异分析等。
这些应用对于整个企业、技术人员、业务人员和IT管理人员都的挥着至关重要的作用。
对于整个企业而言，元数据管理可以协助企业进行数据资产管理;帮助解决数据孤岛的现象，形成统一企业信息地图;实现集中浏览分布在企业部的所有电子文档;同时协助企业建立企业级视图的指标库。
随着企业信息化建设的不断深入和积累，元数据管理平台可以发挥企业知识传承的平台。
通过元数据的“ETL映射分析”功能，从企业级视图去查看“Transformer”这个转换的具体细节。
帮助技术人员更好的理解数据部的来龙去脉。
对于那些已经建设有BI/DW系统的企业而言，企业部分散着数十种系统的情况是很普遍的现象。
这些企业的业务人员和决策层所关注的一些统计报表和指标，往往是经过许多业务系统和若干数据处理环节而形成的。
当最末端的数据发生异常时，在没有元数据管理系统的情况下，需要许多单位和部门（包括软件集成商）的人共同参与，利用手工的方式去逐级查找数据出错的原因。
这种方式不仅不利于问题的与时发现，而且一旦出现问题，很难短时间定位问题，甚至根本不可能定位问题的所在。
而利用元数据管理系统的血统分析等功能，可以很容易的定位问题，再配合监控规则的设置，使问题发现的与时性大大提高。
利用元数据管理系统，企业可以建立数据元（标准）的统一视图。
通过统一数据口径、完善指标体系、建立统一数据视图，可确保数据的完整性、准确性、一致性，从而有效的在各个业务系统进行数据的转换和整理工作。
目前，许多企业经常会面临同一个指标在不同部门或者不同系统中定义不一致的情况，以至于最终的统计数据出现偏差，为决策者提供了错误的决策依据。
如某企业某月A省分公司和B省分公司都给总公司上报了“产品销售量”的指标，A省分公司的产品销售量为500万件，B省分公司的产品销售量为300万件。
按常识判断A省分公司的销售量应该远远小于B省分公司的销售量，但报表的数据却与常识相差甚远，究竟是什么原因造成这种与常识的不一致性呢？
在没有元数据管理系统时，我们很难发现其中的原因，但有了元数据管理系统的指标差异分析等功能，通过元数据的差异分析很容易解释这些现象。
如图5所示:
之所以出现统计的异常是由于A、B两省分公司对同一指标“产品销售量”的定义不一致而造成的。
此外，元数据管理系统可在统一数据视图上进行全行业的指标一致性分析，可对关键业务的监控规则进行设置和管理。
随着数据量的不断积累，数据质量问题的日益突出，元数据管理平台可承担起全企业的数据质量管理的基础平台。
同时，利用需求类元数据和流程类元数据，来协助IT管理人员进行项目和流程的管理，从而减少企业人员流动对于项目造成的影响。
在这个“惟一不变的就是变化本身”的时代，在这个数据和知识爆炸的时代，如何有效的进行企业IT系统建设的扬弃和传承？
如何高效的利用企业数据资产？
这些问题犹如“格尔迪奥斯绳结”摆在我们的面前，而元数据恰是解开这个“结”的关键所在。
对于企业IT系统建设而言，我们依然信奉“元数据不是万能的，但没有元数据是万万不能的”这句经典诠释。
特别是对于那些组织结构复杂、IT系统众多的企业，这个组织和支撑它的IT系统要想有效运转起来，一定少不了元数据这种“润滑剂”。
1.1.2.4目前主流的元数据管理工具
总起来看，目前国的元数据管理工具大概有三类。
一是像IBM、CA等公司都提供的专门工具,比如IBM收购Ascential得到的Metastage，CA的DecisionBase都是如此；二是像DAG的Metacenter，它不依托于某项BI产品，是一种第三方的元数据管理工具,三是国部门开发商在某些具体的项目中也在开发自己的元数据管理工具。
各种元数据管理工具有很多。
理论上讲，用户可以用其中一种管理其他系统中的数据，比如选择数据仓库系统厂商提供的元数据管理工具来管理其他层面的元数据。
但实际应用中的管理效果如何呢？
一般情况是，这些专门工具管理自己本系统的元数据尚可，一旦跨系统管理，效果就不尽如人意了。
从国的实际应用来看，DAG的Metacenter这一工具使用最多，目前所看到的在电信、金融领域建设的元数据管理项目基本上都是应用了这一产品。
至于像CA等公司的工具，在国基本上没有成功案例。
1.1.2.5国有资产管理支持系统元数据管理架构
1.1.2.5.1现状
虽然元数据管理已经很久被业界所关注，但是大多数企业的元数据管理事实上还是处在一个混乱的状态中,元数据没有被有效的纪录下来，大量的元数据嵌入在软件应用编码中，甚至更多的存在于员工的“部落知识”中，某个员工的离职都可能对企业造成极其糟糕的影响。
正如我们在元数据管理的五种状态的第一级状态所描述：
●人元数据知识保留在人的大脑中。
在这种环境中，知道（或不知道）与谁交谈对于理解元数据成为一件十分重要的事。
●处理元数据要通过与“责任人”的交谈才能共享。
新来者需要通过他们的日常工作来学习元数据。
外部人员难以理解元数据，他们必须与“责任人”交谈才能得到他们想要的东西。
因为元数据在局部产生或抓取并在局部使用，所以通常也只能在局部修改，这种修改通常也不会通知公司里其他的组织。
●技术可以用各种不同的工具来生成元数据。
绝大部分是面向个人电脑的应用软件。
例如，ERWin可用于
升级会员 