jigsaw是什么意思

脏数据的定义

脏数据是指源系统中的数据不在给定的范围内或对于实际业务毫无意义，或是数据格式非

法，以及在源系统中存在不规范的编码和含糊的业务逻辑。比如会员已存不存在的，但数据

库中还存留着他的留言信息，好友信息等等，实际没有作用，又占地方，到时还要影响统计

的正确性。

脏数据的隐患

很少有什么IT项目比数据整合更令人头疼的了。如果我们换个方式思考，就会发现有一件

事是比数据整合更可怕的，那就是数据整合出现了问题。

有时候，这是由于用户出错或者恶意用户的蓄意破坏，导致不良数据堆积引起的问题。

有时候原始数据是完好无损的，但是从一个系统/数据库转移到另一个系统/数据库的过程中

丢失、被删截或者被修改了，也会造成麻烦。数据会过时，也会在你企业内部的人事斗争过

程中不幸被流弹击中，要知道每个人都是死抱着自己的一小片数据存储地盘，不愿与其他人

分享。

有很多的方式会导致数据项目的流产，本文列举了其中五种最常见的情况，告诉你究竟

是什么地方出错了，将会导致什么样的后果，以及可以采取什么措施避免同样的情况发生在

自己身上。文中所涉及的公司名字一概隐去。希望不要让你自己的经历像本文所叙述的对象

那样沦为他人口中的经验教训。

1.“亲爱的白痴”邮件事件

小心你的数据来源，它有可能会反过来摆你一道。这个事例源于一个大型金融服务机构

的客户呼叫中心。就像几乎所有的客服柜台一样，这里的客户服务代表们要做的就是接听电

话，并把客户信息输入到一个共享数据库里。

这个特殊的数据库里有一列是用来记录称谓的，并且是可编辑的。但是数据库管理员并

没有对这一列的输入规则进行约束，例如只能输入某某先生，某某女士之类的称谓，反而可

以接受客服代表输入的任何长达20或30字符的内容。在倾听一些客户愤怒的投诉时，部分

客服代表就会给每条记录添加一些他们自己想出来的不完全友善的注释，例如“这个客户

真是个白痴”这类的注释。

这种情况持续了很多年，因为机构里的其他系统都不会从这个称谓列中提取数据，所以

没有人注意到这一情况。其后某天，市场部决定发起一次直接邮寄活动来推广一项新服务。

他们想出了一个绝妙的点子：与其花钱购买一份名单，不如利用客服柜台的数据库。

于是，以诸如“亲爱的白痴客户Linlin”这样的措词抬头的邮件开始源源不断的发到客

户邮箱里。

当然没有任何客户会签约使用这项新服务。该机构直到开始检查他们所发出的邮件时，

才弄清楚前因后果。

我们拥有的数据不是属于我们自己的。如今世界的联系日趋紧密，很可能会有人找到了

你的数据，并把它利用在一个你完全想象不到的地方。如果你从别的地方获取数据，那么在

你利用它们执行新任务时，必须要确保你的数据质量管理水平过关了。

判断水平“过不过关”，取决于你要如何利用这些数据。正确性是判断数据质量的基本

要素之一，对于直邮产业，数据的准确率达到70%至80%就可能就够了。而对于制药业，

你就必须达到99%甚至更高。不过，没有什么公司想要或者需要完美的数据，更不用说为

了得到完美数据而付出金钱，因为要数据保持完美的代价太昂贵了。问题是要怎样利用数据，

以及数据的准确率达到什么程度才足够好。

2.死去的人有没有选举权

相信大家对数据清洗(Datacleansing)这个术语并不陌生，它是数据整合过程中必须进行

的一个复杂过程，通过检测和清除掉垃圾数据(包括不正确、过时、冗余以及不完整的数据)，

以保证数据的正确性、可靠性、完整性和一致性。从字面上，我们就可以看出数据清洗是一

个“生死攸关”的问题。下面讲述的也是“生死攸关”的事例。2006年美国国会选举期间，

某政府工作志愿者在通过电话让已登记的选民来投票的过程中发现，每十个选民中有三个是

已经死去的人，因此没有资格投票。现代社会里死者数据不全所引发的问题很常见，确实也

给生者带来了很大的困扰。

对于诸如保险公司、投资公司、基金公司、通讯公司等拥有大量客户的服务类企业而言，

客户数据是其重要的财富来源。然而，客户数据质量问题却一直是困扰企业开发新服务项目

的绊脚石。在一项关于客户数据质量的调查研究中发现，平均而言，8-15%的客户数据记录

存在各种问题，例如各种证件号码输入错误、联系方式过期等等。其中有五分之一的数据问

题是由于客户的死亡造成的，其中一部分客户死亡时间超过十年却仍保留着股东的身份。

这并不是客户的疏忽，只是自然发生的问题。私营企业上市、被并购或者拆分，而他们

的股东数据却一直被保留着，甚至长达数十年之久。不过这些垃圾数据所引起的问题可能比

起在不必要的邮寄费用上浪费一点钱更为严重。最令人担心的问题莫过于欺诈和盗窃ID，

如果这些情况发生在颇具影响力的机构组织里，必会导致更为严重的现实问题，例如已故股

东的红利被陌生人兑现，继承人的继承权被剥夺，公司机密泄漏等等。

那么要怎么解决这个问题呢?利用商业评测软件可以识别不同系统的异常数据并做好标

记方便检查。即便如此，所有的企业都应当加强重视，做好内部监控，严格执行例行的基本

检查。事实上，每一个企业都或多或少存在垃圾数据方面的问题。从风险管理的观点来看，

最好的解决方案就是持之以恒地检查。如果你从上文的内容能认识到这个自然发生的现象可

能会对你产生什么影响的话，已经有了一个好的开始。

3.数据重复的代价

用户出错会引发麻烦事，用户自作聪明造成的问题可能更严重。某保险公司从上世纪

70年代开始就将大部分客户资料保存在一个主应用软件中，并规定数据录入操作员录入新

数据前先要搜索数据库中是否已经有该客户的记录，但是搜索功能执行起来非常慢而且不够

准确，所以大多数操作员不再执行这一步骤，而从头开始输入新记录，这样做确实简单轻松

多了。然而，结果是很多客户公司的记录在数据库里重复达几百次，使系统运行地更慢，数

据搜索结果更加不准确，形成了恶性循环。

不幸的是，这个应用软件已经根深蒂固的嵌入到该公司的其他系统了，管理部门不愿意

花钱把它替换掉。最后，该公司的IT部门发现如果公司再也无法查找用户资料了，将会造

成的每天75万美元的损失。直到这时候，公司才如梦初醒，使用识别系统来清洗数据，最

终清除了近四万条重复记录。

重复数据的问题一直都让IT管理员头痛不已。数据库越庞大，这个问题越严重。但是，

很少有人真正认识到问题的严重性。如果有人告诉你他的客户数据库里有2.7%的重复数据，

很可能低估了。不过，我们也没有什么灵丹妙药彻底解决这个问题，即使我们能够利用数据

匹配技术来沙里淘金，跨越多个数据库找出唯一有用的信息，最难的一关可能是让企业里的

不同利益团体就什么数据可以大家共享以及如何构建匹配达成一致。同一个机构里的两个不

同的部门可能对匹配和重复项有完全不同的定义。类似的数据整合工作会因为相关人员不能

对“谁才是数据的所有者”以及“什么数据可以拿来与别人交换”的意见不和而土崩瓦解。

4.小心老化的数据

相信很多人对魔域大冒险(Zork)这款最经典的文字冒险游戏还记忆犹新，通过问答形式

由游戏设置提供情景描述，而玩家输入选择关键词判断来推动游戏发展，是现代RPG游戏

的鼻祖。现在，还有不少人仍在开发这类古老的游戏，这也没什么，问题是他们数据库里保

存的用户资料也同样的古老。

某老款游戏开发商利用MailChimp的网络营销服务来联系以前的一万名客户，就是为

了提醒他们游戏的第二版终于完成了。他们所用的大部分电子邮件地址至少是十年前的，其

中有一部分是Hotmail帐户，很久之前就被遗弃不用了，以致微软已经把这些邮件地址当成

垃圾邮件陷阱了。于是，一天之内，所有的MailChimp邮件都被Hotmail的垃圾邮件过滤器

列入了黑名单。

幸好游戏开发商以前保留了原始记录，包括每位客户下载其游戏时的IP地址，这成了

MailChimp的救命稻草。MailChimp给Hotmail的客服发了紧急申明，证明这些邮箱帐户是

合法客户，只是年代比较久远。第二天，hotmail就把MailChimp从黑名单中解救出来了。

所有的数据都会快速老化，就像放射性物质发生衰变一样，而联络数据比其他数据老化

得更快。数据库管理人员必须定期更新每一个系统的数据。

美国工商资料库是个巨额产业，而联络资料是所有资料中最受销售人员青睐的，但也是

最难维护的。2004年成立于美国的是一个在线商务联络资料数据库，面向销售

专业人员，采用Wiki式数据清洗方式来维护。该网站的三十多万名用户通过上传新名片资

料或纠正错误的名片资料来换取点数，上传的每条记录必须完整，如果上传不正确或是资料

太老旧，就会扣除相应的点数。而用户能得到的利益就是用获得的点数购买自己所需要的名

片资料。

Jigsaw的首席执行官JimFowler称一家科技公司想要把他们公司的数据库和Jigsaw的

数据库进行比较，以便清除不良数据。该科技公司拥有四万条记录，其中只有65%是当前

可用的，而且全部数据都不完整。Jigsaw发现他们大部分合作客户都拥有很多毫无价值的数

据，根本就没办法去匹配纠正。公司花费了数百万美元在客户关系管理软件上，可见这些数

据有多糟糕。有时候公司的真正价值不在拥有的数据本身，而在于有没有能力与时俱进地跟

上数据变化的速度。Jigsaw的能力正是在于完善数据并进行自我清洗，如果没有自我修正的

机制，Jigsaw也只不过是一家毫无价值的数据公司而已。

5.小错误与大麻烦

好数据和不良数据之间的差别很可能就体现在一个小点上。某专案优化解决方案供应商

的高级顾问告诉我们，他曾为一个大型数据整合项目做顾问，这个项目看起来一切都运行正

常，但六个月后，某人打开一个数据表，只看到了一排排符号，什么数据都没有。

这其实只是一个字符代码错误：本来在一些域里应该用省略号(三个点)的，但有人只输

入了两个点，导致了整个数据线的崩溃。该公司不得不费尽力气从备份中重新创建整个数据

库：查找省略号，然后用正确数据替换。

很多时候，问题不仅仅是简单的数据录入错误或者是“脏数据进脏数据出”的问题而已。

很多企业在进行不同操作系统之间的数据移植或从老的SQL版本中升级数据等操作时并没

有做好充分计划。他们总是希望利用手头上任何可利用资源火速进行，而把数据清洗任务冀

望于以后完成。更甚者，他们的测试环境和操作环境可能并不一致，或者他们只用少量数据

子集来测试，没有测试过的数据很可能会在后面的操作引发大麻烦。

企业经历着深刻的技术革命，却没有在数据整合和维护的管理上花费足够的时间和精

力，最终只会成为不良数据的牺牲品。在数据迁移的过程中，有无数的机会让它们成为不良

数据。

不要指望IT部门来验证你的数据。让与这些数据密切相关的有能力的用户来帮助你做

好数据整合计划和测试。在你决定进行整合之前，先查看一下所有数据，确定用于从中提取

数据的应用软件。如果可以，最好测试所有的数据而不是其中某个子集，要知道正如上面的

例子所示，就算是一个小的不能再小的错误都会把你和你的数据拉进痛苦的深渊。

我们最后再用一个实例来说明小错误和大麻烦之间的关系。

某商业风险管理解决方案供应商的某位客户创建了一个SQL服务器数据库，用来确定

是否有错误的CAD文件在其网络内部流窜。原本的设想是，如果错误的数据包超过某设定

阈值，公司管理员就会知道并进行数据挖掘和清洗工作。问题是他们不小心颠倒了数据库的

规则设置(把两个阈值放反了)，导致错误数据包越多，提交公司的报告里显示的网络运行情

况就越好。最后该公司网络被某种蠕虫病毒入侵，破坏了他们的工程CAD档案。他们不得

不重头开始花费大量的金钱来重建大部分的文档。这一切都是因为一个非常简单数据提取设

置错误造成的。

希望本文讲述的内容能够让大家对数据整合有个正确的认识，数据整合不可规避，并且

要谨慎行事。

脏数据的处理

目前，基于数据仓库的商业智能应用已经成为国内许多企业的IT规划项目，并受到企业管

理层的关注。作为商业智能的基础,数据质量的好坏是影响商业智能应用效果的关键，但由

于企业的信息化经过长期的积累和发展,数据质量参差不齐，脏数据的存在阻碍了商业智能

应用的进程，下面将重点谈谈如何让脏数据改头换面。

数据的“往事”

脏数据的存在主要是由于源系统的设计不够严密造成的。主要表现为：数据格式错

误，数据不一致，数据重复、错误，业务逻辑的不合理，违反业务规则等。例如，未经验证

的身份证号码、未经验证的日期字段等，还有账户开户日期晚于用户销户日期、交易处理的

操作员号不存在、性别超过取值范围等。此外，也有因为源系统基于性能的考虑，放弃了外

键约束，从而导致数据不一致的结果。

目前，大多数的银行业务系统的输入界面是采用COBOL语言或C语言开发的，

界面处理功能不是很强，一些要素被设计成“输入”而不是“选择”，如企业客户的信用等

级被设计成输入，输入的正确与否完全由操作员的理解决定，这也是脏数据产生的原因之一。

例如，如果被设计成“选择”就不会出现把AAA输成“1”或其他了。

转换与清洗的实例

下面以银行业务系统的客户的惟一标识—客户号为例来讲解如何转换与清洗数据。

客户信息的处理是整个数据抽取、转换、清洗和装载（ETL）工作中最复杂的部分。

目前业务系统中常见的客户信息处理的难点主要有以下两个方面。

客户的惟一标识混乱

银行的客户号一般由证件类型与证件号组成，这里就有一个问题，如果客户有多种

证件怎么办？或者说某个客户办了移民，有了新的身份，系统中怎样体现出他是同一个客

户？这些问题，除了少部分是由于发证机关造成的（如身份证重号），大部分是由于操作人

员的操作不规范造成的。主要表现在以下三个方面。

A、客户身份证号问题

最常见的问题是客户的身份证从15位更换为18位。首先操作人员只要能输入新的

客户号，就认为是一个新的客户；其次，即使操作员知道客户的身份证升位了，但在银行的

客户信息中，客户号是惟一标识，如果对惟一标识进行更新，作为增量反映到目标系统中，

但没有记录原客户号，对于目标系统来说就是一条新记录，而删除原有的客户信息在实际操

作中可能是不允许或做不到的，因为在这个客户号上可能还挂了许多账户，即便物理删除了

这条客户记录，也不可能作为增量数据传输到分析系统，因为这条数据确实已经不存在了。

所以在实际的业务操作中只是简单地增加一条客户信息，新开的账户就挂在新的客户信息

上，这样业务系统中就登记了两条客户信息。

在ETL处理时，对上面这种情况一般都直接转换为18位，但在首次全量处理时，

必须通过比较姓名来真实证明两条记录是同一个客户。增量处理时需要同样的处理。这样做

需要更多的系统时间。

第二个客户身份证号问题是15位身份证号中有字母。如数字“0”被误写为字母“O”。

第三个客户身份证号问题是长度不为15位与18位。

第四个客户身份证号问题是同一身份证多个客户号。

身份证号问题在ETL时要生成异常客户信息记录文件，再交由业务部门处理，如

把原15位身份证上挂接的账户重新挂接到18位上，删除15位的客户信息，删除错误的客

户信息，重新录入正确的客户信息，并进行账户挂接。

B、多种证件问题

多种证件也会导致一名客户有多个客户号，技术上没有能力来发现，只有依靠业务

人员来收集、更新维护信息。如果通过建新表来保存这种关系，将增加数据处理、查询的难

度。

C、其他问题。有些账户上没有客户信息或虚编了客户号，比如1999年11月以前

开设的账户，没有客户可以挂接，于是随意设了客户号，在汇总统计时要注意区分这种情况。

多数据源导致多客户信息

由于客观原因，银行可能有许多分散独立的业务系统，没有做到完全的集中，这些

系统中都有客户信息。

多数据源导致多客户信息，同一客户在不同系统中有不同的数据描述，或者详细程

度不同，在一些系统中甚至可能没有明确的客户代码与客户信息。

在处理时，主要根据客户信息的详细程度与更新时间来考虑，并确定一个信息修改的原则。

首先我们把来自最大的数据源——核心业务系统的客户信息作为基础，这些信息数据量大，

虽然有很全面的数据结构，但大部分的字段内容为空，而来自个人信贷系统、银行卡系统等

的客户信息数据量相对较少，有详细的内容，正常情况下客户记录应该是核心业务系统的一

个子集。数据仓库系统应该综合所有系统的客户信息，客户记录数应该是并集，客户记录字

段应该是一些重要字段的并集。

然后确定不同数据源有公共字段的修改顺序。首先按信息的修改时间来判断，但最

新的信息修改不一定有最全面的信息，如在柜面开户，核心系统仅录入了身份证与姓名，没

有录入地址等其他公共字段信息，而个人信贷系统或卡系统虽然建立的时间比较早，但有较

全面的信息，不能用核心系统信息直接更新。所以公共字段的修改原则是在源数据与目标数

据的字段不为空的情况下，以最新的信息为准。但这样做要耗费大量的系统资源，特别是在

做全量数据初始化时，好在客户信息变化的频率不是很高，在实际全量数据初始化时往往是

确定一个顺序，例如，以核心业务系统信息为基础，银行卡信息覆盖核心业务系统信息，然

后再用贷款信息覆盖。

增量处理时一种折衷的方法是，在目标系统中记录客户信息的来源系统，如果来自

贷款系统，则不能用其他系统的增量信息更新，只能用贷款系统的增量信息更新，而贷款系

统的信息可以修改来自其他系统的信息。

实施经验：转换与清洗的时机

一般来说，转换与清洗发生在数据抽取之后，一些转换与清洗可以在抽取的同时去

做。对于一些相对不繁忙的业务系统，如个人信贷系统，由于不是24小时运行，在每天完

成正常的数据处理后，仍有很多时间空闲，在数据卸载时可以进行转换与清洗，这样做能够

减少数据仓库的负载量。需要注意的是，不能对源系统进行清洗，因为源系统数据正确性的

标准可能与目标系统不一样，对源系统的数据进行任何的修改与删除都是不允许的。当然源

系统清理自身错误的数据对加快数据抽取会有好处。

数据清洗的六个步骤

数据仓库领域的权威博士把数据清洗的过程分为六个步骤：

步骤一：元素化（将非标准的数据统一格式化成数据元素）。

步骤二：标准化（将元素标准化，根据数据字典消除不一致的缩写等）。

步骤三：校验（对标准化的元素进行一致性校验，即在内容上修改错误）。

步骤四：匹配（在其他记录中寻找相似的记录，发现重复异常）。

步骤五：消除重复记录（根据匹配结果进行处理，可以删除部分记录或者把多个记录合并为

一个更完整信息的记录）。

步骤六：档案化（将结果写入元数据存储中心。这样可以更好地进行后续的清理过程，使得

用户容易理解数据库以及更好地进行切片、切块等操作）。