第一章 遇见HADOOP 第五节 写其它系统比较(hadoop:the definitive guide)

    HADOOP不是第一个处理数据存储与查询的分布式系统，但是它的一些特性把它与

其它类似的系统区分开。我们看一下其中的一部分。

    关系型数据库管理系统

    为什么我们不使用有很多的硬盘的数据库来处理大数据分析？为什么需要HADOOP?

    这个问题是由硬盘的另一个趋势引起的：寻道时间的提升速度比传输速率的提升要

慢得多。寻道是指移动硬盘的磁头到指定位置来读取或写入数据。它表示硬盘操作的

延迟性，相对于传输速率与硬盘带宽的比较。

    数据访问的瓶颈是寻道，它在读取写入大批量数据时比通过传输来操作的流要耗费更长

的时间。另一方面，在更新数据库中一小部分的数据时，传统的B-TREE工作的很好。而

在数据库中大部分数据都需要更新时，它就没有MapReduce那么有效，因为它需要使用

排序/合并来重构数据库。

    在许多方面，MapReduce可以视为关系型数据库管理系统（RDBMS）的补充（这两

个系统之间的区别在表1-1中列出）。MapReduce适用于需要分析整个数据集的问题，尤其

是特殊分析。RDBMS更适用于已经索引好的数据的提取和相对较少的数据的更新。MapReduce

适用于数据一次写入多次读取，而RDBMS更适用于需要持续更新的数据集。

   

    尽管如此，RDBMS与HADOOP之间的区别还是很模糊。RDBMS已经从HADOOP里吸取了一

些思想，另一方面，HADOOP系统，如Hive变得更交互（通过摒弃MapReduce）并且加了

一些像索引和事务的特性，使它看看来越来越像传统的RDBMS.

    HADOOP和RDBMS的另一区别是他们操作的数据的结构总量。结构化数据被组织为有自定义

格式的实体，如XML文档或数据库表，符合预先定义好的格式。这是RDBMS的领域。半结构化

数据，是松散的，尽管可能有一个模式，但是它经常是被忽略的，它可能仅仅用于指导结构化数据：

比如，纯文本或图片数据。HADOOP在非结构化或半结构化数据上工作良好，因为它被设计在处理

数据的时候解释数据（也叫chema-on-read）。它更灵活，避免了RDBMS加载数据的耗时，因

为在HADOOP中它只是一个文件副本。

    关系型数据通常要规范化来保持它的完整性并移除冗余。规范化对HADOOP处理来说是有问题的，

因为它使读取记录成为一个非本地的操作，而HADOOP的一个核心思想是它可以处理流的读写。

    服务器日志是一个非规范化的一个例子（比如，每次客户名称需要全名指定，尽管同一个客户端可能

出现很多次），这也是为什么日志文件特别适合用HADOOP来分析。注意HADOOP也可以执行连接，

只是没有关系型世界中那么常用。

    MapReduce--HADOOP中的另一种处理模式--与要处理的数据大小呈线性增长。数据被分区，原型

功能（如映射和归并）可以并行运行在每一个单独的分区。这意味着如果你把输入数据加倍，它会像

运行两次那么慢。但是如果你也集群加倍，它运行的会像原来一样快。这对SQL查询来说几乎是不可能的。

    网格计算

        高性能计算（HPC）和网格计算社区已经做大数据处理好多年了，使用MPI的API。广义上来说，

HPC的方式是把工作分配到集群的每一台机器，这些机器共享访问一个文件系统，由存储社区网络（

storage area network SAN）管理。它对于密集型计算支持的很好，但是当节点需要访问大的数据块（

几百G，HADOOP真正开始的闪光点）时就成了问题，因为网格带宽是一个瓶颈，导致计算节点的空闲。

    HADOOP尽量把数据放在同一地点的计算节点上，所以数据访问是很快的，因为它是本地访问。这个

特性，就是所谓的数据本地化，是HADOOP数据处理的核心，也是它良好性能的原因所在。必须认为到，

在数据中心，带宽是最宝贵的资源（通过复制数据很容易就会让网络连接达到饱和状态）。HADOOP

竭尽全力的明确网格的拓扑结构保卫它。注意这样的安排不会妨碍HADOOP的高CPU分析。

    MPI给了程序员很大的控制权力，但是这需要他们通过暴露的低级的C例程和结构，如SOCKET，和

其它高级的算法分析来自己处理数据流。HADOOP的处理只在更高的层面上：程序员根据数据模型（

如MapReduce的键-值对）来思考，而数据流是隐藏的。

    大规模的分布式计算的协调处理是一个挑战。最困难的一个方面是优雅的处理部分的失败--当你不知道

远程处理是否失败--依然推进整体计算。分布式处理框架像MapReduce不需要程序员考虑失败，因为它的

实现可以探测到失败任务并重新分配给正常的机器。MapReduce可以做这个事是因为它是一个无分享架构，

意味着所有的任务不依赖其它的任务。(这是一个简化，映射器的输出供给归并器，但是它是在MapReduce

系统的控制下；在这种情况下，相比映射器的失败，它更关心归并器的失败，因为他需要确保可以提取需要的

映射输出，如果没有，再次运行相关的映射来重新生成它。）所以站在程序员的视角，任务的运行顺序没有关系。

相比而言，MPI的程序必须显示的管理他们自己的检查点并恢复，它给了程序员更多的权限，却让他们写的

更困难。

    志愿计算

    当人们第一次听到关于HADOOP和MAPREDUCE时，他们常常会问,"他和SETI@home有什么区别？“SETI,

外星智慧搜索，运行着一个叫做SETI@home的项目，志愿者们把他们的空闲时的CPU时候捐献出来用来分析

射电望远镜数据来找地球外智慧生命的迹象。SETI@home是最著名的志愿计算项目，其它还包含大因特网梅森

素数搜索以及Folding@home（了解蛋白质折叠及如何引起疾病）。

    志愿计算项目的工作方式是把要解决的问题分成工作单元的块，并把它发送到世界各地的计算机上分析。

例如，SETI@home的工作单元是大约0.36MB的射电望远镜数据，在一般的家用电脑上分析需要耗时几个小时

到几天。当分析完毕后，结束发送给服务器，同时客户端得到了另一个工作单元。为了防止作弊，每一个工作单元

都被分配到三台不同的机器上，并且需要至少两个结果一致才会被接受。

    尽管SETI@home也许表面上和MapReduce类似（把问题拆分成互不相关的碎片以并行处理），他们有一些重要

的区别。SETI@home项目的问题是CPU密集型的，它适合运行了世界上成百上千的机器的，因为相对于它的计算

时间来讲，它的工作单元的传输时间可以忽略的。志愿者贡献的是CPU周期，而不是带宽。MapReduce被设计用

来在可信任的，全身心的，运行在同一个数据中心有着很高带宽的机器上运行持续几分钟或几小时的任务。相比而言，

SETI@home运行无尽的运算，在不可信任的机器上，可变的连接速度，没有数据本地化等。