数据治理理论10篇

篇一：数据治理理论

　　摘要：：数据是政府、企业和机构的重要资源。数据治理注重数据资源有效利用的众多方面，如数据资产确权、数据管理、数据开放共享、数据隐私保护等。从数据管理的角度，探讨了数据治理中的一项关键技术：数据整理。介绍了以数据拥有者和直接使用者(行业用户)为核心的数据整理的关键技术，包括数据结构化处理、数据质量评估及数据清洗、数据规范化、数据融合与摘取、数据整理的发布共享等。最后，针对增强数据整理方面的研究提出了一些

　　思考。

　　关键词：数据整理；数据准备；数据治理；数据管理

　　1引言

　　大数据作为一种资源，在政府、大型企业和机构中发挥着越来越重要的作用。随着大数据应用的持续推动，与数据资源的价值提炼、保值和增值密切相关的大数据治理越来越引起人们的重视。大数据治理是一项复杂的工程，它需要在国家、行业、企业等多个层面上展开体系化的建设，技术上包含数据资产确权、数据管理、数据开放共享、数据隐私保护等诸多方面。这些技术面临的挑战多、难度大，很多方面还没有形成被广泛认可的系统化的解决方案。本文从数据管理这个关键环节出发，探讨其中的关键支撑技术：数据整理(datawrangling)。数据整理也叫数据准备，是在挖掘提炼数据价值的过程中实行的前期的数据预处理工作。它看似缺乏轻重，实则非常重要。有调查研究说明，很多大数据分析任务80%以上的工作花费在数据整理上，这给数据分析带来了巨大的人力成本。很多分析设想因为承担不起前期的数据整理工作而最终被放弃。更重要的是，因为缺少系统性和理论性的支撑，数据整理的质量千差万别，这给数据分析的结果带来了很大的不确定性，大大影响了大数据价值的挖掘与提

　　炼。所以，人们很有必要重视数据整理的研究工作，它是整个数据治理环节中一项重要的基

　　础性工作，但是这项工作在学术界和企业界并没有得到应有的重视。

　　2数据整理概述

　　在数据仓库时代，数据预处理主要指的是抽取、转换和加载(ETL)过程。作者探讨的数据整理和ETL过程有相似的地方，两者都将多源异构的数据集通过一系列处理和转换，变成想

　　要的输出形式。但二者之间是存有较大差别的，具体如下。

　　●针对的用户不同。ETL服务于专业的数据工程师，而数据整理服务于企业内部所有的数据使用者，以对数据处理技术不熟悉的业务用户为主。这些用户虽然缺少数据管理与数据处理知识，但对业务非常熟悉，对数据背后的语义更清楚。他们是企业机构大数据价值发现的主力。如何针对这类业务型数据分析人员的需求和特点，提供高效的数据整理工具，是数据

　　整理技术面临的一大挑战。

　　●数据处理的目的不同。数据仓库中的ETL是为了建立数据仓库采用的相对固定的数据处理流水线。数据处理过程一旦建立，整个过程比较静态，很少再变化。数据整理是针对企业业务系统中的问题，动态构建的数据处理过程。它针对具体问题实行数据预处理，针对不同

　　问题采用不同的数据整理过程，一些任务之间能够共享某些数据整理过程。

　　●数据处理的对象不同。ETL处理的数据对象多为业务系统数据库中的结构化数据源，这些数据源有很规范的元数据。数据整理则面临更复杂、更多样化的数据源，直接应对大数据多样性(variety)的挑战。这种多源异构性在很多大数据应用中非常常见。数据整理技术通常需要协助用户将其拥有的数据与外部的一些数据源实行关联和数据融合。融合过程中存有

　　的大量数据质量问题(如数据项缺失、不一致、重复、错位、异常值等)给数据整理带来了

　　巨大挑战。与ETL技术相比，这种变化是一种质的变化。

　　数据整理是为了使数据更好地服务于数据分析而对数据实行的审查和转换的过程，它是整个数据分析流程中最占用精力的过程。从技术上讲，数据整理包含前期数据解析与结构化处理、数据质量评估与数据清洗、数据集成和提纯等过程。因为问题的复杂性，数据整理过程通常不是完全自动化的，而是需要用户介入的反复迭代和交互的过程。数据可视化、用户反馈与交互在整个过程中都发挥了重要作用。数据整理是由数据可视化领域的JefferyHeer教授(华盛顿大学)和数据库领域的JosephM.Hellerstein教授(加州大学伯克利分校)等人较早提出来并持续展开系列研究的。他们还将研究成果实行了产业化，成功创立了以数据整理为主业的Trifacta公司。本文主要在上述两位教授及其合作者发表的一些成果的基础上，对数据

　　整理包含的一些核心要素进一步地阐述，以期引起人们对数据整理研究和应用的重视。

　　3数据整理的核心技术

　　3.1数据的结构化处理

　　很多数据模型和算法是构建在结构化数据基础上的，多源异构数据要更好地与其他数据集融合，结构化处理是必不可少的过程。数据结构化处理首先要对原始数据实行解析，提取出需要的信息，再进一步将其转换成结构化数据。很多非结构化数据、Web数据是以文本形式存有的，需要使用信息抽取技术识别文本中的实体、属性、关系等信息。也有很多数据采用的是结构化强一些的数据模型，如JSO格式，这类数据相对关系型数据更灵活，在结构化转

　　换过程中也需要一些技术上的处理。结构化处理的主要输出形式是二维表或者图数据，它需

　　要用户确定数据在转换过程中采用的规则。

　　3.2数据质量评估与数据清洗

　　结构化处理主要是数据表达形式上的转换，数据结构化之后并不意味着能够直接使用。处理后的数据还要实行质量评估，假设发现数据中存有问题，则采取进一步的数据清洗措施。这个过程称作数据质量评估。一些简单的数据质量问题能够利用自动化的算法发现，因为数据质量问题的多样性和不可预测性，数据可视化技术成为数据质量评估的关键技术。借助可视化技术，对数据语义非常理解的业务人员更容易发现数据存有的质量问题(如缺失、不一致、异常等)。伴随着数据质量问题的发现，用户能够定义一些数据清洗规则，批量化地处理数据中存有的质量问题，提升数据清洗的效率。在数据库研究领域，也有人借助众包的思路提升数据清洗的效率。这种做法也是基于用户在数据清洗过程中发挥的重要作用实行的。在数据清洗过程中，需要多轮次的人机交互，系统的交互界面和交互方式对于数据清洗算法的有

　　效性尤为重要。

　　3.3数据规范化

　　数据清洗还有一项重要的内容是数据规范化，这也是数据准备中常见的问题。规范化有简单的底层数据层面的，如数据类型转换、单位变换、格式表换等，也有较为复杂的数据项规范化处理，如号码、、地址等。这类问题的主要成因是自然语言表达上的差异性会造

　　成同一实体存有多种表达形式。比较典型的例子是地址，人们需要对其实行规范化处理，以

　　提升数据的质量。地址的规范化面临的一个比较大的挑战就是粒度的选择，同一个地址能够用不同粒度实行表达。数据的规范化处理需要根据应用的需求特点，确定数据粒度和表达方式。地址规范化处理背后的问题是实体链指问题，即把同一实体的不同表达形式(不同名字)映射到同一个实体名字上，消除实体表达的语义鸿沟，进而通过关联在数据集中不同地方出

　　现的相同语义的实体，达到数据融合的目的。

　　此外，缺失值填充也是数据规范化处理过程中常见的问题。一种处理方式是利用缺失数据的上下文数据，采用数据插值的办法修复缺失数据；另一种处理方式是采用平均值或者缺省值

　　的办法填充缺失数据，有时候也用这种办法替换系统发现的异常值。

　　3.4数据融合与摘取

　　很多数据价值的发现源自于多源异构数据之间的关联和在关联数据基础之上实行的数据分析。将多个数据集(很可能来自于多个数据源)融合到一起，可使数据内容更丰富，更容易获得新的发现。不过，多源数据融合所需的数据整理过程面临的挑战是很大的。多源头的数据缺少统一的设计，这导致数据集成和数据融合的难度增大。传统的基于模式的数据集成方法很难发挥出大的作用，解决这个难题更多地要从数据项的层面关联数据。所以，实体链指操作在数据融合过程中就显得尤为重要。数据在实体层面的链指能够丰富实体的语义，建立跨数据项之间的关联。因为实体表达的模糊性，实体上下文信息对实体链指精度的影响非常大，有效利用实体上下文信息(如文本中的语境、表结构中同行属性值等)是实体链指的关

　　键。

　　数据融合是数据集整合的过程，有些分析任务未必需要全部整合后的数据，可能仅需要一部

　　分数据支撑分析任务。在这种情况下，需要从数据集中提取部分数据(如一些样本或者数据

　　片段),降低数据量，供数据分析模型实现分析操作。这个过程称作数据摘取，它需要根据

　　任务的特点摘取相关数据。

　　3.5发布共享

　　企业中复杂的数据分析任务经常需要被共享，某些数据整理操作也会被重复使用，这意味着数据整理的操作也是企业机构的一种资源。企业需要将这些操作以脚本的形式物化出来，使其能够被检索、分享和重复利用。经过数据整理过程的数据，其世袭关系需要被记录下来，以确保用户能够追溯数据的来源，也便于利用索引技术检索需要的数据整理操作。企业内部

　　对数据整理的共享对于企业内部知识管理、协同工作来说有很重要的意义。

　　4以技术带动数据治理水平

　　通过以上分析能够看出，数据整理以提升数据分析的效率和质量为目的，在整个大数据分析流程中占有重要的地位。近些年来，即使学术界在数据质量管理方面做了大量的研究性工作，但在实际应用中，很多数据整理的需求并没有得到很好的满足，还缺少数据整理方面的工具，尤其是系统化的数据整理工具。对于工业界来说，数据整理工作更多地被看作数据分析人员应完成的工作，人们并没有从工具和系统的角度开发设计高效率的数据准备工具，这使得数据分析人员在执行数据整理任务时，执行了大量重复性的工作。所以，增强数据整理的研究

　　和应用工作是很有必要的。

　　4.1数据的结构化与规范化

　　信息抽取是指从非结构化的文本中识别实体，并发现实体的属性、实体之间的关系，在互联网信息抽取、知识库构建等领域发挥着重要的作用。命名实体识别的目的是发现文档中的各

　　种实体，如人物、地理位置、组织、日期、时间等。命名实体识别技术分为以下3类。

　　●基于正则表达式的命名实体识别：把预先定义的正则表达式和文本实行匹配，把符合正则表达式的文本模式都定位出来。基于正则表达式的命名实体识别一般用于识别日期、时间、金额、电子邮件等规则的文本。

　　●基于字典的命名实体识别：把文本和字典里的<短语，类别>对实行匹配，对匹配的短语

　　实行实体标注，一般用于识别人名、地名。

　　●基于机器学习模型的命名实体识别：预先对一部分文档实行实体标注，产生一系列的<短语，类别>对，利用这些文档实行机器学习模型的训练，然后用这个模型对没有遇到过的文

　　档实行命名实体识别和标注。

　　指代消解是自然语言处理中和命名实体识别关联的一个重要问题。比方在对某位专家学者实行的一个访谈中，除了第一次提到其姓名、职务之外，之后提到这位专家，文本中可能使用“某博士”“某教授”“他”等代称，或者以其担任的职务相称，如“所长”等。假设访谈中还提及其他人物，并且也使用了类似的代称，那么把这些代称对应到准确的命名实体上就是指代消解。在自然语言处理中，经常遇到的一个问题是命名实体的歧义，比方重名问题。为了让计算机准确地分析自然语言书写的文本，命名实体的歧义需要被消除，也就是把具有

　　歧义的命名实体唯一地标识出来。

　　关系抽取是信息抽取的一个重要的子任务，负责从文本中识别出实体之间的语义关系。它分为3类方法：有监督的学习方法，该方法包括基于特征向量的学习方法和基于核函数的学习

　　方法；半监督的学习方法，该方法无需人工标注语料库，但是需要根据预定义好的关系类型

　　人工构造出关系实例，将这个关系实例作为种子集合，然后利用Web或者大规模语料库信息的高度冗余性，充分挖掘关系描绘模式，通过模式匹配，抽取新的实体关系实例；无监督的学习方法，该方法是一种自底向上的信息抽取策略，它假设拥有相同语义关系的实体对的上下文信息较为相似，其上下文集合代表该实体对的语义关系。较新的技术是使用向量

　　(embedding,基于词或者实体)的方式将结构化和非结构化数据中提及的实体关联起来。

　　利用向量间的相似性，实现以向量为中介的异构数据的结构化处理和关联。

　　4.2数据集成

　　数据集成是伴随企业信息化建设的持续深入而形成的。例如，因业务的需要，企事业单位内部普遍构建了多个异构的信息系统(这些信息系统能够自主选择适宜的操作系统，有独立的数据库和应用界面，完全是一个自治的系统),并积累了图片、Word、PDF、Excel、网页等大量非结构化文件。因为开发部门和开发时间的不同，这些信息系统中管理的数据源彼此独立、相互封闭，形成了“信息孤岛”,数据难以在系统之间形成快速有效的共享。数据管理与数据分析需要打破这些“信息孤岛”,实现不同“孤岛”信息系统的互联互通，进而施行精准的决策分析。例如，在电子政务领域中，很多地方的政府机关有多少个委、办、局，就有多少个信息系统，每个信息系统都由独立的信息中心实行维护。政府机关之间需要实现信息互联互通、资源共享，最终实现政务服务的协同操作，从而使社会大众真正享受到一站式办公服务(例如杭州市政府工作报告中的“最多跑一次”改革)。事实上，很多互联网应用

　　(包括机票、酒店、餐饮、租房、商品比价等服务)也是把来自不同数据源中的数据实行有

　　效集成后，对外提供统一的访问服务的。

　　数据集成把一组自治、异构数据源中的数据实行逻辑或物理上的集中，并对外提供统一的访

　　问接口，从而实现全面的数据共享。数据集成的核心任务是将互相关联的异构数据源集成到一起，使用户能够以透明的方式访问这些数据源。集成是指维护数据源整体上的数据一致性，提升信息共享利用的效率；透明的方式是指用户无需关心如何实现对异构数据源数据的访问，只关心以何种方式访问何种数据即可。数据集成涉及的数据源通常是异构的，数据源能够是各类数据库，也能够是网页中包含的结构化信息(例如表格)、非结构化信息(网页内容),还能够是文件(例如结构化CSV文件、半结构化的XML文件、非结构化的文本文件)等。数据集成中涉及的数据源具有自治性，这些数据源能够在不通知集成系统的前提下改变自身的结构和数据。

　　数据源的异构性和自治性是数据集成系统面临的两个主要挑战。针对这两个挑战，数据集成

　　通常采用如下两种解决方案。

　　(1)数据仓库

　　人们把一组自治数据源中的数据加载并存储到一个物理数据库(称为数据仓库)中，然后在数据仓库上对集成后的数据实行后续的操作和分析。图1显示了基于数据仓库的数据集成系统架构。数据仓库技术涉及的技术包括ETL、元数据管理和数据仓库本身涉及的技术。ETL定期地从各个数据源中抽取(extract)、转换(transform)、加载(load)数据到数据仓库中。元数据管理涉及对数据源的描绘、对数据仓库中数据的描绘、数据仓库中数据与数据源中数据之间的语义映射。例如，针对关系数据库类型的数据源，语义映射维护数据源中的某个属性对应于数据仓库的某个属性，并指定如何把属性分配到不同的表中。此外，语义映射还要解决不同数据源间数据描绘的不统一、语义冲突、数据的冗余等问题。

　　数据应用

　　报表

　　即席查询

　　数据挖掘

　　数据

　　数据分析

　　访问

　　数据集市

　　数据仓库

　　元数据

　　数据集成

　　数据集市

　　数据集市

　　ETL数据源

　　数据库

　　数据库

　　XML

　　HTML

　　数据源1图1基于数据仓库的数据集成系统架构

　　(2)虚拟集成系统

　　数据源2数据源3数据源4在虚拟集成系统中，数据保存有原来的数据源中，只在查询时才需要访问。图2显示了一个典型的虚拟集成系统的架构，该类集成系统使用中间模式建立全局数据的逻辑视图，中间模式向下协调各数据源系统，向上为访问集成数据的应用提供统一数据模式和数据访问的通用接口。各数据源独立性强，虚拟集成系统则主要为异构数据源提供高层次的数据访问服务。元数据维护数据源的基本信息以及中间模式到数据源之间的语义映射等。虚拟集成系统接收到用户的查询请求后，根据元数据信息实行查询的重写，把对中间模式的查询转化为对数据源的查询。类似于数据库的查询处理，虚拟集成系统也会实行查询的优化，包括访问数据源的顺序、不同数据源之间的操作访问(例如两个数据源之间数据的连接算法)等。每个数据源都连有一个封装器，负责把上层用户的查询转发到数据源，并把数据源返回的结果转发给上层的应用。虚拟集成系统的关键问题是如何构造逻辑视图，并使得不同数据源的数据模式映射到这个中间模式上。

　　数据应用

　　报表

　　即席查询

　　数据挖掘

　　数据分析

　　数据

　　访问

　　中间模式

　　元数据

　　数据集成

　　中间模式

　　中间模式

　　中间模式7中间模式

　　源数据映射

　　源数据映射

　　源数据映射

　　源数据映射

　　封装器

　　封装器

　　封装器

　　封装器

　　数据库

　　数据库

　　XMLHTML数据源

　　图2基于中间模式的数据集成系统架构

　　无论是基于数据仓库还是基于中间模式的数据集成系统，都需要完成实体与关联抽取、模式匹配(schemamatching)、实体对齐(recordlinkage或entityresolution)和实体融合(datafusion)这4个步骤。面向结构化数据的实体与关联抽取技术比较直观，面向非结构化数据的实体与关联抽取可参考第4.1节。模式匹配主要用于发现并映射两个或多个异构数据源之间的属性对应关系，在大规模数据背景下尤为重要。当前，基于朴素贝叶斯、stacking等机器学习算法的模式匹配得到了广泛的研究，并在某些特定领域得到了良好的应用。基于模式匹配，实体对齐的目标是根据匹配属性的记录特征，将数据源中指代同一实体的记录连接起来。实体对齐主要分为3个步骤：获取候选集、成对匹配、聚簇处理。广义地说，实体对齐的方法能够划分为无监督学习和有监督学习。随着人工智能技术的发展，基于决策树、Logistic回归、支持向量机(supportvectormachine,SVM)的机器学习方法以及基于词向量(wordembedding)的深度学习方法被应用于实体对齐，以提升算法的性能。使用实体对齐能够把一组数据源中同一实体的不同记录连接起来，因为数据质量问题，这些记录在描

　　数据源1数据源2数据源3数据源4述同一实体时可能存有数据冲突，例如同一个人的住址在不同数据源之间的描绘可能是不一样的。所以，在数据集成的最终环节中，实体融合旨在消除不同数据源之间同一个实体属性值的冲突，将不同的数据信息实行综合，从而提取出统一、丰富、高精度的数据。实体融合的主要方法包括基于规则的无监督学习、结合标注数据的半监督学习等。虽然基于标注数据的半监督学习在精度、召回率等方面均获得了令人满意的效果，但是其最大的挑战在于带标签训练数据的获取往往需要耗费较大的人力和物力。如何利用主动学习获取训练数据以降低

　　研究代价，是当前学术界和工业界研究的热点话题。

　　4.3数据清洗与数据质量评估

　　数据清洗是指从数据中检测并纠正可能的错误，以确保数据的质量并符合与领域相关的完整性约束。数据清洗是绝绝大部分数据驱动的任务的必要步骤。缺乏有效的数据清洗可能会使后续的数据分析产生垃圾进、垃圾出(garbagein,garbageout,GIGO)的不良后果。不过，因为数据越发显著的大规模、异质性、高噪音等特点，数据清洗也面临着极大的挑战，这也是近年来学术界和工业界的攻坚重点。一般来说，数据清洗能够分为两个基本的任务：错误检测，即发现数据中潜在的错误、重复或缺失等；数据修复，即针对发现的错误，对数据进

　　行修复。下面结合一个具体的实例分别实行介绍。

　　错误检测任务旨在发现影响数据质量的错误因素。一般将错误因素划分为4类，下面通过图

　　3的例如实行说明。

　　姓氏

　　t1名字

　　年龄/岁

　　三

　　四

　　五

　　张

　　4053540工作单位

　　中国人民大学

　　上海交通大学

　　<缺失>人大

　　所在城市

　　上海

　　上海

　　北京

　　北京

　　张

　　李

　　王

　　三

　　t2t3t4图3数据清洗中错误检测的例如

　　(1)异常值

　　异常值是指明显不符合属性语义的取值。例如，图3中t2的年龄为5岁，显然与其有工作单位这个事实是相悖的。不过，设计一种方法让计算机自动地、通用地检测出异常值是个挑

　　战性很大的问题。现有的代表性解决方案包含以下几类。

　　●基于统计的方法：首先使用一定的分布对数据实行建模，进而检测某个取值是否显著性地偏离正常值。例如，针对图3例如中年龄的例子，能够使用正态分布对数据建模，并计算均值与标准差。假设某个取值在k倍的标准差(如k=3)外，则认定其为异常值。更进一步

　　地，因为均值对异常值比较敏感，很多方法使用中位数作为均值。

　　●基于距离的方法：度量数据值之间的距离，将与绝大部分数据距离过远的值认定为异常值。

　　(2)结构性错误

　　结构性错误是指数据不符合特定领域语义要求的完整性约束。例如图3例如中t1的工作单位是中国人民大学，其所在城市应该为北京，而非上海。检测结构性错误最直接的方法是从外部输入与领域相关的约束条件，如工作单位决定了所在城市。不过，这种方法往往耗时耗力，且很难达到通用性。所以，现有的绝大部分工作聚焦于从数据中发现潜在的约束条件，如条件函数依赖、拒绝约束规则等。近些年，也有些研究者考虑借助外部通用的知识图谱及互

　　联网上公开可用的众包服务(crowdsourcing),其基本的思想是通过发现数据中与知识图谱

　　或众包标注违背的部分，归纳出结构性错误。

　　(3)记录重复

　　记录重复在真实数据中十分普遍，其原因是多方面的，比方数据可能由不同的机构提供，或者数据整合自组织的内外部渠道。例如，图3中的t1和t4实际上指代同一个人，但因为数据存有结构性错误(如t1的城市)、缩写(如t4中的“人大”实为“中国人民大学”的缩写)、属性对应错误(t4中的姓氏与名字填反了)等问题，而被计算机认为是两条不同的记录。记录重复会对数据分析造成很大的影响。人们一般采取实体识别技术解决记录重复问题。

　　其本质与上文提到的实体匹配是相同的。因为前文已经给出了详细的探讨，此处不再赘述。

　　(4)数据缺失

　　数据缺失是指数据的部分属性不存有于数据库中，例如，图3例如中的t3缺失了工作单位信息。这会在两个层面给数据分析带来负面影响：一方面，数据缺失带来信息的损失；另一方面，不同数据源在数据缺失时使用的默认值不尽相同，如“NA”"NaN”“Null”等，这会进一步误导后续的分析过程。针对数据缺失，现有的方法是采用缺失值插补(dataimputation)技术实行修复，其基本想法是使用合理的模型推断出缺失值。比较简单的办法是使用统一的全局值或其他记录在该属性的平均值实行插补，不过这些方法没有考虑具体的数据记录，在实际中难以得到良好的效果。更为有效的办法是采用最大可能性的数据值并实行推理，例如找出最相似记录的相对应取值并实行插补，或通过建立贝叶斯或决策树分类器，将缺失值插补建模成一个分类的问题。

　　数据修复任务是指根据检测出的错误对数据实行更新，以达到纠正错误的目的。与前文介绍的错误检测相比，数据修复的挑战性更大，因为通常缺乏对修复实行指导的信号。为了应对这个挑战，现有的方法往往采用外部知识或一些定量的统计指标。最近，也有人提出一些新

　　方法，即采用机器学习的手段融合多源信号，将数据修复建模成一个结合推理的问题。

　　5结束语

　　数据整理需要研究的工作还有很多。如何展开有针对性的研究工作，并系统化地集成各方面的相关研究工作，形成数据整理方面整体上的研究和应用影响力?威斯康辛大学麦迪逊分校的AnHaiDoan教授等人[4]倡议，从事相关领域的研究学者应充分利用庞大的Python开源社区PyData,投入系统化的数据准备工具研制中，将研究成果更好地应用在实际场景中。

　　这或许是一条较为可行的技术路线。

篇二：数据治理理论

　　数据治理课程体系

　　数据治理课程体系是一个完整的课程体系，旨在帮助企业和组织建立和维护高质量的数据资产。这个课程体系包括了数据治理的基础知识、数据质量管理、数据安全和隐私保护、数据架构和数据管理等方面的内容。

　　数据治理的基础知识是数据治理课程体系的核心。这部分内容包括了数据治理的定义、目标、原则、组织结构和流程等方面的内容。学习这部分内容可以帮助学员了解数据治理的基本概念和理论，为后续的学习打下坚实的基础。

　　数据质量管理是数据治理课程体系的重要组成部分。这部分内容包括了数据质量的定义、评估、监控和改进等方面的内容。学习这部分内容可以帮助学员了解如何评估和监控数据质量，并采取相应的措施来提高数据质量。

　　第三，数据安全和隐私保护是数据治理课程体系的另一个重要组成部分。这部分内容包括了数据安全和隐私保护的基本概念、法律法规、安全措施和隐私保护措施等方面的内容。学习这部分内容可以帮助学员了解如何保护数据的安全和隐私，避免数据泄露和滥用。

　　数据架构和数据管理是数据治理课程体系的另外两个重要组成部分。这部分内容包括了数据架构的设计和管理、数据管理的流程和工具等方面的内容。学习这部分内容可以帮助学员了解如何设计和管理

　　数据架构，以及如何使用数据管理工具来提高数据管理效率。

　　数据治理课程体系是一个非常完整和系统的课程体系，可以帮助企业和组织建立和维护高质量的数据资产。学习这个课程体系可以帮助学员了解数据治理的基本概念和理论，以及如何评估和监控数据质量、保护数据安全和隐私、设计和管理数据架构等方面的知识和技能。

篇三：数据治理理论

　　数据治理的理解

　　数据治理的理解

　　企业高层必须制定一个基于价值的数据治理计划，确保董事会和股东可以方便、安全、快速、可靠地利用数据进行决策支持和业务运行。

　　数据治理对于确保数据的准确、适度分享和保护是至关重要的。有效的数据治理计划会通过改进决策、缩减成本、降低风险和提高安全合规等方式，将价值回馈于业务，并最终体现为增加收入和利润。

　　国际上此方面的研究协会比较多，但截止2014年底中国只有ITSSWG1国际化小组展开了正式研究，并向ISO正式提交和发布了数据治理的研究白皮书。

　　目录

　　1.1什么是数据治理

　　2.2什么是应对型数据治理

　　3.3什么是主动型数据治理

　　4.4应对型数据治理的缺点及其改进方案

　　1.5主动数据治理优势、应当避免的问题

　　2.6主动数据治理最适合哪些领域

　　3.7何时开始主动数据治理

　　1.8数据治理成功的关键——元数据管理

　　2.?数据治理中元数据的作用及其管理

　　3.?什么是元数据？

　　4.?数据治理中元数据管理的重要性

　　1.?数据治理中元数据管理的业务驱动因素

　　2.?特别考虑事项：大数据与数据治理

　　3.?用于全局数据治理的Informatica产品

　　数据治理什么是数据治理

　　信息系统建设发展到一定阶段,数据资源将成为战略资产,而有效的数据治理才是数[1]据资产形成的必要条件。

　　虽然以规范的方式来管理数据资产的理念已经被广泛接受和认可，但是光有理念是不够的，还需要组织架构、原则、过程和规则，以确保数据管理的各项职能得到正确的履行。

　　以企业财务管理为例，会计负责管理企业的金融资产，遵守相关制度和规定，同时接受审计员的监督；审计员负责监管金融资产的管理活动。数据治理扮演的角色与审计员类似，其作用就是确保企业的数据资产得到正确有效的管理。

　　由于切入视角和侧重点不同，业界给出的数据治理定义已经不下几十种，到目前为止还未形成一个统一标准的定义。

　　ITSSWG1认为数据治理包含以下几方面内容

　　（1）确保信息利益相关者的需要评估，以达成一致的企业目标，这些企业目标需要通过对信息资源的获取和管理实现；

　　（2）确保有效助力业务的决策机制和方向；

　　（3）确保绩效和合规进行监督。

　　数据治理是指从使用零散数据变为使用统一主数据、从具有很少或没有组织和流程治理到企业范围内的综合数据治理、从尝试处理主数据混乱状况到主数据井井有条的一个过程。

　　数据治理的全过程

　　数据治理其实是一种体系，是一个关注于信息系统执行层面的体系，这一体系的目的是整合IT与业务部门的知识和意见，通过一个类似于监督委员会或项目小组的虚拟组织对企业的信息化建设进行全方位的监管，这一组织的基础是企业高层的授权和业务部门与IT部门的建设性合作。从范围来讲，数据治理涵盖了从前端事务处理系统、后端业务数据库到终端的数据分析，从源头到终端再回到源头形成一个闭环负反馈系统（控制理论中趋稳的系统）。从目的来讲，数据治理就是要对数据的获取、处理、使用进行监管（监管就是我们在执行层面对信息系统的负反馈），而监管的职能主要通过以下五个方面的执行力来保证——发现、监督、控制、沟通、整合

　　什么是应对型数据治理

　　应对型数据治理是指通过客户关系管理(CRM)等“前台”应用程

　　序和诸如企业资源规划(ERP)等“后台”应用程序授权主数据，例如客户、产品、供应商、员工等。然后，数据移动工具将最新的或更新的主数据移动到多领域MDM系统中。它整理、匹配和合并数据，以创建或更新“黄金记录”，然后同步回原始系统、其它企业应用程序以及数据仓库或商业智能/分析系统。

　　数据治理什么是主动型数据治理

　　我们如何朝着更主动的架构和数据治理模式前进？第一个要求是我们开始在多领域MDM系统中直接授权数据，分离传统CRM和ERP系统中的数据录入。当录入系统和记录系统为同一个系统时，应用程序架构很简单。CRM和ERP系统变成主数据的消费者—它们不再创建它。

　　但是，为了实现此有价值的简化，需要灵活、用户友好的界面。它有助于创建针对不同业务用户（从临时用户到专家）组的用户界面版本，同时仍然具有完整的数据管理控制台，数据管理员通过该控制台可处理需要人为判断的问题，并跟踪数据质量度量标准和解决异常。

　　多领域MDM系统本身的角色发生变化，从在别处输入或更新的数据的被动接收者和整理者变为原始录入系统和记录系统。新记录或修改后的记录通过内部数据治理规则后，MDM系统通过实时或接近实时的中间件将经过认证的记录发布到CRM和ERP系统以及所有数据仓库或分析系统。如果不需要实时或接近实时的反馈，新记录和更改后的记录可排队等候，以便通过批量集成与企业的其它系统同步。

　　这一变化还消除了主要的复杂性原因。MDM系统成为了源系统，企业中的其它应用程序和数据库成为消费系统，而不是让处于复杂源系统网络的中心的MDM系统位于左侧，而消费系统位于右侧。因此，省去了接近一半的系统集成工作量，并且还省去了映射源系统和其独立且特殊方法（允许数据录入返回到MDM系统）的工作。

　　这看上去是一个激进的步骤，但是它实际上是长期趋势的延续。当企业应用程序套件最初变得通用时，公司假设它们的新CRM或ERP系统是唯一的真相来源。但是，随着时间的推移，公司沦为扩散系统

　　和数据库的牺牲品。因此，没有一个前台或后台系统拥有完整的主数据集。

　　如果您将要添加一个多领域MDM系统并承认CRM和ERP系统并不是设计用于管理主数据，为何不进行下一步骤并取消它们的创建、更新或删除主数据的功能，而是允许这些系统只能读取和处理主数据呢？

　　数据治理应对型数据治理的缺点及其改进方案

　　批量集成和应对型数据治理方法引入的时间延迟可能导致业务部门继续操作重复、不完整且不精确的主数据。因此，这会降低多领域MDM方案实现在正确的时间向正确的人员提供正确数据这一预期业务目标的能力。在期望被设定为数据将变得干净、精确且及时之后，批量集成引入的时间延迟让人感到沮丧。应对型数据治理（下游数据管理员小组负责整理、去重复、纠正和完成关键主数据）可能导致让人认为“数据治理官僚化”。

　　应对型数据治理还会导致最终用户将数据管理团队看做“数据质量警察”，并产生相应的官僚化和延迟以及主数据仍然不干净的负面认识。这还将使得MDM方案更难实现它的所有预期优势，并可能导致更高的数据管理总成本。此方法的风险是组织可能以“两个领域中的最差”而告终，至少部分上如此–已在MDM方案中投资，但是只能实现一些潜在优势，即在整个企业内获得干净、精确、及时以及一致的主数据。

　　有三个方法可超越应对型数据治理。

　　1.用户将数据直接输入到多领域MDM系统中：用户使用界面友好的前端将数据直接输入到多领域MDM系统中，但是他们的新记录和现有记录的更新留在暂存区域或保留区域，直到数据管理员审核和认证为止。这之后MDM系统才接受插入或更新，以便进行完整的整理、匹配、合并，并将“最佳记录”发布到企业的所有其他应用程序。此方法好过将一个完全不同的应用程序（例如CRM或ERP系统）作为

　　“录入系统”，但是它仍然会出现延迟和效率低下。尽管存在这

　　些缺点，使用暂存区域确实解决了大部分问题，例如不用强制执行重要属性的录入或在创建前不必进行彻底搜索。此外，由于我们并不受传统应用程序或现代CRM或ERP应用程序如何处理数据录入功能的影响，通过不对应对方法进行批量数据移动，我们还大大缩短了时间安排。

　　2.用户输入直接传送到多领域MDM系统中的数据：在外面输入新记录或更新，但是

　　会立即传送到MDM系统，以便自动整理、匹配和合并。异常或例外传送到数据管理员的队列，几个管理员便可支持更多最终用户。这是第一个主动方法的改进，因为我们利用MDM系统的业务规则、数据整理和匹配功能，只要求管理员查看作为整理、匹配和合并流程的例外而弹出的插入或更新。

　　3.用户使用特定于数据治理的前端输入数据：第三个方法是允许最终用户直接录入到多领域MDM系统中，但是应使用专为主动数据治理方法而设计的前端。可专门为最终用户数据录入设定屏幕，您可利用功能齐全的MDM系统允许的自动化、数据整理、业务规则、搜索和匹配等所有功能。因此，不必首先将数据输入到MDM系统的暂存区域中，并且您不需要系统外的单独工作流应用程序。

　　数据治理主动数据治理优势、应当避免的问题

　　主动数据治理的优势

　　主动数据治理的第一个优势是可在源头获得主数据。具有严格的“搜索后再创建”功能和强大的业务规则，确保关键字段填充经过批准的值列表或依据第三方数据验证过，新记录的初始质量级别将非常高。

　　主数据管理工作通常着重于数据质量的“使它干净”或“保持它干净”方面。

　　如果MDM系统中的数据质量初始级别非常高，并且如果您不会通过从CRM或ERP源系统中传入不精确、不完整或不一致的数据来连续污染系统，则主数据管理的“保持它干净”方面非常容易。

　　主动数据治理还可有效消除新主记录的初始录入和其认证以及通

　　过中间件发布到企业其余领域之间的所有时间延迟。由用户友好的前端支持的主动数据治理可将数据直接录入到多领域MDM系统中，可应用所有典型的业务规则，以整理、匹配和合并数据。当初始数据录入经过整理、匹配和合并流程后，此方法还允许数据管理员通过企业总线将更新发布到组织的其它领域。

　　主动数据治理方法消除了“数据治理官僚化”这一认识，因为主数据的授权已推给上游的业务用户，使数据管理员处于很少被打扰的角色，他们将不会成为诸如订单管理或出具发票等关键业务流程的瓶颈。

　　销售和营销均受益，因为可更迅速且经济有效地完成营销活动，在启动活动之前无需前期数据纠正。财务上也受益，因为将一次性捕获新客户需要的所有数据元素，添加新客户的流程包括提取第三方内容并计算信贷限额，然后将该信息传回ERP系统。

　　没有直接访问MDM系统权限的客户服务代表通常必须搜索几个系统，找到他们需要的信息，从而采取措施。当通话中的客户没有耐心时，很难提供高级别的服务。当所有信息存储在MDM系统中并可通过有效、用户友好的前端进行访问时，客户服务代表将能够访问每个客户交互需要的所有数据，并能够在需要时授权新数据。

　　通过使MDM成为录入系统及记录系统，您能从本质上将数据维持在“零延迟”状态，它在这种状态下适合企业中的任何预期使用场景，同步到CRM和ERP系统的数据的清洁性、精确性、时效性以及一致性应当处于最高级别。

　　主动数据治理避免出现的问题

　　已发展到主动数据治理的组织报告了关于关系管理、历史记录、工作流程以及安全性的一些常见教训。

　　关系管理

　　MDM应当成为不仅是主数据而且是主数据间的关系的记录系统。它成为全方位了解不同系统的数据如何互相关联的中心位置。例如，多领域MDM系统将来自订单管理系统的销售订单和应收帐款中的发票关联在一起。这些关系或层次结构显示在与MDM系统数据直接交

　　互的用户界面中。用户界面还可用于查看主数据间的关系并在MDM系统中直接编辑它们。因此，MDM还成为关系的录入系统。

　　历史记录

　　当您从诸如CRM系统等外部系统中接受新记录或更新后的记录时，可能会限制您跟踪该记录的历史记录，因为外部应用程序作出了一些限制。当MDM为录入系统和记录系统时，审计历史记录的复杂跟踪和数据的沿袭成为可能。随着时间的推移，它甚至可显示核心主记录的更改，按照各种用户和流程在动态时间视图中显示插入和更新，可跟踪和显示每个属性中的每个更改。工作流使用可配置的前端可设计和执行基本工作流功能，因此最终用户可输入新主记录。但是，这些新记录可能需要数据管理员的批准步骤，然后才能将它们完全接受到多领域MDM系统中并发布到企业的其它领域。另外一个工作流应用程序在数据管理员的任务队列中。匹配或自动合并重复记录遇到的例外传送到相应的数据管理员。高级功能允许将问题提交给相应的人员，当用户在休假时可自动重新传送给后备人员。通过直接查看特定工作流步骤和这些流程的经过时间，减少了花费在查询新记录或更改后的记录状态的时间。

　　安全性

　　用户界面应当是可配置的，并且不同的工作角色具有不同的访问和许可级别。帮助数据管理员解决差异的一些数据元素可能不适合企业中的每个人查看。此外，即使在一个工作角色内，例如数据管理员，您可能需要不同的安全性级别，同时更高级别的人员能够对更广泛的记录集执行更多操作。而且，您可能需要分离访问权限，例如德国的数据管理员不能查看法国客户记录。

　　使用MDM外部的CRM或ERP系统作为录入系统时，该应用程序的安全模型可能会在谁有权对哪些记录进行哪些操作方面强加一些限制。将主记录的录入和维护直接移到多领域MDM系统之后，您可更加详细地控制数据的安全性，可具体到每个属性或字段级别。

　　数据治理主动数据治理最适合哪些领域

　　什么因素阻止公司采用主动数据治理方法？总的来说，问题在于

　　它们在数据治理成熟度等级中处于什么位置。一家公司很难从成熟度模型的最左侧—它们在其中没有中央多领域MDM系统并且没有数据治理组织或流程—直接跳到该等级的最右侧，它们在其中拥有强大的数据治理流程外加最新MDM系统和集成架构。通常，随着时间的推移，组织会改

　　进它们的数据治理方法。例如，当初始MDM系统开启并运行之后，一些预期的优势需要较长时间才能实现，或应对方法的局限性变得显而易见，您可计划以便在原始源系统中取消授权记录的功能，并将该功能直接迁移到MDM系统中。

　　升级公司的集成或中间件功能（例如，添加一个能处理实时更新的集成工具）之后，可切换到主动数据治理方法，或作为现有CRM或ERP系统重大升级的一部分，因为这可能是引进需要的业务流程变更的最佳时机。

　　·何时从“应对型”迁移为“主动型”

　　度量标准将推动业务案例从应对型数据治理迁移到主动数据治理。

　　问您自己以下问题，并尝试量化时间、精力和费用投资方面的答案：

　　·吸纳一个新客户需要多长时间？

　　·涉及多少个不同步骤？

　　·在普通新记录被接受到多领域MDM系统之前会接触它多少次？

　　·由于这些源系统的局限性，仍在源系统中创建多少个重复记录（然后在MDM系统中

　　·合并）？

　　·需要多少个数据管理员支持该企业？

　　·主记录是否进入了“更改，改回”循环，因为两个不同的用户组试图强制执行两个不·同的业务规则集？

　　·主记录的重要方面是否因源系统和MDM系统之间的“裂缝而失败”？

　　·维护各个源系统和MDM系统之间的集成的流程是否成为一种负担？

　　·在CRM系统中输入新记录后，必须等待才能在ERP系统中变得可用，用户是否有所

　　·抱怨？

　　·是否存在数据治理的资金问题，因为它被看做是管理费用或一种官僚作风？

　　回答这些问题之后，应当明显看出您是否将能够迁移到更主动的数据治理方法。您可详细计划迁移流程，将它设立为一个独立的项目或将它集成到另一个相关项目中。

　　数据治理何时开始主动数据治理

　　一些情况要求立即开始主动数据治理，例如当您获得多个CRM系统和ERP系统，它们要求与多领域MDM系统集成，以便让它们继续充当录入系统，或当您的当前源系统非常脆弱或很难维护或修改。

　　在这些情况下，要忍受困难并从一开始便为主动数据治理作出计划。一些组织拥有成千上万个直接在MDM系统中授权主数据的最终用户，并且有一个数据管理员团队支持他们、发现异常、解决低质量匹配、在需要时手动合并重复记录等等。另一种应用情况是当您发现自己最终会选择主动数据治理方法—何必再为建立源系统到多领域MDM系统的双向集成而争论？您或许不妨直接授权最终用户来编写主数据。

　　数据治理数据治理成功的关键——元数据管理

　　独立企业数据集成软件提供商Informatica公司（纳斯达克代码：INFA）认为：数据治理成功的关键在于元数据管理，即赋予数据上下文和含义的参考框架。经过有效治理的元数据可提供数据流视图、影响分析的执行能力、通用业务词汇表以及其术语和定义的可问责性，最终提供用于满足合规性的审计跟踪。元数据管理成为一项重要功能，让IT部门得以监视复杂数据集成环境中的变化，同时交付可信、安全的数据。因此，良好的元数据管理工具在全局数据治理中起到了核心作用。

　　数据治理数据治理中元数据的作用及其管理

　　Informatica将数据治理定义为“在组织范围内，对流程、政策、标准、技术和人员进行职能协调和定义来将数据作为公司资产管理，从而实现对准确、一致、安全且及时的数据的可用性管理和可控增长，以此制定更好的业务决策，降低风险并改善业务流程”。

　　数据治理着重于交付可信、安全的信息，为制定明智的业务决策、有效的业务流程并优化利益相关方交互提供支持。因此，数据治理本身并非是结果，而仅仅是方法：即通过数据治理来支持最关键的业务目标。

　　数据治理什么是元数据？

　　元数据为数据提供了一个参考框架。ForresterResearch将元数据定义为“用于描述数据、内容、业务流程、服务、业务规则以及组织信息系统的支持政策或为其提供上下文的信息”。譬如，苹果公司旗下的AppStore在网上销售软件应用程序。在此情况下的数据是应用程序。元数据则是关于这些应用程序的信息，包括应用程序描述、价格、用户评级、评论和开发公司。

　　数据治理数据治理中元数据管理的重要性

　　正如某家大型银行的高管所言：“如果没有数据治理，任何元数据管理方案注定会失败。”元数据管理可作为一项重要功能，让IT部门得以管理复杂数据集成环境中的变化，同时交付可信、安全的数据。当业务利益相关方参与这一进程并接受对数据参考框架的责任，其优势将变得更有说服力。此时，企业就能将业务元数据与基层的技术元数据进行关联，为全公司范围内的协作提供词汇表和背景资料。

　　例如，当业务用户要求其在IT部门的搭档在报告或分析中显示“净收入”，就无需再提问“哪种净收入——财务、销售还是市场营销？”除提供其他优势外，良好的元数据管理还可通过免除此类重要问题，促进数据治理：

　　·这个业务术语的含义是什么？

　　·在（几个相似的）业务术语中应当使用哪一个？

　　·该术语的来源是什么？

　　·该数据从数据源转移到目标时是如何进行转换的？

　　·由谁负责该术语的定义、记录和管理？

　　·谁修改过该术语？如何及何时进行修改？

　　·哪些政策和规则适用于该术语？（示例包括数据质量规则、安全屏蔽规则、存档规则和数据保留政策）

　　·修改环境中的某一特定数据对象会对其他数据对象产生哪些影响？

　　·在不对可能使用相同数据对象的其他报告和分析造成影响的前提下，需要多长时间来实施环境变更？

　　数据治理数据治理中元数据管理的业务驱动因素

　　一系列公司方案推动了数据治理的进展，也由此带动了元数据管理。这些方案包括：·通用业务词汇表（简单的数据管理）。这种“小规模试水”方法着重于某一特定问题或业务部门的通用业务词汇表。

　　·全面数据治理（或数据管理策略）。这是一种更近似由上至下的方式，通常用于涉及企业内一系列业务部门的较大规模计划，并以按多个阶段（如果不是更长时间）进行管理的计划中的多个商机为目标。

　　·合规。此类方案的推动因素是为遵守国际、国家、当地或行业法规的需求。合规——通常由一个治理、风险与合规性（GRC）职能部门进行管理，显然与数据治理唇齿相依。在发现、分析和记录企业的多项内部数据治理要求的同时，还必须与适用外部法规的相关特定要求进行统筹协调。其中部分示例包括：

　　·银行业：BaselII、BaselIII、多德弗兰克法案（DoddFrank）、洗钱法案

　　·保险业：偿付能力监管标准II（SolvencyII）

　　·医疗保健：HITECHAct、HIPAA·一般金融服务：萨班斯—奥克斯利法案

　　·元数据管理。这是更上一层楼的做法，将元数据管理和数据治理作为“最佳实践”与各个新的业务方案挂钩。该方案对业务案例和项目范围进行定义。在多家未能成功实施较大型数据治理方案的公司中，这一方法则取得了成功。

　　数据治理特别考虑事项：大数据与数据治理

　　几乎所有企业都面临着管理数据量、速度和种类的挑战。Hadoop/MapReduce技术在复杂数据分析能力以及按相对低廉的成

　　本实现最大数据扩展性方面提供了一些有趣的优势。Hadoop在不久的将来取代关系性DBMS的可能性不大，这两项技术更有可能并存，因为它们各有独到之处。虽然用于管理和分析数据的技术可能不同，元数据管理和数据治理的目标应始终保持不变：为支持良好的业务决策提供可信、及时且相关的信息。不存在所谓的“大数据治理”或“大数据元数据管理”——相反，这是一个将全局企业数据治理和元数据管理活动

　　加以扩展来包容全新数据类型和数据源的问题。

　　Hadoop带来的挑战之一就是元数据管理。如果没有良好的元数据管理和数据治理，Hadoop将会缺乏透明度、可审计性以及数据的标准化与重复利用能力。企业仍将需要对数据相关关键信息的可见性，例如其来源、质量和所有权，否则就必须承受Hadoop变成环境内的又一个数据孤岛的风险。在该领域涌现的HCatalog和Hive/HiveQL等新技术将使得从非结构化和半结构化数据中收集元数据变得更加简易，从而实现Hadoop上的数据沿袭。这些功能对于将Hadoop集成入总体数据集成框架，以防止大数据在企业中遭到孤立隔绝，可如同任何其他数据源一样进行治理至关重要。

　　数据治理用于全局数据治理的Informatica产品

　　Informatica可提供功能齐全而又稳健可靠的工具，具备交付可信、安全的数据和启动成功的元数据管理方案所需的全部精确功能。MetadataManager&BusinessGlossary可提供独一无二的多项优势，让IT经理能够尽量降低在实施变更时对关键业务数据造成损害的业务风险。

　　InformaticaMetadataManager&BusinessGlossary是InformaticaPowerCenterStandardEdition的关键组件之一。它可提供为数据治理方案奠定基础所需的核心元数据管理工具。MetadataManager&BusinessGlossary是一项单个产品，配备一个共享的元数据信息库。它具备两个用户界面，供两类截然不同的用户使用：

　　·MetadataManager可让IT人员处理技术元数据。

　　·BusinessGlossary可让业务和IT管理员协同管理业务元数据。

　　ITSSWG1发布的白皮书表明

　　数据治理模型包括三个框架:范围，促成因素和执行及评估。他们每个方面都包含许多组件来进行展示和描述它们是如何工作的。该框架显示数据治理内部的逻辑关系。范围展示了我们应该关注什么，促成因素展示了数据治理的推动因素，执行和评估展示了如何实现治理的方法。该DG模型可以通过三个框架帮助我们理解数据治理。

　　数据治理的范围包括四个层次的内容。首先，应该[2]有一个治理要素负责管理其它管理要素，保证治理与管理的一致性。其次，下面的三个层次分别列示了需要治理的数据管理要素，其中价值创造层列示了通过数据治理所创造的价值服务。价值保证层描述了一个组织治理数据时重要保证服务。基础数据服务层描述了一个数据治理的基础数据服务。

篇四：数据治理理论

　　很多组织已经认识到，他们的数据是一种至关重要的企业资产。数据和信息能使他们洞察顾客、产品和服务，帮助他们创新并实现其战略目标。尽管如此却很少有组织能将他们的数据作为一项资产进行积极管理，并从中获得持续价值(Evans和阳ce，2012)0从数据中获取的价值不可能凭空产生或依赖于偶然，需要有目标、规划、协作和保障，也需要管理和领导力。数据管理(DataManagement)是为了交付、控制、保护并提升数据和信息资产的价值，在其整个生命周期中制订计划、制度规程和实践活动并执行和监督的过程。数据管理专业人员(DataManagementProfessional)是指从事数据管理各方面的工作(从数据全生命周期的技术管理工作，到确保数据的合理利用及发挥作用)，并通过其工作来实现组织战略目标的任何人员。数据管理专业人员在组织中担当着诸多角色，从高级技术人员(如数据库管理员、网络管理员、程序员)到战略业务人员(如数据管理专员、数据策略师、首席数据官等)。数据管理活动的范围广泛，包括从对如何利用数据的战略价值做出一致性决定，到数据库的技术部署和性能提升等所有方面。因此，数据管理需要技术的和非技术的双重技能。管理数据的责任必须由业务人员和信息技术人员两类角色共同承担，这两个领域的人员需要相互协作，确保组织拥有满足战略需求的高质量数据O数据和信息不仅是企业为获取未来价值而投资的资产，它们对大多数组织的日常运营也至关重要，因而被称为信息经济的"货币""生命之血"甚至"新的石油"8。一个组织可能没有从数据分析中获得价值，但是绝对无法在没有数据的情况下开展业务。随着专业领域的发展和成熟

　　为支持数据管理专业人员开展工作，DAMA国际数据管理协会出版了本书，即{DAMA数据管理知识体系指南~(第2版)。本书是在2009年{DAMA数据管理知识体系指南~(第1版)提供的基础知识的基础上经过逐步补充和完善最终编篡而成的。本章介绍了一组数据管理原则，讨论了遵循这些原则过程中所遇到的挑战，并提出了应对这些挑战的方法。本章也描述了DAMA数据管理框架，为数据管理专业人员在各种数据管理知识领域内开展的工作提供关联语境。

　　第3章数据治理

　　3.1引言

　　数据治理(DataGovernance,DC)的定义是在管理数据资产过程中行使权力和管控，包括计划、监控和实施。在所有组织中无论是否有正式的数据治理职能，都需要对数据进行决策。建立了正式的数据治理规程及有意向性地行使权力和管控的组织能够更好地增加从数据资产中获得的收益。

　　数据治理职能是指导所有其他数据管理领域的活动。数据治理的目的是确保根据数据管理制度和最佳实践正确地管理数据。而数据管理的整体驱动力是确保组织可以从其数据中获得价值，数据治理聚焦于如何制定有关数据的决策，以及人员和流程在数据方面的行为方式。数据治理项目的范围和焦点依赖于组织需求，但多数项目都包含如下内容:1)战略(Strategy)。定义、交流和驱动数据战略和数据治理战略的执行。

　　2)制度(Policy)。设置与数据、元数据管理、访问、使用、安全和质量有关的制度。

　　3)标准和质量(StandardsandQuality)。设置和强化数据质量、数据架构标准。

　　4）监督(Oversight)。在质量、制度和数据管理的关键领域提供观察、审计和纠正等措施(通常称为管理职责Stewardship)。

　　5)合规(Compliance)。确保组织可以达到数据相关的监管合规性

　　要求。

　　6）问题管理(IssueManagement)。识别、定义、升级和处理问题，针对如下领域:数据安全、数据访问数据质量、合规、数据所有权、制度、标准、术语或者数据治理程序等。

　　1)数据管理项目(DataManagementProjects)a增强提升数据管理实践的努力。

　　2)数据资产估值(DataAssetValuation)a设置标准和流程，以一致的方式定义数据资产的业务价值。

　　为了实现这些目标，数据治理时将制定制度和实施细则，在组织内多个层次上实践数据管理，并参与组织变革管理工作积极向组织传达改进数据治理的好处以及成功地将数据作为资产管理所必需的行为。

　　对于多数企业，采用正式的数据治理需要进行组织变革管理(参见第17章)，以及得到来自最高层管理者(C级别)的支持，如CRO、CF0或者CDO。

　　产生和分享数据、信息的能力改变了个人及经济的互动。在充满活力的市场环境中，随着将数据作为差异化竞争优势的意识提升促使组织调整数据管理职责。上述改变已经很明显地出现在金融、电子商务、政府和零售领域。各个组织都在努力成为数据驱动型组织，主动将数据需求作为战略发展、项目规划和技术实施的一部分。然而，这样做通常会带来企业文化上的挑战。此外，鉴于企业文化可以影响任

　　何战略目标，进行数据治理时需要努力将文化变革部分纳入考虑，以期获得强有力的领导支持。

　　要从作为企业资产的数据中受益，组织必须学会衡量数据和数据管理活动的价值。即使拥有最佳的数据战略，数据治理和数据管理计划也可能不会成功，除非企业愿意接受并进行管理变革。对很多组织而言，文化变革是一项主要的挑战。变革管理的基础信条是，组织变革需要个人的改变(Hiatt和Creasey，2012)。当数据治理和数据管理要求显著的行为变化时，为了成功，一定需要正式的变革管理。数据治理和管理职责语境关系图如图3-1所示。

　　数据治理最常见的驱动因素是法规遵从性特别是重点监控行业。例如金融服务和医疗健康，需要引人法律所要求的治理程序。高级分析师、数据科学家的迅猛发展也成为新增的驱动力。

　　尽管监管或者分析师可以驱动数据治理，但很多组织的数据治理是通过其他业务信息化管理需求所驱动的，如主数据(MDM)管理等。一个典型场景:一家公司需要更优质的客户数据，它选择开发客户主数据平台然后接下来意识到成功的主数据管理是需要数据治理的。

　　3.1.1业务驱动因素

　　数据治理并不是到此为止，而是需要直接与企业战略保持一致。数据治理越显著地帮助解决组织问题，人们越有可能改变行为、接受数据治理实践。数据治理的驱动因素大多聚焦于减少风险或者改进流程。

　　(1)减少风险

　　1)一般性风险管理。洞察风险数据对财务或商誉造成的影响，包括对法律(电子举证E-Discovery)和监管问题的响应。

　　2)数据安全。通过控制活动保护数据资产包括可获得性、可用性、完整性、连续性、可审计和数据安全。

　　3)隐私。通过制度和合规性监控控制私人信息、机密信息、个人身份信息(PII）等。

　　(2)改进流程

　　1)法规遵从性。有效和持续地响应监管要求的能力。

　　2)数据质量提升。通过真实可信的数据提升业务绩效的能力。

　　3)元数据管理。建立业务术语表，用于定义和定位组织中的数据;确保组织中数量繁多的元数据被管理和应用。

　　4)项目开发效率。在系统生命周期(SDLC)中改进，以解决整个组织的数据管理问题，包括利用数据全周期治理来管理特定数据的技术债。

　　5)供应商管理。控制数据处理的合同，包括云存储、外部数据采购、数据产品销售和外包数据运维。

　　在整个组织内澄清数据治理的业务驱动因素是基础性工作将它与企业整体业务战略保持一致。经常聚焦"数据治理"往往会疏远那些认为治理产生额外开销却没有明显好处的领导层。对组织文化保持敏感性也是必要的需要使用正确的语言、运营模式和项目角色。在DAMA-DMBOK2编写过程中，术语"组织"被诸如"运营模式"或"运营框架"之类所取代。

　　人们有时表示难以理解数据治理是什么治理本身是一个通用概念。与其发明新的概念，数据管理专家可以将其他治理的概念和原则应用于数据治理。通常将审计、会计与数据治理放在一起比较，审计员和财务主管设置管理财务资产的规则，数据治理专家制定管理数据资产的规则，然后其他领域执行这些规则。

　　数据治理不是一次性的行为。治理数据是一个持续性的项目集以保证组织一直聚焦于能够从数据获得价值和降低有关数据的风险。可以由一个虚拟组织或者有特定职责的实体组织承担数据治理的责任。只有理解了数据治理的规则和活动才能达到高效执行，为此需要建立可运转良好的运营框架。数据治理程序中应该考虑到组织和文化的独特性问题以及数据管理在组织内面对的具体挑战和机遇(参见第1和第16章)。

　　数据治理要与IT治理区分开。IT治理制定关于IT投资、IT应用组合和IT项目组合的决策，从另一个角度还包括硬件、软件和总体技术架构。IT治理的作用是确保IT战略、技资与企业目标、战略的一致性。

　　COBIT(ControlObjectivesforInformationandRelatedTechnology)框架提供IT治理标准，但是其中仅有很少部分涉及数据和信息管理。其他一些重要法规，如萨班斯法案(SarbanesOxley)则覆盖企业治理、IT治理和数据治理多个领域。相反，数据治理仅聚焦于管理数据资产和作为资产的数据。

　　3.1.2目标租原则

　　数据治理的目标是使组织能够将数据!作为资产进行管理。数据治理提供治理原则、制度、流程、整体框架、管理指标，监督数据资产管理，并指导数据管理过程中各层级的活动。为达到整体目标，数据治理程序必须包括以下几个方面。

　　(1)可持续发展(Sustainable)治理程序必须富有吸引力。它不是以一个项目作为终点，而是一个持续的过程。需要把它作为整个组织的责任。数据治理必须改变数据的应用和管理方式，但也不代表着组织要作巨大的更新和颠覆。数据治理是超越一次性数据治理组件实施可持续发展路径的管理变革。可持续的数据治理依靠于业务领导、发起者和所有者的支持。

　　(2)嵌入式(Embedded)数据治理不是一个附加管理流程。数据治理活动需要融合软件开发方法、数据分析应用、主数据管理和风险管理。

　　(3)可度量(Measured)数据治理做得好有积极的财务影响，但要证明这一影响，就需要了解起始过程并计划可度量的改进方案。

　　实施数据治理规划需要有变革的承诺。早在2000年下列可以帮助建立起强大数据治理基础的原则就被定义出来。

　　(1)领导力和战略(LeadershipandStrategy)成功的数据治理始于远见卓识和坚定的领导。数据战略指导数据管理活动，同时由企业业务战略所驱动。

　　(2)业务驱动(Business-driven)数据治理是一项业务管理计划，因此必须管理与数据相关的IT决策，就像管理与数据有关的业务活动一样。

　　(3)共担责任(SharedResponsibility)在所有数据管理的知识领域中业务数据管理专员和数据管理专业人员共担责任。

　　(4)多层面(Multi-layered)数据治理活动发生在企业层面和各地基层，但通常发生在中间各层面。

　　(5)基于框架(Framework-based)由于治理活动需进行跨组织职能的协调因此对数据治理项目必须建立一个运营框架来定义各自职责和工作内容。

　　(6)原则导向(Principle-based)指导原则是数据治理活动、特别是数据治理策略的基础。通常情况下组织制定制度时没有正式的原则，他们只是在试图解决特定的问题。有时原则可以从具体策略通过逆向工程反推得到。然而最好把核心原则的阐述和最佳实践作为策略的一部分工作。参考这些原则可以

　　减少潜在的阻力。随着时间的推移，在组织中会出现更多的指导原则与相关的数据治理纽件共同对内部发布。

　　3.1.3基本概念

　　正如财务审计人员实际上并不执行财务管理一样，数据治理确保数据被恰当地管理而不是直接管理数据(参见第15章)。数据治理相当于将监督和执行的职责分离。数据治理和数据管理的关系如图3-2所示。

　　1.以数据为中心的组织

　　以数据为中心的组织将数据作为资产估值，在生命周期所有阶段进行管理，包括项目开发和持续运营阶段。为达到以数据为中心组织必须改变将战略转化为行动的方式。数据不再被作为是流程和业务产品的附属。业务处理的目标就是为了得到高质量的数据。有效数据管理成为企业致力于通过分析获得洞察、制定决策时的高优先级事项。

　　人们常常混淆数据和信息技术。企业为达到以数据为中心需要进行不同以往的思考方式，要理解管理数据不同于管理IT。转型并非易事现有文化及内部制度、关于拥有权的争议、预算、历史遗留系统，都将成为建立企业级数据治理和数据管理的最大障碍。

　　虽然每个组织都需要有自己的原则但是那些寻求从其数据中获得更多价值的组织可能会分享以下内容:1)数据应该作为企业资产管理起来。

　　2)应该在整个组织内鼓励数据管理的最佳实践。

　　3)企业数据战略必须与业务战略一致。

　　4)应不断改进数据管理流程。

　　2.数据治理组织

　　治理项目的核心词是治理。数据治理可以从政治治理的角度来理解。它包括立法职能(定义策略、标准和企业架构)、司法职能(问题管理和升级)和执行职能(保护和服务、管理责任)。为更好地管理风险，多数组织采用了典型的数据治理形式，以便能够昕取所有利益相关方的意见。

　　每个组织都应该采用一个支持其业务战略，并可能在其自身文化背景下取得成功的治理模型。组织也应该准备好发展这种模式以迎接新的挑战。模型在组织结构、形式级别和决策方法方面有所不同。有些模型是集中组织的而另一些则是分布式的。

　　数据治理组织还可以具有多个层次，以解决企业内不同级别的问题——本地、部门和企业范围。治理工作通常分为多个委员会，每个委员会的目的和监督水平与其他委员会不同。

　　图3-3展示了一个通用的数据治理组织模型。在组织内部(垂直轴)的不同级别上进行活动，并在组织功能内以及技术(IT)和业务领

　　域之间分离治理职责。注意，这不是组织结构图。该图说明了各个领域如何根据上述趋势共同开展数据治理，以消除对术语"组织"的强调。表3-1描述了可能在数据治理操作框架内建立的典型数据治理委员会。

　　3.数据治理运蕾模型类型

　　在集中式管理模式中，数据治理组织监督所有业务领域中的活动。在分布式管理模式中，每个业务单元中采用相同的数据治理运营模型和标准。在联邦式管理模式中数据治理组织与多个业务单元协同，以维护一致的定义和标准。企业数据治理运营模型示例如图3-4所示(参见图3-4和第16章)。

　　4.数揭管理职责

　　数据管理职责(DataStewardship)描述了数据管理岗位的责任，以确保数据资产得到有效控制和使用。可以通过职位名称和职责描述正式确定管理职责，也可以采用非正式的形式，由帮助组织获取数据价值的人所驱动。通常情况下像保管人、受托人这样的称呼，就是类似的管理岗位的同义词。

　　管理职责的焦点因组织不同而不同取决于组织战略文化、试图解决的问题、数据管理成熟度水平以及管理项目的形式等因素。然而在大多数情况下，数据管理活动将集中于以下部分(未必全部):

　　1)创建和管理核心元数据。它包括业务术语、有效数据值及其他关键元数据的定义和管理。通常管理专员负责整理的业务术语表，成为与数据相关的业务术语记录系统。

　　2)记录规则和标准。它包括业务规则、数据标准及数据质量规则的定义和记录。通常基于创建和使用数据的业务流程规范来满足对高质量数据的期望。为确保在组织内部达成共识，由数据管理专员帮助制定规则并确保其得到连贯的应用。

　　3)管理数据质量问题。数据管理专员通常参与识别、解决与数据相关的问题，或者促进解决的过程。

　　4）执行数据治理运营活动。数据管理专员有责任确保数据治理制度和计划在日常工作或每一个项目中被遵循执行并对决策发挥影响力以支持组织总体目标的方式管理数据。

　　5.数据管理岗位的类型

　　管理专员(Steward，直译为管家，本书译为管理专员)指其职责是为别人管理财产的人。数据管理专员代表他人的利益并为组织的最佳利益来管理数据资产(McGilvray,2008)。数据管理专员代表所有相

　　关方的利益，必须从企业的角度来确保企业数据的高质量和有效使用。有效的数据管理专员对数据治理活动负责，并有部分时间专门从事这些活动。

　　根据组织的复杂性和数据治理规划的目标，各个组织中正式任命的这些数据管理专员在其工作职位上会有一些区别，例如:1)首席数据管理专员(ChiefDataStewards)。CDO的替代角色，担任数据治理机构的主席，也可以是虚拟的(基于委员会)或者在分布式数据治理组织中担任CDO。他们甚至也可能是高层发起者。

　　2)高级数据管理专员(ExecutiveDataStewards)。他们是数据治理委员会(DGC)的资深管理者。

　　3)企业数据管理专员(EnterpriseDataStewards)。他们负责监督跨越业务领域的数据职能。

　　4)业务数据管理专员(BusinessDataStewards)。他们是业务领域专业人士，通常是公认的领域专家，对一个数据域负责。他们和利益相关方共同定义和控制数据。

　　5)数据所有者(DataOwner)。他们是某个业务数据管理专员，对其领域内的数据有决策权。

　　6)技术数据管理专员(TechnicalDataStewards)。他们是某个知识领域内工作的IT专业人员，如数据集成专家、数据库管理员、商务智能专家、数据质量分析师或元数据管理员。

　　7)协调数据管理专员(CoordinatingDataStewards)0这在大型组织中尤为重要，其领导并代表业务数据管理专员和技术数据管理专员

　　进行跨团队或者数据专员之间的讨论。

　　DAMA-DMBOKl指出"通常最好的数据管理专员都是在工作中被发现的而不是靠培养的"。这意味着，在大多数组织中，即使没有数据治理项目，也有人负责数据管理。这些人已经参与到帮助组织降低数据的风险和从数据中获得更多价值的工作中。将他们的岗位管理职责正式化，可以使他们的工作得到认可，帮助他们更加成功、做出更多的贡献。所有这些都意味着，数据管理专员可以被"培养"，可以培训员工成为各类数据管理专员O让那些已经在管理数据的人可以发展他们自己的技能和知识，从而使他们工作得更好(Plotkin，2014)。

　　6.数据制度

　　数据制度包括对数据治理管理初衷的简要说明和相关基本规则这些规则贯穿数据和信息的创造、获取、集成、安全、质量和使用的全过程。

　　数据制度是全局性的，它们支持数据标准以及与数据管理和使用等关键方面的预期行为，不同组织的数据制度差异很大。数据制度描述了数据治理的"什么"(做什么和不做什么)，而标准和规程描述了数据治理的"如何"。数据制度应该相对较少，并且尽量采用简单直接的表述。

　　7.数据资产值值

　　数据资产估值(DataAssetValuation)是一个理解和计算数据对组织的经济价值的过程。因为数据、信息甚至商务智能都是抽象概念，人们很难将它们与经济影响联系起来。理解不可替换项(如数据)价值

　　的关键是理解如{可使用它以及它的使用带来的价值(Redman，1996)。与诸多其他资产(如货币、物理设备)不同，数据具有不可互换性(替换性)。某组织客户数据的重要性不同于另一个组织的客户数据;不仅是客户本身，而且包括与之相关的数据(如采购历史、首选项等)。一个组织如何从客户数据中获得价值(即从这些数据中了解到的客户信息以及如何应用所学信息),可以成为组织的竞争优势。

　　数据生命周期的大多数阶段涉及成本(包括获取数据、存储、管理和处置)。数据只有在使用时才有价值，使用时数据还产生了与风险管理相关的成本。因此，当使用数据的经济效益超过了上述成本时，就会显现其价值。

　　其他度量价值的方式包括:1)替换成本(ReplacementCost)。在灾难性数据破坏事件或者数据中断时，数据替换或恢复的成本，包括组织内的交易、域、目录、文档和指标信息等。

　　2)市场价值(MarketValue)。兼并或收购企业时作为企业资产的价值。

　　3)发现商机(IdentifiedOpportunities)。通过交易数据或者通过售卖数据，从数据(商务智能)中发现商机获得的收入价值。

　　4)售卖数据(SellingData)。-些组织为产品或销售将数据打包从数据中获得的洞察。

　　5)风险成本(RiskCost)。它是基于潜在罚款、补救成本和诉讼费用的估价。来自法律或监管的风险包括:

　　①缺少必需的数据。

　　②存在不应留存的数据(例如，在法律审计期间发现的意外数据;需要清除但尚未清除的数据)。

　　③除上述成本外包括数据不正确造成客户、公司财务和声誉受到损害。

　　④风险下降或者风险成本的下降其实是与提升和验证数据等操作干预成本的抵消之后的溢出部分。

　　为了描述信息资产价值的概念，可以将公认的会计准则转换为公认的信息原则。(表3-2）。

　　3.2活动

　　3.2.1规划组织的数据治理

　　数据治理工作必须支持业务战略和目标。一个组织的业务战略和目标影响着组织的数据战略，以及数据治理和数据管理在组织的运营方式。

　　数据治理与数据相关的决策责任可共享。数据治理活动跨越了组织和系统的边界，以支持整体的数据视图。成功的数据治理应当是清楚地了解需要治理什么、怎么治理以及谁来执行治理。

　　相对于孤立、特定的功能领域，当数据治理是一项企业层面工作时，效果最为显著。在企业中定义数据治理的范围通常需要先定义企业的含义。反过来数据治理控制了定义它的企业。

　　1.执行就绪评估

　　评估当前组织的信息管理能力、成熟度和有效性，对于制订数据治理的计划至关重要。通过它们，可以用来衡量一个项目的有效性。评估工作对于管理和维持数据治理规划也很有价值。

　　典型的评估包括:1)数据管理成熟度。了解组织对数据的处理方式;衡量其当前的数据管理能力和容量。重点是业务人员对公司管理数据和利用数据的优势以及客观标准(如工具的使用、报告级别等)的印象(参见第15章)。

　　2)变革能力。数据治理需要行为上的改变，因此测量组织为适应数据治理所需而改变行为的能力非常重要。此外，这些活动将有助于识别潜在的阻力点。通常进行数据治理需要正式的组织变革管理。在评估变革能力时，变革管理过程中将评估现有的组织结构、文化观念

　　以及变革管理过程本身(Hiatt和Creasy，2012)(参见第17章)。

　　3)协作准备。该评估体现了组织在管理和使用数据方面的协作能力O根据定义，管理工作跨越不同职能领域，因此本质上是需要协作才能完成的。如果某个组织对于如何协作无从下手，那么这样的企业文化将成为管理的障碍。永远不要假设一个组织开始就知道如何协作，当结合变革能力进行评估时，该评估提供了洞察实施数据治理所需企业文化的能力。

　　4)与业务保持一致。通过业务一致性能力评估可以检查组织如何调整数据的使用来支持满足业务战略要求，有时这项评估会包含在变革能力评估中一起进行。通过这项评估常常会惊奇地发现临时安排的(Adhoc)数据相关活动是如何进行的。

　　2.探索与业务保持一致

　　数据治理项目必须能够被找到并提供特定的价值来为组织作出贡献。例如，减少监管机构的罚款。通过评估活动将识别和评价现有制度、指导方针的有效性，如它们处理了哪些风险、鼓励了哪些行为以及实施的情况，同时还能够识别数据治理的机会，以此提高数据及内容的实用性，并把业务调整的商业利益附加在数据治理要素中。

　　数据质量分析是评估的一部分工作。通过数据质量评估可以洞察现有问题和障碍以及低质量数据的影响，还可以识别使用低质量数据执行业务流程存在的风险，以及作为数据治理工作组成部分的数据质量项目带来的财务和其他收益(参见第13章)。

　　数据管理实践的评估是数据治理评估过程的另一个关键方面。例

　　如，评估过程中可能找到一些有能力的用户，为正在进行中的数据治理活动创建一个潜在代理的初始列表。

　　从发现和校准活动中派生出一个数据治理需求清单。例如，如果监管风险对业务产生财务问题，则需指定支持风险管理的数据治理活动。这些需求影响着数据治理的战略和战术。

　　3.制定组织触点

　　协调工作的一部分包括为数据治理工作制定组织接触点。图3-5举例说明了在首席数据官(ChiefDataOfficer,CDO)直接权利之外，支持企业数据治理和数据管理一致性和凝聚力的组织触点。

　　(1)采购和合同(ProcurementandContracts)首席数据官与供应商/合作伙伴的管理部门或者采购部门合作，制定和执行关于数据管理合同的标准文本。这包括数据即服务(DaaS)、云服务采购、其他外包、第三方开发工作或者内容获取/许可协议以

　　及可能的以数据为中心的IT工具采购和升级。

　　(2)预算和资金(BudgetandFunding)如果首席数据官没有直接控制所有与数据采购相关的预算，那么数据管理办公室将成为防止重复工作及保证优化获得数据资产的焦点。

　　(3)法规遵从性(RegulatoryCompliance)首席数据宫在不同地区国家和国际监管环境中工作要理解这些环境如何影响组织及其数据管理活动。需要开展持续性的监控活动，以识别、跟踪新出现和潜在的影响和要求。

　　(4)SDLC/开发框架(SDLC/DevelopmentFramework)数据治理规划中确定了在系统或应用程序开发生命周期中制定组织策略、流程和标准的控制点。

　　首席数据官影响组织触点支持企业在管理其数据时的凝聚力也会增加企业使用数据的敏捷性。从本质上来讲这是组织如何理解和看待数据治理的一个态度。

　　3.2.2制定数据治理战略

　　数据治理战略定义了治理工作的范围和方法。应根据总体业务战略以及数据管理、IT战略全面定义和明确表达数据治理战略。如同标准工件，以迭代的方式开发及获得认可。应根据每个组织制定具体内容，交付物包括:1)章程。确定数据管理的业务驱动愿景、使命和原则，包括成熟度评估、内部流程分析及当前问题和成功标准。

　　2)运营框架和职责。定义数据治理活动的结构和责任。

　　3)实施路线图。制定时间计划其涉及最终发布的制度、指令、业务术语、架构、资产价值评估、标准和程序以及所期望业务和技术流程发生的改变、支持审计活动和法规遵从的交付成果。

　　4)为成功运营制订计划。为数据治理活动描述一个可持续发展的目标状态。

　　1.定义数据治理运营框架

　　开发数据治理的基本定义很容易但是创建一个组织采用的运营框架可能很困难。在构建组织的运营框架时需要考虑以下几个方面:1)数据对组织的价值。如果一个组织出售数据，显然数据治理具有巨大的业务影响力。将数据作为最有价值事物的组织(如Facebook、亚马逊)将需要一个反映数据角色的运营模式。对于数据是操作润滑剂的组织数据治理形式就不那么严肃了。

　　2)业务模式。分散式与集中式、本地化与国际化等是影响业务发生方式以及如何定义数据治理运营模式的因素。与特定IT策略、数据架构和应用程序集成功能的链接，应反映在目标运营框架设计中(图3-6)。

　　3)文化因素。就像个人接受行为准则、适应变化的过程一样，一些组织也会抵制制度和原则的实施。开展治理战略需要提倡一种与组织文化相适应的运营模式同时持续地进行变革。

　　4)监管影响。与受监管程度较低的组织相比受监管程度较高的组织具有不同的数据治理心态和运营模式。可能还与风险管理或法律团

　　队有联系。数据治理层通常作为整体解决方案的一部分。这意味着确定管理活动职责范围、谁拥有数据等。运营模型中还定义了治理组织与负责数据管理项目人员间的协作、参与变革管理活动以引入新的规程以及通过治理实现问题管理的解决方案。图3-6展示了一个运营框架示例这个例子很有说服力。必须定制这种工作才能满足不同组织的个性化需求。

　　2.制定目标、原则和制度

　　依据数据治理战略制定的目标、原则和制度将引导组织进入期望

　　的未来状态。通常由数据管理专业人员、业务策略人员在数据治理组织的支持下共同起草数据治理的目标、原则和制度，然后由数据管理专员和管理人员审查并完善，最终由数据管理委员会(或类似组织)进行终审、修订和发布采用。

　　管理制度可能包含多个不同方面内容，如:1)由数据治理办公室(DCO)认证确认组织用到的数据。

　　2)由数据治理办公室(DCO)批准成为业务拥有者。

　　3)业务拥有者将在其业务领域委派数据管理专员，数据管理专员的日常职责是协调数据治理活动。

　　4）尽可能地提供标准化报告、仪表盘或计分卡，以满足大部分业务需求。

　　5)认证用户将被授予访问相关数据的权限，以便查询即痛(adhoc)报表和使用非标准报告。

　　6)定期复评所有认证数据，以评价其准确性、完整性、一致性、可访问性、唯一性、合规性和效率等。

　　必须有效地沟通监督执行和定期复评数据管理制度。数据管理委员会可将此权力委托给数据管理指导委员会。

　　3.推动数据管理项目

　　改进数据管理能力的举措可为整个企业带来好处。这些通常需要来自数据治理委员会的跨职能关注和支持。数据管理项目很难推动，它们经常被看作"完成工作"的障碍。推动数据治理项目关键是阐明数据管理提高效率和降低风险的方法。组织如果想从数据中获得更多价

　　值，则需要有效优先发展或提升数据管理能力。

　　数据治理委员会负责定义数据管理项目的商业案例，监督项目状态和进度。如果组织中存在项目管理办公室，数据治理委员会要和数据管理办公室协同工作，数据管理项目可视为整个IT项目组合的一部分。

　　数据治理委员会还可以与企业范围内的大型项目集配合开展数据管理改进工作。主数据管理项目，如企业资源计划(ERP)、客户关系管理(CRM)和全球零件清单等都是很好的选择。

　　其他项目中的数据管理活动，一般由组织内部SDLC、服务交付管理、ITIL和PMO统筹考虑。对于每个含有重要数据组件的项目(几乎所有项目都包含)在软件生命周期的前期(规划和设计阶段)就应该收集数据管理需求。这些内容包括系统架构、合规性、系统记录的识别和分析以及数据质量的检测与修复。此外，还可能有一些其他数据管理支持活动，包括使用标准测试台进行需求验证测试。

　　4.参与变革管理

　　组织变革管理(OrganizationalChangeManagement,OCM)是进行组织管理体系和流程变革的管理工具。变革管理研究所(TheChangeManagementInstitute)认为，组织的变革管理不仅仅是"项目中人的问题"，应该被视为整个组织层面管理改良的一种途径。组织经常面临管理项目上的变迁，而不是管理组织体系进化(Anderson和Ackerson，2012)0成熟的组织在变革管理中建立清晰的组织愿景，从高层积极引导和监督变革，设计和管理较小的变革尝

　　试，再根据整个组织的反馈和协同情况调整变革计划方案(参见第17章)。

　　对很多组织来说，数据治理所固有的形式和规则不同于巳有的管理实践。适应数据治理需要人们改变行为和互动方式。对于正式的管理变革项目，需要有适合的发起者，这对于推动维持数据治理所需的行为变化至关重要。组织需要组建一个团队来负责以下事项:1)规划。规划变革管理包括进行利益相关方分析、获得支持以及建立能够克服阻力的沟通方法。

　　2)培训。建立和执行数据治理项目培训。

　　3)影响系统开发。与项目管理办公室(PMO)合作，在软件开发生命周期(SDLC)中增加数据治理步骤。

　　4)制度实施。宣传数据制度和组织对数据管理活动的承诺。

　　5)沟通。提高数据管理专员和其他数据治理专业人员对自身角色和职责以及数据管理项目目标和预期的认知。

　　沟通对变更管理过程至关重要。为了正式的数据治理变更管理方案获得支持应将沟通重点放在:1)提升数据资产价值。教育和告知员工数据在实现组织目标中所起的作用。

　　2)监控数据治理活动的反馈并采取行动。除了共享信息外，通过沟通计划还应引导出相关方反馈，以指导数据治理方案和变更管理过程。积极寻求和利用利益相关方的意见可以建立对项目目标的承诺，同时也可以确定成功和改进的机会。

　　3)实施数据管理培训。对各级组织进行培训，以提升对数据管理最佳实践和管理流程的认知。

　　4)可以从以下5个关键领域衡量变革管理的程度:①意识到需要改变。

　　②希望参与并支持变革。

　　③知道如何改变。

　　④具备实施新技能和行为的能力。

　　⑤保持持续变革。

　　5)实施新的指标和关键绩效(KPI)。应重新调整员工激励措施，以支持与数据管理最佳实践相关的行为。由于企业数据治理需要跨职能合作，激励措施中应该鼓励跨部门活动和协作。

　　5.参与问题管理

　　问题管理是识别、量化、划分优先级和解决与数据治理相关的问题的过程，包括:1)授权。关于决策权和程序的问题。

　　2)变更管理升级。升级变更过程中出现问题的流程。

　　3)合规性。满足合规性要求的问题。

　　4)冲突。包括数据和信息中冲突的策略、流程、业务规则、命名、定义、标准、架构、数据所有权以及冲突中利益相关方的关注点。

　　5)一致性。与策略、标准、架构和流程一致性相关的问题。

　　6)合同。协商和审查数据共享协议，购买和销售数据、云存储。

　　7)数据安全和身份识别。有关隐私和保密的问题，包括违规调查。

　　8)数据质量。检测和解决数据质量问题，包括灾难事件或者安全漏洞。

　　很多问题可以在数据管理团队中被解决。需要沟通或者上报的问题必须被记录下来，并将其上报给数据管理团队或者更高级别的数据治理委员会如图3-7所示。数据治理计分卡可用于识别与问题相关的趋势如问题在组织内发生的位置、根本原因等。数据治理委员会无法解决的问题应升级上报给公司治理或管理层。开展数据治理需要在以下几个方面建立控制机制和流程:

　　1)识别、收集、记录和更新的问题。

　　2)各项活动的评估和跟踪。

　　3)记录利益相关方的观点和可选解决方案。

　　4)确定、记录和传达问题解决方案。

　　5)促进客观、中立的讨论，昕取各方观点。

　　6)将问题升级到更高权限级别。

　　数据问题管理非常重要。通过问题管理为数据治理团队建立了信任减轻了生产支持团队的负担，这对数据消费者有直接、积极的影响。通过解决问题也证明了数据管理和质量的提高。对于成功的问题管理

　　需要有展示工作过程和消除影响的控制机制。

　　6.评估法规遵从性要求

　　每个组织都受到政府和行业法规的影响，其中包括规定如何管理数据和信息的法规。数据治理的部分功能是监督并确保合规。合规性通常是实施数据管理的初始原因。数据治理指导实施适当的控制措施，以记录和监控数据相关法规的遵从情况。

　　对管理信怠资产有重大影响的部分全球性法规如下:1)会计准则。政府会计准则委员会(GASB)和财务会计准则委员会(FASB)的会计准则对(在美国)管理信息资产具有重大影响。

　　2)BCBS239(巴塞尔银行监管委员会)和巴塞尔II。这是指有效的风险数据汇总和风险报告原则，是一整套针对银行的法规。自2006年以来在欧盟国家开展业务的金融机构必须报告证明流动性的标准信息。

　　3)CPG235。澳大利亚审慎监管局(APRA)负责监督银行和保险实体，公布了一些标准和指南以帮助被监管对象满足这些标准其中包括CPG235，一个管理数据风险的标准。制定这个标准的目的是解决数据风险的来源并在整个生命周期中管理数据。

　　4)PCI-DSS。支付卡行业数据安全标准(PCI-DSS)。

　　5)偿付能力标准II。欧盟法规，类似巴塞尔协议旺，适用于保险行业。

　　6)隐私法。适用于各地区、各主权实体和国际的法律。

　　数据治理组织与其他业务和技术的领导一起评估各种法规的影

　　响。例如，评估过程中每个组织必须确定:1)与组织相关的法规有哪些?2)什么是合规性?实现合规性需要什么样的策略和流程?3)什么时候需要合规?如何以及什么时候监控合规性?4)组织能否采用行业标准来实现合规性?5)如何证明合规性?6)违规的风险和处罚是什么?7)如何识别和报告不合规的情况?如何管理和纠正不合规的情况?数据治理监控组织要对涉及数据和数据实践的监管要求或审计承诺作出响应，如在监管报告中证明数据质量合格(参见第6章)。

　　3.2.3实施数据治理

　　数据治理不可能一夜之间实现。治理过程包含了很多复杂性协调工作，需要对治理进行规划，不仅要考虑到组织的变化，而且改变得要简单。最佳方式是创建一个实施路线图，说明不同活动间的关系和整体时间框架。例如，如果数据治理项目的重点是提高合规性，则优先事项可能由特定的法规要求驱动。在联合数据治理组织中，根据不同业务线的参与程度、成熟度以及资金来源，可以在不同时间表上执行不同业务线的数据治理。

　　有一些数据治理工作是基础性的，其他工作依赖于此。这些基础性工作分为初始阶段和持续阶段。高优先级的前期工作包括:1)定义可满足高优先级目标的数据治理流程。

　　2)建立业务术语表，记录术语和标准。

　　3)协调企业架构师和数据架构师，帮助他们更好地理解数据和系统。

　　4)为数据资产分配财务价值，以实现更好的决策，并提高对数据在组织成功中所起作用的理解。

　　1.发起数据标准和规程

　　标准被定义为"用来判断其他事物质量的好东西"或"由权威建立和确定作为衡量数量、重量、范围、价值或质量的规则hO因为标准提供了一种比较方法，所以其有助于质量的定义。标准还提供了简化流程的潜力。通过采用标准，组织只需做一次决定，并将其编成一组实施细则(标准)，而不再需要为每个项目重新做出相同的决定。实施标准应促进使用标准的过程产生一致的结果。

　　不幸的是，建立或采用标准通常是一个政治化的过程，这样的过程很可能导致制定标准的目标丢失。大多数组织在开发或实施数据或数据治理标准方面没有很好的实践。在某些情况下，他们没有意识到这样做的价值，因此也没有花时间这样做。有的时候他们根本还不知道怎么做。因此，"标准"在组织内部和跨组织变化很大，对一致性的期望也是如此。数据治理的标准应该具有强制性。

　　数据标准可以采用不同的形式具体取决于所描述的内容:关于如何填充字段的要求、控制字段之间关系的规则、可接受和不可接受值的详细文档、格式等。它们通常由数据管理专业人员起草。数据标准应由数据治理办公室或授权工作组(如数据标准指导委员会)审查、批

　　准和采用。数据标准文档中的详细程度在某种程度上取决于组织文化。应记住，通过记录数据标准提供了一个捕获细节和知识的机会，否则可能会丢失这些细节和知识。与预先记录相比，重新创建或反向工程获取这些知识是非常昂贵的。

　　数据标准必须得到有效沟通、监控，并被定期审查和更新。最重要的是，必须有强制手段，对数据可以根据标准进行测量。数据管理活动可由数据治理委员会或数据标准指导委员会按照规定的时间表或作为SDLC批准流程的一部分进行审核，以确保符合标准。

　　数据管理流程是遵循文档化的方法技术和步骤来完成产生特定的结果和支持的特定活动。与数据标准一样，通过流程文档以明确的形式捕获组织知识。通常由数据管理专业人员来起草数据流程文档。

　　数据管理知识领域内的标准化概念示例如下:1)数据架构(DataArchitecture)。它包含企业级数据模型、工具标准和系统命名规范。

　　2)数据建模和设计(DataModelingandDesign)。它包括数据模型管理程序、数据模型的命名规范、定义标准、标准域、标准缩写等。

　　3)数据存储和操作(DataStorageandOperations)。它包括标准工具、数据库恢复和业务连续性标准、数据库性能、数据留存和外部数据采集。

　　4)数据安全(DataSecurity)。它包括数据访问安全标准、监控和审计程序、存储安全标准和培训需求。

　　5)数据集成(DataIntegration)。它是用于数据集成和数据互操

　　作的标准方法、工具。

　　6)文件和内容(DocumentsandContent)。它包含内容管理标准及程序，包括企业分类法的使用，支持法律查询、文档和电子邮件保留期限、电子签名和报告分发方法。

　　7)参考数据和主数据(ReferenceandMasterData)。它包括参考数据管理控制流程、数据记录系统、建立标准及授权应用、实体解析标准。

　　8)数据仓库和商务智能(DataWarehousi吨andBusinessIntelligence)。它包括工具标准、处理标准和流程、报告和可视化格式标准、大数据处理标准。

　　9)元数据(Metadata)。它指获取业务和技术元数据，包括元数据集成和使用流程。

　　10)数据质量(DataQuality)。它包括数据质量规则、标准测量方法、数据补救标准和流程。

　　11)大数据和数据科学(BigDataandDataScience)。它包含数据源识别、授权、获取、记录系统、共享和刷新。

　　2.制定业务术语表

　　数据管理专员通常负责整理业务术语表的内容。由于人们说话用词习惯不同，所以建立术语表是必要的。由于数据代表的是自身之外的事务，因此数据的明确定义尤为重要(Chisholm，2010)。此外许多组织使用个性化的内部词汇术语表是在组织内部共享词汇的一种方法。开发、记录标准数据定义，可以减少歧义混乱，提升沟通效率。

　　定义必须清晰、措辞严谨，并能解释任何可能的例外、同义词或者变体。术语表的批准人包括来自核心用户组的代表。通过数据架构通常可以从主题域模型中提供草稿定义和类型突破。业务术语表具有如下目标:1)对核心业务概念和术语有共同的理解。

　　2)降低由于对业务概念理解不一致而导致数据误使用的风险。

　　3)改进技术资产(包括技术命名规范)与业务组织之间的一致性。

　　4)最大限度地提高搜索能力，并能够获得记录在案的组织知识。

　　业务术语表不仅仅是术语和定义的列表，而且每个术语还同其他有价值的元数据关联，包括同义词、度量、血缘、业务规则，负责管理术语的人员等。

　　3.协调架构团队协作

　　数据治理委员会支持并批准数据架构。例如，面向业务的企业数据模型。数据治理委员会可以任命或与企业数据架构指导委员会或架构审查委员会(ARB)互动，以监督项目及其迭代项目。应由数据架构师和数据管理专员在业务领域团队中共同开发和维护企业数据模型。根据组织情况的不间，可以由企业数据架构师或数据管理专员协调这项工作。随着业务需求的发展，数据主管团队应提出更改建议，并开发扩展企业级数据模型。

　　企业级数据模型应经数据治理委员会评审、批准并正式采用与关键业务战略、流程、组织和系统保持一致性。在管理数据资产方面数据战略和数据架构是在"做正确的事"与"正确地做事"之间协调的核

　　心。

　　4.发起数据资产估值

　　数据和信息是具有价值或者可以创造价值的企业资产。现今的财务实践中，考虑将数据和信息视为无形资产，如同软件、文档、专家知识、商业秘密和其他知识产权一样。尽管如此，各组织都认为赋予数据以货币价值是一项有挑战性的事情。数据治理委员应组织开展相关工作，并为此设置标准。

　　有些组织首先应该估计由于信息不足而造成业务损失的价值。信息缺口一一所需信息和可用信息之间的差异一一代表业务负债。弥补或防止差距的成本可用于估算数据丢失的业务价值。参考这个思路，组织可以开发模型来评估实际存在信息的价值。

　　可以将价值评估过程构建在数据战略路线图中以便为质量问题的解决方案以及其他治理方案的业务案例提供依据。

　　3.2.4嵌入数据治理

　　数据治理组织的一个目标是将治理活动嵌入到数据作为资产管理相关的一系列流程中。数据治理的持续运作需要规划。运营计划包含实施和运营数据治理活动所需的事件，其中包括维持成功所需的活动、时间和技术。

　　可持续性意味着采取行动保证流程和资金到位以确保可持续地执行数据治理组织框架。这一要求的核心是组织接受数据治理·实现管理职能监控和测最其结果并克服常导致数据治理不稳定或失败的障碍。

　　通常为了加深组织对数据治理的理解，可通过其本地应用创建一个感兴趣的数据治理社区来加强相互学习O这种做法在治理的最初几年特别有用但随着数据治理运营的成熟其效果可能会逐渐减少。

　　3.3工具和方法

　　数据治理从根本上讲是关于组织行为的。这不是一个可以通过技术解决的问题。但是，仍需要一些工具支持整个过程。例如数据治理需要持续的沟通可以利用现有的沟通渠道以一致的方式传达关键信息，使相关方了解到制度、标准和要求。

　　此外，数据治理流程必须有效管理自己的工作和数据。利用工具不仅仅对任务有帮助，而且对支持它们的指标也有帮助。在为某些特定功能(如业务术语表解决方案)工作选择工具之前，组织应该通过定义总体治理目标和需求来选择适合的工具。例如有些术语表解决方案中还包括用于策略、工作流管理其他组件。如果需要这样的附加功能，那么在采用工具之前，应该对需求进行澄清和测试。否则，组织会拥有多个工具，却没有一个能够完全满足需求的。

　　3.3.1线上应用/网站

　　数据治理也应该能够线上体现，可以通过中心门户或者协作门户提供核心文档。网站可以容纳文档库，提供搜索功能，帮助管理简单的工作流。通过LOGO和统一视觉展现，在一个网站上可以帮助建立相应的品牌。数据治理规划的网站应该包括如下内容:1)数据治理战略和项目章程，包括愿景、效益、目标、原则和实施路线图。

　　2)数据制度和数据标准。

　　3)数据管理制度的角色和职责说明。

　　4)数据治理相关新闻公告。

　　5)指向相关数据治理社区论坛的链接。

　　6)指向相关数据治理主题执行进展的链接。

　　7)数据质量测试报告。

　　8)问题识别和上报的规程。

　　9)请求服务或获取问题的入口。

　　10)相关在线资源的描述和链接、演示文档和培训计划。

　　11)数据管理实施路线图。

　　3.3.2业务术语表

　　业务术语表是数据治理的核心工具。IT部门要认可业务术语的定义并将定义与数据进行关联。业务术语表的工具有很多，有些是大型ERP系统、数据集成工具或者元数据管理工具的一部分以及一些独立工具。

　　3.3.3工作流工具

　　更大的组织可能会考虑使用强大的工作流工具来管理流程如实施新的数据治理策略。通过这些工具将流程连接到文档，这在策略管理和问题解决中非常有用。

　　3.3.4文档管理工具

　　治理团队经常使用文档管理工具协助管理策略和规程。

　　3.3.5数据治理记分卡

　　它是跟踪数据治理活动和制度遵从性的指标集合，通过自动记分卡的形式向数据治理委员会和数据治理指导委员会报告。

　　3.4实施指南

　　一旦定义了数据治理的规程、制订了运营计划，加上在数据成熟度评估过程中收集数据制定的实施路线图，组织即可启动实施数据治理(参见第15章)。数据治理要么起始于一些重大项目(如MDM主数据管理)，要么通过区域或者部门试点。大多数推广策略都是渐进式的，很少有直接在整个组织范围内部署的情况。

　　3.4.1组织和文化

　　如3.2.9节所述，数据治理中很多固有的形式和规则对于许多组织来说都是新的、不同的。数据治理通过改变组织行为来提升价值。对于决策和治理项目的新方法，可能存在抵制变化及学习或采用消极态度的情况。

　　有效而持久的数据治理需要组织文化的转变和持续的变革管理文化包括组织思维和数据行为，变革包括为实现未来预期的行为状态而支持的新思维、行为、策略和流程。无论数据治理战略多么精确、多么独特，忽视企业文化因素都会减少成功的概率。实施战略必须专注于变革管理。

　　组织变革自标是可持续性的。可持续性是过程的质量指标以此衡量过程持续增值的难易程度。维持数据治理规程需要对变化作出计划(参见第17章)。

　　3.4.2调整与沟通

　　数据治理规程是在更广泛的业务和数据管理战略背景下逐步实现的。实现成功需要更广泛的目标，同时需要将各部分落实到位。数据治理团队要有灵活性并且能够随着条件的变化调整相应的方法。管理和沟通变更所需的工具包括:1)业务战略/数据治理战略蓝图(Business/DCStrategyMap)。这些蓝图将数据治理活动与业务需求联系起来。定期衡量和沟通数据治理对业务的帮助对于数据治理持续获得支持是至关重要的。

　　2)数据治理路线图(DCRoadMap)。数据治理路线图不应刻板、僵化，而应适应业务环境或优先级的变化进行调整。

　　3)数据治理的持续业务案例(OngoingBusinessCaseforDC)0数据治理的业务案例必须定期被调整，以反映组织不断变化的优先级和财务状况。

　　4)数据治理指标(DCMetrics)。随着数据治理规程的成熟，数据治理的相关指标也应随之逐渐增长和变化。

　　3.5度量指标

　　为应对长期学习曲线的阻力和挑战对数据治理项目必须要有通过证明数据治理参与者如何增加业务价值和实现目标的指标来衡量进展和成功。为了管理所需的行为变化要着重衡量数据治理的推广进展、与治理需求的符合程度以及数据治理为组织带来的价值。重点是充实和强化治理价值的指标。另外，数据治理推出后，要验证组织是否拥有支持数据治理所需资源的指标，这对于维持治理规程同样重要。

　　数据治理指标的示例包括:

　　(1)价值

　　1)对业务目标的贡献。

　　2)风险的降低。

　　3)运营效率的提高。

　　(2)有效性

　　1)目标的实现。

　　2)扩展数据管理专员正在使用的相关工具。

　　3)沟通的有效性。

　　4)培训的有效性。

　　5)采纳变革的速度。

　　(3)可持续性

　　1)制度和流程的执行情况(即它们是否正常工作)。

　　2)标准和规程的遵从情况(即员工是否在必要时遵守指导和改变行为)。

篇五：数据治理理论

　　数字治理理论

　　数字治理理论是一种指导管理组织和公共政策的框架，试图引入数据科学和技术方法来重新定义政策制定传统的技术和治理结构。这项理论的核心假说是，大数据技术和计算能力可以加快决策的速度，提高解决复杂问题的效率，并使政策更加智能和有效。数字治理理论包括使用先进技术来收集大量实时数据，使用算法来分析它们，并将结果应用于政策和决策制定。它还支持社会科学研究，以便更好地了解事务发展的影响，并根据反馈优化政策。与其他政策制定技术和方法不同，数字治理理论强调及时反馈，并根据不断变化的环境提供可执行的改动建议。数字治理的假设是，通过采用数据驱动的解决方案，政府可以更有效地实施政策，提高公民服务，并在日常操作中改进工作流程。此外，它还可以增强政府之间的协作，帮助各国更好地应对变化。

　　数字治理理论可以帮助政府更快、更准确地处理和识别影响公众利益的因素，并帮助决策者更好地了解它们。它还可以加强政府和公众之间的建立沟通渠道，使公众参与到政策制定过程中来。数字治理理论还支持采用先进系统，如人工智能和机器学习，以改善公共运营效率。它还可以通过支持政府的数据分析能力，帮助政策制定者更快更准确地识别影响公众利益的隐藏因素。

　　然而，数字治理也有一些潜在的风险，如偏见和安全性问题，以及政策制定者和决策者有可能忽略技术限制和其他社会因素的问题。另外，数字治理还面临着保护公民权利和隐私的问题，以及如何确保数据安全和准确性的挑战。因此，在数字治理实施过程中，各国政府必须考虑政策规划、监管和管理问题，以确保数据使用的可靠性和安全性，并防止任何滥用和滥用。此外，政府必须制定有效的法律框架，以维护和保护公民权利和隐私，并确保数据保护和安全机制的可行性。

篇六：数据治理理论

　　数据治理专题-2从11?开始，将开展本年度的课题写作阶段，?课题的主题主要是围绕银?的数据治理展开，尤其涉及反洗钱??的数据治理。上期讲述了在监管?件《法??融机构洗钱和恐怖融资风险管理指引（试?）》中提到了反洗钱数据质量的框架，主要包括反洗钱数据治理?标、反洗钱数据治理范围等，本期，将讲述数据治理的演变历程，了解数据治理是怎么来的，为什么要开展数据治理。从德勤【数据治理实践】专题中，讲到了数据治理的发展主要为三个阶段。第?阶段-早期探索1988年，由?省理?学院的两位教授启动了全?数据质量管理计划（TDQM），同年，DAMA（国际数据管理组织协会）成?。到2002年，数据治理概念?次出现在学术界，美国两位学者发表题为《数据仓库治理》的研究探讨了BlueCross和BlueShieldofNorthCarolina两家公司的最佳实践，由此拉开了“数据治理”在企业管理中的?幕。第?阶段-理论研究在美国学者发表《数据仓库治理》的第?年，2003年DGI(国际数据治理研究所)成?，研究数据治理理论框架，与ISO国际标准化组织对数据管理与数据治理进?定义。直到2009年，DAMA国际发布DMBOK数据管理知识体系指南，?此数据治理的理论框架基本固定。第三阶段-?泛接受与应?伴随着数据仓库的建设，主数据管理与BI的实施，国内也逐步开始接受并利?数据治理的概念进?推?实践。我国数据治理之路在DMBOK基础上不断延伸和扩展，?程碑事件为在2015年提出了《数据治理??书》国际标准研究报告，在2018年发布了《银?业?融机构数据治理指引》，这标志着数据治理在我国银??融机构中全?实践时代的到来。?对于我们银?业?融机构来说，?熟能详的、频繁听到数据治理这四个字是源?《银?业?融机构数据治理指引》颁布后。?此之后，数据治理?作被国内银?业?融机构正式提上?程，为啥呢，???是监管要求的应对，另???是多年积累的数据治理需求集中迸发。不过，对于?多数银?业?融机构??，在2018年，数据治理?作的主要内容仍是同业间的相互学习、研究探索或是观望。到了2019年，数据治理?作已在?融机构全?铺开。《指引》中明确提出的年度?评报送、年度培训、不少于每年?次的数据质量现场检查等监管要求在2019年可能成为数据治理??的监管重点。从2019年开始，各银?需要满?监管合规的要求，逐步开展包括数据治理组织架构的建设、数据管理专项?作的推进、数据质量控制的落实、数据应?和数据价值的实现，以及?评、审计和监督检查的?作。为此，?融机构称2019年是银?业?融机构的“数据治理监管元年”。

篇七：数据治理理论

　　数据治理的核心框架和六大思维

　　数据成为新的生产力，必将引发数据生产关系的变革，而数据治理体系就代表着新的生产关系。近日发布的《广东省数据要素市场化配置改革理论研究报告》（下称《报告》），提出数据治理以数据为对象，在确保数据安全的前提下，建立健全规则体系，理顺各方参与者在数据流通的各个环节的权责关系，形成多方参与者良性互动、共建共治共享的数据流通模式，从而最大限度地释放数据价值，推动数据要素治理体系和治理能力现代化。

　　01搭建数据治理的核心框架

　　数据治理的核心框架从价值目标到条件环境是一个自上而下的推导过程，数据价值释放为数据治理提供了远景和方向，数据资产地位确立提供了关键基础，多元协同治理提供了动力，数据开放共享提供了实现路径，而平台技术保障提供了保障。从而，整个过程形成逻辑闭环，构成了数据治理的核心框架，保证了数据治理体系不断完善，实现迭代发展。

　　第一，数据治理的目标是保障数据及其应用过程中的运营合规、风险可控和价值实现，通过数据治理体系规范数据治理流程，保证数据治理的合规运营，促进对数据的深度挖掘和有效利用，从而将数据中隐藏的巨大价值释放出来。

　　第二，数据治理的关键基础是确立数据的资产地位，明确数据权属的主体资格，明确规定数据的收集、使用、管理权限，明确各类经营者收集数据的合法途径，平衡数据利用与数据保护。

　　第三，数据治理的核心动力在于建立健全规则体系，通过数据安全、有序地流通，推动资本、人才、技术等要素的不断重组和优化，形成多方参与者良性互动、共建共治共享的数据流通模式。

　　第四，数据治理的行为选择在于让数据动起来、用起来，通过数据的共享、开放、运营、开发、交易等多元化方式，促进数据的融合碰撞和高效流通，激活数据要素潜能，实现数据要素价值充分释放。

　　第五，数据治理的条件环境以国家、企业和个人信息安全为前提，通过数据的分类分级管控，严格的权限管理机制、完善的组织架构和监督评估体系，防范化解数据危机。

　　02明确数据治理的六大思维

　　数据治理涵盖数字世界和物理世界，构建数据治理体系必须要有正确的方法论来予以指导。《报告》对数据治理基本思路进行归纳，提出“战略思维”“精准思维”“系统思维”“辩证思维”“创新思维”“底线思维”六大思维方式，形成数据治理的思维视角。

　　战略思维是顶层，聚焦构建数据治理的生态体系；系统思维是主体，聚焦协同治理体制机制；辩证思维和创新思维是支柱，分别聚焦数据要素市场一般规律和前沿技术、先进文化；精准思维是切入点，聚焦数据资源质量管理；底线思维是基础，聚焦保护国家安全和民众权益。

　　一是战略思维。数据治理涉及政治、经济、社会、技术、文化等方方面面，具有非常复杂、宽广的视域。应从全球发展战略层面出发，立足经济社会发展根本和全球数字化变革大局，着眼数字经济时代的长远发展，完善相关战略规划、政策规定与法律体系，构建数据治理生态体系，形成公共价值目标共同体。

　　二是精准思维。数据只有流动起来才能创造价值，数据治理需要促进数据在不同主体之间有序流动，而数据流通的前提，需要建立统一规范的数据标准，并建立在数据质量可靠的基础上。低质量甚至错误的数据，会影响数据流通，并最终影响价值的挖掘。

　　三是系统思维。数据治理过程中，应当从整体性、系统性着手，打破

　　部门壁垒，搭建开放共享平台，打通国家、行业、组织等多层次，整合政府、企业、个人等多利益相关方的力量，从政策、标准、技术、应用等多维度进行综合考量，构建共建、共享、共治的数据治理环境。

　　四是辩证思维。数据治理是有效的切入点，要从辩证法和认识论的角度入手，深刻理解数据资源的深刻内涵、网络空间的内在本质，辨析虚拟空间与现实社会、安全保护与开放利用的辩证统一关系，归纳和总结数据治理的一般规律，推动数据由资源向要素转化，最大程度上挖掘数据价值。

　　五是创新思维。主动把握数据资产、数据经纪人、数字人等各种新概念、新理念、新应用、新需求，勇于探索运用新机制、新技术、新手段来防范和化解面临的新风险，聚焦管理方式、协调机制、组织文化等方面改革创新，积极推动数据治理体系建设。

　　六是底线思维。数据是个人和企业的重要资产，是国家重要的战略资源，成为数字经济发展的重要驱动力。要注重防风险，做好风险评估，努力排除风险因素，加强先行先试、科学求证，健全监管体系，提高监管能力，筑牢安全网。

篇八：数据治理理论

　　数据治理理论实践（全）

　　数据治理是什么？为什么要做数据治理？关于数据治理我们需要做什么？

　　数据治理无论是在数仓建设过程中还是数仓建设完成之后都是及其重要的，是数据部门基础建设的必经之路，是降本提效，形成企业数据资产的关键一环

　　一

　　数据质量管理

　　1.1数据质量基本概念

　　数据质量管理（DataQualityManagement），是指对数据从

　　计划、获取、存储、共享、维护、应用、消亡生命周期的每个阶段里可能引发的各类数据质量问题，进行识别、度量、监控、预警等一系列管理活动，并通过改善和提高组织的管理水平使得数据质量获得进一步提高

　　数据质量管理不是一时的数据治理手段，而是循环的管理过程。其终极目标是通过可靠的数据，提升数据在使用中的价值，并最终为企业赢得经济效益

　　1.2影响因素

　　数据问题的来源可能产生于从数据源头到数据存储介质的各个环节。在数据采集阶段，数据的真实性、准确性、完整性、时效性都会影响数据质量。除此之外，数据的加工、存储过程都有可能涉及对原始数据的修改，从而引发数据的质量问题。所以，技术、流程、管理等多方面的因素都有可能会影响到数据质量。

　　在企业中，随着企业业务的增长，数据也是一个增量积累的过程。随着数据类型、数据来源的不断丰富以及数据数量的快速增长，企业在数据管理工作和数据流程中面临越来越多的数据质量问题。而且数

　　据质量的管理并没有被企业重视起来，其根本原因还是ROI并没有那么明显。

　　数据质量管理相对来说成本比较高。因为它涉及到企业数据标准的制定、规范的落地、生命周期的管理等多个环节。从收益上来说，数据质量的效益和结果并不是十分明显，大部分企业不会把数据质量作为KPI。在企业的不同系统中，业务领域的关键指标不一致，数据无法共享导致出现数据孤岛，大量数据无法关联，并且有明显的数据冗余等问题，还有数据的维护需要投入大量的人员、时间、软硬件成本。所以数据的质量管理往往被会边缘化甚至趋向于无。

　　在此附上数据的生命周期图，包括各环节的数据流转和数据处理。

　　1.3评估维度

　　完整性

　　数据完整性问题包含数据条目不完整，数据属性不完整等

　　一致性多源数据的数据模型不一致，如命名不一致，数据编码不一致，含义不一致，生命周期不一致等

　　准确性准确性也叫可靠性，不可靠的数据可能会导致严重的问题，会造成有缺陷的方法和糟糕的决策

　　唯一性

　　用于识别和度量重复数据，冗余数据，重复数据是导致业务无法

　　协同，流程无法追溯的重要因素，也是数据治理需要解

　　决的最基本的数据问题

　　关联性数据关联性问题是指存在数据关联的数据关系缺失或错误，例如：函数关系、相关系数、主外键关系、索引关系等。存在数据关联性问题，会直接影响数据分析的结果，进而影响管理决策。

　　真实性

　　数据必须真实准确的反映客观的实体存在或真实的业务，真

　　实可靠的原始统

　　计数据是企业统计工作的灵魂，是一切管理工作的基础，是经

　　营

　　者进行正确

　　经营决策必不可少的第一手

　　资料。

　　及时性数据的及时性(In-time)是指能否在需要的时候获到数据，数据的及时性与企业的数据处理速度及效率有直接的关系，是影响业务处理和管理效率的关键指标。

　　逻辑检查不同表字段之间可能会有逻辑关联，需要稽核

　　离群值检查部分数据可能会偏离其他数据，比如同一个商品金额大家都是100元，而有一条数据是1W?

　　自定义规则由需求方自定义相关规则

　　波动稽核

　　与上周环比稽核波动情况

　　强弱规则

　　每个规则的权重应该是不一样的，需要配置优先级，这对后续的告警方

　　式是有帮助的我们最终的目的是希望做到页面可配置

　　1.4实施流程

　　1.4.1事前定义质量规则

　　梳理表，字段等信息

　　确定资产等级

　　制定检验规则

　　数据探查

　　1.4.2事中监控数据质量

　　在数据抽取过程中，可以对数据进行数据量稽核及唯一性，非空性稽核

　　etl过程对脏数据进行清洗，保证数据质量

　　指标计算过程中，可以对指标进行波动值稽核，保证指标变化在合理范围内

　　以上如果有异常都需要邮件短信报警，对应负责人根据优先级判断是不是需要及时处理

　　1.4.3事后分析和问题跟踪

　　非空性等

　　对于程序跑出来的数据：

　　数据质量概览在数据质量管理系统查询

　　数据质量明细数据在数据质量管理系统查询

　　根据异常数据统计出来的各种数据质量报表也可以在数据质量管理系统查询，包括表覆盖率，历史趋势，综合分析，排名分析等(质量报告支持导出为word，pdf，excel)

　　每周定时跑一次程序，对全局数据进行质量稽核控制，如唯一性，对异常进行评估、严重程度、影响范围、问题分类等

　　可以订阅自己比较关心的主题，表或者规则，邮件只会发送订阅内容

　　对于打分比较低的表或者业务，可以反推业务方进行整改

　　1.4.4重大问题告警

　　1.警告

　　邮件短信通知

　　2.数据整改

　　问题跟踪处理，故障review，一周内处理完成

　　a.订阅

　　b.给表及业务进行评分

　　c.核心字段勾选

　　以上是在公司规模比较大的情况下，会开发的数据平台，里面会有数据质量管理模块，会有对应的页面进行配置，当然底层其实也是使用的sparksql或者sparkcore实现的。在开发资源比较紧张或者目前不太注重平台这一块的时候，只有自行开发python脚本去监控一些数据质量了，如空值率，波动值，数据量等

　　飞书群监控消息：

　　1.5总结

　　数据质量管理贯穿数据生命周期的全过程，覆盖质量评估、数据监控、数据探查、数据清洗、数据诊断等方面。数据源在不断增多，数据量在不断加大，新需求推动的新技术也不断诞生，这些都对大数据下的数据质量管理带来了困难和挑战。因此，数据质量管理要形成完善的体系，建立持续改进的流程和良性机制，持续监控各系统数据质量波动情况及数据质量规则分析，适时升级数据质量监控的手段和方法，确保持续掌握系统数据质量状况，最终达到数据质量的平稳状态，为业务系统提供良好的数据保障。

　　二

　　数据安全管理

　　1.数据脱敏(udf函数)数据脱敏是保证数据安全的最基本的手段，脱敏方法有很多，最常用的就是使用可逆加密算法，对入仓每一个敏感字段都需要加密。比如手机号，邮箱，身份证号，银行卡号等信息

　　2.数据权限控制

　　需要开发一套完善的数据权限控制体系，最好是能做到字段级别，有些表无关人员是不需要查询的，所以不需要任何权限，有些表部分人需要查询，除数据工程师外，其他人均需要通过OA流程进行权限审批，需要查看哪些表的哪些字段，为什么需要这个权限等信息都需要审批存档。

　　3.程序检查

　　有些字段明显是敏感数据，比如身份证号，手机号等信息，但是业务库并没有加密，而且从字段名来看，也很难看出是敏感信息，所以抽取到数据仓库后需要使用程序去统一检测是否有敏感数据，然后根据检测结果让对应负责人去确认是否真的是敏感字段，是否需要加密等。

　　4.流程化操作

　　流程化主要是体现在公司内部取数或者外部项目数据同步，取数的时候如果数据量很大或者包含了敏感信息，是需要提OA审批流程的，让大家知道谁要取这些数据，取这些数据的意义在哪，出了问题可以回溯，快速定位到责任人。开发外部项目的时候，不同公司之间的数据同步，是需要由甲方出具同意书的，否则的话风险太大。

　　5.敏感SQL实时审查及操作日志分析

　　及时发现敏感sql的执行并询问责任人，事后分析操作日志，查出有问题的操作。

　　6.部门重视数据安全

　　把数据安全当做一项KPI去考核，让大家积极的参与到数据安全管理当中去。

　　三

　　元数据管理及应用

　　3.1概述

　　元数据通常定义为”关于数据的数据”，元数据贯穿了数据仓库的整个生命周期，使用元数据驱动数据仓库的开发，使数据仓库自动化，可视化。元数据打通了源数据、数据仓库、数据应用，记录数据从产生到消费的全过程。

　　例如我们看一部电影，电影本身就是数据，那么元数据就是用来描述这部电影的数据。如下图所示：

　　元数据主要记录数据仓库中模型的定义、各层级间的映射关系、元数据可以帮助数据仓库管理员和开发人员非常方便地找到他们所关心的数据，用于指导其进行数据管理和开发工作，可以极大的提升工作的效率。

　　3.2元数据定义

　　将元数据按用途的不同分为两类：

　　技术元数据（TechnicalMetadata)?

　　业务元数据（BusinessMetadata）

　　监控数据仓库的数据状态及

　　ETL的任务运行状态。在数据仓库系统中，3.2.1技术元数据

　　技术元数据是存储关于数据仓库系统技术细节的数据，是用于开发和管理数据仓库使用的数据。常见的技术元数据有：

　　1.存储元数据：

　　如表、字段、分区等信息。记录了表的中英文名及表状态。分区信息、责任人信息、对应主题，文件大小、表类型，生命周期，权限信息

　　记录列的字段中英文名、字段类型、字段备注、是否是分区字段，保密级别及权限信息等信息。

　　2.运行元数据，如大数据平台上所有作业运行等信息：类似于HiveJob日志，包括作业类型、实例名称、输入输出、SQL、运行参数、执行时间，执行引擎等。

　　3.数据开发平台中数据同步、计算任务、任务调度等信息

　　包括数据同步的输入输出表和字段，以及同步任务本身的节点信息：计算任务主要有输入输出、任务本身的节点信息

　　任务调度主要有任务的依赖类型、依赖关系等，以及不同类型调度任务的运行日志等。

　　4.数据质量和运维相关元数据，如任务监控、运维报警、数据质量、故障等信息，包括任务监控运行日志、告警配置及运行日志、故障信息等。

　　3.2.2业务元数据

　　业务元数据从业务角度描述了数据仓库中的数据，它提供了介于使用者和实际系统之间的语义层，使得不懂计算机技术的业务人员也能够读懂”数据仓库中的数据。

　　常见的业务元数据有维度及属性(包括维度编码，字段类型，创建人，创建时间，状态等)、业务过程、指标(包含指标名称,指标编码，业务口径，指标类型，责任人，创建时间，状态，sql等)，安全等级，计算逻辑等的规范化定义，用于更好地管理和使用数据。数据应用元数据，如数据报表、数据产品等的配置和运行元数据。

　　3.3元数据管理

　　对于元数据管理，目前来说有三种方式可供选择。

　　3.3.1Excel手工录入保存

　　对于规模比较小，并且业务不大的公司，可能会用这种方式，但是这种方式太古老，且容易出错

　　3.3.2自研系统

　　自研元数据管理系统或者在数据平台开发元数据管理模块

　　很多公司会自研元数据管理系统或者相关模块，直接读取hive元数据或者数据平台配置的任务及调度元数据进行展示，相比较Excel人工导入，会更智能一点，但是相对于Atlas，成本更高且效果不一定有Atlas好，很多时候也需要批量导入和手工录入

　　3.3.3Atlas元数据管理(常用)Atlas是一个可伸缩且功能丰富的元数据管理系统，深度对接了

　　Hadoop大数据组件。

　　简单理解就是一个跟

　　Hadoop关系紧密的，可以用来做各类数据的元数据管理的一个软件系统；

　　atlas本身从技术上来说，就是一个典型的JAVAWEB系统，其整体结构图如下所示：

　　核心组件

　　Core?

　　Integration?

　　Metadatasource?

　　Applications

　　核心特性

　　数据分类管理

　　集中审计

　　搜索与血缘管理

　　ATLAS的使用，包含两个方面：

　　注入元数据信息到atlas中（本质是：写入元数据到atlas中）

　　注入方式?

　　注入方式1：通过atlas为数据系统开发好的hook来注入

　　2：通过atlas自带的WEB-UI来人工填写元数据信息再注入

　　注入方式3：通过在自己的数据系统中调用atlas对外暴露的api，来灵活注入

　　使用atlas中的元数据信息来为我们服务（本质是：从atlas中读、改元数据）

　　方式1：通过atlas自带的WEB-UI前端系统来查看、修改元数据

　　方式2：通过调用atlas对外暴露的api，来开发自己的管理系统

　　3.4元数据应用及价值

　　1.基于调度元数据的数据模型设计及优化--跨层引用率及复用度

　　2.基于技术元数据的数据模型设计及优化--主题覆盖率

　　3.基于技术元数据的成本优化

　　--生命周期，运行时长，资源消耗(存储，计算)

　　4.基于元数据生成的数据地图可以对整个数仓的一些表，任务有一个全面的了解，可以通过数据地图让其快速找到所需要的数据

　　5.数据血缘，追踪表血缘甚至字段血缘，可以极大的提高我们排查问题的效率

　　6.基于业务元数据，可以了解目前每个业务涉及到的维度及指标，每个指标的业务口径，指标类型，创建人及指标状态等

　　四

　　数据成本治理

　　4.1为什么要做成本治理

　　最主要的原因应该是减少企业成本，让企业走提效降本的可持续发展道路。

　　4.2目前存在的问题

　　4.2.1机器利用率低

　　比如所有任务都是在晚上跑，白天机器大部分空闲，直接导致资源浪费，利用率非常低

　　4.2.2存储周期过长，存储资源增长过快

　　有的表，大家没有设置生命周期，或者没有定时删除分区，导致分区太多，数据膨胀，存储资源需要补充

　　4.2.3成本没有量化标准

　　用阿里云服务器还好，会有实际的账单，但是如果是自己买的服务器搭建的大数据生态，可能不知道怎么去量化成本，然后做成本治理

　　4.2.4降本意识薄弱

　　数据开发或者需求方，没有成本治理的意识，满足需求后就没有进一步优化

　　4.2.5任务优化空间非常大，尤其是离线计算

　　数据开发的开发水平参差不齐，所以对于任务来说，是有非常大的优化空间的，可以从各方面取调优，比如数据倾斜，小文件，存储，压缩

　　4.3问题解决

　　4.3.1延迟启动

　　优先级比较低的任务可以设置执行时间为白天，避免晚上任务运行高峰期抢占资源，做到错峰执行

　　4.3.2任务下线

　　通过数据地图，找出无用数据或者是用频次很低的数据，跟业务方沟通后及时下线

　　4.3.3任务调优

　　数据倾斜，存储压缩，小文件优化等方面调优

　　4.3.4修改执行周期

　　很多时间，我们的任务不但有实时，t+1，甚至还会有小时任务，每小时跑一次，众所周知，这是非常占资源的，我们要和业务方，需求方取沟通，看一下没必要的小时任务是否可以转化为日任务

　　4.3.5账单排名，促进优化

　　我们可以通过每个月的成本账单，按照业务线和开发或者其他维度去做排名，督促相关人员进行优化整改

　　4.4治理效果分析

　　4.4.1总览

　　可以看一下总的成本，以及趋势

　　4.4.2topn取出排名靠前的一些业务或者开发的成本账单

　　4.4.3各业务线成本

　　按照业务线取分析成本

　　4.4.4成本明细分析

　　拆分到各个任务取分析成本

篇九：数据治理理论

　　范文

　　范例

　　指导

　　参考

　　大数据治理——为业务提供持续的、可度量的价值

　　目录

　　大数据治理——为业务提供持续的、可度量的价值....................................1概述

　　..............................................................................................................2大数据治理系列...........................................................................................2第一部分：大数据治理统一流程模型概述和明确元数据管理策略

　　......2第二部分：元数据集成体系结构

　　.........................................................15第三部分：实施元数据管理................................................................25第四部分：大数据治理统一流程参考模型的第四步到第九步............36第五部分：定义度量值和主数据监管.................................................53第六部分：大数据监管和信息单一视图监管......................................6第七部分：分析监管、安全与隐私管理和信息生命周期监管............8word版

　　整理

　　范文

　　范例

　　指导

　　参考

　　概述

　　面对我们身边每时每刻迅速增长的庞大数据，因为其数量大、速度快、种类多和准确性的特征，如何更好地利用大数据创造出有意义的价值，一直是我们探索的重要话题。而在这之前，就需要用科学正确的方法策略对大数据进行治理。大数据治理是指制定与大数据有关的数据优化、隐私保护与数据变现的政策，是传统信息治理的延续和扩展，也是大数据分析的基础，还是连接大数据科学和应用的桥梁，因此大数据治理是大数据再创高峰的“必修课”。下面我们将与您分享新鲜出炉的大数据治理方案。

　　大数据治理系列

　　本系列共分为七个部分，围绕大数据治理统一流程参考模型，并结合实际业务问题和IBM相应的产品解决方案展开叙述。

　　第一部分：大数据治理统一流程模型概述和明确元数据管理策略

　　为了更好地帮助企业进行大数据治理，笔者在IBM数据治理统一流程模型基础上结合在电信、金融、政府等行业进行大数据治理的经验，整理出了大数据治理统一流程参考模型。本文主要介绍了大数据治理的基本概念，以及结合图文并茂的方式讲解了大数据治理统一流程参考模型的前两步：“明确元数据管理策略”和“元数据集成体系结构”内容。

　　大数据治理概述

　　（狭义）大数据是指无法使用传统流程或工具在合理的时间和成本内处理或分析的信息，这些信息将用来帮助企业更智慧地经营和决策。而广义的大数据更是指企业需要处理的海量数据，包括传统数据以及狭义的大数据。（广义）大数据可以分为五个类型：Web和社交媒体数据、机器对机器（M2M）数据、海量交易数据、生物计量学数据和人工生成的数据。

　　word版

　　整理

　　范文

　　范例

　　指导

　　参考

　　Web和社交媒体数据：比如各种微博、博客、社交网站、购物网站中的数据和内容。

　　M2M数据：也就是机器对机器的数据，比如RFID数据、GPS数据、智能仪表、监控记录数据以及其他各种传感器、监控器的数据。

　　海量交易数据：是各种海量的交易记录以及交易相关的半结构化和非结构化数据，比如电信行业的CDR、3G上网记录等，金融行业的网上交易记录、corebanking记录、理财记录等，保险行业的各种理赔等。

　　生物计量学数据：是指和人体识别相关的生物识别信息，如指纹、DNA、虹膜、视网膜、人脸、声音模式、笔迹等。

　　人工生成的数据：比如各种调查问卷、电子邮件、纸质文件、扫描件、录音和电子病历等。

　　在各行各业中，随处可见因数量、速度、种类和准确性结合带来的大数据问题，为了更好地利用大数据，大数据治理逐渐提上日程。在传统系统中，数据需要先存储到关系型数据库/数据仓库后再进行各种查询和分析，这些数据我们称之为静态数据。而在大数据时代，除了静态数据以外，还有很多数据对实时性要求非常高，需要在采集数据时就进行相应的处理，处理结果存入到关系型数据库/数据仓库、MPP数据库、Hadoop平台、各种NoSQL数据库等，这些数据我们称之为动态数据。比如高铁机车的关键零部件上装有成百上千的传感器，每时每刻都在生成设备状态信息，企业需要实时收集这些数据并进行分析，当发现设备可能出现问题时及时告警。再比如在电信行业，基于用户通信行为的精准营销、位置营销等，都会实时的采集用户数据并根据业务模型进行相应的营销活动。

　　大数据治理的核心是为业务提供持续的、可度量的价值。大数据治理人员需要定期与企业高层管理人员进行沟通，保证大数据治理计划可以持续获得支持和帮助。相信随着时间的推移，大数据将成为主流，企业可以从海量的数据中获得更多的价值，而大数据治理的范围和严格程度也将逐步上升。为了更好地帮助企业进行大数据治理，笔者在IBM数据治理统一流程模型基础上结合在电信、金融、政府等行业进行大数据治理的经验，整理了大数据治理统一流程参考模型，整个参考模型分为必选步骤和可选步骤两部分。

　　word版

　　整理

　　范文

　　范例

　　指导

　　参考

　　大数据治理统一流程参考模型

　　如图1所示，大数据治理统一流程参考模型必要步骤分为两个方向：一条子线是在制定元数据管理策略和确立体系结构的基础上实施全面的元数据管理，另一条子线是在定义业务问题、执行成熟度评估的基础上定义数据治理路线图以及定义数值治理相关的度量值。在11个必要步骤的基础上，企业可以在7个可选步骤中选择一个或多个途径进行特定领域的数据治理，可选步骤为：主数据监管、（狭义）大数据监管、信息单一视图监管、运营分析监管、预测分析监管、管理安全与隐私以及监管信息生命周期。企业需要定期对大数据治理统一流程进行度量并将结果发送给主管级发起人。

　　图1大数据治理统一流程参考模型

　　第一步：明确元数据管理策略

　　在最开始的时候，元数据（MetaData）是指描述数据的数据，通常由信息结

　　word版

　　整理

　　范文

　　范例

　　指导

　　参考

　　构的描述组成，随着技术的发展元数据内涵有了非常大的扩展，比如UML模型、数据交易规则、用Java，.NET，C++等编写的APIs、业务流程和工作流模型、产品配置描述和调优参数以及各种业务规则、术语和定义等[1]。在大数据时代，元数据还应该包括对各种新数据类型的描述，如对位置、名字、用户点击次数、音频、视频、图片、各种无线感知设备数据和各种监控设备数据等的描述等。元数据通常分为业务元数据、技术元数据和操作元数据等。业务元数据主要包括业务规则、定义、术语、术语表、运算法则和系统使用业务语言等，主要使用者是业务用户。技术元数据主要用来定义信息供应链（InformationSupplyChain，ISC）各类组成部分元数据结构，具体包括各个系统表和字段结构、属性、出处、依赖性等，以及存储过程、函数、序列等各种对象。操作元数据是指应用程序运行信息，比如其频率、记录数以及各个组件的分析和其它统计信息等。

　　从整个企业层面来说，各种工具软件和应用程序越来越复杂，相互依存度逐年增加，相应的追踪整个信息供应链各组件之间数据流动、了解数据元素含义和上下文的需求越来越强烈。在从应用议程往信息议程的转变过程中，元数据管理也逐渐从局部存储和管理转向共享。从总量上来看，整个企业的元数据越来越多，光现有的数据模型中就包含了成千上万的表，同时还有更多的模型等着上线，同时随着大数据时代的来临，企业需要处理的数据类型越来越多。为了企业更高效地运转，企业需要明确元数据管理策略和元数据集成体系结构，依托成熟的方法论和工具实现元数据管理，并有步骤的提升其元数据管理成熟度。

　　为了实现大数据治理，构建智慧的分析洞察，企业需要实现贯穿整个企业的元数据集成，建立完整且一致的元数据管理策略，该策略不仅仅针对某个数据仓库项目、业务分析项目、某个大数据项目或某个应用单独制定一个管理策略，而是针对整个企业构建完整的管理策略。元数据管理策略也不是技术标准或某个软件工具可以取代的，无论软件工具功能多强大都不能完全替代一个完整一致的元数据管理策略，反而在定义元数据集成体系结构以及选购元数据管理工具之前需要定义元数据管理策略。

　　元数据管理策略需要明确企业元数据管理的愿景、目标、需求、约束和策略等，依据企业自身当前以及未来的需要确定要实现的元数据管理成熟度以及实现目标成熟度的路线图，完成基础本体、领域本体、任务本体和应用本体的构建，word版

　　整理

　　范文

　　范例

　　指导

　　参考

　　确定元数据管理的安全策略、版本控制、元数据订阅推送等。企业需要对业务术语、技术术语中的敏感数据进行标记和分类，制定相应的数据隐私保护政策，确保企业在隐私保护方面符合当地隐私方面的法律法规，如果企业有跨国数据交换、元数据交换的需求，也要遵循涉及国家的法律法规要求。企业需要保证每个元数据元素在信息供应链中每个组件中语义上保持一致，也就是语义等效（semanticequivalence）。语义等效可以强也可以弱，在一个元数据集成方案中，语义等效（平均）越强则整个方案的效率越高。语义等效的强弱程度直接影响元数据的共享和重用。

　　本体（人工智能和计算机科学）

　　本体（Ontology）源自哲学本体论，而哲学本体论则是源自哲学中“形而上学”分支。本体有时也被翻译成本体论，在人工智能和计算机科学领域本体最早源于上世纪70年代中期，随着人工智能的发展人们发现知识的获取是构建强大人工智能系统的关键，于是开始将新的本体创建为计算机模型从而实现特定类型的自动化推理。之后到了上世纪80年代，人工智能领域开始使用本体表示模型化时间的一种理论以及知识系统的一种组件，认为本体（人工智能）是一种应用哲学。

　　最早的本体（人工智能和计算机科学）定义是Neches等人在1991给出的：“一个本体定义了组成主题领域的词汇的基本术语和关系，以及用于组合术语和关系以及定义词汇外延的规则”。而第一次被业界广泛接受的本体定义出自TomGruber，其在1993年提出：“本体是概念化的显式的表示（规格说明）”。Borst在1997年对TomGruber的本体定义做了进一步的扩展，认为：“本体是共享的、概念化的一个形式的规范说明”。在前人的基础上，Stude在1998年进一步扩展了本体的定义，这也是今天被广泛接受的一个定义：“本体是共享概念模型的明确形式化规范说明”。本体提供一个共享词汇表，可以用来对一个领域建模，具体包括那些存在的对象或概念的类型、以及他们的属性和关系[2]。一个简单的本体示例发票概念及其相互关系所构成的语义网络如图2所示：

　　word版

　　整理

　　范文

　　范例

　　指导

　　参考

　　图2简单本体（发票）示例

　　随着时间的推移和技术的发展，本体从最开始的人工智能领域逐渐扩展到图书馆学、情报学、软件工程、信息架构、生物医学和信息学等越来越多的学科。与哲学本体论类似，本体（人工智能和计算机科学）依赖某种类别体系来表达实体、概念、事件及其属性和关系。本体的核心是知识共享和重用，通过减少特定领域内概念或术语上的分歧，使不同的用户之间可以顺畅的沟通和交流并保持语义等效性，同时让不同的工具软件和应用系统之间实现互操作。

　　根据研究层次可以将本体的种类划分为“顶级本体”（top-levelontology）、应用本体（applicationontology）、领域本体（domainontology）和任务本体（taskontology），各个种类之间的层次关系如图3所示。

　　word版

　　整理

　　范文

　　范例

　　指导

　　参考

　　图3本体层次关系

　　顶级本体，也被称为上层本体（upperontology）或基础本体（foundationontology），是指独立于具体的问题或领域，在所有领域都适用的共同对象或概念所构成的模型，主要用来描述高级别且通用的概念以及概念之间的关系。

　　领域本体是指对某个特定的领域建模，显式的实现对领域的定义，确定该领域内共同认可的词汇、词汇业务含义和对应的信息资产等，提供对该领域知识的共同理解。领域本体所表达的是适合自己领域的术语的特定含义，缺乏兼容性，因而在其他领域往往不适用。在同一领域内，由于文化背景、语言差异、受教育程度或意识形态的差异，也可能会出现不同的本体。很多时候，随着依赖领域本体系统的扩展，需要将不同的领域本体合并为更通用的规范说明，对并非基于同一顶级本体所构建的本体进行合并是一项非常具有挑战的任务，很多时候需要靠手工来完成，相反，对那些基于同一顶级本体构建的领域本体可以实现自动化的合并。

　　任务本体是针对任务元素及其之间关系的规范说明或详细说明，用来解释任务存在的条件以及可以被用在哪些领域或环境中。是一个通用术语的集合用来描述关于任务的定义和概念等。

　　应用本体：描述依赖于特定领域和任务的概念及概念之间的关系，是用于特定应用或用途的本体，其范畴可以通过可测试的用例来指定。

　　从详细程度上来分，本体又可以分为参考本体（referenceontologies）和共享本体（shareontologies），参考本体的详细程度高，而共享本体的详细程度低。

　　本体（哲学）

　　word版

　　整理

　　范文

　　范例

　　指导

　　参考

　　哲学中的本体（ontology）也被称为存在论，源自哲学中“形而上学”分支，主要探讨存在的本质，也就是存在的存在。英文ontology实际上就是来源于希腊文“ον”（存在）和“λ?γο?”（学科）的组合。本体是由早期希腊哲学在公元前6世纪到公元前4世纪提出的“始基”延伸出来的。始基（Principle，又称本原）最早由泰勒斯（米利都学派）最早提出来，认为万物由水而生，其学生阿那克西曼德认为万物由一种简单的原质组成，该原质不是水[3]。而毕达哥拉斯（学派）认为“万物都是数”，数不仅被看作万物的本原，而且被看作万物的原型、世界的本体。后来巴门尼德（爱利亚学派）提出了“存在”的概念，认为存在才是唯一真正存在的真理，其创造了一种形而上学论证方式，之后的哲学一直到近时期为止，都从巴门尼德处接受了其“实体的不可毁灭性”。苏格拉底继承了巴门尼德的存在概念，主张“真正的善”并完善了巴门尼德弟子芝诺的辩证法，其学生柏拉图提出了“理念论”，认为只要若干个个体拥有一个共同的名字，它们就有一个共同的理念或形式。亚里士多德（柏拉图学生）总结了先哲们的思想，完成了《形而上学》，并将本体总结为：对世界上客观存在事物的系统的描述，即存在论，也就是最形而上学的知识。形而上学不是指孤立、静止之类的意思，而是指超越具体形态的抽象意思，是关于物质世界最普遍的、最一般的、最不具体的规律的学问。

　　第二步：元数据集成体系结构

　　在明确了元数据管理策略后需要确定实现该管理策略所需的技术体系结构，即元数据集成体系结构。各个企业的元数据管理策略和元数据管理成熟度差别较大，因此元数据集成体系结构也多种多样。大体上元数据集成体系结构可以分为点对点的元数据集成体系结构、中央辐射式元数据体系结构、基于CWM（CommonWarehouseMetaModel，公共仓库元模型）模型驱动的点对点元数据集成体系结构、基于CWM模型驱动的中央存储库元数据集成体系结构、分布式（联邦式）元数据集成体系结构和层次/星型元数据集成体系结构等。

　　针对信息供应链中不同的组件，为了实现跨组件的元数据交换和集成，最开始人们采用点对点的方式进行，也就是每一对组件之间通过一个独立的元数据桥（metadatabridge）进行元数据交换，桥一般是双向的能够理解两个方向的元数据映射[4]。点对点的元数据集成体系结构帮助用户实现了跨企业的元数据集成

　　word版

　　整理

　　范文

　　范例

　　指导

　　参考

　　和元数据交换，对提升信息化水平提供了巨大帮助。这种体系结构在应用过程中，也暴露了很多问题，比如元数据桥的构建工作量和耗时都非常大，对中间件厂商、应用厂商、集成商和用户来说都是一个巨大的挑战，而且构建元数据桥还必须具有所有者的元数据模型和接口的详细信息。构建完成的桥很多时候无法在构建其他元数据桥时进行重用，因此开发和维护费用大幅度增加，用户投资回报率（ROI）不高。以动态数据仓库为例，其点对点的元数据集成体系结构具体如图4所示，信息供应链各组件之间的空心箭头表示全部的数据流，实心箭头表示不同的元数据桥和与之关联的元数据流。

　　图4点对点的元数据集成体系结构

　　通过使用中央元数据存储库（centralmetadatarepository）取代各个工具软件和应用程序之间的点对点连接方式，改成中央元数据存储库与各个工具软件和应用程序实现元数据交换的访问层（也是一种桥），可以有效降低总成本，减少建立点对点元数据桥的工作，提高投资回报率。信息供应链各组件可以从存储库访问元数据，不必与其他产品进行点对点交互。这种使用中央元数据存储库方式进行元数据集成的方式就是中央辐射式元数据体系结构（hub-and-spokemetadataarchitecture），具体如图5所示。由于特定的元数据存储库是围绕其自身的元模型、接口和交付服务建立的，所以仍需要建立元数据桥实现与ISC各组件的互相访问。

　　word版

　　整理

　　范文

　　范例

　　指导

　　参考

　　图5中央辐射式元数据体系结构

　　采用模型驱动的元数据集成方法（比如使用CWM）可以有效降低元数据集成的成本和复杂度，无论点对点元数据集成体系结构还是中央辐射式元数据集成体系结构都可以因此受益。在点对点体系结构中，通过使用基于模型的方法可以不必在每一对需要集成的产品之间构建元数据桥，每个产品只需要提供一个适配器（adapter）即可实现各个产品之间的元数据交换，适配器既了解公共的元模型也了解本产品元模型的内部实现。如图6所示，基于CWM模型驱动点对点元数据集成体系结构使用通用元模型，不再需要在各个产品间建立元数据桥，在各个产品之间通过适配器实现了语义等价性。

　　word版

　　整理

　　范文

　　范例

　　指导

　　参考

　　图6基于CWM模型驱动的点对点元数据集成体系结构

　　如图7所示，在基于模型驱动（比如CWM）的中央辐射式元数据体系结构中，中央存储库包含公共元模型和整个领域（domain）用到的该元模型的各个实例（模型）、存储库自身元模型及其实例、理解元模型（公共元模型和自身元模型）的适配器层，当然存储库也可以直接实现公共元模型的某些内部表示。

　　图7基于CWM模型驱动的中央存储库元数据集成体系结构

　　如图8所示，这种体系架构是基于CWM模型驱动的中央存储库元数据集成体系结构的一个变种，两个中央辐射式的拓扑结构通过各自的元数据存储库连接起来，也被称为分布式（Distributed）或联邦（Federated）体系结构。两个元数据存储库之间通过元数据桥连接，两个存储库使用相同的元模型和接口，也可以使用不同的元模型和接口。建立分布式元数据集成体系结构的原因有很多种，比如企业基于多个区域单独部署自己的应用，每个区域有自己的数据中心。

　　word版

　　整理

　　范文

　　范例

　　指导

　　参考

　　图8分布式（联邦式）元数据集成体系结构

　　如图9所示，这种体系结构是分布式体系结构的变体，根存储库实现了元模型的公共部分（横跨整个企业），叶子存储库实现了一个或多个特定的公共元模型子集，并只保存这些自己所对应的元数据实例。特定客户可以主要访问其感兴趣的元数据所在的叶子存储库，也可以访问其它叶子存储库和根存储库。这种体系结构被称为层次或星型拓扑结构。

　　word版

　　整理

　　范文

　　范例

　　指导

　　参考

　　图9层次或星型元数据集成体系结构

　　结束语

　　本文详细介绍了大数据治理的基本概念和统一流程参考模型，并阐述了该模型的第一步“明确元数据管理策略”和第二步“元数据集成体系结构”等内容。在第一步“明确元数据管理策略”中讲述了元数据的基本概念以及本体在人工智能/计算机科学和哲学中的含义。在第二步“元数据集成体系结构”讲述了元数据集成体系结构的六种示例，分别为：点对点的元数据集成体系结构、中央辐射式元数据体系结构、基于CWM模型驱动的点对点元数据集成体系结构、基于CWM模型驱动的中央存储库元数据集成体系结构、分布式（联邦式）元数据集成体系结构和层次/星型元数据集成体系结构。在本系列文章的下一部分将继续介绍大数据治理统一流程参考模型第二步“元数据集成体系结构”，具体包括元模型、元-元模型、公共仓库元模型（CWM）、CWM发展史、OMG的模型驱动体系结构（ModelDrivenArchitecture，MDA）。

　　参考文献

　　[1]

　　DavidFrankelConsulting,”UsingModelDrivenArchitecture?toManageMetadata”,P3;[2]

　　FredrikArvidssonandAnnikaFlycht-Eriksson,2008,OntologiesI,”Anontology

　　provideasharedvocabulary,whichcanbeusedtomodeladomain,thatis,thetypeofobjectsand/orconceptsthatexist,andtheirpropertiesandrelations”;

　　word版

　　整理

　　范文

　　范例

　　指导

　　参考

　　[3]

　　更多内容请参考:[专著]/(英)伯特兰.罗素/著孙绍武/主编<<西方哲学史>>;[4]

　　JohnPoole,DanChang,DouglasTolbertandDavidMellor,2002,CommonWarehouseMetamodel,p18-32,p180-202;[5]

　　本系列文章参考了SunilSoares编写的《TheIBMDataGovernanceUnifiedProcess》和《BigdataGovernance》书中内容?

　　第二部分：元数据集成体系结构

　　在明确了元数据管理策略后需要确定实现该管理策略所需的技术体系结构，即元数据集成体系结构。元数据集成体系结构涉及到多个概念，如元模型、元-元模型、公共仓库元模型（CWM）等，本部分将继续介绍大数据治理统一流程参考模型第二步“元数据集成体系结构”的相关内容。

　　在本系列的第一篇文章中，我们主要介绍了大数据治理的基本概念和统一流程参考模型，并阐述了该模型的第一步“明确元数据管理策略”和第二步“元数据集成体系结构”的六种示例等内容。大数据治理统一流程参考模型的第二步是“元数据集成体系结构”，具体包括元模型、元-元模型、公共仓库元模型（CWM）、CWM发展史、OMG的模型驱动体系结构（ModelDrivenArchitecture，MDA）本文将对元数据集成体系结构包含的各种模型展开叙述。

　　大数据治理统一流程参考模型，第二步：元数据集成体系结构

　　元模型（Metamodel）

　　模型（Model）是用来描述特定的系统、过程、事物或概念的准确而抽象的表示。例如软件架构师可以用概要设计的形式建立一个应用系统的模型。本质上来说，元数据是数据的形式化模型，是数据的抽象描述，该描述准确地描述了数据。元模型（Metamodel）也就是模型的模型（或者元-元数据），是用来描述元数据的模型。

　　下面基于关系型表实体-关系（ER）模型举例说明什么是元模型。如图1所示，一个简单的关系型表元模型描述了如何定义一个关系型表，规定了每个表必

　　word版

　　整理

　　范文

　　范例

　　指导

　　参考

　　须有一个名字（字符串），一个表可以有1到多个列，每个列必须有一个名字（字符串）和数据类型（字符串）：

　　图1简单关系型表元模型

　　如果要创建一个关系型表模型，基于该表元模型创建一个实例即可，比如创建一个常见的雇员表Employees表模型，具体如图2所示，Employees表包含6个列，分别是编号、姓、名字、部门编号、经理编号和职位编号。

　　图2Employees表实例

　　比如在DB2中创建employees表，可以很容易的从employees表模型中得到相应的DDL语句，执行DDL语句时DB2会生成描述employees表的内部元数据并存储在目录（DB2内部的元数据存储库）中。

　　清单1在DB2中创建employees表示例

　　Createtableemployees(Idintegernotnull，word版

　　整理

　　范文

　　范例

　　指导

　　参考

　　First_nameStringnotnull，Last_nameStringnotnull，Depart_IDIntegernotnull，Manager_IDIntegernotnull，Job_IDIntegernotnull)同样基于图1简单关系型表元模型创建另一个实例department表模型。department表包含2个列，分别是编号和部门名称，具体如图3所示。由于department表模型和employees表模型都是基于相同的公共元模型，其它工具和应用程序软件（了解关系型表的公共元模型）可以很容易理解department表和employees表，因为它们都是同一个元模型的实例。其它工具或应用程序通过调用导入映射（importmapping）将该department表模型或employees表模型翻译成自己内部的元数据实例。同样，也可以将该软件内部元数据翻译成一个与平台无关的形式化模型，也就是导出映射（exportmapping），以便其他软件使用其专有的元数据。这种基于公共元模型的集成方法就是模型驱动的元数据集成体系结构[1]。

　　图3department表实例

　　元-元模型（Meta-metamodel）

　　元-元模型就是元模型的模型，有时也被称为本体（ontology），是模型驱动的元数据集成体系结构的基础，其定义了描述元模型的语言，规定元模型必须依

　　word版

　　整理

　　范文

　　范例

　　指导

　　参考

　　照一定的形式化规则来建立，以便所有的软件工具都能够对其进行理解。

　　元-元模型比元模型具有更高的抽象级别，一个元模型是一个元-元模型的实例，元模型比元-元模型更加精细，而元-元模型比元模型更加抽象。元数据（模型）则是一个元模型的实例，遵守元模型的规定和约束。用户对象（或用户数据）则是元数据（或者称为模型）的实例。元数据层次结构具体如表1所示，共分为4层，最高层L3是元-元模型，之下是L2元模型和L1模型/元数据，最底层是L0用户对象/用户数据：

　　表1元数据层次结构

　　元层次

　　L3L2L1名称

　　元-元模型

　　元模型

　　模型/元数据

　　示例

　　元类、元属性、元操作

　　类、属性、操作、构件

　　实体-关系（ER）图

　　交易数据、ODS数据、数据仓库L0用户对象/用户数据

　　数据、数据集市数据、数据中心数据等

　　公共仓库元模型（CWM）概述

　　公共仓库元模型（CommonWarehouseMetaModel，CWM）是被对象管理组织OMG（ObjectManagementGroup）采纳的数据仓库和业务分析领域元数据交换开放式行业标准，在数据仓库和业务分析领域为元数据定义公共的元模型和基于XML的元数据交换（XMI）。CWM作为一个标准的接口，可以帮助分布式、异构环境中的数据仓库工具，数据仓库平台和数据仓库元数据存储库之间轻松实现数据仓库和业务分析元数据交换。CWM提供一个框架为数据源、数据目标、转换、分析、流程和操作等创建和管理元数据，并提供元数据使用的世系信息[2]。

　　CWM是一个基于模型驱动方法的完整地描述数据仓库和业务分析领域的元模型，提供构建元数据所需的语法和语义，由若干个不相同又紧密相关的子元模型组成。CWM模型的目的是最大限度的重用对象模型（ObjectModel，UML的一个子集），并在可能的地方共享通用模型结构。如图4所示，CWM元模型使用包（package）和层次来简化管理的复杂度并便于理解，共包含21个单独的包，word版

　　整理

　　范文

　　范例

　　指导

　　参考

　　这些包被分为5个层次。对象模型层包含定义基本元模型的概念、关系和约束的包，其它CWM包都需要用到这些定义，对象模型层的包构成了其它CWM包所需要的基本元模型服务的全部集合。对象模型层主要包括核心包（Corepackage）、行为包（Behavioralpackage）、关系包（Relationshipspackage）和实例包（Instancepackage）。

　　数据源层（DataResources）：主要描述CWM元数据交换中既可作为源又可以作为目标的数据源的结构，本层含有的元模型主要描述面向对象的数据库和应用、关系型数据库、面向记录的数据源（如文件、记录数据库管理系统等）、多维数据库和XML数据源等。对于面向对象数据源，CWM一般情况下重用基本的对象模型（位于对象模型层），如果该数据源具有对象模型层无法处理的一些特征和功能时，可以通过定义一个扩展包来解决。

　　数据分析层（DataAnalysis）：本层含有的元模型主要描述数据转换、在线分析处理OLAP、数据挖掘、信息可视化和业务术语等。

　　仓库管理层（WarehouseManagement）：本层含有的元模型主要描述数据仓库处理和数据仓库操作。

　　图4CWM1.1元模型

　　CWM1.1是在2003年3月发布的，与之相关的OMG组织规范还有MOF、UML和XMI。CWM使用统一建模语言（UML）定义公共元数据的模型（CWM元模型），使用可扩展标记语言（XML）生成CWM元数据交换规范（也就是XML元数据交换，XMI），使用CORBA接口定义语言（IDL）为访问CWM元数据生成编程语言API的规范（依赖MOF到IDL的映射）。

　　word版

　　整理

　　范文

　　范例

　　指导

　　参考

　　UML是一种规范化、可视化、描述明确、结构化和文档化的定义分布式对象系统的图形化语言。1996年，业内三种最杰出的面向对象建模语言：GradyBooch的Booch方法、IvarJacobson的面向对象软件工程（OOSE）和JimRumbaugh的对象建模技术（OMT）被统一起来发布，也就是UML0.9。2011年，UML2.4.1发布。CWM依赖于UML规范的前三个部分，即UML语义、UML符号向导和对象约束语言规范。UML语义定义UML元模型的语义，UML元模型是层次结构并以包为单位进行组织，每个包按照抽象语言（使用类图）、结构良好规则（采用OCL）和语义（采用英语）来定义。UML符号指定表达UML元模型语义的图形语法（例如类图）。对象约束语言规范定义对象约束语言（OCL）的句法、语义和语法，OCL是一种表述约束的形式化语言[3]。

　　构造块和结构良好规则：UML提供了组成构造块和结构良好规则的面向对象建模语言，基本的构造块包括模型元素（如类、对象、接口、组件、用例等）、关系（如关联、泛化、依赖等）和图（如类图、对象图、用例图等）等。

　　UML可以为一个系统进行不同方面的建模，比如结构建模（又包括使用类图和对象图的静态结构建模、使用组件图和部署图实现建模）、用例建模和行为建模等。元数据建模只需要静态结构建模，静态结构的核心元素是类、对象、属性和操作。

　　UML用包来将模型元素组织成语义上相关联的分组，每个包拥有其自己的模型元素，每个模型元素不能同时被多个包拥有。

　　UML在CWM中主要作为三种角色出现[4]：

　　1、UML作为和MOF等价的元-元模型。UML，或者部分对应MOF模型、UML符号和OCL的UML分别被用作建模语言、图形符号和约束语言，用来定义和表示CWM。

　　2、UML作为基础元模型。对象模型层（ObjectModel）与UML关系密切，是UML的一个子集。

　　3、UML用来作为面向对象元模型。

　　元对象框架（MetaObjectFramework，MOF，本文以2.4.1版本为例）是一个以独立于平台的方式定义、操作、集成元数据和数据的、可扩展、模型驱动的分布式对象集成框架。此框架支持各种类型的元数据，还可以根据需求添加新类

　　word版

　　整理

　　范文

　　范例

　　指导

　　参考

　　型的元数据。MOF包括MOF模型（定义建立元模型的建模元素和使用规则）、MOF反射接口（允许程序在不使用元模型指定接口时对元数据进行各种操作）和MOF到IDL的映射（定义MOF模型定义的元模型到CORBAIDL之间的标准映射）。MOF模型是以UML的概念和结构为基础，尤其是以UML的静态结构模型和模型管理为基础。MOF模型没有定义自己的图形符号和约束语言，而是采用UML的图形符号和OCL来实现。MOF模型也是层次结构，并以包为单位进行组织。

　　MOF支持各种类型的元数据，采用四层元数据体系结构（也就是OMG元数据体系结构）[5]，具体如表2所示，该体系架构将元数据（M1）视同为数据（M0），并对之进行形式化建模（即元模型，M2）。元模型（M2）使用元-元模型（M3）所提供的元建模结构来表示。表2表明MOF模型（元-元模型）、UML元模型、用户模型和用户对象/数据之间的关系。

　　表2MOF四层元数据体系结构

　　M3描述

　　MOF,i.e.thesetofconstructsusedtodefinemetamodelsMetamodels,consistingofinstancesofMOFconstructs.Models,consistingofinstancesofM2metamodelconstructs.示例

　　MOFClass,MOFAttribute,MOFAssociation,etc.UMLClass,UMLAssociation,UMLAttribute,UMLState,UMLActivity,etc.CWMTable,CWMColumn,etc.Class“Customer”,Class“Account”

　　Table“Employee”,Table“Vendor”,etc.CustomerJaneSmith,CustomerJoeM0Objectsanddata,i.e.instancesofM1modelconstructsJones,Account2989,Account2344,EmployeeA3949,Vendor78988,etc.XML元数据交换（XMI）是在工具软件、应用程序之间进行元数据交换的XML语言，整合了UML、MOF和XML三种技术，允许MOF元数据（即遵从MOF或基于MOF的元模型的元数据）以流或文件的形式按照XML的标准格式进行交换。XMI是OMG在元数据交换方面的标准之一，同时也是W3C认可的标准。本质上，word版

　　整理

　　M2M1范文

　　范例

　　指导

　　参考

　　XMI是W3C的XML和MOF之间，以及XML文档和MOF元数据之间的一对平行映射。2011年8月，XML发布了2.4.1。

　　CWM发展史

　　其实早在上世纪80年代末90年代初，很多企业就尝试使用一种元模型实现元数据集成以整合分布于各个业务竖井中的元数据，但最终失败了，因为很多的利益相关者各自拥有不同的观点，且需要不同的模型结构。1997年，OMG将UML采纳为标准，为CWM标准制定打下了第一个基础。同样在1997年，MOF被OMG采纳为标准，为CWM的产生打下了第二个基础。1999年初，OMG采纳XMI作为标准，为CWM的出现打下了第三个基础。1998年5月，IBM、ORACLE和Unisys向OMG提交了公共仓库元数据交换（CommonWarehouseMetadataInterchange，CWMI）征求意见稿（RFP），同年9月OMG发布了该征求意见稿，经过8个公司（IBM、Unisys、Oracle、Hyperion、UBS、NCR、Genesis和DimensionEDI）2年半的努力和协作，OMG于2001年4月正式采纳CWM为标准。

　　在CWM发展的同时，其他一些元数据标准的制定也在进行中。最早在1993年，电子信息组织就发布了计算机辅助工程数据交换格式（CASEDataInterchangeFormat，CDIF）并得到了一定的认可。1995年10月，元数据联盟（MetaDataCoalition，MDC）成立，并与1996年4月发布了元数据交换规范1.0（MetaDataInterchangeSpecification，MDIS），与CWM相比，MDIS涉及的范畴少很多，且其规范和交换语言都是自身独有的。此时微软也在和其他一些合作者一起开发开放信息模型（OpenInformationModel，OIM），该模型于1996年10月成形，采用UML作为其规范语言。1998年11月，微软加入MDC并提交OIM标准，1999年7月MDC发布了OIMv1.0版本，由此业内面临着两种元数据集成规范的竞争局面，之后考虑到业内对CWM的认可，MDC于2000年9月决定终止其OIM后续工作，将其元数据标准归入到OMG中，从此CWM影响力和范围持续扩大并得到了业内的统一认可。

　　word版

　　整理

　　范文

　　范例

　　指导

　　参考

　　OMG的模型驱动体系结构（ModelDrivenArchitecture，MDA）

　　OMG组织成立不久制定了对象管理体系结构（ObjectManagementArchitecture，OMA）参考模型，描述了OMG规范所遵循的概念化的基础结构。OMA是由对象请求代理（ObjectRequestBroker，ORB）、对象服务、公共设施、域接口和应用接口等几个部分组成，其核心是对象请求代理（ORB）。对象请求代理（ORB）是公共对象请求代理体系结构（CommonObjectRequestBrokerArchitecture，CORBA）的核心组件，提供了识别和定位对象、处理连接管理、传送数据和请求通信所需的框架结构。OMA和CORBA被定位为软件框架，用来指导基于OMG规范的技术开发。

　　从1995年开始，OMG开始非正式的采用针对特定行业（“领域”，Domain）的技术规范，为了保持扩张重点，OMG在2001年正式采用第二个框架，模型驱动体系架构（ModelDrivenArchitecture，MDA）。与OMA和CORBA不一样，MDA不是部署分布式系统的框架，而是在软件开发中基于模型驱动的方法。为了实现MDA，OMG随后制定了一系列标准如UML、MOF、XMI和CWM等，解决了MDA的模型建立、扩展、交换等几个方面的问题。模型驱动体系结构源自众所周知的和长期建立的思想：“将系统操作规范从系统利用底层平台能力的细节中分离出来”。MDA提供了一种方法（基于相关工具）来规范化一个平台独立的系统，为系统选择一个特定的实现平台，并把系统规范转换到特定的实现平台。MDA的首要三个目标是：可移植性、互操作性和可重用性。MDA三个视角（viewpoint）[6]分别是：

　　计算无关视角（ComputationIndependentViewpoint）：侧重系统环境和系统需求；系统结构和流程细节被隐藏或尚未确定。其对应的是计算无关模型（ComputationIndependentModel，CIM）。

　　平台无关视角（PlatformIndependentViewpoint）：侧重系统的操作，同时隐藏用于特定平台的必要细节。其对应的是平台无关模型（PlatformIndependentModel，PIM），PIM是抽出技术和具体工程细节之后的模型。

　　平台相关视角（PlatformSpecificViewpoint）：结合平台无关系视角和系统所使用的特定平台细节。其对应的是平台相关模型（PlatformSpecificViewpointModel，PSM），PSM是包含技术和具体工程细节的模型。

　　word版

　　整理

　　范文

　　范例

　　指导

　　参考

　　OMG模型驱动体系结构如图5所示：

　　图5OMG模型驱动体系架构

　　CWM元模型、规范以及生成的产品同MDA非常契合，从技术平台角度来说，所有的平台相关模型（CWMXML、CWMIDL和CWMJava等）都是自动地从平台无关模型（CWM元模型和规范）中产生的；从产品平台角度来说，平台相关模型（比如DB2、ORACLE、SQLSERVER等）都是人工从平台无关模型（CWM元模型和规范）中构造出来的。

　　结束语

　　本文详细介绍了大数据治理统一流程参考模型第二步“元数据集成体系结构”的后续内容，主要包括元模型、元-元模型、公共仓库元模型（CWM）、CWM发展史、对象管理组织OMG的模型驱动体系结构（ModelDrivenArchitecture，MDA）。在本系列文章的下一部分将重点介绍大数据治理统一流程参考模型的第三步：“实施元数据管理”，讲述在大数据时代如何实施元数据管理，如何使用元数据管理成熟度模型，以及IBM在元数据管理方面的产品：业务元数据管理工具IBMInfoSphereBusinessGlossary、业务词汇表小工具InfoSphereBusinessGlossaryAnywhere和技术元数据管理工具InfoSphereMetadataWorkbench。

　　word版

　　整理

　　范文

　　范例

　　指导

　　参考

　　参考文献

　　[1]

　　更多信息请参考:OMGModelDrivenArchitecture:http://www.omg.org/mda/;[2]

　　OMG,CommonWarehouseMetamodel(CWM)Specificationv1.1,P44;[3]

　　JohnPoole,DanChang,DouglasTolbertandDavidMellor,2002,CommonWarehouseMetamodel,p48-53,p58-63;[4]

　　OMG,CommonWarehouseMetamodel(CWM)Specificationv1.1,P45;[5]

　　DavidFrankelConsulting,”UsingModelDrivenArchitecture?toManageMetadata”,P46;

　　[6]

　　OMG,2003,MDAGuideVersion1.0.1,p11-12,P15-16;第三部分：实施元数据管理

　　了解了元数据管理策略和元数据集成体系结构之后，企业可以根据需要选择合适的业务元数据和技术元数据管理工具，并制定相应的元数据管理制度进行全面的元数据管理。本部分主要介绍大数据治理统一流程参考模型第三步“实施元数据管理”，元数据管理成熟度模型、IBM元数据管理相关工具等内容。

　　第三步：实施元数据管理

　　在明确了元数据管理策略和元数据集成体系结构之后，企业可以根据需要选择合适的业务元数据和技术元数据管理工具，并制定相应的元数据管理制度进行全面的元数据管理。比如可以使用

　　IBMInfoSphereBusinessGlossary进行业务元数据的管理，使用

　　IBMInfoSphereMetadataWorkbench作为元数据管理统一工具并进行图形化的元数据分析。

　　大数据扩大了数据的容量、速度和多样性，给元数据管理带来了新的挑战。在构建关系型数据仓库、动态数据仓库和关系型数据中心时进行元数据管理，有助于保证数据被正确地使用、重用并满足各种规定。同样，对大数据来说，元数据管理过程中出现的任何错误，都会导致数据重复、数据质量差和无法访问关键信息等问题[1]。随着大数据技术在企业中的应用越来越广泛，企业需要在原有的元数据管理策略中增加大数据相关的内容。通常，大数据分析是受用例驱动的，企业可以通过梳理大数据用例的方式逐步完善大数据的元数据管理。

　　针对大数据的业务元数据，依旧可以通过构建基础本体、领域本体、任务本

　　word版

　　整理

　　范文

　　范例

　　指导

　　参考

　　体和应用本体等的方式来实现。通过构建基础本体，实现对级别且通用的概念以及概念之间关系的描述；通过构建领域本体，实现对于领域的定义，并确定该领域内共同认可的词汇、词汇业务含义和对应的信息资产等，提供对该领域知识的共同理解；通过构建任务本体，实现任务元素及其之间关系的规范说明或详细说明；通过构建应用本体，实现对特定应用的概念描述，其是依赖于特定领域和任务的。这样就通过构建各种本体，在整个企业范围提供一个完整的共享词汇表，保证每个元数据元素在信息供应链中每个组件的语义上保持一致，实现是语义等效。

　　为了实现信息供应链中各个组件元数据的交互和集成，大数据平台的元数据集成体系结构依然可以采用基于模型驱动的中央辐射式元数据体系结构。对大数据平台中的结构化数据的元数据管理可以遵循公共仓库元模型（CWM）构建元数据体系结构，以便方便的实现各个组件间元数据的交互；对大数据平台中的半结构化和非结构化数据的元数据管理，因为业内还没有通用的公共元模型，企业可以尝试采用基于自定义模型驱动的方式构建中央辐射式元数据体系结构。

　　简单来说，企业可以尝试以下步骤进行大数据的元数据管理：

　　1、考虑到企业可以获取数据的容量和多样性，应该创建一个体现关键大数据业务术语的业务定义词库（本体），该业务定义词库不仅仅包含结构化数据，还可以将半结构化和非结构化数据纳入其中。

　　2、及时跟进和理解各种大数据技术中的元数据，提供对其连续、及时地支持，比如

　　MPP数据库、流计算引擎、ApacheHadoop/企业级

　　Hadoop、NoSQL数据库以及各种数据治理工具如审计/安全工具、信息生命周期管理工具等。

　　3、对业务术语中的敏感大数据进行标记和分类，并执行相应的大数据隐私政策。

　　4、将业务元数据和技术元数据进行链接，可以通过操作元数据（如流计算或

　　ETL工具所生成的数据）监测大数据的流动；可以通过数据世系分析（血缘分析）在整个信息供应链中实现数据的正向追溯或逆向追溯，了解数据都经历了哪些变化，查看字段在信息供应链各组件间转换是否正确等；可以通过影响分析可以了解具体某个字段的变更会对信息供应链中其他组件中的字段造成哪些影响等。

　　word版

　　整理

　　范文

　　范例

　　指导

　　参考

　　5、扩展企业现有的元数据管理角色，以适应大数据治理的需要，比如可以扩充数据治理管理者、元数据管理者、数据主管、数据架构师以及数据科学家的职责，加入大数据治理的相关内容。

　　在实施元数据管理的过程中，可以参照元数据管理的成熟度模型确定企业当前元数据管理所在层次，并根据业务需要制定路线图实现元数据管理水平的提升。元数据管理成熟度模型具体如图1所示：

　　图1元数据管理成熟度模型

　　根据元数据管理的成熟度，大体可以分成6个级别，具体如图1所示：

　　L0:初始状态

　　元数据分散于日常的业务和职能管理中，由某个人或某一组人员在局部产生或获取，并在局部使用，其他人如果想获得该元数据需要找到相应的人进行沟通获取。

　　L1:从属于业务系统

　　在这个阶段，随着各个业务系统自动化构建完成，相应的元数据也随着需求整理、设计、开发、实施和维护等过程被各个业务系统孤立的全部或部分管理起来。业务元数据可能分散在各种业务规章、流程规定、需求、需求分析和概要设计等文档以及业务系统中，技术元数据可能分散在详细设计、模型设计和部署方

　　word版

　　整理

　　范文

　　范例

　　指导

　　参考

　　案等各种文档和各种中间件以及业务系统中。由于各个业务系统处于一个个竖井之中，元数据之间互通互联困难，如果需要获取其他系统的元数据，除了调阅各种文档外，对分散在各种中间件和业务系统中的技术元数据需要通过桥（bridge）的方式实现互通互联。

　　L2：元数据统一存储

　　元数据依然在局部产生和获取，但会集中到中央存储库进行存储，业务元数据会手工录入到中央存储库中，技术元数据分散在文档中的部分也通过手工录入到中央存储库中，而散落在各个中间件和业务系统中的技术元数据则通过桥（bridge）的方式被读取到中央存储库中。业务元数据和技术元数据之间全部或部分通过手工方式做了关联。中央存储库的构建，使得元数据在整个企业层面可被感知和搜索，极大地方便了企业获取和查找元数据。缺点是，元数据仍然在各业务系统上维护，然后更新到中央存储库，各业务竖井之间仍然使用不同的命名法，经常会造成相同的名字代表不同意义的事情，而同一件事情则使用了多个不同的名字，有些没有纳入业务系统管理的元数据则容易缺失。元数据没有有效的权限管理，局部元数据更改后也不自动通知其他人。

　　L3:元数据集中管理

　　在L2的基础上做了改进，增强了元数据的集中控制，局部业务单元或开发小组如不事先通知其他人，将无法对元数据进行修改。局部元数据的修改完成后将被广播给其他人。和其他中间件和应用系统的交互，仍然通过桥（bridge）的方式进行，中央存储库中的业务元数据和技术元数据之间还是通过手工方式进行映射。

　　L4：元模型驱动管理

　　在L3的基础上，通过构建元模型以及元元模型，优化各业务单元之间的各种冲突和各种副本，创建、管理和共享业务词汇表和分类系统（基于主题领域的层次结构）。业务词汇表（业务元数据）包含与企业相关的词汇、词汇业务含义以及词汇与信息资产（技术元数据）的关系，可以有效帮助企业用户了解其业务元数据和技术元数据对应的业务含义。分类是基于主题领域的层次结构，用以对业务术语归类。和其他中间件和应用系统的交换，通过基于CWM的适配器方式进行连接。

　　word版

　　整理

　　范文

　　范例

　　指导

　　参考

　　L5:元数据管理自动化

　　在L5元数据管理是高度自动化的，当逻辑层次元数据变更时，会被传播到物理层次，同样物理层次变更时逻辑层次将被更新。元数据中的任何变化将触发业务工作流，以便其他业务系统进行相应的修改。由于各个业务系统遵照相同的业务词汇表和分类系统（元模型），他们之间的关系可以通过知识本体进行推断，因此各个应用系统之间的数据格式的映射自动产生。

　　IBMInfoSphereInformationServer元数据管理组件介绍

　　IBMInfoSphereInformationServer可以帮助组织从分散在其系统中的各种复杂信息中获取更多价值。它让组织能够整合分散的数据，在需要的地方和时间，按顺序和关联关系把可信的信息交付给特定的人员、应用程序和流程。InfoSphereInformationServer帮助业务人员和

　　IT人员进行协作，理解来自任何来源的任何类型的信息的含义、结构和内容。它可以显著提高在整个企业内一致且安全地清理、转换和交付信息的生产力和效率，这样就可以以新的方式访问和使用信息，从而促进创新、提高运营效率并降低风险。InfoSphereInformationServer让客户可以跨分析、运营和事务环境应用一致的可重复的流程以解决企业级数据问题，不受数据量、复杂性或延迟的限制。InfoSphereInformationServer的每个核心产品可以作为集成平台的一部分使用，也可以作为单独的集成产品使用。

　　这些产品由一个全面的集成服务平台支持，提供全程数据集成、元数据管理、任何数据源与任何平台上的任何应用程序之间的连接以及通过并行处理技术无限制地扩展。可以按任何配置部署这些功能以支持事件驱动或按时间表执行的处理。还可以通过

　　InfoSphereInformationServicesDirector交付基础设施“随需”使用

　　InfoSphereInformationServer数据集成功能，从而补充

　　EnterpriseApplicationIntegration(EAI)、BusinessProcessManagement(BPM)、EnterpriseInformationIntegration(EII)和

　　ApplicationServers集成基础设施。

　　InfoSphereInformationServer提供一个全面的模块化解决方案，可以根据业务需求和客户预算扩展。客户既可以部署完整的InfoSphereInformationServer以处理整个企业数据集成生命周期，也可以使用单独的集成产品并根据需要添加其他组件。这种灵活的方式让客户既可以通过完整的InfoSphereInformation

　　word版

　　整理

　　范文

　　范例

　　指导

　　参考

　　Server实现全面集成，也可以通过购买一个或更多组件的许可证实现部分集成，以后可以添加其他组件以创建单一的集成解决方案。InfoSphereInformationServer可以提高从事数据集成项目的开发团队的生产力，改进这些开发团队之间以及开发人员与提出需求的业务用户之间的协作，促进项目团队内部和之间的重用，这些都会产生价值。为

　　SAP、Oracle、PeopleSoft、Siebel、SalesForce.com等公司的企业应用程序预先构建的接口扩展了

　　InfoSphereInformationServer的功能范围。这些包帮助公司通过企业数据仓库或

　　ERP厂商业务智能化解决方案集成来自这些企业应用程序的数据，构建分析解决方案。

　　InfoSphereInformationServer提供一套统一的可单独购买的产品模块

　　(即套件组件)，可以解决多种类型的业务问题。可以跨项目重用信息检验、访问和处理规则，这会提高一致性、增强对数据的管控并提高

　　IT项目的效率。

　　IBMInformationServer让企业能够实现

　　5种关键的集成功能：

　　连接任何数据或内容，无论它驻留在什么地方：大型机或分布式系统，内部或外部；

　　了解并分析信息，理解数据源的内容、质量和结构，从而在整个企业中集成和传播数据之前全面了解数据；

　　清理数据，确保数据的质量和一致性，让公司可以访问任何个人或业务实体及其关系的权威且一致的视图；

　　转换大量数据，从而有效且高效地从原数据源向目标提供丰富的有针对性的信息；

　　交付数据，让人员、流程和应用程序可以像访问单一资源一样访问和集成不同类型的数据和内容，无论信息驻留在什么地方。

　　这些功能的基础是一个共用的元数据和并行处理基础设施，它为整个平台提供支持和自动化。产品组合中的每个产品还可以连接许多数据和内容源，能够通过多种机制交付信息。另外，可以通过便于发布的共享服务在面向服务架构中使用这些功能。IBMInformationServer提供：

　　最广泛的访问信息源的能力；

　　最全面的集成功能，包括联合、ETL、内联转换、复制和事件发布；

　　word版

　　整理

　　范文

　　范例

　　指导

　　参考

　　在使用这些功能的方式方面的灵活性，包括支持面向服务架构、事件驱动的处理、按时间表执行的批处理以及

　　SQL和

　　Java等标准

　　API平台的功能广度和灵活性让它能够解决许多类型的业务问题，满足许多类型的项目的需求。这可以增加重用的机会，加快项目的速度，提高信息的一致性，增强信息治理。

　　IBMInfoSphereInformationServer由以下组件组成:?

　　元数据服务

　　InfoSphereBusinessGlossaryInfoSphereBusinessGlossaryAnywhereInfoSphereMetadataWorkbenchInfoSphereInformationAnalyzerIBMInformationServerFastTrackInfoSphereQualityStageInfoSphereDataStageInfoSphereInformationServicesDirectorInfoSphereChangeDataDeliveryforInformationServerInfoSphereFederationServer元数据服务是

　　IBMInformationServer所基于的平台的组成部分。可以通过使用元数据服务访问数据以及完成分析、建模、清理和转换等数据集成任务。IBMInformationServer的主要元数据服务组件是

　　InfoSphereBusinessGlossary、InfoSphereMetadataServer以及

　　InfoSphereMetaBrokers和桥。

　　InfoSphereBusinessGlossary是一个基于

　　web的交互式工具，可以帮助用户创建、管理和共享业务词汇表和分类系统。业务词汇和技术信息资产保持一致可以促进业务和

　　IT群体的协作，有助于更有效地治理数据。另外，这个工具的数据专员功能可以提升责任感，支持数据治理策略。

　　InfoSphereMetadataWorkbench允许以基于

　　web的方式查看

　　IBMInfoSphereInformationServer和其他第三方应用程序生成和使用的信息资产。这个浏览工具可以提高对最重要的信息的信任程度。另外，InfoSphereMetadataWorkbench向

　　IT人员提供健壮的查询功能和全面且灵活的数据世系报告，让他

　　word版

　　整理

　　范文

　　范例

　　指导

　　参考

　　们可以深入了解环境中使用的数据，还可以监视数据集成活动。在处理数据集成项目中的变动时，强大的影响分析工具可以帮助数据分析师和开发人员做出更好的决策。

　　InfoSphereBusinessGlossary介绍

　　BusinessGlossary是用来管理和展示企业业务元数据的基于

　　Web的交互式工具，支持用户创建、管理和共享业务词汇表和分类系统（基于主题领域的层次结构）。业务词汇表（业务元数据）包含与企业相关的词汇、词汇业务含义以及词汇与信息资产（技术元数据）的关系，可以有效帮助企业用户了解其业务元数据和技术元数据的对应的业务含义。BusinessGlossary可以使所有用户协同管理业务元数据比如元数据定义、同义词、样例和分类等，并提供多种查询方式，比如报表、条件查询、影响分析等。

　　元数据应该由了解信息资产对业务的意义和重要性的人员进行管理。InfoSphereBusinessGlossary设计用于协作授权，使用户能够共享关于数据的见解和体验。产品为用户提供关于数据资源的以下信息：

　　数据的商业意义和说明；

　　数据和流程的管家；

　　保证的业务等级；

　　获准使用的术语；

　　用户可根据可控词汇表定义的语义来组织并查找

　　InfoSphereBusinessGlossary，您可使用

　　Web控制台来创建可控词汇表。IBMBusinessGlossary业务术语管理分类如图2所示，通过业务术语管理可以实现：

　　定义权威性的含义；

　　增加对整个企业机构的业务理解；

　　建立职责和可追溯的制度；

　　描绘业务层次；

　　记录业务描述，例如缩写和同义词；

　　查找相关的信息资产；

　　鼓励使用、重用和更正业务术语；

　　word版

　　整理

　　范文

　　范例

　　指导

　　参考

　　让

　　IT与业务目标更有效地结合；

　　提供业务内容与

　　IT资产的对应联系；

　　建立职责和数据管控的政策。

　　图

　　2IBMInfoSphereBusinessGlossary业务术语管理分类

　　通过使用

　　BusinessGlossary解决方案可以帮企业带来很多价值，比如：

　　获取业务术语并进行分类，基于

　　Web的业务元数据生成、管理和共享；

　　把业务术语及其分类与

　　IT资产关联，为信息技术资产提供业务环境；

　　识别数据使用者让业务术语可被访问，让每个用户可立刻访问有内涵的信息；

　　让

　　IT项目向数据管理看齐，创建和管理业务术语及关系，同时链接到物理数据源。

　　加强业务与

　　IT人员的通力合作，确立责任和义务，使

　　IT部门的工作与业务部门的目标保持一致。

　　BusinessGlossary与

　　InformationServer其他组件以及第三方产品交互如图

　　3所示，BusinessGlossary负责对业务元数据进行管理，MetadataServer作为中央共享元数据库负责存储业务、技术和操作元数据，InformationServer组件的各种开发和运行元数据将会自动存储在

　　MetadataServer中，通过

　　import/exportmanager还可以将第三方各种元数据与

　　MetadataServer进行元数据交互，MetadataServer还支持导入

　　CSV、XML、Glossaryarchive和

　　InfoSphereDataArchitect等内容。MetadataWorkbench允许用户浏览、分析和管理在

　　MetadataServer中的元数据并为企业用户提供信息供应链全程的数据流报告、数据沿袭和

　　word版

　　整理

　　范文

　　范例

　　指导

　　参考

　　依赖性分析等。InformationServer其他组件（如

　　FastTrack/InformationAnalyzer/InfoSphereDataArchitect等）可以直接访问

　　MetadataServer获取元数据，DataStage和

　　QualityStage可以通过

　　DataStageConnectors访问

　　MetadataServer。如右下方所示，访问业务元数据的方法有多种，可以通过

　　BusinessGlossary浏览器浏览和搜索词汇表，可以通过

　　BusinessGlossaryAnywhere客户机浏览词汇表内容并支持屏幕取词功能，可以通过

　　BusinessGlossaryRESTAPI（RepresentationalStateTransfer应用程序编程接口）编写自己的程序来访问和修改业务词汇表内容，还可以通过

　　BusinessGlossaryClientforEclipse插件让基于

　　Eclipse的应用程序直接访问词汇表内容。BusinessGlossary还支持与

　　CognosBI和

　　IBMIndustryModels等集成。

　　图

　　3元数据管理体系结构图

　　InfoSphereBusinessGlossaryAnywhere介绍

　　IBMInfoSphereBusinessGlossaryAnywhere可以从在

　　MicrosoftWindows计

　　word版

　　整理

　　范文

　　范例

　　指导

　　参考

　　算机上打开的任何文本文件直接访问业务词汇表。另外，InfoSphereBusinessGlossaryAnywhere附带

　　IBMInfoSphereBusinessGlossaryClientforEclipse和

　　IBMInfoSphereBusinessGlossaryRESTAPI。

　　通过使用

　　IBMInfoSphereBusinessGlossaryAnywhere，用户可以在执行其他基于计算机的任务的同时搜索业务词汇表，不会丢失上下文或分散注意力。用户可以通过鼠标或键盘操作在

　　MicrosoftWindows桌面上打开的文档中捕捉单词或短语，然后在业务词汇表内容中搜索它。用户不必另外打开并登录

　　InfoSphereBusinessGlossary，就可以使用大多数业务词汇表信息。

　　InfoSphereMetadataWorkbench介绍

　　IBMInfoSphereMetadataWorkbench是基于

　　Web界面的元数据管理工具，对

　　MetadaServer中的业务元数据和技术元数据提供完整的管理并提供元数据的完整视图，提供多种元数据导入导出功能。InfoSphereMetadataWorkbench可以在整个数据集成项目中跟踪和维护信息的关系，从而提高

　　IT对业务人员的透明性和

　　IT的响应能力。使用

　　InfoSphereInformationServer产品中不同的模块用户，可以通过

　　InfoSphereMetadataWorkbench查看

　　InfoSphereInformationServer元数据存储库中的元数据和数据资产。MetadataWorkbench可以提供丰富的元数据分析，为整个信息供应链的元数据提供全程的数据流报告，提供基于字段或作业的数据沿袭（也就是数据世系分析或血缘分析）、影响分析和系统相关性分析等。例如某电信公司在前端展示工具

　　CognosReportStudio中展示的掉话率指标明显和实际不符，可以通过

　　MetadataWorkbench使用血缘分析上溯到数据源（数据仓库、ODS、ETL、网管系统、EOMS）并图形化的显示出该路径上的所有对象，方便查找在哪个环节出现问题。

　　数据流报告显示数据从最开始的业务系统（粒度到列级别）、复制、ETL、ODS或数据仓库到前端展示报告或

　　Dashboad完整的转移路径，包括其中对数据执行的处理的类型等。数据流报告方便业务人员了解信息的起源以及具体的转移过程，有助于进行数据世系分析，满足法律遵从性和可审计性需求。比如可以方便的找出前端展示报告中的某个字段的来源，某个

　　Datastage作业将数据移动到什么位置等。数据世系分析可以跟踪整个企业的数据流（即便数据没有保存在

　　Metadata

　　word版

　　整理

　　范文

　　范例

　　指导

　　参考

　　Server中），可以通过创建扩展映射和扩展数据源来跟踪数据流，为数据流中的任何资产创建扩展的数据世系分析报告。

　　结束语

　　本文详细介绍了大数据治理统一流程参考模型的第三步：“实施元数据管理”，并详细讲述了在大数据时代如何实施元数据管理，随后介绍了元数据管理成熟度模型，帮助企业可以参考该模型衡量自己当前元数据管理水平，最后简单介绍了

　　IBM在元数据管理方面的产品：业务元数据管理工具

　　IBMInfoSphereBusinessGlossary、业务词汇表小工具

　　InfoSphereBusinessGlossaryAnywhere和技术元数据管理工具

　　InfoSphereMetadataWorkbench。在本系列文章的下一部分将重点介绍大数据治理统一流程参考模型第四步“定义业务问题”、第五步“获得主管支持”、第六步“执行成熟度评估”、第七步“构建路线图”、第八步“建立组织蓝图”和第九步“了解数据”等内容，并继续介绍

　　IBM信息服务器中的InfoSphereInformationAnalyze、InfoSphereFederationServer、InfoSphereReplicationServer和

　　InfoSphereChangeDataCapture等。InfoSphereInformationAnalyze是一款数据质量分析工具软件，用来在项目初期对数据源进行数据质量分析，以便真正地了解源数据的结构、质量和数据分布等，提早发现数据的缺失、错误、重复和不一致等问题，为后面的数据复制、ETL等过程提供支持，以便降低项目实施风险。

　　参考文献

　　[1]

　　SunilSoares,“BigDataGovernance”,Part7；

　　[2]

　　本章参考了

　　IBM相关产品的信息中心、白皮书、方案建议书以及其他各种资料。

　　第四部分：大数据治理统一流程参考模型的第四步到第九步

　　如果想要成功地实施大数据治理计划，需要了解信息供应链中的各个环节的数据模型、主外键关系等。本部分主要介绍大数据治理统一流程参考模型第四步“定义业务问题”、第五步“获得主管支持”、第六步“执行成熟度评估”、第七步“构

　　word版

　　整理

　　范文

　　范例

　　指导

　　参考

　　建路线图”、第八步“建立组织蓝图”和第九步“了解数据”等内容。

　　第四步：定义业务问题

　　如何准确的定义和描述业务问题是数据治理计划成功的关键，企业可以从对特定问题或领域进行数据治理的紧迫程度以及数据治理能够带来的价值来综合衡量，对排名靠前的问题或领域优先进行数据治理，这样能充分获得业务职能部门以及

　　IT部门的支持，从而保证数据治理计划的成功。数据治理初始范围确定后，执行具体的数据治理工作，等成功后再考虑扩展至其他领域。

　　总结以往很多企业进行数据治理失败的原因时可以发现很多经常出现的症状，比如：

　　企业未从数据治理中获得任何价值；

　　数据治理过于长期，和企业专注短期目标不符；

　　IT部门应对数据质量负责；

　　IT部门认为数据治理过于复杂，无法顺利落地；

　　企业为数据管理员分配了其他职责。

　　分析以上问题出现的根源，可以发现数据治理计划失败的根本原因在于与业务价值缺乏关联，IT部门独自进行数据治理，没有和相关业务部门进行联动。数据治理需要所有利益相关方参与，可以从业务角度（而不是技术角度）总结出各种数据治理的价值，从而吸引相关业务领域高层领导的支持，从而保证数据治理可以获得更高的业务收益。举例说明如何定义业务问题，很多上市公司财报都被监管机构要求提供其数据来源并证明其数据可信，而报告本身所使用的数据流经信息供应链多个组件（如立方体、数据集市或数据仓库、ODS、ETL、数据源等）并在各个组件间进行特定转换，如果没有方便易用的数据沿袭分析，公司无法准确向监管机构描述其数据来源，如果没有严格的审计分析报告（记录数据都经过哪些访问和变更），公司无法向监管机构证明其数据可信。另外，安全与隐私同样是企业关注的重点，比如如何保护个人可标识信息（PII），如何限定对敏感信息的访问等。

　　word版

　　整理

　　范文

　　范例

　　指导

　　参考

　　第五步：获得主管支持

　　数据治理计划获得主管支持至关重要，通常需要创建虚拟数据治理工作团队、获取来自

　　IT部门和业务部门内部高级管理层的支持以及识别数据治理的所有者等子步骤。

　　创建虚拟数据治理工作团队：通过跨部门的虚拟数据治理团队解决各个业务条块各自关心的业务问题。

　　获取来自

　　IT部门和业务部门内部高级管理层的支持：越早越频繁地引入利益相关方参与并获取利益相关方高层的支持，数据治理计划越容易成功。

　　识别数据治理的所有者：数据治理可以根据业务条块单独进行以及跨业务部门（需要业务部门和

　　IT部门参与）统一进行。按业务条块单独进行的好处是业务部门非常熟悉其业务问题可以快速上手，缺点是难以解决跨业务条块的数据治理问题。跨业务部门统一进行数据治理的好处是可保证整个企业数据治理的一致性，缺点是协调工作比较多，进展不如按业务条块快速。同时越来越多的企业倾向于委任数据治理的综合所有者进行统一的数据治理协调和管理，该所有者可能是首席信息安全官（CISO）、首席信息官（CIO）、首席风险官（CRO）、首席合规官（CCO）和首席隐私官（CPO）等，也可能是全职的首席数据官（CDO）。

　　第六步：执行成熟度评估

　　根据能力成熟度模型（CMM）提供的分类方法，成熟度可以分为

　　5个等级，1级为初始级，此时流程通常是临时的，整体环境不够稳定；2级为受管级，成功是可重复发生的，但可能无法针对组织中所有项目重复流程，存在基本的项目管理和流程规则，但仍有超出预期成本和时间的风险；3级为定义级，建立了标准流程集，通过组织的标准流程集定制标准、流程描述和项目过程，以适应特定项目或组织单位；4级为定量管理级，对流程进行定量度量和控制，所选的子流程大大提高了整体流程绩效；5级为优化级，在该级明确了组织的定量流程改进目标，并不断优化以适应变化的业务目标。

　　IBM数据治理成熟度模型如图

　　1所示，共包含

　　11个类别来度量数据治理

　　word版

　　整理

　　范文

　　范例

　　指导

　　参考

　　能力，分别隶属于四个相互关联的组

　　[1]。

　　成果（Outcomes）：数据治理计划预期结果，通常致力于降低风险和提升价值等，而降低成本和提高收入反过来又促进了实现这些结果。

　　数据风险管理及合规性（DataRiskManagement&Compliance）：确定数据治理与风险管理关联度，用来量化、跟踪、避免或转移风险等。

　　价值创造（ValueCreation）：确定数据资产是否帮助企业创造更大价值。

　　支持条件（Enablers）：

　　组织结构和意识（OrganizationalStructures&Awareness）：主要用来评估企业针对数据治理是否拥有合适的数据治理委员会、数据治理工作组和全职的数据治理人员，是否建立了数据治理章程以及高级主管对数据的重视程度等。

　　管理工作（Stewardship）：是指质量控制规程，用来管理数据以实现资产增值和风险控制等。

　　策略（Policy）：为企业如何管理数据在高级别指明方向。

　　核心规程（CoreDisciplines）：

　　数据质量管理（DataQualityManagement）：主要指用来提高数据质量，保证数据准确性、一致性和完整性的各种方法。

　　信息生命周期管理（InformationLifecycleManagement）：主要指对结构化、半结构化以及非结构信息化全生命周期管理相关的策略、流程和分类等。

　　信息安全与隐私（InformationSecurityandPrivacy）：主要指保护数据资产、降低风险的各种策略、实践和控制方法。

　　支持规程（SupportingDisciplines）：

　　数据架构（DataArchitecture）：是指系统的体系结构设计，支持向适当用户提供和分配数据。

　　分类与元数据（ClassificationandMetadata）：是指用于业务元数据和技术元数据以及元模型、存储库创建通用语义定义的方法和工具。

　　审计信息记录与报告（AuditInformationLoggingandReporting）：是指与数据审计、内部控制、合规和监控超级用户等有关的管理流程。

　　word版

　　整理

　　范文

　　范例

　　指导

　　参考

　　图1IBM数据治理成熟度模型

　　IBM数据治理成熟度模型框架提供了衡量当前状态和未来状态之间差距的参考，比如某用户其数据治理成熟度评估结果如图

　　2所示，成熟度级别与能力成熟度模型一一对应。

　　图2数据治理成熟度评估示例

　　word版

　　整理

　　范文

　　范例

　　指导

　　参考

　　第七步：构建路线图

　　路线图是关于人员、流程和技术方案的短期和中长期计划，通常，企业需要制定未来

　　1到

　　2年数据治理计划的路线图。根据数据治理成熟度的评估结果（11类数据治理成熟度的当前状态）以及与未来目标的差距，列出弥补这些差距所需要关键人员、流程和技术计划并根据计划的优先级制定路线图。随着大数据对企业越来越重要，信息治理计划需要将大数据纳入路线图之中。

　　第八步：建立组织蓝图

　　企业需要组建具有足够权限的数据治理组织架构以便可以贯穿整个企业各个业务、技术和管理部门对整个信息供应链进行治理。针对大数据治理计划，企业需要明晰大数据治理的目标和关键流程图，以识别大数据治理中的利益攸关者，酌情任命大数据主管并确定新增角色和现有角色的适当组合，确定各个角色应当承担的大数据责任。当企业的数据治理计划相对成熟时，就会有很多确定的角色如首席信息官（CIO）、首席信息安全官（CISO）、首席隐私官（CPO）、首席数据官（CDO）、信息治理主管和数据主管等，企业需要明确这些已经存在的角色是否可以承担大数据治理职责，还是需要设立新的大数据角色，二者都可以，企业可以根据自己的情况进行选择。比如很多企业特别是金融机构都会设有首席数据官（CDO），负责制定企业的信息治理计划，保证整个企业层面的信息可信度，很多时候首席数据官也会将大数据纳入其职责范围。

　　建立组织蓝图总共包括以下步骤：

　　1、定义数据治理章程：描述数据治理主要目标和关键流程图、关键利益相关方、角色、职责、决策权和成功的度量方式等。

　　2、定义数据治理的组织结构：通常建议在三层模式运行数据治理效果最佳，顶层为数据治理委员会（包括高级利益相关方），中间是数据治理工作组（包括负责定期治理数据的成员），底层是数据管理员工作组（负责数据的日常处理）。

　　3、建立数据治理委员会：由数据治理计划的主管发起人组成，该委员会负责数据治理的愿景和目标、并协调企业内各部门，掌控数据治理计划的总方向。该委员会可能包含首席信息官（CIO）、首席信息安全官（CISO）、首席风险官（CRO）、word版

　　整理

　　范文

　　范例

　　指导

　　参考

　　首席合规官（CCO）、首席隐私官（CPO）和首席数据官（CDO），还可能包括来自财务、法律、HR团队以及各业务部门的代表等。

　　4、建立数据治理工作组：主要负责数据治理计划的日常运作并负责监督数据管理员工作组，该组组长通常由数据治理委员会成员兼任，如果存在首席数据官（CDO）常常会由该角色担任。

　　5、确定数据管理员：数据管理员负责处理每天具体的问题和事物。

　　6、定期召开数据监管委员会和工作组会议。

　　第九步：了解数据

　　想要成功地实施大数据治理计划，需要了解信息供应链中的各个环节的数据模型、主外键关系、数据分布情况、数据源之间的数据沿袭和转换逻辑等。针对狭义大数据，可以根据用例的实际情况详细了解该用例中信息供应链各个环节的详细情况，具体实施第九步了解数据时可以通过使用

　　IBMInformationServer相关组件减少工作量，提高工作效率。

　　InfoSphereInformationServerV9.1（以下简称

　　IIS）主要用来帮助企业实现数据集成并构建健壮的信息架构，其由多个产品模块组成，这些模块可以一起部署也可以单独部署。IIS提供了全方位数据整合的功能，使信息能够在企业内跨不同系统实现无缝共享。如图

　　3所示，IIS主要实现的功能有：了解、清理、变换、交付和执行统一元数据管理：

　　了解数据：IIS可以帮助您自动发现信息内容和结构，并对其进行建模、定义和监管，以帮助您了解和分析信息的含义、关系和继承。通过

　　IIS可以更好的了解数据源和关系，并定义业务规则来消除使用火扩散错误数据的风险。

　　清理数据：IIS通过对数据执行标准化、验证、匹配和合并操作，支持信息质量和一致性管理。该平台通过匹配数据源之间或数据源内的记录，可以帮助您创建一个全面而准确的信息视图。

　　将数据转换为信息：IIS转换并整合信息，确保其具有正确的含义，通过

　　ETL（抽取，转换和装入）提供大容量的复杂数据转换和移动能力，根据需要可以提供批处理或实时数据处理。

　　word版

　　整理

　　范文

　　范例

　　指导

　　参考

　　交付信息：IIS允许对信息进行虚拟化和同步，允许转换规则发布为

　　service并被多个应用部署和复用，支持

　　SOA体系架构。

　　统一的元数据管理：IIS在共享元数据存储库的基础上统一进行业务、操作和技术等领域元数据的管理，采用统一元数据基础架构，支持基于字段的影响分析和元数据的血缘分析。

　　图3IBMInfoSphereInformationServer信息服务器集成功能

　　IIS对应的产品组件如图

　　4所示，所有组件由一个全面的集成服务平台支持，提供统一的用户界面、统一的并行处理引擎、统一的元数据管理、共用的连接能力（可以连接各种信息源，无论是结构化还是非结构化）和共用的基础服务（比如用户管理、安全管理、日志记录和报告等）。IIS包含四层：客户机、元数据存储库、服务和引擎，客户机包含

　　InformationServer控制台（面向任务的控制界面，比如创建作业调度）和

　　InformationServerWeb控制台（主要用来浏览信息服务目录）两部分；元数据存储库主要由

　　MetadataServer提供服务；服务层主要由

　　InformationServicesDirector提供，其本身是一组在

　　WAS上运行的EJB程序，并将

　　IIS组件任务生成为

　　EJB会话

　　Bean，比如

　　DataStage作业或

　　QualityStage作业如果发布为服务就会生成为会话

　　Bean；引擎层是实际提供信息服务程序所在的位置，比如

　　DataStage、QualityStage和

　　FederationServer都在这里。

　　word版

　　整理

　　范文

　　范例

　　指导

　　参考

　　图4IBMInfoSphereInformationServer信息服务器产品组件

　　如图

　　5所示，在

　　IIS各个组件中我们可以使用

　　BusinessGlossary来获取数据的业务视图，使用

　　DataArchitect定义数据模型，使用

　　InformationAnalyzer来分析数据，使用

　　FastTrack来指定数据关系和变换，使用

　　DataStage进行数据转换并使用

　　QualityStage进行数据标准化，使用

　　MetadataServer进行统一元数据管理，并使用

　　MetadataWorkbench对公共元数据存储库中的信息进行查询、分析和报告，还可以使用

　　InformationServicesDirector发布

　　web服务。

　　word版

　　整理

　　范文

　　范例

　　指导

　　参考

　　图5IBMInfoSphereInformationServer信息服务器各组件协作流程

　　InfoSphereInformationAnalyzerInfoSphereInformationAnalyze（以下简称

　　IA）是一款数据质量分析工具软件，用来在项目初期对数据源进行数据质量分析，以便真正地了解源数据的结构、质量和数据分布等，提早发现数据的缺失、错误、重复和不一致等问题，为后面的数据复制、ETL等过程提供支持，以便降低项目实施风险。通过使用IA，项目开发人员可以方便的了解源数据的特性从而为ETL、复制等制定合适的规则，确保项目的顺利进行。IA的逻辑体系结构如图6所示：

　　word版

　　整理

　　范文

　　范例

　　指导

　　参考

　　图6IA系统体系结构

　　IA通过读取数据源的表结构

　　DDL信息，对表中数据进行扫描、统计，并将统计结果存入自带的IADB数据库中。通过

　　IADB中的各种信息，可以为用户提供各种数据质量分析结果。IA数据质量分析功能主要包括：

　　1、强劲和可扩充的数据轮廓分析：

　　完全并行处理的系统架构，提供强大的数据处理能力。

　　针对全部分析任务，提供对字段、数据表和多数据表之间的抽样运行选项。

　　实现多个字段、主键/外键的灵活组合分析。

　　提供立刻或定时运行分析任务的选项。

　　2、与

　　IBM数据服务器集成：

　　与

　　IBMQualityStage/DataStage软件工具共享元数据。

　　支持

　　IBMBusinessGlossary元数据录入和管理的软件工具。

　　通过分析结果，进行验证并可生成可供参考的映射表。

　　3、高安全性的分析架构：

　　以项目为基础，控制并允许对重要数据的访问。

　　支持以角色为基础，和以用户为基础的安全访问权限控制。

　　word版

　　整理

　　范文

　　范例

　　指导

　　参考

　　4、支持广泛数据库系统和平台：

　　通过

　　IBM-brandedODBC驱动软件，连接全部符合业界标准数据库，也可连接

　　IBM主机系统数据库。

　　支持全部开放操作系统平台，包括：AIX、Solaris、RedHatEnterpriseLinuxAS、HP-UX、SuSEEnterpriseLinux、MicrosoftWindows。

　　5、灵活分析机制：

　　支持多种分析逻辑流程组合。

　　支持多种层次分析，可选择从数据目标（Schema）、数据表（Table）、或指定字段（Column）作分析。

　　支持全部字段或部分数据抽样分析。

　　支持交互式分析数据。

　　6、标准元数据管理：

　　无需把源系统的数据传送和复制到本地数据库，仅对源数据作分析。

　　存放分析结果和对应元数据的数据库，是标准的关系型（RDBMS）数据库并支持

　　DB2、Oracle、SQLServer等。

　　提供多达

　　40种

　　out-of-the-box分析报告，元数据库可开放给任何

　　BI系统或报表工具系统，以共享分析结果数据。

　　IA工具软件具体提供的功能有：

　　1、列分析：通过对源数据库表的列进行分析，帮助用户了解源数据的结构、内容、质量和准确性等，允许用户对具体的列进行钻取以便对该列进行特殊的质量控制，支持用户进行值域（某个属性正确值的集合）分析。

　　2、主键分析：通过对源数据库一个或多个表的所有候选列进行分析，帮用户找出表中哪些列适合做主键，以及哪些列不适合做主键等（比如存在大量重复记录）。

　　3、外健分析：检查表之间的内容和关系，帮助用户识别外键，并检查主键和外键之间的参照完整性。

　　4、跨域分析：检查表之间的内容和关系并进行分析，以确定列之间值的重叠以及表内和表间数据的冗余情况。

　　5、基准分析：帮助查看内容和数据结构随时间而发生的变化。

　　word版

　　整理

　　范文

　　范例

　　指导

　　参考

　　6、数据规则和指标：支持用户创建逻辑规则进行数据验证，验证规则分析可以延伸数据源或跨数据源的评估，以定义数据之间的关系。允许以多种方式表达验证规则。

　　InfoSphereFederationServerInfoSphereFederationServer提供了对同构和异构数据源的虚拟化集成，从而使应用程序可以访问和集成不同数据和内容源（就如同它们是单个资源一样）。InfoSphereFederationServer执行此操作时与信息所在的位置无关，同时保留了数据和内容源的自主性和完整性。联邦系统是一个典型的分布式数据管理系统，通过联邦功能，我们可以透明实时的访问分布在企业各个竖井中的数据，包括同构和异构数据，数据源可以是各种关系型数据库和半结构化数据，比如

　　XML、Excel等。只要对数据源具有足够的权限，就可以对源库表中的数据做增加、删除、更改和查询操作，在实际使用过程中，企业倾向于只拥有源库的查询权限，以便万一源库数据出现问题时责任比较清晰。

　　InfoSphereFederationServerV10.1支持多种数据源，包括

　　DB2、DB2/390、DB2/400、Informix、Oracle、Sybase、MSSQLServer、postgreSQL等多种关系型数据库，也包支持非关系型的半结构化数据源。联邦服务器（InfoSphereFederationServer）通过包装器（Wrapper）与各个数据源进行通信，针对各类数据源，联邦服务器提供专用的包装器实现对异构数据源的SQL处理，支持对异构数据库直接的数据类型和函数的转换。对主流关系型数据库（比如

　　DB2、Informix、Oracle、Sybase、MSSQLServer等）包装器通过该数据库的客户端与该数据库进行交互，对开源关系型数据库通过ODBC驱动与其进行交互。对非关系型数据源，包装器直接进行数据访问。联邦服务器不需要在数据源端做任何更改，也不安装任何插件，只需要安装配置联邦服务器，即可实现实时的信息整合。联邦服务器的原理如下图7所示：

　　word版

　　整理

　　范文

　　范例

　　指导

　　参考

　　图

　　7联邦服务器原理

　　InfoSphereReplicationServerInfoSphereReplicationServerV10.1（从

　　10.1开始，将和

　　CDC一起合并为

　　InfoSphereDataReplication）能跟踪源数据库的更新并将其中部分或全部更新复制到目标数据库，利用

　　ReplicationServer提供的复制能力可以实现在不同数据库直接的数据复制。复制支持

　　1个数据源对多个目标数据库，多个数据源对一个目标数据库，既可以单向复制，也可以双向复制，从而实现数据整合、业务分离、数据容灾的功能要求。

　　ReplicationServer具体支持两种数据复制：SQL复制和

　　Q复制。SQL复制可以在主流关系型数据库（同构或异构）之间实现数据复制，Q复制是基于对数据源日志文件捕获对源表所作的更改，并通过

　　WebsphereMQ消息队列将已落实的更改传输至目的服务器，并将更改应用于目标表。这两种复制技术都能支持多种数据同步拓扑结构，提供数据同步监控、数据一致性校验和容错机制。

　　SQL复制具体复制方式包括准实时复制、定时复制、双向复制、复制转发、增量复制等，复制范围可整表复制或表中部分行复制，可对复制对象进行简单转换、归并、拆分等操作。SQL复制支持的数据源有

　　DB2z/OS版、DB2forLinux，word版

　　整理

　　范文

　　范例

　　指导

　　参考

　　UNIXandWindows、DB2i版、Informix、MicrosoftSQLServer、Oracle和

　　Sybase，目的数据库除了上述源库以外还支持

　　Teradata。当数据源是

　　DB2数据库时，ReplicationServer通过读取数据库日志获取数据的更新，当数据源是非

　　DB2数据库时，则通过触发器机制捕获源库的更新并存储到

　　CCD表中，然后通过

　　Capture服务器提取源库的更新信息，Apply服务器获取

　　Capture的结果后根据复制映射关系进行转换并按照一定的刷新周期应用到目标数据库。

　　Q复制是一种高吞吐量、低延迟的数据同步方法，通过使用

　　WebsphereMQ的消息队列，在源数据库和目的数据库之间以及源系统和目标系统之间传递事务。通过捕获并同步数据变化的增量信息，使数据源和目标数据之间数据内容保持一致。与

　　SQL复制相比，Q复制对网络的要求不高，因为

　　Q复制可以做到数据的异步复制（基于

　　MQ的消息异步传输）。Q复制目前支持的数据源有

　　DB2?z/OS版、DB2forLinux，UNIXandWindows、DB2VSE&VM服务器和

　　Oracle（10.2和更高版本），目的数据库在上述源数据库中不支持

　　DB2VSE&VM服务器，对

　　Oracle数据库没有版本限制，另外还支持

　　Informix、MicrosoftSQLServer、Sybase和

　　Teradata。Q复制设计用于支持业务连续性、数据备份、工作负载分发和应用程序集成场景。Q复制具有以下几个优点：

　　低延迟：通过与

　　WebsphereMQ的有效集成，使得对源表进行的修改一旦提交，并从日志中读取到这些修改，这些变化就会立即被发送出去。

　　对数据源影响小：最大程度减小对源数据库上的操作。

　　高吞吐量：QCapture程序始终可以跟踪在源表发生的快速变化，并且

　　QApply程序使用多线程，使得它能够及时跟踪通信通道中的消息。

　　低网络流量：消息使用一种压缩格式在队列中传送，而且在发送数据的选项中允许选择传送最少量的数据。

　　异步性：消息队列使得

　　QApply程序可以不连接源数据库或者源子系统就可以接收事务。如果

　　QCapture程序或者

　　QApply程序停止，在程序可用后，需要进行处理的消息仍然存在于队列中。由于消息是永久的，所以数据源和目标即使在系统或设备故障的情况下仍可以保持同步。

　　可以对数据进行筛选，使得仅复制需要的数据。

　　通过调用存储过程方便的实现数据的转换，以适应不同应用的要求。

　　word版

　　整理

篇十：数据治理理论

　　9612020.08《数据治理之论》我们正处在数字经济飞速发展的时代。党的十九届四中全会审议通过《中共中央关于坚持和完善中国特色社会主义制度、推进国家治理体系和治理能力现代化若干重大问题的决定》，其中首次把“数据”列为生产要素，这充分西显了数字经济时代数据对于经济活动和社会生活的巨大价值，数据是经济活动数字化进程的需要，体现了数字经济快速发展背景下分配制度的与时俱进。

　　开展数据治理的理论探索和实践创新，有利于全面释放数据价值，助力数字经济发展，也有利于数字赋能国家治理体系和治理能力现代化，而数据价值的充分释放，有赖于构建一套科学合理的数据治理体系作为支撢。由中国科学院院士梅宏主编，北京大学、中国人民大学、中国软件评测中心、贵州省量子信息和大数据应用技术研究院共同探讨研究并梳理形成的《数据治理之论》—书，尝试从理论上探讨和构建数据治理的框架体系，为开展数据治理研究提供参考。本书从数据治理的起源和现状、数据治理的体系框架，以及不同学科对数据治理问题的认识进行探讨和思考。内容分为两篇：

　　第一篇介绍数据危机的概念，数据治理的理论与实践现状，以及数据治理的基本思路和体系框架；第二篇分别从信息资源管理、法学、经济学、管理学和数据科学五个学科来讨论数据治理，采用不同的研究方法，从不同的视角来分析数据治理面临的挑战，并从不同角度提出了数据治理方案.

推荐访问:数据治理理论 治理 理论 数据