1.3大数据的编程模型
大数据的编程模型主要有以下几种类型：
- 大规模并行处理（Massively Parallel Processing，MPP）数据库系统：EMC公司的Greenplum系统和IBM公司的Netezza系统就是这样的系统。
- 内存数据库系统：Oracle公司的Exalytics和SAP公司的HANA正是此类系统。
- MapReduce系统：这样的系统包括所有大数据系统中最广泛使用的Hadoop。
- 整体同步并行（Bulk synchronous parallel，BSP）系统：Apache HAMA和Apache Giraph就是这样的系统。
1.3.1大规模并行处理数据库系统
大规模并行处理（MPP）数据库系统的核心思想是把数据按照某一列或者某一组列的值，按照某种形式进行划分，以分别处理。举个例子，上文例子中计算2000年的各州总销售额，并按州排序，我们可以按照各个州来划分数据，这样使用固定的计算节点来处理固定州的相应数据。这样的数据分割方法使得各个计算节点都可以计算出对应州的2000年总销售额。
这样的系统有个明显的缺陷。你需要在算法设计的时候就决定数据如何划分。而划分的准则通常由底层的用例来决定。如此一来，这就不适合临时的数据查询需求。某些数据的查询，由于数据在各个计算节点的划分合理，从而执行速度很快。而有些数据查询，由于数据在各个计算节点的划分不合理（与数据的访问方式不一致）导致其执行速度异常缓慢，为了得到计算结果，系统需要通过网络来进行大量的数据交换。
为了解决这个缺陷，大规模并行处理数据库系统经常采用的办法是把数据存储多份，并按照不同的准则来进行划分。根据不同的查询需求，选择不同的数据集。
下面列出了MPP 编程模型的几个要点，这些要点符合前文中给出的最初的大数据系统定义（想一下按州排序统计计算销售总额的例子）：
- 数据按州划分，分配到不同的计算节点。
- 各个计算节点都拥有程序所需的执行库，并对分配到该节点的数据进行数据处理。
- 每个计算节点读取本地数据。一个例外是你未考虑数据的分布情况就进行了数据查询，这时，计算任务会通过网络从其他节点来获取数据。
- 每个任务都是顺序读取数据。所需要的所有数据都存放在磁盘上的相邻位置，并且被一次性地读取，并在内存中应用过滤条件（year＝2000）。
1.3.2内存数据库系统
从系统运行的角度来看，内存数据库系统类似于MPP系统。它们的不同之处在于，内存数据库系统的每个计算节点拥有巨大容量的内存，并且大部分数据会被预先加载到内存中。SAP 公司的HANA系统就是按照这个原则来运行的。另外一些系统，比如Oracle公司的Exalytics系统，利用特殊的硬件，一个应用程序就可以管理执行多个主机。就本质来说，内存数据库系统就像是带有SQL接口的内存MPP数据库系统。
内存数据库系统的商业版本中有个重要的缺点是，其中内置了大量的硬件和软件。诚然，这些系统拥有专用设备和特定硬件，但这通常费用高昂。如果因为这些内存数据库系统准备的商用硬件来扩容内存数据库系统集群是非常方便的。举个例子，假设一个商用服务器有25GB RAM。我们要搭建1TB容量的内存数据库就需要40台以上的主机（考虑到还有其他业务需要使用这个服务器）。1TB也未必够用，但是我们的集群节点数已经达到了40个。
下面列出了内存数据库系统编程模型的几个要点特征，这些特征同样符合前文中给出的最初的大数据系统定义：
- 如前面的例子中所述，数据按州划分。各个节点把数据加载到内存中。
- 各个计算节点都拥有程序所需的执行库，并对分配到该节点的数据进行数据处理。
- 每个计算节点读取本地数据。一个例外是你未考虑数据的分配情况就进行数据查询请求，这时，计算任务会从其他节点来获取所需数据。
- 由于数据是被缓存到内存的，所以除了最初的数据加载入内存的过程外，这里不适用顺序读取数据的特性。
1.3.3MapReduce系统
MapReduce编程范型是本书所要讲述内容的核心基础重点。截至目前，MapReduce框架已被广泛的用于大数据的处理过程（four methods）。Hadoop系统对MapReduce框架的实现具有如下几个重要特征：
- 使用商用级别的硬件。需要注意的是这个商用硬件的要求不是指笔记本或者台式机。尽管计算集群是商用级别，但是我们可以使用常用的硬件设备来搭建。
- 无需事先定义数据划分准则来把数据分配到各个计算节点。
- 用户仅需要定义两个独立的处理过程：Map和Reduce。
本书会重点深入地讲解MapReduce框架。总体上说，MapReduce框架需要用户定义一个Map处理和Reduce处理。当Hadoop系统实现MapReduce时，数据常常按照64～128MB数据块大小进行分发，每个数据块会被复制两次（Hadoop系统数据备份默认参数为3）。在计算每个州的2000年的总销售额，并按照州排序的例子中，所有的销售数据都会分割为大量的数据块（大小64～128MB），加载到Hadoop分布式文件系统（Hadoop Distributed File System，HDFS）。MapReduce程序启动的时候，Hadoop系统会把程序运行依赖库（包括用户自定义Map处理和Reduce处理）拷贝到各个计算节点。
各个计算节点按照调度执行Map任务，该Map任务会读取包含销售数据的数据块。每个Mapper（各自节点上的）会逐条读取数据块中的数据记录（Record），并过滤掉无用数据，仅保留2000年的数据。对应所输入的数据记录，Mapper会输出一条包含键/值对（key/value pair）的数据记录。如果读入的销售数据是2000年的，那么其键（key）就是州，其值（value）就是从读入数据记录中获取的销售数字。
最后，Reducer会从每个Mapper的输出中获取那些键/值对，运行Reducer的数量是可以配置的。各个键会被发送到特定Reducer进行处理，确保相同的键仅被相同的Reducer处理。各个Reducer把接受的键/值对中的销售数字相加。Reducer接受的数据格式是键（州）和这个键对应的销售数字列表（销售记录是2000年的）。输出结果写回HDFS中。客户端从HDFS上读取结果数据后，对结果按州排序。最后这个步骤也可以交给Reducer完成，因为Reducer在接受它要处理的键时，这些键是已经排序完成的。本例中，为了达到按州排序的目的，我们需要把Reducer的运行数量严格限制为1。可是由于Mapper和Reducer之间传输数据会引起网络I/O，这样可能会导致网络拥塞。本书的后面部分会详细地讨论这个问题。
下面列出了MapReduce编程模型的几个要点特征，这些特征同样符合前文中给出的大数据系统定义：
- 数据以较大的数据块的形式存放在HDFS上。HDFS是一个分布式文件系统，数据块分散存储到各个节点，数据块是有冗余的。
- 程序运行依赖库，包括Map和Reduce代码被复制发送到所有的任务节点。
- 每个计算节点仅读取节点本地数据。集群中所有节点运行Mapper，从节点本地读取数据到Mapper中（大多数情况下，哪个节点的Mapper读取哪个节点磁盘的数据块，这是由调度程序管理决定的。调度程序可能会分配某个节点的Mapper任务来处理远程节点的数据块，以保持集群中的所有节点负载均衡）。
- 数据被每个节点的任务以数据块的方式一次性顺序读取（数据块大小一般为64～128MB）。
MapReduce编程范型的一个重要不足是它不适合迭代算法。大量的数据科学计算算法很自然就要使用迭代，并最终收敛于一个解。当我们使用这样的算法的时候，MapReduce编程范型需要我们把每个迭代过程放到相互独立的MapReduce任务中去。每次迭代产生的数据输出作为下次迭代计算的数据输入。但是，由于MapReduce任务每次都要从持久性存储中重新读取数据，所以每次迭代产生的结果需要存到持久性存储中供下次迭代计算使用。这个过程导致了不必要的I/O操作，并对系统吞吐量造成重大影响。这样的问题在下面即将讲到的关于BSP类型系统的讲解中，也有论述。
1.3.4整体同步并行系统
整体同步并行（BSP）系统的运行过程跟MapReduce过程非常相似。与MapReduce程序在它的处理循环结束后即可终止不同的是，BSP系统程序执行由一系列的超步（processes）（这个与Map处理的处理过程类似）组成，这些超步保持栅栏同步（synchronize on a barrier），向主节点发送数据并进行相关的信息交换（exchange relevant information）。每当一次迭代执行完毕，主节点会通知每个数据处理节点进行下一次迭代。
间隔通信是在并行计算处理中经常提到的概念。间隔通信指的是许多线程在分别执行各自的任务，这些线程在运行之前需要协商出一个检查点。这种模式是非常必要的，所有的处理线程在到达那个检查点之前就要决定是继续执行剩下的计算任务还是终止它们（并行的或者顺序的），以便所有线程确认何时完成数据处理任务。间隔同步（Synchronizing on a barrier）的方法在我们的日常生活中就经常使用。例如，一起拼车的伙伴们会常常商定在某一个特定的地方等车。整个等待过程的长短，取决于那个最晚到达该指定等车位置的人何时到达。
在BSP方法执行过程中，允许每个类似Map的处理过程缓存上次迭代的结果，如此即可大幅提高整个数据处理过程的吞吐量。我们会在本书第15章中讲解BSP系统。涉及了一些相关的迭代算法。