基于 InfoSphere QualityStage 的中文数据清洗解决方案

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

级别： 初级

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

2009 年 9 月 21 日

针对企业有效信息采集的需求，IBM 提出了基于信息整合的 solution，能够进行伸缩以满足任何信息量需求。 Information server 就是实现这个架构的产品，提供了数据理解，清洗，转换，提交四大功能。其中对数据质量方面的改善，就是由 InfoSphere QualityStage 来完成的。本文通过分析一个具体案例，说明如何使用 QualityStage 产品，为客户提供一套灵活的数据清洗方案。

案例分析

A 电信公司，对每个客户申请电话业务时，都建立了一条记录 , 现从公司战略出发，需要完成系统数据整合。通过系统整合，电信公司建立唯一的客户视图，汇总入客户关系管理系统。另外，对于决策系统而言，需要实时统计新增客户，以分析商务趋势。这需要在唯一的客户视图上，有新的客户记录输入时，电信公司能够迅速判断该客户为新客户还是既有客户。这个项目在实施的第一个阶段，将唯一的客户视图汇总入客户关系管理系统中时，面临了如下挑战，首先，电信公司，业务繁多，根据不同的业务分类，固话，移动，小灵通等，客户数据分别存储于不同的业务系统，因此导致同一客户在多个系统内保留有记录，项目实施需要准确定位出重复的客户，选出唯一的客户主记录，放入客户关系管理系统。另外，客户申请电话业务时，不同的书写习惯，手写造成的笔误，业务员录入的时候，数据存储的不规范，分类的错误，都加大了第一阶段业务数据整合的难度。

根据这个 case 的数据质量清洗需求，数据清洗项目开发人员选择了 InfoSphere QualityStage 作为清洗工具，它是 IBM 提供的解决数据质量问题的优秀产品，和 InfoSphere DataStage 一起提供了一个完整高性能的数据清洗转换的开发平台。它包含了一系列的具有某个特定数据清洗功能的 Stage，每个 Stage 能够根据用户需要，做合理的配置，同 InfoSphere Datastage 提供的 Stage 相互组合，完成某个具有特点数据清洗转换功能的 job，最后 job 能够被单独执行以完成用户的需求。

这个数据清洗开发平台，能够帮助客户管理，编辑数据标准化规则和匹配去重的策略，定制出用户满意的数据清洗方案，提高数据质量。在数据清洗的过程中，InfoSphere QualityStage 提供了一个标准的数据处理流程，分为四个阶段，每个阶段中，QualityStage 均推出了一到两个核心 stage，由用户选择配置去完成这一阶段清洗任务 job 的构建。

Investigate 支持多种输入格式，可以对单个字段，或多个字段同时进行调查，统计出每个字段值出现的频率，也可以基于 standardization 阶段使用的 stan ruleset，统计每个字段数据的分布情况，理解目标数据的结构。

Standardization 也支持多种输入格式，帮助用户识别错误，校验列值，给于针对不同国家的地址 / 人名 / 区域 / 电话号码等 stan ruleset 标准化用户数据。

Match 支持用户基于源数据自定义 match rule，对单个文件去除重复纪录，或者参考其他文件判断匹配纪录，并将所有的相似或者重复的记录分组，为下一阶段作准备。

Survive 支持用户根据最终的商业目的，制定 survive rule，从一组重复的记录中，根据规则交叉组合不同行的 column 值，生成最后的主纪录。

为了便于理解这个解决方案的制定过程，以及 QualityStage 如何应用，采用 20 多条样本数据作为演示输入，详细剖析该方案中 4 个阶段的实施过程。

回页首

Investigation

Investigation 阶段中，电信公司需要了解地址数据的来源主要是单位组织，还是个人，便于在决策系统中进行帮助分析。另外，客户关系管理决定了唯一的客户视图，需要该项目开发人员对客户数据去重，但是如何选择字段参加去重，得到有效的去重匹配数据结果，并有好的性能呢？在这一阶段，QualityStage 主推了 Investigate stage，它与 Datastage 提供的文件输入相关的 stage 一起，设计完成一个或者多个完整的数据调研 job 。它能够按列分析源数据质量，以及源数据的分布特点，能帮助用户在数据清洗设计阶段，清晰的认识项目目标，数据的规则和趋势，合理的决定规则的采用。以 demo 中的地址数据栏为例，由于中文数据的独特性，数据中字与字之间并没有空格，在中文的方案中，我们通常选择 Word Investigate，借助地址 Rule Set (CNADDR.SET)，帮助用户分析这个地址的特性。设计出来的 job，不仅能帮助用户了解到地址数据中组织，个人数据的百分比。而且能分析地址数据中重复和空字段的比率有多高，因为空字段太多的列做匹配的意义不大，重复的比例太高，则不能用于做 match 阶段的分组，这最终都会影响到最后的匹配结果。

回页首

Standardization

Standardization 阶段中，标准化地址数据输出，为下一步去重作准备。开发人员发现“久亚新 2 楼 48 号”，“久亚新二楼 48 ”明显应是同一个地址，可是直接用数据库 sql 查询，不能使其匹配，从而遗失了对整条记录而言，重要的匹配参考信息。总结下来，地址数据写法多样，经常会有略写的，导致两条数据基本相同，但一个信息更详细，一个信息有所缺失，用普通查找的方法，不能很好的把相似的地址数据找出来，所以采用 QualityStage 在这一阶段主推的 standardize stage，它提供了将数据按照可定制的划分策略，标准化为若干小的一致的地址单元功能。

1. 首先，要为固定的字段指定 RuleSet，例如地址数据，我们使用地址 rule（CNADDR.SET），姓名则使用中国姓名 rule.

2. 根据不同的字段，选择不同的 rule 。

3. 分析 stan 后的结果，地址数据被切分成了很多小得地址单元，比如城市，区域，街道，建筑物等信息，而且每个地址单元的内容被标准化成一致的描述方法，能够有效的帮助开发人员在下一个阶段制定合理的规则，并大大提高了同一个地址不同写法的匹配的可能性。观察下图可以发现，“久亚新 2 楼 48 号”，“久亚新二楼 48 ”被划分成了完全一致的三个小的地址元素，建筑物，楼层，房间号完全一致，特别是楼层信息，被统一成相同的数字写法。

回页首

Unduplicate Match

因为该项目最终需要生成唯一的客户视图，所以在 Match 阶段中，开发人需要最大程度的将重复的客户记录找出来，借助 standardization 的标准化结果，匹配有了更高的几率，但是开发人员发现仍然有些数据，比如“南昌市西湖区花园角 20 号”“ 南昌市西湖区花园 20 号 609 室” ，由于第一条地址记录的不完整，standardization 后仍然不能判断是否是同一个客户的记录。总结得出，不完整的记录，存在少部分错误的记录，以及属于同一个客户的单位和个人的记录，都是普通匹配技术很大的障碍。在 QualityStage 的 Match 阶段，推出了专为一个文件内部去重设计的 Unduplicate Match stage, 它可以支持多个路线的去重策略， 能够尽量最大化所有可能的情况，在每个路线中，开发人员可以指定

匹配方法，有两组字段是需要开发人员重点设置的，block 字段和 match commands 字段， block 字段用于客户数据的分组，比如以姓名分组，所有姓名是“成海江”的记录将被放在同一组，然后组内，每条记录会根据在 match commands 字段中选择的列名相互做概率匹配计算，最后生成的权重累加，得到每条记录的最终权重值，这个权重值会与两个用户指定的临界值进行比较，根据比较结果，每条记录被自动的标记为主记录，重复记录，和相似记录。完全没有匹配的记录会作为留存记录参与下一条路线的匹配规则。

分析数据后开发人员根据数据特点，分成了 4 个分支。首先，像身份证号，电话号码，都是客户的唯一标示符，开发人员相信这个字段的重要性，尽管有些缺失，导致不太相同，但仍然极大程度的代表了数据的唯一性。开发人员在第一个分支里，就采用了 number 作为 block 域，将数据分组，如果客户的 number 号与姓名都相同，开发人员认为他们就是同一个客户的多条记录。但是开发人员也发现，有些姓名的写法相当相似，但是却不是完全匹配的，比如“王赟”“ 王贇”， 这很有可能是客服小姐，在录入时选择了不同的输入法导致的，那么如何匹配这两条记录呢？开发人员发现，这两条记录不仅 number 一致，而且地址信息基本一致，所以在第二个分支里，开发人员仍然采用 number 作为 block 域分组数据，以地址数据作为 match 域，意味着 number 相同，地址也相同时，认为他们匹配上了。以下各表展示了整个处理过程。

Pass1 - ID number 字段被作为 block 域，选择 name 作为 match commands 域。

Pass2- ID number 字段被作为 block 域，选择重要的地址字段作为 match commands 域，当姓名又缺失，或者错误的时候，数据能在 Pass2 中被匹配。

两条分支之后，开发人员发现 60% 可以匹配的数据都匹配上了，那么剩下的 40% 是因为什么原因漏掉的呢？ 原来有部分 number 号码不全，比如成海江的 number 号“ 932602197810159079 ”，“ 932602781015905 ”，开发人员由此想到，把姓名作为 block 字段，选择相应的地址域参与匹配计算，就能成功地匹配这部分数据。运行完这三条分支之后，匹配上的数据概率有所增长，但是仍然有一部分数据没有理想的结果。开发人员由此从新审视数据和之前的调研结果，发现在第一部分的调研结果中，表明有 30% 以上的组织数据，那么大量的地址信息用于匹配的时候，有可能地址信息并不存在，所以在最后一个分支中，开发人员选择了 number 作为 block 字段，组织信息作为 match 字段。

Pass3- 姓名作为 block 字段，地址域参与 match 运算，当 number 缺失或者有错误信息时，数据仍然能够根据 pass3 的配置被匹配。

Pass4- 根据第一步 investigate 之后的结果，我们知道数据组成里还有 30% 以上是组织数据，所以加上最后一个 pass 。

匹配最后的结果显示出了 4 条分支的匹配情况，每条记录的权重得分，以及主记录和重复纪录的标示，这个结果也让客户感觉非常满意。

回页首

Survive

客户关系管理系统最终是希望有一个唯一的客户关系视图，第三个阶段 match 之后，重复的记录都已经被找到了，在 Survive 阶段中，开发人员需要将重复的记录合并成一条唯一的记录提交给客户关系管理系统。观察第三个阶段后的结果，发现数据根据 setID 被分成若干组，当开发人员选择留存的数据时，也需要建立相应的规则。首先，qsMatchSetID 被选择作为分组的列，然后要在分组的记录中，选择名字，地址，号码值。选择方法是可以根据具体的数据情况，客户的偏向去作选择的。在这个项目中，开发人员规定，地址数据，在小组中选择最长的输出，号码数据，则选择出现频率最高的输出，姓名则直接输出主记录所对应的姓名即可。

输入：

输出 Survive 后，可以看到小组内的数据被交叉组合，生成了唯一的一条客户记录：

回页首

唯一客户视图

最后，开发人员需要将完全没有匹配的数据，它们代表这部分数据，没有重复记录，和在第四阶段中挑选出来的去重记录进行组合，借助 Datastage 提供的 funnel stage 可以方便的合并数据，最终客户关系管理系统得到了他们满意的唯一客户视图。

回页首

结束语

这篇文章通过一个具体的案例，介绍了 InfoSphere QualityStage 的四个经典流程在数据清洗解决方案中的一种批量处理的应用，该应用创建了用户满意的客户唯一视图。对于案例中的决策系统，需要实时统计新增客户，是另一种实时处理的经典应用，与本文介绍的应用中有很多相似的设计过程，同时也有一些实时应用的特殊性，将在以后的文章中介绍。

参考资料

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

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

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

作者简介

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

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

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

对本文的评价

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