在SOA中创建独立的数据清洗服务

在soa架构中开发一种独立的服务，它能够在服务之间进行数据交换时检测和清洗错误，这样不仅能在第一时间保证数据质量，而且可以避免为每个涉及数据交换的服务开发错误数据检测和清洗程序，从而大大减少了程序员的开发工作量。

SOA为IT系统的设计、开发和部署提供了一种新的思路。通过引入SOA的架构，IT系统解决了系统紧耦合、异构系统的互联互通及标准服务契约等问题。特别是SOA把Web Service作为SOA中的服务的标准实现方式，为后续的服务组合和业务流程编排提供了基础。然而，SOA只是为IT系统提供了好的基础架构，至于服务如何组合以及服务之间的数据如何交换还需要另外考虑。比如，保证服务之间交换的数据的正确性就一直是组合服务时一个很头疼的问题，因为数据的质量不仅影响服务组合后的运行结果，很可能还会影响未来基于这些数据所做决策的正确性。

实际上，有关数据质量保证的研究在许多领域都在进行中，特别是在数据库和数据挖掘领域。这些研究主要集中于在数据库中标识脏数据，比如在数据库中标识某个表中的多余值或者名字和结构冲突等。另一方面，使用统计的方法来标识数据集合中的可疑数据或丢失数据的研究也在进行中。不过，这些办法都是在数据收集保存下来之后对数据进行处理的，属于事后处理，而本文提出在服务之间进行数据交换的同时进行数据清洗。

独立数据清洗工具的不足

部署独立的数据清洗工具几乎是目前进行数据质量保证最为流行、也最为有效的办法，市场上也有不少商业化的数据清洗工具可供选择。不过，如果SOA环境中数据清洗只是单纯地依靠某个清洗工具，将会引发一些问题。比如，只依靠某个数据库的清洗工具或者数据挖掘系统来完成数据清洗的话，可能由于数据库与应用系统的数据规则不同而导致应用程序无法处理，从而引发程序错误; 或者将不正确的数据存入数据库，从而导致未来决策以及系统间对账的不准确。为了解决这些问题，许多应用系统不得已另外引入了数据清洗工具，尤其是在与数据挖掘有关的应用中。然而，这些工具一般都只应用于数据挖掘等特定应用的特定数据种类（比如，邮件地址、地址变动、寻找重复的人等），而且它们是独立开发的，一般很难在SOA架构内部使用。具体而言，独立的数据清洗工具有以下不足:

首先，不可能保证服务之间数据交换的质量。例如，两个交互服务（服务A和服务B）之间要交换数据（这些数据构成数据集），服务B将数据集的某个数据删除了或者系统中的清洗工具正在对它进行清洗，但是服务A并不知道，可能要一直等待这个数据的到来。要避免出现这种情形，就要求数据清洗服务能够在服务中实时地监测数据的交互。

其次，在SOA架构下，开发者为了满足服务对数据输入和输出的要求，往往需要对服务的内部进行调整。例如，通过集成服务A和服务B来创建一个新的服务，假设A已经输出数据集，但B只是处理该数据集中的部分数据，而且A中的数据并不完全符合B对输入数据的要求，这时，就需要对B服务进行修改，此时独立的数据清洗工具派不上太大用场，而能单独管理服务间的数据交换的独立服务则能完成这一任务。

第三，即使有一个由单独组件开发的清洗工具，如果不满足一定的要求，仍然不太可能灵活地进行脏数据检测。换句话说，即使一个清洗工具被开发成一个组件应用于服务A和服务B，要让清洗引擎重复更新以反映规则中的任何变化，从而建立新的规则去检测从服务A输出的数据中的错误，是非常困难的。这个以单独组件形式存在的清洗工具必须具备灵活地处理数据集中规则和约束变化的能力，而且一定要使用XML作为标准的交互语言。

另外，数据清洗工具是在所有的数据都已经收集存储起来后才使用的，与之相比，在数据输入的同时就进行数据的校验和清洗显然具有更多的优势。为此，人们提出开发出一种独立的服务，该服务符合SOA的规范，能够在服务间的数据交换过程中检测和清洗错误。其优点是能减少开发者组合服务时的重复劳动，而且能有效地管理应用系统中的数据，尤其是像电子商务这类需要频繁交互的系统。实践证明，通过应用此服务来集成基于SOA的CRM和EPR服务，能将两个服务间数据交换中出现的错误减少30%以上。

制定脏数据检测规则

检测和清洗脏数据之前必须明确脏数据的分类以及检测和清洗的规则。

我们根据数据收集、集成及储存的各种数据处理过程，将数据库中可能发生的错误进行分类。如表1所示，能够被处理的用于服务间交互的脏数据种类一共有33种类型。“可检测的”代表脏数据能够被服务开发者设定的限制或者使用特殊工具检测到。在这33种脏数据种类中，有12种属于交互数据错误，其他的数据错误主要发生在数据库中或者只在和其他数据集对比的时候才被称之为脏数据。而在这选取的12种数据错误中，按照服务开发者设置的限定只有6种能被称之为可检测的。而一些数据错误，比如拼写错误、无关数据登记项、歧义数据以及不完整文本都能使用特殊工具检测到（如拼写检查工具）且大部分都与自然语言处理有关，所以这些数据种类都不属于此次研究的范畴。

接下来，要将检测和清洗脏数据的规则与脏数据的分类对应起来（参见表2），表1中可检测的6种交互数据错误在表2中分别都有相应的检测和清洗规则。值得一提的是，在规则11中列出的错误检测采用的不是专门的工具，因此不可能标出识所有的错误。其中，部分的错误检测可以使用普通的表达式，比如使用yy/mm/dd、yyyy/mm/dd来描述日期、邮政编码中的数字或者电话号码只能是数字、用“string@string（.string）”来描述邮件地址、用“（string.）+string（.string）”来描述网址和URL等。

开发数据清洗服务

SOA中控制数据质量的基本服务由转换、检测以及清洗等处理过程构成（参见附图），即输入数据和用户数据约束的转换过程、按照特殊规则从脏数据中提取必需信息的检测过程以及在浏览器中显示脏数据的清洗、相关统计的清洗过程。

该服务在Windows 2000 Server环境中用Java 2的企业版实现。下面对服务中的主要过程进行描述:

从输入到XML转换器: 对服务器A中输入的数据进行XML要素的映射（服务中所有的规则都是使用XML编写的），如需要可为其赋予层级结构。

数据约束: 从服务器用户接受输入数据的相关约束。例如，ID必须唯一且不能为空。

生成XML的数据约束扩展信息: 包含了从输入文件中转换成XML扩展文件，其中每项数据的约束都是符合规定的。XML文件的扩展必须符合规定的XML文档类型定义（DTD）。这种DTD分为4部分: 规则申报部分、类型申报部分（过滤出错误类型数据）、数据申报部分（按照输入规定接收到的元素值和数据）以及属性申报部分（每个元素的约束）。

XML扩展语法: 只有那些必要的信息才使用XML语法分析器从XML扩展文件中提取出来。作为分析结果，每项数据的元素名、元素ID、需要的规则数量、类别数量和规则条件都被提出来。

检测脏数据: 根据此前制定的有关脏数据的检测规定对数据进行分析。

清洗: 根据上面的检测结果和制定的清洗规则对有错误的数据进行修正。清洗信息提供了被检测出的脏数据的名称和值。

生成报告: 依据脏数据的统计信息生成报告。

将被清洗后的数据转换成XML: 当数据被清洗后，数据值将被替换成清洗后的值。

检验数据清洗服务

我们将这项服务应用在一个由9个服务构成的系统中，用于完成订单的处理。

订单的处理过程如下: 购买者将订单信息通过CRM系统（客户关系管理系统）发送给ERP系统（货品管理系统）。ERP系统判定是否要批准或拒绝该订单，然后使用电子邮件方式发送给客户或者将拒绝结果展示在对话框中。这个系统由多个服务组成，分别是负责下产品订单的CRM系统（Service A）和订单处理的ERP系统（Service B），这两个服务处理之后的信息由XML文件服务（XML文件服务）先转换成XML文件，然后发送给传输信息的服务（SMTP服务）和显示结果的服务（结果显示服务）。为了减少数据在服务A与服务B之间数据转换时所发生的错误，应把脏数据检测和清洗服务加入到这两个服务之间。

这是一个很有代表性的多服务整合并在服务间有比较大量的数据转换的应用实例。通过将脏数据检测和清洗服务作为一个独立的服务器嵌入到CRM系统和ERP系统之间内，即可对CRM系统和ERP系统的数据进行分析和检测，这些数据错误包括购买者所填信息错误、服务间数据处理范围不一致以及网络原因造成的数据传输错误等。

数据的检测和清洗过程如下: 当从CRM系统中接收到了数据集时，数据检测和清洗服务器通过相关界面从用户服务器接收数据的约束，此时将生成XML扩展信息并且发送至检测流程。在检测流程中，服务使用脏数据检测算法进行检测并将结果展示给用户，提供给客户一个环境去清理脏数据。另外，该项服务可将所有数据信息或是所有脏数据信息以及统计结果展示给用户。

保险业务系统的数据质量保证

目前在保险行业，伴随行业监管要求的逐步加强、保险公司全国大集中模式和基于SOA进行系统整合的趋势日益明显，保险公司现有系统之间、与行业监管平台之间、与外部渠道之间，甚至保险公司总公司与各个分公司之间都存在各种服务调用和数据交互。如何保证交互过程中的数据质量问题，已经不仅仅影响保险公司自身的运营，还直接影响行业监管部门对保险公司的监管，甚至会影响到终端客户的切身利益。

实际上，在保险行业应用的系统整合过程中，数据质量及数据一致性问题是集成的重中之重，如何保证业务系统、财务系统、再保系统、决策分析系统，甚至行业监管机构间传输的数据的一致性和各自系统中数据质量问题，是基于SOA集成项目的一个重要课题。因此，在基于SOA进行系统整合的过程中，数据的检测和清洗工作的重要性将被提升到一个新的高度。

而本文介绍的这种基于SOA的脏数据检测和清洗服务可以应用于保险行业的业务系统，特别是频繁进行数据交互的业务系统中。比如，保险核心业务系统需要集成周边渠道、财务和再保等，而成熟的脏数据清洗服务对数据质量的有效控制将直接帮助保险公司降低经营风险、减少决策失误和提升客户满意度。除了保险核心业务系统与财务系统和再保险系统之间的数据交换外，可以应用脏数据的检测和清洗服务的还有行业监管平台与保险公司核心业务系统之间的数据交互以及数据挖掘。

另外，通过允许用户使用XML来设定检测规则给服务用户提供进行数据约束的灵活设定，还能提升IT部门运维的效率。当检测和清洗结束后，按照规则计算出的脏数据率、单个数据的脏数据率和清洗后脏数据率，可以指导IT部门进行数据质量的维护工作。