海量数据运算中公开的秘术：传递逻辑而不是传输数据

数据或逻辑的不变性是这两类大型系统（以及系统开发语言）的核心区别，如图49所示的两种“PD模型”¹：

¹ PD模型描述处理（Process）与数据（Data）之间的关系，通常用于对计算范式的描述。

图1　两种 “PD模型”：数据或逻辑的不变性

函数式语言，例如Erlang和MapReduce，主张第一种系统模型（另一种模型在后文中另作讨论），因此适宜于编写逻辑确定的系统。它使数据D穿过逻辑，形成D’，这一过程是确定的；而由D’与其他的、后续的逻辑构成的部分（子系统或领域），并不影响当前系统的确定性。

但是我们也可能会注意到，在网络上产生数据（例如发表博客或提交回复）时，数据是动态产生的；而当这些数据被收集起来之后，我们展示它们时数据却是静态的。简单地说，数据收集和规格化，与基于数据的应用程序开发看起来并不是一回事。在后者，即对于我们一般意义上的应用程序开发（而非数据处理），我们通常还是会选择第二种模型——让逻辑作用于数据。

而这一模型事实上并不简单。例如，即使我们的数据是确定的，但如果它本身是海量的、分布的、复杂结构的，又应当如何处理呢？仍以我们在上一小节讨论过的“搜索”为例，如果一个搜索引擎已经获得了数以亿计的网页，分布在不同物理位置的存储设备中，又如何能让一个关键字搜索快速得到响应呢？

首先，真正发生一个“按Key搜索”的行为时，事实上是不会到具体网页中去“逐字节查找”的。关于“Search Keys”与“Page Keys”的关系以及“Page Keys”与存储的部署关系，将涉及非常多的系统策略，在此我们不细讨论。我们这里只关注“如何发生查找逻辑”这一个问题。而这个问题的本质是：如果逻辑所需处理的数据是不可迁移的，那么逻辑可否迁移？例如，如果我们的“按Key搜索”行为可以被分拆为多个子处理，那么能否将这些子处理“送入到”数据所在的集群（Cluster）并完成运算呢？

传递逻辑而不是传输数据，是海量数据运算的另一个思路，而这一思路依赖的条件是：逻辑的子过程的分拆是可能的、可控的²。在类似MapReduce的方案中，Map/Reduce Jobs的执行就具有类似的特点。也就是说，我们必须关注另一个事实：

² 我们讨论过，这正是函数式语言的优势——将逻辑作为可迁移对象通常是基于运行机制来保障的、具有逻辑自身的不知觉性，而命令式语言则难于实现这一点。但看起来，我们在这里所面临的又似乎是典型的“数据不变”的系统环境。所以语言范式之于系统模型，是两种语境。

语言选型与系统架构在“数据与逻辑的可变性”上是可以互为补充的。

图书简介：https://www.ituring.com.cn/book/2429

相关阅读

创作场景

程序原本（五）：海量数据运算中公开的秘术