主数据管理 (MDM) 提供关键实体的可信视图，这些实体包括客户、供应商、合作伙伴、产品、材料、帐户等，通常存储在多个彼此没有联系的应用中，而且可能存在重复。

IBM 的主数据管理 (MDM) 解决方案可以提供单一可信的数据视图。这有助于实现以客户为中心的目标和业务成果。

通过整合各种来源的非结构化数据和外部数据，构建并管理可信视图。使用准确及时的信息，留住最有价值的客户。

获得有关大数据项目、数据仓储和 Hadoop 计划的清晰、一致且及时的信息。

 

IBM 主数据管理产品对比与分析

主数据管理（MDM Master Data Management）描述了一组规程、技术和解决方案，这些规程、技术和解决方案用于为所有利益相关方（如用户、应用程序、数据仓库、流程以及贸易伙伴）创建并维护业务数据的一致性、完整性、相关性和精确性。主数据管理的关键就是“管理”。主数据管理不会创建新的数据。相反，它提供了一种方法，使企业能够有效地管理存储在分布系统中的数据。InfoSphere MDM Server 和 Initiate 是 IBM 提供的两种前言的主数据管理的解决方案，本文从开发人员的角度出发，对比了两款主数据管理产品的体系架构，从服务、模型、集成等多个方面分析了两者的优势和区别，最后给出了两种产品的应用场景。

体系架构的比较

通过对 MDM Server 与 Initiate 体系架构的比较，可以很清楚地了解两款产品在总体功能、组成结构上的区别与差异。

1. MDM Server的体系结构

MDM Server 是一个基于 SOA 架构的企业级应用。主要分为服务层和数据层两大模块。服务层主要负责业务逻辑的处理，由于该层是由 EJB 技术实现的，所以其必须要部署在 J2EE 应用服务器上，目前支持的应用服务器有 WebSphere 和 Weblogic。数据层主要负责数据的持久化，目前支持的数据库有 DB2 和 ORACLE。MDM Server 提供了完善的数据模型，包括客户、账户和产品，同时提供强大的扩展机制来支持用户需要的业务模型。MDM Server 的体系结构如下图所示。接下来我们将对主要组件模块进行介绍。

图 1. MDM Server 的体系结构

1.1 消费系统（MDM Server Consumers）

消费系统就是使用 MDM Server 的系统。其中包括 Data Stewardship 以及客户应用等。Data Stewardship 是一个可以对 MDM Server 底层数据进行管理和维护的 Web 应用。客户系统是指那些需要与 MDM Server 进行交互的系统。

1.2 请求框架（Request Framework）

请求框架为 MDM 服务的调用提供了统一的入口。MDM Server 支持 RMI(Remote Method Invocation) 和 Web Services 两种调用方式。

1.3 MDM Server 内核（MDM Server Core）

MDM Server 内核是整个 MDM Server 最核心的部分。它包含了 Party、Account、Location 和 Product 四个域模型以及相关的服务。MDM Server 中业务逻辑的执行、数据的持久化操作都是 MDM Server 内核完成的。

1.4 扩展框架（Extension Framework）

如果 MDM Server 中预制的数据模型或服务不能够满足特定的业务需求，扩展框架提供了对于数据模型和服务的扩展功能。开发人员可以通过 MDM Workbench 来完成扩展工作。

1.5 系统集成模块（IM/AM Integration, 3rd Party Integration）

系统集成模块为 MDM Server 提供了与其他系统、产品进行集成的功能。例如，可以与 DataStage、QualityStage 以及 iLog 进行集成。

2. Initiate 的体系结构

Initiate 也是一个基于 SOA 架构的企业级应用。由于其底层不是使用 J2EE 规范中的相关技术实现的，所以不用部署在 J2EE 应用服务器上。Initiate 中的数据同样是要持久化到关系型数据库中的，其目前支持的数据库有 DB2、Oracle 和 SQL Server。Initiate 的体系结构如下图所示。接下来我们将对主要组件模块进行介绍。

图 2. Initiate 的体系结构

1.1 消费系统

Initiate 与 MDM Server 类似，也包含一些消费系统。其中包括 Inspector 和 Enterprise Viewer。Inspector 是一个可以对 Initiate 中的数据进行管理和维护的 Web 应用。Enterprise Viewer 是一个可以查看 Initiate 中数据的 Web 应用。

1.2 MPINET

MPINET 为 Initiate 中业务逻辑的调用提供了统一的入口。它与 MDM Server 中的请求框架很类似。Initiate 支持 Web Services 和 Message Broker 的调用方式。Initiate 还提供了一些 SDK，客户端在使用了这些 SDK 后，也可以对 Initiate 中的业务逻辑进行调用。这些 API 包括 Java SDK、C++ SDK 以及 .NET SDK。

1.3 Master Data Engine

Master Data Engine 是 Initiate 最核心的部分。与 MDM Server 内核类似，Initiate 中业务逻辑的执行、数据的持久化操作都是 Master Data Engine 完成的。

1.4 系统集成工具

客户端系统通过使用 Initiate 提供的集成工具就可以与 Initiate 进行集成。这些集成工具包括 HL7 Query Adapter、Inbound Broker、Outbound Broker、SDK 等。

1.5 数据分析工具

Initiate 提供了数据分析工具，开发人员可以通过使用该工具对权值、阈值、Initiate 中存储的数据等进行分析。

构建方式的比较

所有系统或应用在投入使用之前都要经过开发的过程，这个过程就是系统的构建。接下来我们将对 MDM Server 和 Initiate 的构建方式进行比较。

1. MDM Server 的构建方式

MDM Server 的构建方式是众多开发人员所熟悉的，以下是其构建步骤。

• 进行需求分析，设计数据模型和服务。
• 根据所设计的数据模型，在 MDM Workbench 中进行配置，然后生成相应的代码和数据库脚本，最后通过运行数据库脚本在数据库中生成相应的数据表，从而对 MDM Server 中现有数据模型的扩展。
• 在 MDM Workbench 中创建所需的服务并利用其生成框架代码，然后在框架代码中写入所需的业务逻辑。在开发服务的过程中可能需要对 MDM Server 进行其它的配置，例如，根据需求修改其预制的 External Rule。
• 开发基于 Web 的管理界面。开发人员可以选择修改 MDM Server 自带的 Data Stewardship，也可以选择自行开发该管理界面。

通过以上步骤可以看出，MDM Server 的构建是需要开发人员写入代码的，而且在构建过程中是不会有真实的客户数据存入数据库的。

2. Initiate 的构建方式

Initiate 的构建过程与众多开发人员所熟悉的有所区别，以下是其构建步骤。

• 进行需求分析，设计数据模型。
• 根据所设计的数据模型，在 Initiate 的 Workbench 中进行配置。
• 在 Initiate 的 Workbench 中配置算法，该算法主要是用来描述数据在进行疑似重复比较时需比较那些属性，以及比较时所使用的比较方法。
• 将真实的客户数据导入数据库，数据量一般在 50 万条左右。
• 将数据模型和算法部署到 Initiate Master Service Instance。
• 根据导入到数据库的数据生成权重，该权重将用于疑似重复性比较
• 执行全数据库范围的数据疑似重复比较，根据比较结果纠正当前的阈值。阈值是 Initiate 用来判断是否执行 Link 操作的标准。
• 在 Initiate 的 Workbench 中配置 Inspector。

通过以上步骤可以看出，Initiate 的构建过程不需要写入任何代码，而且不需要开发基于 Web 的管理界面。另外，在其构架过程中需要导入真实的客户数据。

数据模型的比较

数据模型是对实际业务中所需数据的抽象，也是主数据管理的关键。接下来我们将对 MDM Server 和 Initiate 的数据模型进行比较。

1. MDM Server 的数据模型

MDM Server 底层数据模型主要分为四个域 (Domain)，Party、Account、Product、Location。Party 域是对组织 ( 包括企业、机构，政府部门 )、人员的抽象。Product 域是对不同行业的不同产品的抽象。Location 域是对地址与联系方式的抽象，对于一个人或组织而言，Location 主要是指联系地址与联系方式，而对于产品而言，则是指产品的存放地址。Account 域主要表现的是一种交易关系。Account 是 Party 域中的人 ( 或组织 ) 与在 Location 记录处存放的 Product 发生关系的结果的记录。这样四个数据域就非常巧妙的联系在了一起。这也是 MDM 系统数据模型思想的精髓所在。

如果 MDM Server 中预制的数据模型不能够满足特定的业务需求，那么 MDM Server 还提供了一套数据模型的扩展框架，其中包括 Addition、Extension、Demographics 三种对数据模型进行扩展的方法。通过 Addition，可以在 MDM Server 底层构筑一个崭新的数据模型；通过 Extension，可以对预制数据模型的属性进行扩展 ( 对原有的表结构进行扩展 )；通过 Demographics，可以对某一条记录的属性进行扩展。开发人员可以使用 MDM Workbench 对数据模型进行配置，然后生成相应的代码和数据库脚本，从而完成数据模型的扩展。

2. Initiate 的数据模型

与 MDM Server 不同，Initiate 中不提供任何完整的数据模型，而是预制了一些属性，这些属性包括 MemName，MemAddress，MemPhone，MemDate，MemIden，MemAttr。MemName 用来存储姓名，MemAddress 用来存储地址，MemPhone 用来存储电话，MemDate 用来存储日期，MemIden 用来存储与标识相关的属性，MemAttr 用来存储除前几个属性之外的属性。Initiate 数据模型的设计思想与 MDM Server 完全不同，它通过提供预制的属性，可以使开发人员根据具体的业务需要组装出相应的数据模型。开发人员可以使用 Initiate 的 Workbench 对数据模型进行配置，然后部署这些配置，相应的数据表就会在数据库中自动创建。

如果 Initiate 中预制的属性不能够满足特定的业务需求，开发人员可以使用 Initiate 的 Workbench 创建新的属性，然后再与其他所需属性组成所需的数据模型。

服务的比较

服务是对业务逻辑的抽象，也是主数据管理的关键。接下来我们将对 MDM Server 和 Initiate 的服务进行比较。

1. MDM Server 的服务

MDM Server 会预制一些与底层数据模型相关的服务，例如，Add Person，Update Person 等。MDM Server 中的服务主要分为两大类，Txn 类型的服务和 Inquiry 类型的服务。Txn 类型的服务是与持久化相关的服务，而 Inquiry 类型的服务是与查询相关的服务。

这些服务可以通过 RMI( 远程方法调用 )、Web Services 的方式进行调用。MDM Server 中的服务是基于请求 / 响应 (Request/Response) 模型的。在请求的报文中通常会包含一个 BObj(Business Object)。Business Object 是对一次服务请求中所要用到的所有数据的抽象和封装，其包含的元素可以是基本类型也可以是其它的 EObj(Entity Object, 是对数据库中某一张数据表的封装 ) 或者 BObj。一个 BObj 可以包含另一个 BObj 的原因是，在一次服务处理的过程中，有可能调用到其它一些相关的子服务。例如，一个人员的信息中会包含地址信息，那么在执行添加病人的操作时就会调用添加地址的子服务。在服务执行完成后，MDM Server 会将处理结果数据封装为 BObj，然后通过响应的报文将这个 BObj 返回至服务的请求者，从而结束了一次服务调用的过程。

如果 MDM Server 中预制的服务不能够满足特定的业务需求，那么 MDM Server 还提供了一套服务的扩展框架。这套服务扩展框架使用户可以创建符合用户特定需求的 Txn 类型的服务、Inquiry 类型的服务以及组合式服务 ( 一个服务中包含若干个子服务 )，还可以通过 Behavior Extension 对原有服务进行修改。开发人员可以使用 MDM Workbench 创建相应的服务并生成相应的框架代码，然后在框架代码中写入相应的业务逻辑，从而完成服务的扩展。

2. Initiate 的服务

Initiate 像 MDM Server 一样，也会预制一些服务。这些服务包括与底层数据模型相关的服务 ( 例如，Member Put，Member Search) 以及与系统配置相关的服务 ( 例如，Dictionary Get，Dictionary Put)。这些服务可以通过 .NET API，Java API，C++ API，Message Broker 以及 Web Services 的方式进行调用。Initiate 中的服务同样也是基于请求 / 响应模型的。在请求的报文中通常会包含一个 MemRowList(Member Row List)。MemRowList 是对一次服务请求中所要用到的所有数据的抽象和封装。MemRowList 中可以包含多个 Member 的数据，其中 Member Head 作为每个 Member 的标识，具体说来，MemRowList 中 Member Head 的数量就等于 Member 的数量。在服务执行完成后，Initiate 会将处理结果数据封装为 MemRowList，然后通过响应的报文将这个 MemRowList 返回至服务的请求者，从而结束了一次服务调用的过程。

Initiate 中服务的设计思想与 MDM Server 完全不同。Initiate 中的所有数据模型称为 Member，它提供了 Put Member、Get Member、Search Member、Delete Member、Drop Member 等较为通用的服务。开发人员无论创建了怎样的数据模型，Initiate 都可以支持对其增、删、改、查的操作。

数据唯一性机制的比较

由于主数据管理系统是对存储在分布系统中的数据进行管理，所以主数据管理系统中的数据出现重复的几率会很大。数据唯一性机制将最大限度地减少数据的重复性，是主数据管理系统不可或缺的功能。接下来我们将对 MDM Server 和 Initiate 的数据唯一性机制进行比较。

1. MDM Server 的数据唯一性机制

在 MDM Server 中将疑似重复的数据被分为四个等级，A1、A2、B、C。A1 级别表示两条数据一定是重复的，A2 表示两条数据可能是重复的，B 表示两条数据有可能是不重复的，C 表示两条数据一定是不重复的。

如果 CONFIGELEMENT 表中 /IBM/Party/SuspectProcessing/ 的值为 True，那么在添加、更新 Party 域的数据 ( 包括人员和组织 ) 时，MDM Server 会根据相应的业务逻辑 ( 该逻辑会以 External Rule 的形式暴露出来，用户可以根据自己的需求进行修改 ) 去数据库中查找疑似重复的数据，然后根据预定义的 Critical Data(Critical Data 就是数据库中的字段，是数据进行比较的标准，用户可以根据需求添加或删除相应的 Critical Data) 将要添加 ( 或要更新 ) 的数据与数据库中现有的数据进行比较，然后根据 Party Matching Matrix( 数据库中的数据表 ) 计算出相似度评分，从而得到疑似重复的等级。Party Matching Matrix 如下图所示。

图 3. Party Matching Matrix

如果 CONFIGELEMENT 表中 /IBM/Party/SuspectProcessing/PersistDuplicateParties/enabled 的值为 False，且欲添加 ( 或更新 ) 数据与数据库中现有的数据是 A1 级别的疑似重复等级，那么该数据将不会持久化到数据库；如果该值为 True，且欲添加的数据与数据库中现有的数据具有不同的 LOB Relationship，那么具有 A1 级别疑似重复的欲添加 ( 或更新 ) 数据就会被持久化到数据库，然后 MDM Server 会向消息队列中发送 Notification 进行通知 ( 发送 Notification 的前提是 CONFIGELEMENT 表中的 /IBM/DWLCommonServices/Notifications/enabled 的值为 True)。

2. Initiate 的数据唯一性机制

在 Initiate 中，并没有明确地划分出疑似重复的等级，而是定义了三个阈值，Auto Link，Task，Overlay。重复性检查会在添加、更新 Member 时被触发。

当添加一个 Member 时，Initiate 会先将数据从请求的报文中解析出来，并持久化到数据库，然后进行数据标准化并生成 Bucketing Data，再根据生成的 Bucketing Data 去数据库中查找疑似重复的数据，最后新添加数据再与查找返回的结果集中的所有数据进行比较，评出分数，如下图所示。如果分数大于 Auto Link 阈值，那么就会自动执行 Link 的操作，从而成为一个 Identity 类型的 Entity；如果大于 Task 阈值且小于 Auto Link 阈值，那么 Initiate 就会向 Task Queue 中发送一个 Task，以通知相应的系统；如果小于 Task 阈值，那么 Initiate 在添加新数据之后，不会再执行任何操作。

图 4. Initiate 的数据唯一性机制

当更新一个 Member 时，Initiate 会将欲更新的数据与原有数据进行对比，然后评出分数。如果，这个分数低于 Overlay 阈值，那么 Initiate 会向 Task Queue 中发送一个 Task，以通知相应的系统欲更新数据与原有数据差异很大，然后更新暂缓，等待相应系统的处理结果。

与 MDM Server 不同，Initiate 中的比较项是在 Initiate 的 Workbench 中通过拖拽的方式配置的。开发人员为哪个属性提供了 Comparison Function，那么那个属性就会在疑似重复比较时作为比较项进行比较。还有一点值得注意的是，在 Initiate 中，如果两条疑似重复的数据是来自于同一系统的，那么可以对其进行 Merge 的操作，但如果两条疑似重复的数据是来自于不同系统的，那么则不可以对其进行 Merge 的操作。

MDM Server 与 Initiate 的应用场景

以上，我们对于 MDM Server 与 Initiate 进行了较为全面的比较。在这一部分，我们将根据实际项目中会遇到的情况作为考量因素，介绍如何选择这两款主数据管理产品，并列举了两个真实的应用场景。

表 1. MDM Server 与 Initiate 的应用场景比较

考量因素	MDM Server	Initiate	选择及理由
数据模型	预制丰富而复杂的数据模型，主要分为 Party，Location，Account，Product4 个域，涵盖了日常经济活动中的所有实体，如果预制的数据模型不能够满足需求，MDM Server 还提供了 Addition、Extension、Demographics 等扩展数据模型的方法	预制一些常用的属性，并为这些预制的属性提供了标准化、比较等算法，开发人员可以利用这些属性搭建出符合需求的数据模型，如果预制的属性不能够满足需求，可以自定制属性，但是不能为自定制的属性定制标准化、比较等算法	1) 如果数据模型很庞大、很复杂时，建议使用 MDM Server，因为如果使用 Initiate，需要自定制很多属性，而且无法自定制相应的算法。使用 MDM Server 的好处是可以在预制数据模型的基础之上酌情进行扩展 ( 有时甚至可以完全使用预制的数据模型 )。 2) 如果数据模型相对比较简单，建议使用 Initiate，因为其开发周期较短。
服务	默认提供与预置数据模型相关的服务，若这些服务不能满足需求，MDM Server 还提供了一些对服务进行扩展的方法	默认提供对于数据模型进行操作的服务，但不能扩展现有服务	1) 如果想要对现有服务的业务逻辑进行修改或者创建一些有特殊用途的服务时，建议使用 MDM Server，通过使用 MDM Server 可以对服务随意地进行定制  2) 如果不需要定制特殊服务时，建议使用 Initiate，因为其开发周期较短。
构建方式	在开发的过程中需要在生成的框架代码中写入特定的业务逻辑，开发完成后还需要做大量的测试工作	整个的开发过程是拖拽式的，不需要开发人员写入任何代码，开发完成后也不会有太多测试的工作	由于 Initiate 的开发简单，所以其开发周期要比 MDM Server 的开发周期短
集成方式	MDM 作为 J2EE 应用，需要部署在应用服务器上，需要集成其他的 ETL 工作做数据抽取	不需要部署在 J2EE 服务器上，有 standalone 的 initiate service, 包含开源的 ETL 工具	如果你需要一个轻量级的解决方案，或有一定的资金限制，initiate 是一个比较好的解决方案
调用方式	可以通过 RMI 和 Web Services 对其进行调用	可以通过 Web Services，Message Broker，Java API，C++ API 以及 .Net API 对其进行调用	可以看到 initiate 提供更多的调用方式

应用场景一

下图是一个真事项目的数据模型图，这个模型看上去比较复杂，如果使用 Initiate，那么需要自定义许多属性，例如，URL，Email 等。而且 Initiate 不支持 URL 和 Email 等扩展属性的标准化、比较的算法。所以在这种数据模型较为复杂的情况下，应选用 MDM Server。在 MDM Server 中，Company 可以用 Organization 实现，Contact Person 可以使用 Person 实现，Address 可以使用 Party Address 实现，Telephone、Mobile Phone、Fax、URL、Email 可以使用 Contact Method 实现。如果使用 MDM Server，则几乎不用做太多的扩展，使用 MDM Server 预制的数据模型就可以满足需求。

图 5. 应用场景一 （查看大图）

应用场景二

下图是 EMPI 的总体架构图。EMPI 的主要作用是对病人的信息进行集中地维护，所以其数据模型并不是非常复杂，而且其还要遵守 HL7 医疗规范。在这种情况下，如果使用 MDM Server，虽然可以满足相应的需求，但是开发周期较长，且需要自行开发支持 HL7 报文格式的解析器。如果使用 Initiate，在满足业务需求的基础上，不仅可以显著地缩短开发周期，而且使用 Initiate 自带的 HL7 Query Adapter 即可实现对 HL7 报文格式的支持。

图 6. 应用场景二

总结

以上，我们从体系结构、构建方式、数据模型、服务、数据唯一性机制比较了 MDM Server 与 Initiate，进而分析了二者的区别。通过分析了二者各自的优势，最后给出了二者的应用场景。相信随着信息随需应变，以客户为中心的 IT 架构越发成熟，MDM 将发挥在各个行业中发挥其越来越大的作用。

 

文章转载于互联网