设计数据密集型应用程序

第 10 章 批量处理 批量处理

本作品已使用人工智能进行翻译。欢迎您提供反馈和意见：[e-mail]

如果一个系统受一个人的影响太大，它就不可能成功。一旦初步设计完成并相当稳健，真正的考验就开始了，因为许多持不同观点的人都要进行自己的实验。

唐纳德-克努特

在本书的前两部分中，我们谈了很多关于请求和查询以及相应的响应或结果的内容。许多现代数据系统都采用了这种数据处理方式：你提出请求或发送指令，一段时间后系统（希望）会给你一个答复。数据库、缓存、搜索索引、网络服务器和许多其他系统都是这样工作的。

在此类在线系统中，无论是请求页面的网络浏览器，还是调用远程 API 的服务，我们通常假定请求是由人类用户触发的，而用户正在等待响应。他们不应该等待太长时间，因此我们非常关注这些系统的响应时间（参见"描述性能"）。

网络以及越来越多的基于 HTTP/REST 的应用程序接口，使得请求/响应式的交互方式变得如此普遍，以至于人们很容易将其视为理所当然。但我们应该记住，这并不是构建系统的唯一方法，其他方法也有其优点。让我们来区分三种不同类型的系统：

服务（在线系统）

服务等待来自客户端的请求或指令。收到请求或指令后，服务会尽快处理，并发送响应。响应时间通常是衡量服务性能的主要标准，而可用性通常也非常重要（如果客户端无法访问服务，用户很可能会收到一条错误消息）。

批处理系统（离线系统）

批处理系统接收大量输入数据，运行作业对其进行处理，并产生一些输出数据。作业通常需要一段时间（从几分钟到几天不等），因此通常不会有用户等待作业完成。相反，批处理作业通常安排定期运行（例如每天一次）。批处理作业的主要性能指标通常是吞吐量（处理一定大小的输入数据集所需的时间）。我们将在本章讨论批处理。

流处理系统（近实时系统）

流处理介于在线和离线/批处理之间（因此有时也被称为近实时或近线处理）。与批处理系统一样，流处理器消耗输入并产生输出（而不是响应请求）。不过，流作业是在事件发生后不久对其进行操作，而批处理作业则是对一组固定的输入数据进行操作。 这种差异使得流处理系统的延迟时间低于批处理系统。由于流处理建立在批处理的基础上，我们将在第 11 章讨论它。

正如我们将在本章中看到的，批处理是我们构建可靠、可扩展和可维护应用程序的一个重要组成部分。例如，MapReduce 是 2004 年发布的一种批处理算法[1]，它被称为 "让 Google 具备大规模可扩展性的算法"（也许是过于狂热了）[2]。该算法随后在 Hadoop、CouchDB 和 MongoDB 等各种开源数据系统中得到了应用。

与多年前为数据仓库开发的并行处理系统相比，MapReduce 是一种相当低级的编程模型[3,4]，但它在商品硬件可实现的处理规模方面向前迈出了一大步。虽然 MapReduce 的重要性现在正在下降 [5]，但它仍然值得了解，因为它清楚地说明了批处理为什么有用以及如何有用。

事实上，批处理是一种非常古老的计算形式。早在可编程数字计算机发明之前，打卡制表机--如 1890 年美国人口普查中使用的 Hollerith 机器[6]--就采用了半机械化的批处理形式，从大量输入中计算汇总统计数据。MapReduce ...