第 12 章 对移动靶的偏见式看法：数据集成（A Biased Take on a Moving Target: Data Integration）

原文：Readings in Database Systems, Fifth Edition (2015)，Chapter 12: A Biased Take on a Moving Target: Data Integration，by Michael Stonebraker。原书文本采用 CC BY-NC-SA 4.0 许可；本译文按同一许可发布。

作者：Michael Stonebraker

我会从数据集成中两个主要主题的历史开始这篇论述。在我看来，这个主题始于 20 世纪 90 年代大型零售商把销售数据整合进数据仓库。为此，他们需要从店内销售系统中抽取数据，把它转换为预定义的公共表示（可以把它看作全局模式），然后加载到数据仓库中。这个数据仓库存储数年的历史销售数据，并由组织中的采购员用于轮换库存。换言之，采购员会发现宠物石头已经“不流行”，而芭比娃娃正在“流行”。于是，他会用一笔大订单锁定芭比娃娃工厂，把宠物石头挪到前面并打折清仓。一个典型零售数据仓库，通常可以通过更好的采购和库存轮换决策在一年内收回成本。20 世纪 90 年代末和 21 世纪初，出现了一次巨大的“跟风”：几乎所有企业都追随零售商，把面向客户的数据组织进数据仓库。

为了支持数据仓库加载，一个新行业诞生了，称为抽取、转换和加载（ETL）系统。其基本方法是：

1. 预先构造一个全局模式。
2. 派程序员去每个数据源的所有者那里，让他弄清楚如何抽取数据。历史上，编写这类“连接器”很费力，因为格式往往晦涩难懂。希望随着更多开源和标准化格式出现，未来这个问题会减少。
3. 让他编写转换逻辑，通常用脚本语言，并编写任何必要的清洗例程。
4. 让他编写脚本，把数据加载进数据仓库。

后来人们发现，由于三个重大问题，这种方法大概只能扩展到十几个数据源：

1. 需要预先拥有全局模式。大约在这个时期，许多企业推动为所有公司对象编写企业级模式。一个团队被指派去做这件事，并为此工作数年。等到结束时，他们的结果已经过时两年，并被宣布失败。因此，对于一个宽泛领域来说，预先构造全局模式极其困难。这限制了数据仓库的合理范围。

2. 手工劳动太多。对于每个数据源，方法中的多数步骤都需要熟练程序员完成。

3. 数据集成和清洗本质上很困难。20 世纪 90 年代的典型数据仓库项目，预算超出两倍，时间也延迟两倍。问题在于，规划者低估了数据集成挑战的难度。这里有两个重大问题。首先，数据是脏的。一条经验法则是，你的数据中有 10% 是错误的。这可能来自给人或产品使用昵称，供应商地址过时，人员年龄错误，等等。第二，去重很难。必须判断 Mike Stonebraker 和 M.R. Stonebraker 是同一个实体还是不同实体。同样具有挑战性的是位于同一地址的两家餐馆。它们可能在美食广场里，也可能是一家在独立店面中取代了另一家，也可能是数据错误。在这类场景中弄清事实真相代价很高。

尽管存在这些问题，数据仓库在面向客户的数据方面仍然取得了巨大成功，并被多数大型企业使用。在这个用例中，组装复合数据的痛苦，被由此产生的更好决策所证明是值得的。我几乎从未听企业抱怨其数据仓库的运营成本。相反，我听到的是业务分析师不断希望获得更多数据源，无论是来自 Web 的公共数据，还是其他企业数据。例如，一个普通大型企业大约有 5000 个运营数据存储，其中只有少数进入了数据仓库。

举一个简短例子，不久前我拜访了一家大型啤酒制造商。他有一个典型数据仓库，记录按品牌、经销商、时间段等维度划分的产品销售。我告诉分析师们，那年冬天人们普遍预测会发生厄尔尼诺，西海岸会比平常更潮湿，东北部会比平常更温暖。然后我问，啤酒销量是否与温度或降水相关。他们回答：“我们希望能回答这个问题，但天气数据不在我们的仓库里。” 使用 ETL 技术支持数据源扩展性非常困难。

快进到 21 世纪，新的流行词是主数据管理（MDM）。MDM 背后的思想是标准化企业中重要实体的表示，例如客户、员工、销售、采购、供应商等。随后，为每种实体类型精心策划一个主数据集，并让企业中的每个人都使用这个主数据。这有时被称为“黄金记录”。实际上，以前的 ETL 厂商现在在销售 MDM，作为一个范围更广的产品。在我看来，MDM 被严重过度炒作了。

先从“谁会反对标准？”开始吧。当然不是我。然而，MDM 有以下问题，我会通过几个小故事来说明。

15 年前我在 Informix 工作时，新任 CEO 在一次早期员工会议上问人力资源副总裁：“我们有多少员工？” 她下一周带回的答案是：“我不知道，而且没有办法查出来。” Informix 在 58 个国家运营，每个国家都有自己的劳动法、员工定义等等。并不存在员工的黄金记录。因此，回答 CEO 问题的唯一办法，是对这 58 个数据源执行数据集成，以解决语义问题。让 58 个国家经理同意这么做会很有挑战性，而且更困难的是，Informix 甚至并不拥有所涉及的所有组织。新 CEO 很快意识到这种尝试徒劳无功。

那么，为什么一家公司会允许这种情况发生？答案很简单：业务敏捷性。Informix 经常建立国家级运营机构，并希望销售团队快速运转起来。它不可避免地会雇用一位国家经理，然后告诉他“把事情做起来”。有时这是一家经销商或其他独立实体。如果公司说“这里是你需要遵守的 MDM 黄金记录”，那么国家经理或经销商就会花数月时间试图把自己的需求与现有 MDM 系统协调起来。换言之，MDM 是业务敏捷性的反面。显然，每个企业都需要在标准与敏捷之间取得平衡。

第二个小故事涉及一家大型制造企业。出于业务敏捷性原因，它被去中心化为多个业务单元。每个业务单元都有自己的采购系统，用来指定该业务单元与供应商交互的条款和条件。这样的系统大约有 300 个。整合这些系统显然有投资回报：毕竟需要维护的代码更少，而且企业大概可以获得比每个业务单元单独谈判更好的综合条款。那么，为什么会有这么多采购系统？收购。这家企业主要通过收购成长。每次收购都会成为一个新的业务单元，并带来自己的数据系统、已有合同等等。把所有这些数据系统合并进母公司的 IT 基础设施，往往根本不可行。总之，收购会打乱 MDM。

那么，数据集成（或数据策展）包含什么？它包括以下步骤：

1. 摄取。必须定位并捕获数据源。这需要解析用于存储的任何数据结构。
2. 转换。例如，把欧元转换为美元，或者把机场代码转换为城市名称。
3. 清洗。必须发现并纠正数据错误。
4. 模式集成。你的工资是我的薪水。
5. 合并（去重）。Mike Stonebraker 和 M.R. Stonebraker 必须合并成一条记录。

ETL 厂商以高成本和低扩展性完成这些事情。MDM 厂商也有类似特征。因此，这里存在一个巨大的未满足需求。规模化数据策展就是“房间角落里的 800 磅大猩猩”。那么，这个领域有哪些研究挑战？

我们逐步来看。

摄取只是解析数据源的问题。其他人已经编写过这样的“连接器”，而它们通常构造成本很高。一个有趣挑战是半自动生成连接器。

数据转换也已经被广泛研究，主要集中在过去十年左右。用于指定转换的脚本/可视化工具已经在 [130, 54] 中研究过。Data Wrangler [94] 似乎是这个领域的最新水平，鼓励感兴趣的读者去看看。此外，有一批商业产品提供收费转换服务（例如地址到经纬度，或者公司名称到规范公司表示）。另外，文献 [4] 报告了从公共 Web 中寻找有用转换的工作。

数据清洗已经用多种技术研究过。[41] 应用函数依赖来发现错误数据并建议自动修复。异常值检测（可能对应错误）已经在许多上下文中被研究 [87]。[162, 158] 是用于发现数据中有趣模式的查询系统。这些模式可能对应错误。[148] 研究了在错误被识别后，利用众包和专家外包来纠正错误。最后，还有各种商业服务可以清洗常见领域，例如人员地址和日期。在我看来，数据清洗研究必须使用真实世界数据。查找被注入到原本干净数据中的故障并不可信。不幸的是，真实世界的“脏”数据相当难获得。

模式匹配已经被广泛研究了至少 20 年。感兴趣的读者可以查阅 [117, 77, 134]，了解该领域的最新水平。

实体合并的问题，是在高维空间中找到彼此接近的记录（实体的所有属性，通常是 25 个或更多）。实际上，这是一个 25 维空间中的聚类问题。这是一个 N ** 2 问题，在规模化时运行时间会非常长。因此，近似算法显然是这里的前进方向。文献 [87] 中有技术综述。

在我看来，真正的问题是端到端系统。数据策展包含所有这些步骤，它们必须无缝集成，而企业级系统必须能规模化执行策展。Data Tamer 系统 [148] 是一种有趣的端到端方法，看起来扩展性不错。另一方面，数据策展问题也会出现在部门层面，其中某个个人贡献者想集成少量数据源，上面提到的 Data Wrangler 系统似乎是一种有趣方法。有商业公司支持这两个系统，因此应该会持续出现增强。

希望下一版红宝书能够在这个领域收录一组奠基论文，以替代这篇（带有自我服务意味的）行动号召。在我看来，这是企业正在处理的最重要主题之一。我的一个提醒是：“轮胎必须真正贴到路面。” 如果你想在这个领域工作，就必须在真实世界企业数据上尝试自己的想法。构造人工数据、向其中注入故障，然后发现这些故障，根本不可信。如果你在这个领域有想法，我建议构建一个端到端系统。通过这种方式，你可以确保自己解决的是重要问题，而不只是一个真实用户可能感兴趣、也可能不感兴趣的“点问题”。

评论：Joe Hellerstein

2015 年 12 月 6 日

我总体同意 Mike 在这里的评估，但想补充我对这个空间的看法，尤其是他顺带提到的“部门层面”问题。

基于我们与各种组织中用户打交道的经验，我们看到数据转换正越来越成为以用户为中心的任务，并且关键依赖用户体验：用于交互式评估和操纵数据的界面与语言。

在今天的许多场景中，数据转换的正确结果严重依赖上下文。要理解数据是否脏，你必须知道它“应该”是什么样子。要转换数据以供使用，你需要理解它会被用于什么。即使在单个组织内部，关于数据将如何使用、它需要是什么样子的上下文，也会因人而异、随时间而变。把这一点加到 Mike 对“黄金主数据”思想的批评上：对许多现代用例来说，尤其是在分析语境中，这个思想根本没有意义。

相反，你需要为最理解数据和用例的人设计工具，并使他们能够以敏捷、探索式方式完成自己的数据剖析和转换。计算机科学家往往为技术用户设计，也就是 IT 专业人员和数据科学家。但在多数组织中，理解数据和上下文的用户更接近“业务”，而不是 IT 部门。他们往往技术能力也较弱。相比使用传统 ETL 工具，他们倾向于退回到电子表格和桌面数据库包中操纵数据，而这两者都不适合评估数据质量或进行批量转换。对于大型数据集，他们会“用 Microsoft Word 写代码”：用自然语言规范描述自己想要的工作流，等待 IT 有空为他们写代码，然后当拿到结果时，通常意识到结果并不完全可用。到那时，他们对数据的需求往往已经发生变化。因此，人们经常说自己 50-80% 的时间花在“准备数据”上，这并不令人惊讶。（作为脚注，根据我的经验，现代“数据科学家”倾向于用 Python、R 或 SAS DataStep 中的临时脚本整理数据，并且对这些脚本的代码质量和版本控制惊人地松懈。因此，随着时间推移，他们往往比旧式 ETL 用户处境更糟！）

业务用户选择图形工具是有充分理由的：他们想在数据被转换时理解数据，并评估它是否正在接近对其业务问题有用的形式。因此，数据库研究文献中的无人值守算法，在解决这个空间中的关键问题方面做得太少。我相信，最相关的解决方案将基于这样的界面：让人直观理解自己数据的状态，并与算法协作，使数据更适合使用目的。

这带来了重大的创新机会。数据转换是探索“可视化和交互式处理数据”这一通用主题的完美培养皿。在这个领域，可以把数据库、HCI 和机器学习中的思想结合起来，创造算法与人之间的交互式协作，解决实际的、特定上下文的数据问题。为了支撑这一点，我们需要交互式数据系统，它们能够完成诸如对临时转换步骤结果即时提供数据剖析（各种聚合），并实时预判用户下一步以建议多种可能有用的替代转换等事情。交互式分析一章中的一些主题在这里相关，尤其是对于大数据集。近年来，我很高兴看到数据库社区中有更多关于可视化和交互的工作；这是这些工作的绝佳应用领域。

评论脚注

• Heer, J., Hellerstein, J.M. and Kandel, S. “Predictive Interaction for Data Transformation.” CIDR 2015.