基于 QualityStage 的 Duplicate Suspect Processing 的 SOA 方案

文档选项 未显示需要 JavaScript 的文档选项

级别： 初级

闫哲, 软件工程师, IBM
郑丹丹, 软件工程师, IBM
王玮, 软件工程师, IBM
尹瑞, 软件工程师, IBM

2009 年 10 月 15 日

Duplicate Suspect Processing 用来发现可能重复的记录，结合业务需求进行整理，以提高数据质量，广泛应用于客户关系管理中。 QualityStage 作为 IBM Information Server 套件的核心产品，通过数据分析、标准化、重复匹配、整理加工等一整套处理方法进行数据清洗，以建立满足需求的高质量数据。本文结合区域医疗的业务场景，提出了基于 QualityStage 的 DSP 的 SOA 方案，具体解释了 QualityStage 任务的开发、调试和服务部署、以及与 J2EE 应用的集成方法。

Duplicate Suspect Processing 简介

在很多行业中，客户是非常重要的主数据资源，它们的采集、存储和管理直接影响着业务的开展。而由于数据分布采集等原因，客户信息往往存在重复和不一致等问题，这会增加业务处理的负担，并且无法为同一客户关联所有相关的业务数据，从而降低客户满意度。针对这一问题，duplicate suspect processing（以下简称 DSP）用来发现可能重复的记录，结合业务需求进行整理，以提高数据质量。以医疗行业为例，医院为患者提供医疗服务，而一个人可能在多家医院就诊，在建立区域医疗电子健康档案时，来自不同医院的患者可能是同一个人，实际业务需要将所有医疗记录和相关信息关联到这个人，形成一份完整的健康档案。该场景中，DSP 针对来自不同医院的患者信息，进行匹配，合并重复记录，并结合业务逻辑关联相关信息。

QualityStage 是 IBM Information Server（以下简称 IS）产品套件中用于提高数据质量的核心产品，它可以针对多种类型的数据源，进行快速的清洗处理，通过数据分析、标准化、重复匹配、整理加工等一系列完整的处理步骤，形成满足用户需求的高质量数据。该产品共享 IS 的开发和运行环境，通过 Designer 支持开发人员对标准化规则、匹配规则等进行定制，只需将面板上的元素（Stage）拖动到任务画板上进行连接，就可以设计出符合需求的数据处理流程；借助 Service Director 将开发的任务发布为 Web 服务、EJB 等多种形式，从而与其它应用进行无缝集成；任务可以启动多实例运行，并提供监控和日志管理。

DSP 恰好可以充分利用 QualityStage 的匹配能力，发现可能存在的重复记录，继而清理客户记录，并关联业务数据。本文结合区域医疗的业务需求，提出了基于 QualityStage 的 DSP 的 SOA 方案。该方案采用分层架构，包括数据层、信息集成层、业务服务层和表示层，如图 1 所示。在“信息集成层”中开发 QualityStage 的匹配任务，并发布为 Web 服务；“业务服务层”提供针对客户信息的管理，适时调用下层的匹配服务；表示层则为客户提供统一的业务视图。

本文将结合具体例子说明 QualityStage 的开发和部署过程，以及 J2EE 应用如何与 QualityStage 进行集成，从而提供完整的 DSP 方案。

回页首

安装与配置 QualityStage

由于 QualityStage 属于 IBM Information Server 产品套件，它的安装也随 IS 一起进行。 IS 当前最新版本是 8.1，可以支持 AIX、Linux 和 Windows 等多平台。为提高灵活性，可以选择服务器端和客户端分开安装。因为服务器端要求较高的计算资源，推荐将服务器端安装在高配置的 AIX 机器上，而开发和测试使用的客户端则可以安装在 Windows 平台上。在开发和运行时，客户端需要实时连接服务器，完成管理项目和编辑、运行、监控任务等操作，而实际的运算在服务器端完成。

安装完客户端后，开始菜单中新增“ IBM Information Server ”文件夹，里面包含图 2 所示的几个主要工具。

其中，Administrator 用于管理项目，创建项目是开发任务的前提； Designer 用于开发和运行任务，Director 则监控任务的运行情况，这两者通常一起使用； Console 用于将编辑完的任务发布为多种形式的服务。

首先运行 Administrator，在登录窗口中输入服务器地址和端口号（IS 内置 WAS 的端口号），用户名和密码（IS 内置 WAS 的管理员用户和密码），以及服务器名称。这里需要注意的是，由于客户端和服务器端通信采用 RMI 的方式，需要在客户端所在操作系统的 host 文件中注册服务器机器名和 IP 地址的映射。

成功登录之后，Projects 标签页列出已创建的项目，点击 Add 创建新项目，命名为 SampleProject，其他采用默认设置，如图 4 所示。

然后运行 Designer，在登录窗口输入服务器地址和端口号、用户名和密码，以及当前项目。单击下拉框箭头，选择刚刚建立的项目名称。

成功登录之后，进入 Designer 编辑界面。新建并行任务，保存为 Jobs/dsp_sample 。

至此，开发环境已经准备好，进入下一步开发匹配任务。

回页首

在 QualityStage Designer 中开发匹配任务

QualityStage 提供一套完整的方法论，主要分为四个步骤，即 investigate、standardize、match 和 survive 。 Investigate 对现有数据进行分析，旨在发现数据中可能存在的规律以及异常； standardize 对数据进行标准化，将没有结构的数据分解成更小的、具有确定含义的数据项； match 匹配重复记录，通过设定匹配规约执行灵活的静态或概率匹配； survive 对数据进行整理，以形成统一的数据视图。

在本文的例子中，各医院的病人信息上传至中心数据库，进行 DSP 处理。由于系统异构性，病人信息的结构不一致，这增加了匹配的难度。 QualityStage 和 DataStage 都包含在 Information Server 安装包中，因此任务开发时会使用基本的数据处理 Stage 。本文假设有两家医院的病人信息，需要从中提取用于匹配的字段，合并到一起，再进行标准化和匹配工作。处理流程如图 6 所示。

据此设计出的匹配任务如图 7 所示，下文将详细介绍各步骤。

Source

在 Designer 中，通过 DB2 UDB Stage 加载数据，设置 PatientA 和 PatientB 表结构。

PatientA: 
 ID  varchar(20) 系统编号
 INSURANCEID  varchar(50) 社保编号
 SOCIALID varchar(20) 身份证号
 NAME varchar(20) 姓名
 GENDER varchar(4) 性别
 BIRTHDAY date 出生日期
 PHONE varchar(30) 电话号码
 ADDRESS varchar(100) 联系地址
 POSTCODE varchar(6) 邮政编码
 PatientB: 
 RECORDID varchar(16) 系统编号
 IDCARD varchar(18) 身份证号
 NAME varchar(20) 姓名
 SEX varchar(2) 性别
 BIRTHDAY date 出生日期
 RESIDENT varchar(100) 户口地址

[DB2 UDB Stage]Patient_A 的属性设置如下，Server name 填入数据库名（需要事先通过 db2 client 将该数据库 catalog 到本地），然后输入数据库的用户名和密码。

[DB2]Patient_A 连接输出线后，可以设置其数据格式以及与数据库表的连接。在 SQL 标签页选择默认类型” Use SQL Builder tool ”，将使用向导配置读取数据的 SQL 语句。在 SQL Builder 中，首先选择数据库表。由于是第一次添加，需要导入数据库表结构，通过 Import Meta Data->Plug-in Meta Data Definitions，导入 SAMPLE_PATIENTA 。选择其中用于匹配的字段，包含 ID、SOCIALID、NAME、GENDER、BIRTHDAY、ADDRESS 共 6 项。生成的 SQL 语句如图 9 所示。

然后在 Columns 标签页加载 SAMPLE_PATIENTA 的字段定义。

Transformer

[DB2]Patient_A 连接至 [Transformer]TransA，表示读取出数据后进行转换，以得到统一的数据格式，其设置如图 11 所示。为标识数据来源，在输出结果中增加字段 DOMAIN，取值为 PATIENTA ；系统标识字段更名为 LOCALID ；字段 GENDER 需要进行转换，统一对常量（男 / 女）的定义，其他字段不变。

类似的，[DB2]Patient_B 从数据库表 SAMPLE_PATIENTB 中读取数据，经过 [Transformer]TransB 的转换，生成与上面一样的数据格式。

来自不同数据源的数据通过 Funnel Stage 汇合到一起后，就可以进行统一的标准化和匹配了。

Standardize

QS8.1 内置了针对姓名、电话号码、地区、地址的中文标准化规则，使用它们可以将没有结构的字符串拆成具有明确含义的若干部分，以提高匹配的准确度。使用 Standardize 进行标准化，对姓名、地址字段分别应用规则，在 Stage 输出标签页中，就会增加标准化产生的字段，如图 13 所示。本例中选取部分字段供后续的匹配使用，如针对姓名的标准化产生的姓氏、名字，针对地址标准化产生的省、市、区、街道、街道号和邮箱。

Match

QS 提供了两种匹配 Stage，一种是 Unduplicate Match，一种是 Reference Match 。前者在同一种数据源内部进行匹配，找到其中可能重复的记录；后者针对两种数据源（分别作为 master 和 reference），找到 reference 数据在 master 数据中的重复记录。本例中虽然存在不同的数据源，但目的是作为一个整体来找到其中的重复记录，所以在经过 2-2 转换步骤后，使用 Unduplicate Match 。

Match Specification 是描述针对特定结构的数据如何进行匹配，它可以在多个任务中共享。新建 Data Quality->Match Specification，可以打开 Match 设计器。其中首先选择匹配类型，这里选择 Unduplicate Match 。然后声明数据格式，匹配的具体操作都是针对指定的数据字段进行的，可以将上步的处理结果保存下来，假设为 PATIENTTOMATCH，从而在这里指定。接下来设计具体匹配通路 (pass) ，每个通路需要遍历所有数据，根据分块 (block) 字段分组，同一组内的数据再根据匹配条件字段进行匹配。在第一个通路 pass_socialID 中，将身份证号作为分块字段，匹配条件为姓和名。在第二个通路 pass_name 中，将姓名和性别一同作为分块字段，匹配条件为身份证号、生日和标准化后的地址。每个通路还需要设置两个阀值，当计算出的权重值高于 match 值时，认为是重复记录；当权重值低于 clerical 值时，认为是不同记录；当权重值介于这两者之间时，作为相似记录。这里阀值使用缺省值 0，原因是在开始设计时，不确定实际数据的匹配情况，需要在分析测试数据的匹配结果之后进行设定。

回到设计中的匹配任务，Unduplicate Match 要求两个输入，一个是数据本身，另一个是对数据出现频率的统计。后者需要借助 Match Frequency，在其属性中选择已定义的匹配声明。这两个输入要与 Match 接受的两类输入严格对应，即在 match 属性的 Link Ordering 标签页中调整 Data 和 DataFreq 的实际输入。

Match 的输出包括主记录 (MP)、重复记录 (DA)、相似记录 (CP) 和无关记录 (RA) 。根据匹配声明的介绍，同一组的记录中会根据出现频率和对权重值的贡献等选择一条记录作为主记录，其他的权重值高于 Match 阀值的记录作为重复记录，介于 Match 和 Clerical 阀值之间的记录作为相似记录，低于 Clerical 阀值以及分块字段唯一的记录作为无关记录。本例关心可能重复的记录，因此勾选 MP、DA、CP 作为输出。同样的，在 match 属性的 Link Ordering 标签页中调整 Match、Clerical 和 Duplicate 的实际输出。如图 15 所示。

匹配结果在原有记录的基础上增加若干字段，包括：

• 匹配类型 qsMatchType：在 MP、DA、CP、RA 中取值；
• 匹配权重值 qsMatchWeight：根据通路中匹配条件的设置而计算的权重值。
• 通路序号 qsMatchPassNumber：确定匹配结果的通路序号；
• 数据记录标识 qsMatchDataID：为每条记录分配唯一序号；
• 匹配分组标识 qsMatchSetID：分组后主记录的标识；

将这些匹配结果作为输出，以便后续进行 Survival 处理。

Survive

Survive 可以处理重复的记录，依据不同的条件选择字段值，从而建立高质量的数据。本例从匹配的结果中取出主记录和重复记录，交由 Survive 处理。根据匹配分组标识，在同组中选择字段值：

• 出现最多且非空：身份证号、姓、名、性别、省、市、区、街道、街道号、邮箱。
• 最长：生日、地址。
• 唯一值：DOMAIN、LOCALID、匹配结果（取自 MP 记录）。

经过 Survival 的数据作为最终的主记录，和 DA、CP 的记录一起写入结果表中。

至此，匹配任务已经开发完成，从准备数据表中取出原始数据，经过转换、标准化、匹配、整合后存入结果表。

回页首

在 QualityStage Designer 和 Director 中调试匹配任务

Designer 可以编译、运行任务。如果出现编译错误，根据提示进行修改。可能出现的编译错误如下：

• 数据库 Stage 中数据字段与 SQL 语句不对应；
• 匹配声明定义或修改后没有分发（provision）至服务器；
• 数据处理流中类型映射不一致等。

确认编译通过后，运行任务，designer 会在任务图中以不同颜色显示当前实例的运行状态，蓝色表示正在运行、绿色表示运行完成、红色说明出现错误。

Director 为开发人员提供了更详细的监控和日志功能，它列出各实例的运行状态，选择一个实例，可以显示其详细日志。一旦实例异常终止，可以通过查看日志定位错误。 Director 运行界面如图 18 。

在对部分数据进行测试后，可以观察匹配结果，总结权重值的分布情况，从而确定 Match 和 Clerical 的阀值。关于调整匹配结果的最佳实践，将在随后的另一篇文章中具体介绍。

回页首

在 Service Director 中将匹配任务发布为 Web 服务

在 Designer 中开发的任务可以封装为 Web 服务，以便与其他应用集成。在此之前，需要对任务的属性进行设置。在 Designer 中，右键选择任务的属性，在通用标签页中勾选 Allow Multiple Instance 和 Enabled for Information Services，如图 19 所示。

运行 Service Director，登录后，显示工作区界面。下方列出已有的项目，这是服务发布项目，与 Designer 中的项目没有直接关系。新建项目 Sample，然后在该项目中工作。点击左上角导航栏的开发 DEVELOP-> 信息服务应用 Information Services Application，新建应用 SampleApp 。在其中新建服务 SampleService，采用缺省的包名 com.ibm.isd.SampleApp.SampleService，服务可以通过不同类型的绑定发布为不同形式，如 EJB、Web 服务、REST 服务等，这里选择 Web 服务，即 SOAP over HTTP，属性采用缺省设置。服务中包含若干操作，将缺省操作命名为 match，然后选择信息提供者，在打开的窗口中选择 DataStage and QualityStage 类型，就可以浏览服务器上的项目及包含的任务，选中 SampleProject->Jobs->dsp_sample 。保存该应用。

由于本例中匹配任务处理的数据量较大，所以通过数据库表来传递数据，并没有用到 WISD Input 和 Output Stage，这使得封装为服务操作后没有输入和输出数据。应用被创建后需要发布至服务器，才能暴露为 Web 服务。选择该应用，点击部署，保持缺省设置。发布成功后，当调用该服务时，IS 将自动启动匹配任务的实例，此时可以通过 Director 监控器状态，待任务完成后整个服务执行结束。

回页首

在 RSA 中生成 Web 服务客户端

IS 提供 Web 控制台，来管理发布的服务。在浏览器中运行 http://<is-host >:<is-port>/，登录后，选择 Information Services Catalog 标签页，点击 Manage Deployed Services，然后打开刚发布的服务 SampleService，在 Bindings 部分可以看到 SOAP over HTTP 的内容，这里点击 Open WSDL Document，就可以看到该服务的 WSDL 。

如果待处理的原始数据量较大，匹配服务的执行就需要一段时间。此时对于集成的其他应用而言，最好采用异步方式来调用该服务，从而提高系统利用率和用户体验。 Rational Software Architect for WebSphere v7.5 已经内置了对 JAX-WS 的支持，可以生成异步调用的 Web 服务客户端。

在 RSA 中新建 Web Service Client，在向导窗口中填入刚刚提到的 WSDL 地址，选择 Web Service Runtime 为 IBM WebSphere JAX-WS，并选择所在项目类型 Java Utility Project 和项目名称 SampleClientProject，如图 21 所示。

点击 Next，勾选 Enable asynchronous invocation for generated client，这使得客户端能够异步调用 Web 服务。点击 Finish 后将生成该客户端项目。项目中包含输入数据类型 Match，输出数据类型 MatchResponse，服务接口 SampleService，服务访问类 SampleService_Service 以及代理类 SampleServiceProxy，应用开发可以直接使用该代理类。

回页首

在 J2EE 应用中调用匹配服务

J2EE 应用可以借助上节生成的客户端来调用匹配服务。为简单说明调用过程，本例将在生成的主记录和相似记录间建立关联。

主控程序中通过客户端异步调用匹配服务。 matchAsync 是异步调用方法，输入参数是回调处理对象 asyncHandler，它发出调用后立刻返回，程序将显示提示信息。

			SampleServiceProxy proxy = new SampleServiceProxy(); 
 //asynchronous invocation 
 AsyncHandler<MatchResponse> asyncHandler = new MatchHandler(); 
 proxy.matchAsync(asyncHandler);logger.info("IS match job is started.");

回调处理类 MatchHandler 描述在匹配服务调用返回后如何进行处理，包含的 MatchRespones 即服务返回值。在接口方法 handleResponses 中，取出匹配结果进行处理，建立 CP 记录与 MP 记录的相似关系。

	 public  class MatchHandler implements AsyncHandler<MatchResponse> { 
	 public  void handleResponse(Response<MatchResponse> response) { 
	 ...... //read SAMPLE_MATCH and build relation between MP and CP 
	 for ( int i=0; i<sizeOfPart; i++){ 
	 record = (SAMPLEMatch)resultList.get(i); 
	 if (record.getQsMatchType().equals("MP"))
	 { 
		 primaryID = IDGenerator.allocateID(record.getQsMatchDataID());
		  ...... 
	 }else if (record.getQsMatchType().equals("CP")){ 
		 currentID = IDGenerator.allocateID(record.getQsMatchDataID()); 
		 PatientRelation pr = new PatientRelation(); 
		 pr.setRelationType(SampleConstants.RELTYPE_SIMILAR); 
		 pr.setSourcePatientID(currentID); 
		 pr.setTargetPatientID(primaryID); 
	 } 
	 } 
}

在该 DSP 方案的业务服务层，除了批量匹配客户数据之外，还提供增加、更新、删除以及查询客户的功能，它们暴露为 EJB、Web 服务等多种形式，可以为上层的表示层提供服务。

回页首

在表示层为客户建立统一视图

来自不同数据源的客户数据，经过 QualityStage 的匹配和 J2EE 应用的处理，已经建立起唯一而完整的客户记录。该记录既包含个人基本信息（demographics），这汇总了各数据源的个人信息；也包含与原始数据的关联，在此基础上可以找到与该客户关联的所有业务数据。本例中病人信息视图包含基本信息、健康信息，以及与各医院内病人编号的关联。

在上节中，疑似重复的客户已经建立关系，它们可以交由管理员进行人工干预，通过联系客户等方式确定是同一个人还是不同的人。管理相似人员的界面如图 23 所示。

回页首

结束语

在很多行业中，duplicate suspect processing 是普遍关注的问题，它用来发现可能重复的记录，结合具体业务进行整理，以提高数据质量。本文以医疗行业为例，提出了基于 QualityStage 的 DSP 面向服务解决方案。该方案充分利用 QualityStage 的数据清理能力，使用一整套工具，开发匹配任务，继而发布为 Web 服务，从而与病人管理应用集成在一起，消除重复记录、关联业务数据，最终为用户提供一个统一而完整的视图。

参考资料

• 通过 developerWorks Information Management 专区：在这里可以学到更多关于 Information Management 的知识。还可以找到技术文档、how-to 文章、培训、下载、产品信息等。
  
  
• 参考“IBM Information Server 信息中心”，了解更多 Information Server 的相关内容。
  
  
• 参考“IBM DB2 V9.7 信息中心”，了解更多 DB2 V9.7 及 InfoSphere Warehouse V9.7 的相关内容。
  
  
• 通过 InfoSphere 产品专题，了解更多有关 InfoSphere QualityStage 的产品和技术资源。
  
  
• 通过 用 IBM WebSphere DataStage 进行数据整合，第 3 部分 : 实时数据整合，了解更多有关 InfoSphere QualityStage 数据整合的技术资源。
  
  

• 使用可直接从 developerWorks 下载的IBM 试用软件构建您的下一个 Linux 开发项目。
  
  

• 参与developerWorks blogs并加入 developerWorks 社区。

作者简介

		闫哲，IBM 中国开发中心 SOA 设计中心的一名软件工程师。于 2007 年 7 月毕业后加入 IBM，参加了基于策略的 SOA 治理、面向服务的元数据管理、医疗行业解决方案等项目。

		郑丹丹，IBM CDL 软件工程师，2007 年开始做 QS dev Chinese solution 的 enablement， 现在从事QS core 方面的开发。

		王玮，IBM CDL 软件工程师，2006 年开始做 QS dev Chinese solution 的enablement，并参与了大量的 presales， post service 的客户用例。

		尹瑞， IBM 中国开发实验室SOA 设计中心的高级软件工程师，曾参与过国内外多个SOA客户项目的实施，目前正从事于医疗卫生行业解决方案的开发。

对本文的评价

太差！ (1) 需提高 (2) 一般；尚可 (3) 好文章 (4) 真棒！(5) 建议？