程序原本(一百零七):系统的基本组织方法与原理——领域间的组织(海量数据运算中公开的秘术:传递逻辑而不是传输数据)

阅读数:17 2019 年 10 月 5 日 13:50

程序原本(一百零七):系统的基本组织方法与原理——领域间的组织(海量数据运算中公开的秘术:传递逻辑而不是传输数据)

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

6 PD 模型描述处理(Process)与数据(Data)之间的关系,通常用于对计算范式的描述。

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

程序原本(一百零七):系统的基本组织方法与原理——领域间的组织(海量数据运算中公开的秘术:传递逻辑而不是传输数据)

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

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

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

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

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

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

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

评论

发布