数据清洗：问题和当前的途经

来着 Haka Donna 博客

数据清洗：问题和当前的途经

Erhard Rahm(埃哈德·兰姆) hong hai do（洪海渡）
莱比锡大学（德国） http://dbs.uni-;eipzig.de
翻译：
概念
我们将数据质量问题分类为对数据清洗的概述和提供对主要解决途径的总揽。在集成异构数据源时，数据清洗尤其需要。并且应该和计划-关系数据转换一起来演讲。在数据仓库中，数据清洗是一个被称为ETL过程的主要部分。我们同样将讨论当前用来进行数据清洗的工具。

1 介绍
数据清洗，同时也被称为data cleansing或者scrubbing,是为了改进数据质量而执行从数据中探测并驱除错误和矛盾的过程。数据质量问题出现在单个数据集合中，如文件和数据库，比如由于在数据输入少拼写，丢失信息或有非法数据。当多个数据源需要被集合起来，数据清洗的需求就显著增加了。比如，在数据仓库中，联合数据系统（federated database systems）或者基于网络的全球信息系统。为了提供精确稳定的数据访问，不同数据形式的合并与消除重复信息狴犴得很需要。

数据仓库要求并且也提供了对数据清洗的扩展支持。它们装载并且不断从大量不同的源更新数据，所以某些源包含脏数据的可能性是很高的。进一步说，数据仓库是用来辅助决策的，因此数据正确性对避免错误结论是至关重要的。比如，重复或者丢失信息将产生错误和误导状态(无用输入，无用输出)。归咎于广泛排列可能数据不一致性和纯粹数据体积，数据清洗被认为在数据仓库中最大的问题之一。在ETL过程（图1）， 处理计划/数据翻译和集成的深层数据转换，通过过滤和合并数据来在数据仓库中执行存储。如图所示，在装载被转换的数据进入数据仓库前，所有数据清洗典型地完成于在一个独立的数据输入分段。大量有分类功能的工具能完成这些任务，但经常地，一个重要的清洗转换的工作将被手工或者低水平程序完成，因为这些工作很难写和维护。
联机数据库和网基信息系统数据转换的过程和数据仓库的类似，特别的，通常有为提取数据源做的包装和为集成作的一个调停。目前为止这些系统只能为数据清洗提供有限的帮助，他们主要关注于为计划转化和集成做的数据传输。数据需要从多个数据源提取出来而不是如同在数据仓库中那样预先集成，在查询进行时被转换和联合。这些通信联系和处理过程的迟缓所造成的影响是无法在可以接受的响应时间内完成。在提取和集成过程中需要作的数据清洗工作的努力，将进一步增加响应时间，但这是为完成有效的查询结果所强制的。
一个数据清洗途径应该满足及个需求。首先，它应该探测和消除所有主要的错误和不一致，无论单个还是在集成多个数据源时。该途径应该被工具支持来限制手工查找和编程努力，并且可以方便地覆盖增加的源。此外，数据清洗不应该孤立地完成，而应该和基于可理解的原数据的计划-关系数据转换协同。为数据清洗和其他数据转换作的映射功能应该通过一个被声明的方法指定并且在其他数据源查询处理时也可以重用。特别地对数据仓库来说，一个工作流的基础构造应该有支持处理所有多源数据和大数据集合转换过程的稳定有效的方法
当大量的对模式转化和整合的处理研究存在时，数据清理仅得到研究机构的很少注意.有些作家关注于重复的鉴定和消除，有些研究组织注意于不仅和数据清洗有关的通用问题，比如特殊数据挖掘，基于计划比较的数据转换。最近，一些研究努力建议和调查使覆盖多个转换状态的数据清洗更易于理解和统一处理，特别算子和它们的执行。
在这篇文章中，我们提供一个对这问题在数据清洗和解决方法上的全局阐述。在下一章节我们提供一个对这些问题的分类。第三章讨论用工具进行的主要清洗方法和研究文献。第四章总览包括ETL在内的商业上的数据清洗公爵，第五章是总结。


2．数据清洗问题

这章分类了用数据清洗和数据转换来解决的主要数据质量问题。如我们所知道的那样，问题都是相互关联而且由此就可以以同一种方式来处理。对于在结构，表达形式或者数据内容上任何的改变数据转换都需要提供支持。这些转换在很多情况下变得很有必要，比如模式演化的处理，遗传系统到一个新的信息系统的迁移，或者当多个数据源需要集成时。如图2所示，我们粗略地在一源和多源之间模式和实例相关问题之间进行分类模式。模式水平问题自然又实例反映出来；他们可以在改进的模式设计，模式转换和模式集成中讲述清楚。实例级别的问题，从另一个方面来说，和在实际数据内容上的错误和不一致相关，这些是无法在模式级别上可以解决的。它们是数据清洗基本关注的东西。图2同样显示了对于很多例子来说较为典型的问题。尽管没有在图2上表示，和某些多源问题一样。一源的问题发生在多源的实例中。



2.1单源问题

一个源的数据质量很大程度上取决于它是否用模式和集成约束控制容许的数据值来管理。对于没有模式的源，比如一个文件，几乎没有对什么数据可以被输入和存储有限制，将带来很大错误和不一致性的可能性。数据库系统，从另一方面说，加强一个特定的数据模式的约束（比如，the relational approach requires simple attribute values ,referential integrity, etc）正如特定集成约束的应用一样。模式相关数据质量问题常因为适当的模式指定的缺乏或者应用集成约束的缺乏，比如由于数据模式的有限性或者较差的模式设计，或者因为只有横扫较好的集成约束被定义去限制超过集成控制的过高构架。实例方面的问题和无法在模式级别预先消除的错误和不一致性相关。（比如，拼写缺漏）。

对于模式和实例级别两者的问题来说，我们可以区分不同问题的范围：属性（类别），记录，记录类型和源；这些事例的范例在table1和2中都有展示。记住在模式级别的唯一约束并不能避免重复实例，比如，如果真实世界的相同信息用两种不同的属性输入（看表2的例子）。

得到干净的数据源是一个昂贵的过程，避免脏数据被输入显然是减少清洗问题的一个重要的步骤。这就要求一个合适的对数据库的模式和集成于数的设计，数据输入应用也是一样的。同样，在仓库设计时的数据清洗规则的发现能改进约束，这是通过已有的模式做到的。

2.2 Mulit-source problems
这个在单源中出现的问题在多源需要集成时表现得严重得多。每一个源可能包含脏数据而且这些源中的数据表现形式也可能不同，交叉或者抵触。这是因为这些源是为了不同的需求开发，配置，维护。这导致大量的关于数据库管理系统的异构，数据模式，模式设计和实际数据。在模式级别，数据模式和模式设计的不同处可以通过模式转换和集成来得到解决。和模式设计相关的主要问题三命名和结构冲突。命名冲突是当相同的名字被用在不同的对象（同名异物）或者不同的名字用在相同的对象上（同物异名）时产生的。结构冲突发生在很多变量和对不同源的同一对象的不同陈述的引用中，例如，属性与表的表达方式，不同组件结构，不同数据类型，不同集成约束等等。另外，对于模式级别的冲突来说，很多冲突只在实例级别显示（数据冲突）。所有的单源问题能够在不同源中以不同的表现形式发生（例如，重复记录，矛盾的记录。。。）更多的是，即使有相同属性名和数据类型，也有可多个有不同的值表达式（比如对于婚姻状况）或者跨越不同源的不同的值的传达（比如，美元和欧元的计量单位）。更多时候，在这些源中的信息可能被不同的合并级别表达（比如，当前销售时来自昨天的源1和上周的源2）。一个多源数据清洗的主要问题是确认相互交迭的数据，即相关联的同一现实世界实体的特定匹配记录。这个问题有时被称为对象身份问题，重复消除或者融合/净化问题。经常地，信息只是部分的冗余，同时源可能通过提供增加关于实体的信息完成对数据的处理。因此，重复信息可能被净化并且完成信息处理的过程应该为到达对真实世界尸体的持续的观察被整理融合。

在图3例子中的两个源都三有理数形式但展示的模式和数据冲突。在模式级别上，有命名冲突（同物不同名，客户/顾客，Cid/Cno, Sex/Gender）和结构冲突（不同的名称和地址表达式）在实例级别上，我们注意到有不同的性别表达方式（“0”/“1”vs.“F’/”M”）和可以假定的重复记录（Kristen Smith）.稍后的发现同样展示当Ｃｉｄ／Ｃｎｏ都是源指定的身份，他们的内容是不能在两个源中进行比较的；不同的数字（１１／４９３）可能关联到相同的人。但不同的人可能拥有相同的数字．解决这些问题需要模式整合与数据清洗；第三个表显示了一个可能的解决方法．注意模式冲突应该第一个被解决，这是为了数据清洗能在基于一个统一的命名和地址表达式上探测重复，匹配gender/sex的值通常，数据清洗涉及到几个方面
·　数据分析：为了探测三何种错误和不一致性需要被消除，需要一个针对细节的数据分析．另外对数据或者数据样本的手工探测，分析程序也要可以收集关于数据的属性的元数据和探测数据质量问题．
·　转换工作流和映射规则的定义：取决于数据源的种类，数据源的异质程度和它们的数据＂肮脏＂程度，可能不得不执行大量的数据转换和清洗步骤．有时候，一个模式转换可能被用于将源映射到一个普通数据模型；对于数据仓库来说，关系表达式典型的被用到．前期的数据清晰步骤可能改正单源实例问题并且准备开始数据集成．稍后的步骤处理模式／数据集成和清洗多源实例的问题，例如，重复．针对数据仓库，为这些转换和清洗步骤作的控制和数据流应该用定义ＥＴＬ过程的数据流规定（图１）．
　为能够自动化生成转换数据代码，模式相关数据转换和清洗步骤，需要尽可能的用一种公布的查询和映射语言来规定．另外，在一个数据转化工作流中调用用户编写的清洗代码和特定目的工具也应该是可以的．转换步骤也可能因为用户没有建立清洗逻辑而要求用户对数据实例反馈．
·　确认：一个转换工作流和转换定义的改正和效果应该被测试和评估，比如，在一个样本或者复制品中，为了可能的需要而改进定义．分析，涉及和确认步骤的多个反复可能是必须的，比如，因为一些错误在应用一些转换后仅仅变得表面化．
·　转换：执行转换的步骤既可能通过装载和刷新数据仓库ＥＴＬ工作流也可能通过回答多源上的查询．
·　清洁数据的回流：在（单源）错误消除后，为了给后续应用以改进的数据和避免未来数据提取重复做清洗工作，清洁数据应该替代源中的肮脏数据。对于数据仓库，清洁数据是可以从分段运输区域利用的。（图１）
转换过程很显然要求大量元数据，比如模式，实例级别数据特征，转换映射，工作流程定义，等等。对一致性来说，机动性和重用的便利性，这个元数据应该在基于ＤＢＭＳ的库中可以维护。为保证元数据质量，关于数据转换过程的细节信息要在库和实例中被记录，这些信息包括关于源数据和系列信息的完整性和更新度的特定信息，而系列信息是关于转换对象的最早状态和应用到它们的改变。例如，在图３中，导出的表Customers包含了允许最终原记录的CID和Cno的属性，
接下来，我们描述更多用于数据分析的详细的方法（冲突探测），转换定义和冲突决定。对于模式转换的方法和模式转换的集成，我们在这篇著作中涉及到他们的问题已经广泛的被研究和描述了。命名冲突可以通过重命名来解决；结构性冲突要求局部重构和对输入模式的融合。

3.1数据分析
在模式中反映的元数据显然没有充分估计到源的数据质量，尤其如果只有少量集成约束存在。这样的话分析获得真实元数据特征或者特别的值模式的实例是很重要的。元数据帮助找到数据质量问题。更多地，它对确认源模式的关联属性用重要作用，基于这些属性才能得到自动化数据转换。
有数据压型和数据挖掘两种用于数据分析的方法。数据压型关注于单独属性的实例分析。通过它能得到比如数据类型，长度，值的范围，离散值和频率，变量，唯一性，空值的发生，典型string式样（例如：电话号码）等信息，提供一个能对各种质量方面属性的额外的察看。
表3展示了元数据如何能辅助探测到数据质量问题的范例。

数据挖掘有助于在大型数据中发现特殊数据模式，比如，多个属性所拥有的关系。这是被称为描述性的数据挖掘模式的关注点，它包括聚类，摘要，联合发现和排列发现。如[28]所示，在属性中的集成约束如功能依赖或者专门应用中的“商业规则”都能实现，它们可以用来完成丢失的值，改正非法数据和从数据源中确认重复的记录。例如，一个高可信度的联合规则能在实例违背规则时暗示出现了数据质量问题。所以一个可信度达99%对于规则”total=quantity*unit price”显示1%的记录不符合比功能且要求更细的诊断。

3.2 定义数据转换
数据转换一般处理多个步骤的组成，这些步骤每一步都可能执行模式相关转换（映射）和实例相关转换（映射）。要允许某个数据转换和清洗系统产生转换代码并且那样还要减少自编译的数量，用合适的语言来指定被要求的信息是必要的，比如GUI支持的。很多ETL工具（看第四章）通过支持专门规则语言来提供这样的功能。一个更普遍和可行的方法三用标准查询语言SQL来完成数据转换和利用专门应用语言来扩展，比如在SQL：99中支持的[13]14]特殊用户定义函数（UDFs）。UDFs能在SQL中实现也能在通用程序语言中用嵌入SQL语句来实现。他们允许大范围内实现数据转换和支持对不同转换和查询任务的简单重用。更进一步，由DBMS对他们的执行能减少数据访问成本并且这样的话题胜利性能。最后UDFs是SQL：99标准的一部分而且应该（最终）方便地跨越多个平台和DBMSs。

图4展示了一个SQL：99的转换步骤，这个例子与图3有关，并且覆盖了将要应用到第一个源的必要的数据转换。该转换定义了能完成深度映射的view. 该转换完成了一个模式的调整，这是通过分离源中的名称与地址来获得view中增加的属性。UDFs完成被要求的数据的抽取。UDF的处理能够包括清洗逻辑，比如，消除拼错的城市名称或者提供丢失的zip代码。
UDFs可能仍然意味着一个潜在的实现方式而且不支持所有必要的模式转换。特别地，不能经常支持如属性分离或者融合这样简单常用的函数，而要经常在专门应用的变量中重新处理（见图4中的特殊提取函数）。更多的复杂模式重建（比如，折叠和打开属性）并被完全支持。为大量支持模式相关转换，语言扩展如SchemaSQL的建议就被提出来了。在实例级别上的数据清洗也能从特殊语言扩展中受益，比如一个支持“相似连接”的匹配操作数（见下面）。对这样强大的操作数的系统支持能大大地简化数据转换中的编译工作同时提高性能。
目前致力于数据清洗的一些研究还在调查这样的查询语言扩展的有效性和实现[11][25]。

3.3 冲突仲裁
必须制定和执行一套转换步骤来解决大量的模式与实例级别的数据质量问题，这些问题常常在数据源附近反映出来。一些类型的转换要在单独数据源上完成，这是为了处理单源问题和准备和其他源的集成。另外对一个可能需要的模式转换，有些预备步骤一般包括：
·从自由格式属性中提取值（属性分离）：自由格式属性经常占有多个单独的值，这些应该被提取出来产生一个更精确的表达同时支持更多的清洗步骤比如实例匹配和重复的消除。典型的样本三明治和地址领域（表2，图3，图4）。在这个步骤中的所需求的转换是在一个区域内重新排列值，这个区域是处理文字传输和为属性分离作的值提取。
· 确认和改正：该步骤将车每一个圆实例是否有数据输入错误同时试图尽可能自动修改它们。基于字典搜索的拼写检查对鉴别和改正拼写错误是很有用的。并且，邮编和地理名称字典有助于改正地址错误。属性依赖(birthdate-age,total price-unit price/quantity,city-phone area code,…)能被利用区探测错误和替代丢失的值和改正错误值。
· 标准化：为促使实例匹配和集成，属性的值应该被转换成一个统一的格式。比如，日期和时间输入应该是一种专门的格式；名称和其他string类型数据应该转换到或者高或者低的格等等。文本数据应该通过处理词干，移去前缀和后缀停止字符来被精简和统一格式。此外，缩写和编码模式应该可以通过咨询的特殊同名字典或者应用预定义转换规则来解决。
处理多源问题要重建模式来完成一个模式的集成，包括分离，融合，折叠，打开属性和表等步骤。在实例级别上，冲突的表达式需要解决，交迭数据需要处理。消除重复的任务一般要在多数其他转换和清洗步骤之后，尤其三在完成清洗单源和冲突表达式后。既可以同一时间在两个清洗过的源完成，或者一个源已经集成到数据集里的时候。消除错误需要：首先，确认也i就是匹配相同记录是否关联着相同实体。然后，相同数据被融合到一个包含相同实体的记录中去。此外，多于记录被净化。接下来我们讨论实例匹配对关键问题。更多这方面细节在其他地方提供[22]。在最简单的例子里，每个记录里都有一个确认属性或者属性联合，它能用来匹配记录，比如，如果不同源里共有一个主键或者由其他通用唯一属性。不同源中的实例匹配在那时间通过在确认属性上的一个标准的相同联合来完成。在一个单源集合的例子中，匹配能被排列确认属性和检查相同记录是否匹配来决定。两个例子中，既是对大型数据集高效完成都是可以实现的。不幸的是，对于没有普通键的属性或者脏数据这样直接迅速地方法常常是有限制的。为测定大多数或者全部匹配，根据匹配规则找到相似记录，一个模糊匹配（相似联合）变得越来越需要。例如，被特别声明或者被用户定义函数实现[14][11]。举例：这样一个规则能够声明人的记录很可能符合如果名称和地址部分匹配的话。两条记录的相似程度经常由一个在0到1之间的小数来衡量，经常取决于应用的特征。例如，不同的属性在一个匹配规则下可能体现出不同程度的相似度。对于string组件来说（比如，客户姓名，公司名称，。。。）精确匹配和模糊方法，基于通配符，字符频率，编辑距离，键盘距离和语音相似度等的，都是有用的[11][15][19]。很多复杂的string匹配方法也考虑到缩写[23]。一个对匹配string和text的通用方法是使用普通信息修补公制。WHIRL代表一个可信的日志表达方式，它使用向量空间模型的组成距离来决定文档之间的相似程度。
用这样一种方法决定匹配的实例对于大型数据集合来说显然是一个花费极大的操作。推断数值的相似程度对于任何两条记录来都意味着在笛卡儿产品输入上进行匹配的评估。此外在相似值上的排列对于对于决定匹配包含重复信息的记录是很重要的。所有针对相似值的记录超过一个极限能被认为三匹配，或者是作为由顾客确定的匹配的候选。在[15]中一个多通道方法被建议用在实例匹配中来减少overhead。这是基于匹配来自不同属性的记录。和结合不同匹配结果。假设一个单独的输入文件，每一个匹配传输排列在一个特别属性上的记录并且仅用某个确定的窗口测试邻近记录，无论他们是否满足一个预定义的匹配规则。与笛卡尔产品方法相比，这大大减少了匹配规则的运算数量。 每一个通过和关闭的匹配对的集合占有了种的匹配集合。

4 Tool support
可以在市场上找到大量工具来完成数据转换和数据清洗任务，尤其是数据仓库。有些工具集中处理某些领域，想清洗名称和地址，或特别的清洗方面，比如数据分析或者重复消除。由于它们被局限在某些领域，专业化的工具一般能很好地完成任务但必须用其他工具来解决广泛的转换和清洗问题。其他工具，比如，ETL 工具，提供了易于理解的转换和工作流容量来覆盖达赖能够的数据转换和清洗过程。ETL工具的一个普遍问题是他们有限的协作能力，这是因为私有的程序应用接口（API）和私有元数据格式是的它很难联合其他几种工具的功能[8]。
我们首先讨论数据分析和数据重建的工具，它们处理实例数据来确认数据错误和不一致性，并且得到相关联的清洗转换。我们然后展示专门的清洗工具和ETL工具。

4.1 数据分析和重建工具
根据我们在3.1中的分类，数据分析工具能被分为数据压型工具和数据瓦据工具。MIGRATION ARCHITECT（Evoke Software）是少量商业数据压型工具之一。对每一个属性来说，它决定了以下真实元数据：数据类型，长度，基数性，离散值和他们的百分比，最小和最大值，丢失的的值和唯一性。MIGRATION ARCHITECT也帮助了针对数据迁移的目标模式的开发。数据挖掘工具，如WIZRULE（WizSoft）和DATAMINGSUITE（InformationDiscovery），显示检验过的列的数目来推断属性们和他们的值和计算可信度的关系。特别地，WIZRULE能显示三种规则：数学公式，if-then规则，和基于拼写的规则显示漏拼的名称，比如“value Edinburgh appears 52times in field Customer;2 case(s) contain similar value(s)”,WIZRULE也能自动指到偏差位置如果从发现规则集合中发现了可疑的错误。数据重建工具，比如，INTEGRITY(Vality)，利用发现的模式和规则来指定和完成清洗转换。

4.2 专业清洗工具
专业清洗工具一般来说是针对专门领域，基本上是名称和地址数据，或者专注在消除重复。转换是由预先定义的规则库或者和用户交互来完成的。二者择一地，数据转换可以象[21]中描述的那样从模式匹配工具中导出。
·特殊领域清洗：名称和地址由多个源记录同时有高的集的势。比如，对于用户关系管理，找到客户是很重要的。某些商业工具，比如IDCENTRIC(FirstLogic),PUREINTEGRATE(Oracle),QUICKADDRESS(QASSytem),UM(TrillliumSoftware),就是清晰这样的数据的。他们提供了象提取和转换名称地址信息到个人标准，规范街道名称，城市和邮编等技术，这些是和用基于清洗过的数据衍生的匹配功能的联合来实现的。他们与大量的预定义规则协同来处理一般在处理数据中发现的问题。比如TRILLUM的提取工具和匹配工具模式包含了超过200，000的商业规则。这些工具同时也提供了客户化或者扩展用户为专门用途定义的规则库的功能。
·重复消除：用来确认重复和消除的工具，比如DATACLeaner（EDD）,MERGE/PURGELIBRARY(Sagent/QMSoftware),MATCHIT(HelpITSystems),和(MASTERMERGE(PitneyBowes).通常，他们要求要匹配的数据源已经被清洗。一些用来匹配属性值的方法已经被支持；象DATACLEANSER和MERGE/PURGELIBERARY也允许用户指定匹配规则的集成。