许多人都有一个误解，认为数据集数量及其内部维护的数据质量之间存在一种固有的平衡。这个问题频繁显现，并且成为了 Tom 加入的 Financial Services Information ">Sharing and Analysis Center (FS-ISAC) 和其他地方的座谈小组最近谈论的一大主题。
根据这种思维，如果没有填写 Apache Hadoop 集群、大规模并行数据仓库和包含不一致、不准确、冗余、过时或不确定的17830.html">垃圾数据的其他节点，就无法扩展到 PB 级别。但我们不同意这样的观点。这也是我们认为这个概念对于实际情况过于简单化的原因所在。
大数据并非大部分数据问题的事务性来源
绝大部分企业中的数据质量问题通常可归因于来源事务系统，无论是客户关系管理 (CRM) 系统、通用账务应用程序，还是其他程序。这些系统通常都处于 TB 级别。
在进行这方面的讨论时，Jim 正确指出，未能保证记录系统整洁、通用且一致的任何 IT 管理员实际上已经输了一半。当然，您可以通过聚合、匹配、合并和清除中间临时数据库中的数据（使之达到某种程度），从下游修复问题。但质量问题与数据事务性来源控制不足有着密切的关系，但与来源的绝对数量并无太大关系。
通过大规模并行部署 IBM® InfoSphere® QualityStage®（或使用 IBM BigInsights 来冒充此功能），您可以从问题来源下游来扩展数据清除操作，但不能将无法“治愈”某个疾病归咎于该疾病并非由它所导致的。
大数据如今可以聚合以前从不需要清除的新型数据源
在传统的数据仓库系统中，人们已对数据质量问题已经有很清楚的认识（即使它仍然是一项挑战），但是，当时人们主要关心的是核心记录系统的维护问题，包括客户、财务、人力资源、供应链等。但在大数据空间又该如何做呢？
很多大数据计划均用于深入分析聚合数据源，比如社会营销情报、实时传感器数据源、从外部来源提取的数据、浏览器点击流会话、IT 系统日志等这类数据源。在历史上，这些来源并未链接到事务性系统的官方参考数据。一直以来，人们不必清除它们，因为通常采用脱机方式处理问题的专业团队往往会孤立地看待这些问题，并未将处理结果记入官方记录系统中。然而，跨信息类型分析（在大数据空间很常见）改变了这一机制。
虽然个别数据点可能具有孤立的边际价值，但拼凑起来可能会相当可观。它们有助于为发生（或即将发生）的问题提供上下文。
与业务参考数据不同的是，这些新型来源没有提供需要直接加载到企业数据仓库和脱机存档中的数据，或者说没有提供需要为了进行电子搜索而保留的数据。相反，您需要深入了解它们，以提取关键模式、趋势和根源；一旦达到自身的核心战术目的，您就可以将它们当中的大部分清理掉。这通常需要执行大量的挖掘、切片和切割操作。
在这种情况下，数据质量问题将以两种形式体现。首先，您不能失去来源、主角、参与者或操作，而这些项目需要与其余数据的定义保持一致。第二，您不能丢弃处理事务的沿袭方法。人物、事件、时间、地点以及发现和复制的方式。
正如我们 IBM 研究院的同事 John McPherson 所说的，“请记住，很多时候，当您谈到大数据时，我们所说的数据指的是过去无法很好利用的一些数据，因此我们通常是在尝试解决不同的问题。我们并非试图划定各店面的盈利能力。我们应当已经运用记录系统中的高质量数据做到了这一点，并竭尽所能在将数据放入数据仓库之时进行规范和重塑。”此处，也就是在 John 的案例中，我们要做的是找出提高店面盈利能力的一些因素。
本文仍会在第 2 部分继续我们的讨论。与此同时，请在评论中告知我们您在保持大数据质量方面的一些经验。
