|
简介： 经过多年 IT 的建设，信息对于企业的日常运营已经日益重要，并逐渐成为企业内重要的资产，信息资产的管理已经成为企业日常管理中一个非常重要的环节。如何管理和利用好企业内部纷繁的数据资产也越来越成为企业管理的一项重要工作。近几年企业更加专注于优化自己的业务以便在市场竞争中获得更大更持久的优势，比如银行希望能够通过对客户的分析，找出哪些人的风险更高，从而为信贷的风险管理提供帮助，保险公司希望知道哪些理赔客户骗保的可能性更高等等。这些都离不开企业对现有数据的分析和利用，从而为企业创造更多的价值或规避更多的风险，因此数据中心的构建就提上了日程，本文将探索如何去构建新一代数据中心。
经过多年 IT 的建设，信息对于企业的日常运营已经日益重要，并逐渐成为企业内重要的资产，信息资产的管理已经成为企业日常管理中一个非常重要的环节。如何管理和利用好企业内部纷繁的数据资产也越来越成为企业管理的一项重要工作。 最近几年企业更加专注于优化自己的业务以便在市场竞争中获得更大更持久的优势，比如银行希望能够通过对客户的分析，找出哪些人的风险更高，从而为信贷的风险管理提供帮助，保险公司同样期望加强其风险管理能力，比如通过分析历史数据，找出哪些理赔客户骗保的可能性更高等等。这些都离不开企业对现有数据的分析和利用，从而为企业创造更多的价值或规避更多的风险。 在应用议程（“Application Agenda”）时代，由于应用的构建多是自下而上构建，主要以满足某个领域或某个部门的业务功能为主，从而造成了一个个分立的应用，分立的应用导致了一个个的静态竖井（Static Silos）。由于数据从属于应用，缺乏企业全局的单一视图，形成了一个个信息孤岛，分立的系统之间缺乏沟通，同样数据的孤岛导致只能获得片面的信息，而不是全局的单一视图。存储这些信息的载体可能是各种异构的关系型数据库，比如 DB2、ORACLE、MS SQL SERVER 或 SYBASE，也有可能是 XML、EXCEL 等文件。因此，很多企业将构建新一代的数据中心提上了日程，目的是覆盖生产、经营各个环节的关键业务数据，完善元数据管理，形成全局的数据字典、业务数据规范和统一的业务指标含义，能够灵活的获取企业业务数据的单一视图（为保证数据的一致性、完整性、准确性和及时性，需要实现数据的联邦、多个数据源的抽取、转换、装载、汇总等）。数据的数据交换和共享主要发生在上下级组织机构之间或同级的不同部门（或分公司，比如不同省或地市公司之间）之间。最终，这些数据可以为生产分析、决策支持（多维分析、即席查询、数据挖掘）等应用提供更及时、准确、有效的支持。 数据中心的目标是实现跨系统数据共享，解决信息孤岛，提升数据质量，辅助决策分析，提供统一的数据服务。同时，数据中心的构建也面临着各种挑战，比如信息整合在技术上的复杂度、信息整合的管理成本、数据资源的获取、信息整合的实施周期以及整合项目的风险等。 数据中心的整体架构如图 1 所示，比如一个企业上下级之间存在三层结构，分别为总部、省级系统和下属企业，计划在省级和总部分别构建数据中心。来自下属企业的 ERP、MIS 或其他业务系统的数据可以通过联邦（Federation）、复制（Replication）、抽取（ETL）或 Web Service 的方式集成到省级数据中心，同样，下属企业的 ERP、MIS 或其他业务系统也可以通过联邦（Federation）、复制（Replication）、抽取（ETL）或 Web Service 的方式访问省级数据中心的数据。省级的商业系统和数据仓库都可以将数据中心的 ODS 数据当成数据源，直接获取整个企业数据的单一视图。总部机构的财务系统、电子商务或其他系统也可以通过信息交换平台采集各个省级数据中心的数据，下发总部的业务数据等。 图 1. 数据中心架构  数据中心的构建主要有三种方式，分别是信息整合技术、数据仓库技术和主数据管理技术，并且在这三种方式中，都可能部分使用 Web Services（基于企业服务总线和应用服务器）方式实现数据的访问和更新等，所以不再单独介绍 Web Services 相关的内容。 在以往，我们经常在集成应用中使用数据接口的方式实现文件或信息的交换，该方式优点是有利于复杂消息转发，缺点是接口多难以管理，特别是随着时间的推移业务发生变更，接口的维护成本会越来越高，管理越来越复杂。信息整合解决方案，通过信息整合平台，屏蔽数据复杂性，提供准确，一致，及时，及有条理的业务数据。该解决方案的技术基础是其联邦（Federation）能力，这种能力可以将异构数据集中一起。 在如今的电子商务随需应变环境中，激烈的竞争要求必须将企业内外的信息加以集成。客户关系管理、供应链管理和业务智能等方案之所以能够顺利实现，离不开对来自多数据源（包括结构化和非结构化数据源）信息的成功集成。由于组织结构或运营方面的限制，这些数据源通常不适合进行全盘复制或在一个数据库中进行合并。因此，对分散的数据源实施联邦式访问的需求增加。 通过联邦功能我们可以把关系数据、半结构化数据（如 Excel 文件、XML 文件、Web 搜索引擎、IBM WebSphere MQ 查询和内容源）组成一个逻辑数据库，对这些数据源中的表我们可以像操作本地数据库表一样进行操作，而不必关心我们操作的这些昵称底层是什么数据源，物理在什么位置，同样的，还可以通过联合存储过程调用远程的存储过程，具体如图 01-02 所示： 图 2. 信息整合 -- 联邦的特点  联邦机制很容易理解，具体如图 3 所示，下层是各种数据源，有关系型的也有非关系型的，通过 InfoSphere Federation Server，屏蔽了下层数据间的差异，从逻辑上看，就如同一个数据库一样，可以灵活的访问。在实现的时候，通过在 InfoSphere Federation Server 中为外部数据源创建昵称（Nicknames），使得这些外部数据看起来就像是一个本地表。你可以访问这些外部表就像访问本地表一样。你还可以对本地表和昵称（nickname）执行 SQL JOINS 和 UNIONS 等命令。 图 3.IBM 信息整合体系架构  信息整合解决方案的另一个重要支柱就是对异构数据的准实时增量复制（刷新周期最低可以到秒级）。复制的实现是基于对源数据库的日志进行捕获，获取增量数据，并基于消息的机制将其复制到目的数据库，复制的过程中可以实现数据的合并、拆分、转换等操作。目前 IBM 针对复制主要有两个产品： InfoSphere Replication Server 和 InfoSphere change data capture（CDC）。比如，Q 复制（InfoSphere Replication Server）就是在复制的过程中，Q Capture 程序通过直接读取 DB2 或 ORACLE 数据源的日志，获得要捕获数据内容的增量变化信息，然后，Q Capture 程序将这些增量信息通过 MQ 消息队列发送，Q Apply 程序从队列中读取这些消息，并将这些增量变化内容应用到目标数据源中的相应表中。 InfoSphere Change Data Capture 是 IBM 信息集成产品家族中的重要产品，它广泛应用在信息集成的多个领域中：比如跨地域数据采集和交换，企业内部数据交换平台，统一客户信息等业务视图，实现查询系统与业务系统分离，业务系统高效镜象备份，扩展商业智能应用，以及主机 /AS400 的与开放平台数据交换等。IBM InfoSphere Change Data Capture 提供的复制能力，使我们可以在不同的数据库之间复制数据。复制的方式可以是一个源对多个目标，也可以是多个源对一个目标，从而实现数据整合、业务分离、热备灾备的功能要求。产品架构如图 4 所示： 图 04. CDC 产品架构  基于 InfoSphere Change Data Capture 的技术方案存在很多技术上的优势：
图 05. CDC 支持的各种异构数据源  数据仓库技术，又分为两种方式，一种是传统数据仓库技术，另一种是动态数据仓库技术。相比传统数据仓库技术，动态数据仓库首要特点是一线用户可以动态（或者说实时地）地访问数据仓库以便获取其所需的信息。传统数据仓库用户通常只针对高端管理层或少数管理人员，通常只有几十个或几百个用户。一线用户，比如银行，成千上万的客户经理和客户代表无法访问数据仓库，而动态数据仓库中，一线用户可以动态的访问数据仓库。动态数据仓库的第二个特点是动态数据加载，相比传统数据仓库以批量形式加载数据，动态数据仓库通常以准实时的方式连续加载数据（以增量数据加载为主），最低可以到秒级的时间间隔，从而在根本上保证数据仓库数据的实时性。动态数据仓库的第三个特点是事件驱动，主动推送，比如银行的信贷风险管理员，当审批某人的贷款请求时，关于该申请人的相关风险评级等信息就会主动提示给信贷风险管理员。 首先我们来看如何以传统数据仓库技术构建数据中心，如图 01-06 所示，ETL 层负责完成将分布的异构的数据源中的数据抽取到临时中间层后进行清洗、转换、集成，加载到 ODS 中，然后再通过 ETL 或 ELT（转换在数据仓库内部完成，而不是在临时中间层完成）的方式最后加载到数据仓库或数据集市中，成为联机分析处理、数据挖掘的基础。ODS（Operational Data Store）通常是一个可选项，用来在业务系统和数据仓库之间形成一个隔离层，提供一部分业务系统细节查询的功能（转移业务系统压力），并转接一些数据仓库中不能完成的一些功能（比如对细节数据的访问需求，DW 层通常都是存储汇总过的数据，偶尔对细节数据的查询可以转移到 ODS 来完成）。 如图 6 中间部分所示，数据仓库用来存储面向主题的、集成的、相对稳定的、反映历史变化的数据，用于支持管理决策；而数据集市（DataMarts）是为了特定的应用目的或应用范围，而从数据仓库中独立出来的一部分数据，也可称为部门数据或主题数据（subjectarea）。在对 ODS 中的操作型数据进行加工和集成，统一和综合后加载到数据仓库或数据集市中。OLAP( 联机分析处理 ) 服务器对分析需要的数据进行有效集成，按多维模型予以组织，以便进行多角度、多层次的分析，并发现趋势。我们可以根据需要选择使用 ROLAP（关系型在线分析处理）或 MOLAP（多维在线分析处理）。报表统计、即席查询、多维分析等我们可以使用 COGNOS 来完成，数据挖掘可以使用 SPSS 来完成。而元数据（metadata）的管理可以 InfoSphere Business Glossary 来完成。 图 6. 数据仓库的思路  IBM 信息服务器（IBM InfoSphere Information Server） 如果不能有效地集成信息，现在的大多数关键业务计划都将以失败告终。提供单一客户视图、商务智能、供应链管理以及遵守 Basel II 和 Sarbanes-Oxley 法案等计划，都需要一致的、完整的、值得信赖的信息。IBM? 信息服务器（IBM InfoSphere Information Server）是业界第一款面向企业信息架构的完整的、统一的基础产品，能够通过扩展来支持任何数量的信息，使上述计划能够加速实现更理想的商业成效。 IBM 信息服务器（IBM InfoSphere Information Server）将 IBM 信息集成解决方案 (InfoSphere DataStage、InfoSphere QualityStage、InfoSphere ProfileStage、InfoSphere Federation Server、InfoSphere Replication Server、InfoSphere Change Data Capture、InfoSphere Business Glossary、InfoSphere Information Analyzer) 的技术集成到了一个统一平台中，使公司能够了解、整理、转换并提供值得信赖的、上下文丰富的信息。 如图 7 所示，InfoSphere DataStage 实现了信息整合流程的一个完整部分：“数据转换”，组合和重构信息以用于新的用途。InfoSphere DataStage 通常部署于企业应用、数据仓库和数据集市等系统中，最简单地说，InfoSphere DataStage 执行从源系统到目标系统的批量和实时（需要和 InfoSphere Information Server 复制组件即 InfoSphere Replication Server 或 InfoSphere change data capture 相结合）的数据转换和移动。数据源可以包括索引文件、顺序文件、关系数据库、档案、外部数据源、企业应用和消息队列。InfoSphere DataStage 具有满足绝大多数苛刻的数据整合需求所需的功能、灵活性和可扩展性。 图 7.IBM 信息服务器解决方案  如图 7 所示，InfoSphere QualityStage 执行企业数据整合的准备阶段（通常称为数据清理）。InfoSphere QualityStage 利用 InfoSphere Information Analyzer 执行的源系统分析，并为 InfoSphere DataStage 的转换功能提供支持。这些产品协同工作，将过去手动或被忽视的活动自动化，合并到一次数据整合工作中，即：数据质量保障。组合的收益可以帮助公司避免以数据为中心的 IT 项目中最大的问题之一：由使用质量低下的数据导致的低投资回报 (ROI)。对于整合项目的成功来说，数据准备是至关重要的。InfoSphere QualityStage 包含一套阶段、一个 Match Designer、和相关的功能，为建立数据清理任务（称为作业）提供一个开发环境。使用阶段和设计组件，您可以快速、轻松地处理大量数据，按照需求有选择地转换数据。InfoSphere QualityStage 提供一套整合模块，以完成数据重组任务：
InfoSphere QualityStage 的概率匹配功能和动态权重策略可以帮助您创建高质量、准确的数据，并在整个企业中一致地识别核心业务信息，如客户、位置、和产品。InfoSphere QualityStage 标准化并匹配任何类型的信息。通过确保数据质量，InfoSphere QualityStage 能够降低实施 CRM、商业智能、ERP、和其他与客户相关的 IT 战略措施的时间和成本。 元数据服务是支撑 IBM 信息服务器的平台的组件。通过使用元数据服务，您可访问数据并执行分析、建模、整理和转换等数据集成任务。IBM 信息服务器主要的元数据服务组件包括：InfoSphere Business Glossary、 InfoSphere Metadata Server 以及 InfoSphere MetaBrokers and bridges。InfoSphere Business Glossary 是基于 Web 的应用，针对数据集成环境提供面向业务的视图。通过使用 InfoSphere Business Glossary，您可察看并更新业务说明并访问技术元数据。元数据最好由了解信息资产对业务的意义和重要性的人员进行管理。InfoSphere Business Glossary 设计用于协作授权，使用户能够共享关于数据的见解和体验。 IBM InfoSphere Information Analyzer 可以迅速有效地执行全面的数据加工，使源数据分析的任务自动化，从而为关键数据整合项目将总体成本和资源降到最低。在获得项目需求之后，项目经理启动数据整合的分析阶段，以理解源系统并设计目标系统。在很多时候，分析工作都是艰苦、人工的过程，依赖于过期的（或不存在的）源文档，或是维护源系统的人员的知识。但是，要理解有哪些可用的数据及其当前状态，源系统分析至关重要。在为整合准备数据的过程中，InfoSphere Information Analyzer 扮演着关键的角色，它分析业务信息以确保其准确、一致、及时、连贯。
IBM InfoSphere Warehouse Edtion IBM InfoSphere Warehouse Edtion 的核心引擎是行业领先的 DB2 企业版数据服务器，旨在满足大中型企业的需求。DB2 可以部署在任何规模的服务器上，从一个 CPU 到数百个 CPU。DB2 企业版是构建随需应变的企业级解决方案的理想基础，比如多 TB 数据仓库、高可用性大容量 OLTP 系统或基于 Web 的 BI 解决方案。DB2 企业版核心引擎的许多功能是专为提高数据仓库和分析功能及性能而设计的，比如：物化查询表、星爆式优化器和多维群集。简单总结其技术优势如下： 数据库分区技术（DB2 Database Partitioning Feature） 企业可以灵活地利用 DB2 数据库分区，来支持数据仓库环境中常见的特大型数据库以及复杂的工作负荷和更多的并行管理任务。DB2 UDB 提供了先进的“哈希（HASH）算法”映射数据库的每一条记录到特定的数据库分区中。“哈希算法”使用表中的一列 ( 或一组列 ) 作为分区关键字，得到 0 至 4095 的数值，提供了业界最强的水平扩展能力。DB2 UDB 为数据存储提供了灵活的拓扑结构以达到高性能及高并行。其中每个数据库由一些数据库分区组成，每个数据库分区实际上是数据库的一个子集，它包含自己的用户数据，索引，交易日志及配置文件。 强大的深度压缩技术 优秀的压缩技术对成功构建海量数据中心至关重要。针对海量数据，IBM DB2 革命性地推出了深度压缩 ( 或称为“行压缩”) 技术。它采用基于字典表的 Lempel-Ziv (LZ) 算法记录行中的重复模式进行压缩，这些模式可以跨列组合或在列内提取子元素。这与其他某些数据库厂商简单的页面压缩具有本质的区别，行压缩具有极高的压缩比。如图 8 所示： 图 8. 行压缩示例  深度压缩对于节省存储成本其意义是显而易见的。IBM 在国内外许多实际客户中，均达到了 50% 以上的压缩效果。深度压缩的意义还表现在节省 I/O 操作和提高内存利用率上。由于进行了深度压缩，I/O 操作得到了有效地降低，并且提高了内存中 Bufferpool 的利用，因此，在许多客户系统中，使用了 DB2 不仅节省了存储还提高了查询性能。例如在国内某著名 ERP 厂商的测试中，数据存储减少了 60%，同时性能提升了 10%。 数据库系统的高度自主管理能力 IBM DB2 版本 9 引入了一个在业界具有革命性意义的内存自我调整系统—— the Self Tuning Memory Manager ( 缩写：STMM)。STMM 技术使得 DB2 能够自动控制 DB2 主要的内存对象：Sort, locklist, package cache, buffer pools, 和 total database memory；无需人工干预地进行内存自我在线调优；自我感知工作负载、按需调整内存大小；能够迅速适应工作负载的突然变化，自动重新划分内存区域；并自动化适应工作负载的周期性变化。在国内外的多个客户实际场合中，STMM 对系统的优化效果甚至超过了一个具有多年经验的 DBA 的调优效果。 工作负载管理（WORKLOAD MANAGEMENT） IBM 的 DB2 V9.5 引入并完善了工作负载管理（WORKLOAD MANAGEMENT）功能，使得我们可以更深入地洞察系统的运行情况并更好地控制资源和性能。在 DB2 V9.5 中，新引入的工作负载管理功能（WLM）可以帮助您标识、管理和监视数据服务器的工作负载。工作负载管理提供了第一个真正集成到ＤＢ２数据服务器的工作负载管理解决方案，对标识声明的支持使您可以为多层应用程序环境中的各个用户或组提供工作负载管理。一个好的工作负载管理（WLM）系统能够能够帮助企业更有效的监控系统的运行情况。由于 DB2 V9.5 的数据管理方面得到了极大的增强，在数据库服务器环境中，你可以获得远远超过你预期的高效的管理性能。为了保证数据库服务器得到最大的性能，一个高效的工作负载管理（WLM）系统是必需的。一个成功的工作负载管理（WLM）需要考虑很多方面，并且要清楚的知道自己的目标是什么，比如核心的业务将获得更多的资源，一些非核心的业务对其能够获取的资源进行一定的限制，又或者，对一些流氓查询进行限制等等。 Cognos, 隶属于 IBM 公司，是商业智能 (BI) 和绩效管理解决方案的全球领导者。提供世界一流的企业 BI、预算管理，财务合并，风险管理和控制软件和服务，帮助企业计划、了解和管理财务和业务绩效，适应法规监管，并协助企业制定和执行市场战略。IBM Cognos 是公认的商业智能和绩效管理解决方案的行业领袖和最大供应商之一，在全世界拥有超过 25,000 名客户和 3,000 多个合作伙伴和经销商。IBM Cognos 8 业务智能是唯一能够在一个单一的、已证的体系结构上提供报表、分析、计分卡、仪表盘、企业事件管理等完整 BI 功能的 BI 产品。Cognos 8 BI 提供了一种简化的 BI 环境，可以提高用户接受度，提高决策水平，可以作为绩效管理的企业级基础。 SPSS，数据挖掘领域的领导者，在 2009 年被 IBM 收购。SPSS 预测分析产品 (PASW) 目前其主要有以下四类产品，具体如图 9 所示： 图 9.SPSS 产品概要图 
数据中心构建方式三：主数据管理技术（Master Data Management，MDM） 主数据是指在整个企业范围内各个系统（操作 / 事务型应用系统以及分析型系统）间要共享的数据， 比如，可以是与客户（customers）, 供应商（suppliers）, 帐户（accounts）以及组织单位（organizational units）相关的数据。主数据管理（MDM）可以帮助我们创建并维护整个企业内主数据的单一视图（Single View），保证单一视图的准确性、一致性以及完整性，从而提供数据质量，统一商业实体的定义，简化改进商业流程并提供业务的响应速度。从变化的频率来看，主数据和日常交易数据不一样，变化相对缓慢，另外，主数据由于跨各个系统，所以对数据的一致性、实时性以及版本控制要求很高。IBM InfoSphere MDM 可以帮助你快速构建主数据管理。 主数据管理（MDM）的成功实施依赖于三个重要的因素：人、流程和技术。其中，技术是受人和流程驱动的。如果所有问题都是技术问题那事情将非常简单，但现实往往不是如此。技术问题容易解决，但与人相关的技术问题不容易解决，流程同样如此。如同任何实施，主数据管理的成功部署取决于在企业范围内更有效率的实现三个要素。主数据管理并不是一个新的概念。人们在开始管理他们的数据的时候都在按照他们自己的方法使用这个概念。那么，MDM 的准确定义是什么？ MDM 是流程和技术的联合体，用来帮助企业用一种更好的方法管理他们的数据流、数据完整性和数据同步。这个定义在企业级别突出强调了对核心数据的强制策略和标准。因为 MDM 存在不同的解释，很容易出现一些常见的误解，如同 Lalitha Chikkatur 在“Top 5 Master Data Management Misconceptions”一文中所述： 误解 1：主数据管理（MDM）就像一个数据仓库 主数据管理和传统数据仓库解决方案不是一个概念，数据仓库会将各个业务系统的数据集中在一起在进行业务的分析，而主数据管理系统不会把所有数据都管理起来，只是把需要在各个系统间共享的主数据进行采集和发布。相对于传统数据仓库解决方案的单向集成，主数据管理正注重将主数据的变化同步发布到各个关联的业务系统中（主数据管理数据是双向的）。 主数据管理（MDM）就是关于如何将信息作为服务来使用，是一套理论和方法，用来保证横跨整个企业和不同主题域相关数据的准确性、完整性、相同的内涵、及时性、一致性和质量。从主数据管理（MDM）自身架构上来看，主要分为两类，依据不同的目的，分为操作型（Operation）和分析型（Analytical）两种。顾名思义，操作型主数据管理用来处理来自前端业务系统的主数据，而分析型主数据管理更多的是用来预测分析，历史信息分析和预测。复杂的数据层次结构和他们的关系可以在主数据管理中，而不是在一个数据仓库中更有效地维护。 主数据管理（MDM）在架构上通常具有一个集中总线，正因为如此，人们经常将其和数据仓库进行比较。总的来说，主数据管理（MDM）和数据仓库的目的都是为企业提供干净和有意义的信息。但除此之外，二者建立的目的和受众都不相同。主数据管理（MDM）是更像是一个服务，更多时候运行在业务数据集成方面，而数据仓库是用来支持 BI 应用，通过挖掘模型分析可用历史信息的趋势。 误解 2：主数据管理（MDM）是一个技术或基础架构概念 与其说主数据管理（MDM）是一个 IT 概念，不如说主数据管理（MDM）更像一个学科（Discipline）。主数据管理（MDM）实施成功的关键是让所有的利益相关者达成一致意见。如果我们将主数据管理（MDM）分解成如下六个类别，我们将看到有趣的是，技术处于最后位置。在进行技术的评估或工作之前有很多其它方面的事情需要注意。在行业中应用主数据管理（MDM）包含以下顺序： 1、愿景（Vision）: 为什么该企业需要主数据管理（MDM），该企业的主数据管理（MDM）应该是什么样子？谁拥有它？这些 why、what、who 的问题从业务角度来说非常重要，将有利于帮助利益相关者密切关注方案是否满足最初的目标。 2、策略（Strategy）: 这是整个方案中“How”部分，策略应该标识两件重要的事情： 企业的主数据管理（MDM）愿景是否和商业、利润收支、质量监督等因素正确匹配。 针对不同的垂直面以及未来业务发展，哪些属于范围内，哪些属于范围外？范围外的定义如同范围内的定义一样重要，因为，每个垂直面和业务范围需要满足不同的业务需求，其期望值和优先级也不相同。因此，策略将确定每个垂直面和业务范围的优先顺序。 3、矩阵（Metrics）: 矩阵是衡量主数据管理（MDM）和业务价值之间联系的有效方法。这些可衡量的目标来自主数据管理（MDM）策略。如果你已经定义了，比如，策略中的利润收支，你可以通过相关的矩阵来测量其 KPI。这些矩阵需要由业务驱动和拥有，而不能由 IT 驱动和拥有，因为只有业务才能完全标识和衡量这些活动的价值。 4、治理（Governance）: 治理对主数据管理（MDM）的成功同样重要。实现治理的正常的流程需要拥有一个管理委员会，其将负责主数据管理（MDM）中的角色匹配、账户和权限管理等。理想的方法就是通过业务端发挥领导作用，而 IT 端需要推动这些活动。治理涉及多个主题域比如安全、变更管理、培训和沟通等，其基本部分需要标识出主数据的创建者、管理者、拥有者和消费者。 5、流程（Processes）: 在主数据管理（MDM）中流程的定义和遵循治理的各个方面规定十分重要。所有治理计划中的“who”方面的问题需要有一个“how”和流程去完成这些目标，这将涉及到数据的发布和标识数据质量问题的流程。 6、技术（Technology）: 技术本身是一个广阔的世界。进行技术评估时应该有一个大致思路，为数据集成、数据存储、中间件、发布、用户接口、与未来应用系统的整合做好架构（包括基础架构）方面的规划，还包括实施这些解决方案所做的选择（需要作出一些关键决定比如是否构建自主研发的能力还是使用市场上现有的工具）、采用的方法论、获得正确的技能和资源矩阵等，以便让整个项目站在技术的前沿。 误解 3：主数据管理（MDM）需要做成一个数据质量程序 对主数据管理（MDM）来说，数据质量的重要性和关联性是毋庸置疑的。如果无法准确无误地标识出将会导致差的数据质量的某个客户或某个产品，那么无论是构建主数据还是关联数据的目标都会失败。通过治理和质量控制来保证主数据的实时性、关联性、完整性、有效性、准确性和一致性非常重要。话虽如此，也应该认识到，主数据管理（MDM）包含数据质量管理程序，数据质量是主数据管理成功实施的前提，但其仅仅是成功的其中一个要素，不是唯一的一个。主数据管理（MDM）和数据质量管理之间有着巨大的区别。一个典型的数据质量程序需要至少两个主要的步骤：数据质量需求分析和数据质量模型。不能说 MDM 就是一个数据质量管理程序，两者的目标、愿景和成功标准有十分大的区别。他们可能共享某一部分数据，但是仍然是两个不同的程序。 误解 4：认为数据治理是一个可选的架构组件 当企业实现信息面向服务（Information To Service）后，维护信息质量和一致性的挑战就随之而来。当企业组织机构高度分散，业务也分散时，相互之间具有很高的关联性，松耦合的 IT 和业务基础架构很容易让主数据管理（MDM）面临挑战。多数的数据质量管理是被某些方面的压力驱动的，最常见的有：
驱动力可能来自内部或外部，但是显而易见的是，数据治理不是一种奢侈行为。如果在开始时没有定义和控制，决策者将无法依据信息作出决定，因为信息必须是准确、实时和可信的。 数据中心系统架构的构建基本上分为三种模式（以下示例公司的组织结构分为两级：总公司和分公司）： 1.集中式结构： 数据中心系统集中部署在总公司，逻辑上按分公司进行区分，分公司通过内部网远程访问数据中心使用新系统，具体如图 10 所示： 图 10. 集中式结构示意图  集中式结构在业务上有利于总公司对分公司的集中管控，有利于对分公司及营销网点的集中管控，整个公司的报表一致，数据统一；业务上的缺点是不符合目前以分公司为运营中心的现状以及分公司业务开展的灵活性降低等。 集中式结构在技术上的优点是：
缺点是：
2.分散式结构： 数据中心系统分散部署在各个分公司，总公司只有简单的报表统计、查询分析功能等，具体如图 11 所示： 图 11. 分散式结构示意图  分散式结构业务上的优点是有利于分公司灵活地业务开展和有利于分公司对辖内营销网点的集中管控；缺点是总公司对分公司的管控力较弱以及跨地区公司间的业务开展和数据分析较难。 分散式结构技术上的优点是系统实时性和可靠性高，分公司系统互相不影响，停机风险最小，易于进行分公司的业务功能扩展等；缺点是多点部署，维护成本高，冗余数据多，各分公司数据与总部间数据集成难度大。 3.适度集中式架构： 按照不同子系统的业务和技术特性区分成两类，A 类应用集中部署，B 类应用分散部署，具体如图 12 所示： 图 12. 适度集中式架构示意图 适度集中式架构业务上的优点是有利于总公司对分公司的集中管控，同时符合以分公司为运营中心的现状，可以结合各个分公司的实际情况，更好地支持业务运转；缺点是总公司对 B 类业务的管控力不如方案一。 适度集中式架构技术上的优点是 A 类应用集中，易于维护，易于和其它系统的数据整合，满足不同应用对数据要求的不同特点；缺点是 B 类应用分散部署，不易维护，数据集成技术要求较高，存在一定的数据冗余。 数据中心的建设可以根据业务现状为了降低实施风险和加快实施进度，采用模式三“适度集中式架构”，待各地业务模式标准化、网络架构条件成熟和总公司统一综合业务后，过渡到方案一（大集中式模式），具体如图 13 所示： 图 13. 业务逻辑部署的演进示意图 XXX 数据交换与共享服务平台使用了数据中心构建方式一和二，即信息整合技术加数据仓库技术，其体系架构如图 14 所示：目前应用基本上呈两级方式部署（数据中心和数据分中心），数据交换与共享服务平台的主要组件都部署在数据中心。 首先数据交换与共享服务平台提供对核心业务数据源和外网、专网交换数据的接入能力。数据交换与共享服务平台通过数据联邦技术连接相应的数据中心、数据分中心各个业务系统的数据库，实现对对各业务系统数据的透明实时访问，通过增量复制技术可以实现数据源到目的数据库的增量实时复制以及反向的增量实时数据分发。数据的清洗、转换、加载层获取增量变化数据，通过数据清洗、数据转换处理后，完成中心数据库的构建，中心数据库对外提供标准访问接口，在此基础上建设各类综合应用。 中心数据库中的数据一方面可以使用本地应用的方式进行展现，另一方面也可以包装成服务，供不同地点不同部门的应用来进行调用。 图 14. 数据中心示例架构 数据交换与共享服务基础软件平台采用购买成熟的商业软件产品来搭建。以屏蔽（或支持）异构数据（访问）、支持数据共享和数据交换的运行管理、实现通过数据中心共享访问其它节点数据中心的数据等的基本目标。软件组成如下图所示，信息整合服务层的联邦功能由 InfoSphere Replication Server 提供，数据的增量复制功能由 InfoSphere change data capture（CDC）负责完成，数据的清晰、转换和加载由 InfoSphere DataStage 负责，而元数据管理由 InfoSphere Business Glossary 完成，具体如图 15 所示： 图 15. 数据中心示例软件组成 |
|
|
