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

在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种数据错误中，按