Hadoop权威指南摘抄(初识Hadoop)

初识Hadoop

古代，人们用牛来拉重物，当一头牛拉不动一根圆木时，他们不曾想过培育更大更壮的牛。同样，
我们也不需要尝试开发超级计算机，而应该结合使用更多计算机。
--格蕾斯.霍珀

数据的存储与分析

大数据时代，磁盘存储容量快速增加的同时，其访问速度--磁盘数据读取速度缺未能与时俱进。
1990年，一个1370MB的磁盘，传输速度为4.4MB/S,因此读取整个磁盘需要5分钟，20年后，1TB的磁盘逐渐
普及，其数据传输速度约为100MB/S,因此读取整个磁盘的数据要约两个半小时。
假如我们拥有100块磁盘，每个磁盘存储1%的数据，并行读取，那么不到两分钟就读取所有数据。
仅使用磁盘容量的1%似乎很浪费，但我们可以存储100个数据集，每个数据集1TB，实现共享磁盘访问。

尽管如此，实现多个磁盘的并行读写，还有更多的问题要解决：
1.硬件故障，一旦使用多个硬件，其中任一硬件发生故障的概率非常高，常见办法是进行备份，发生
故障后使用另一副本。例如RAID就是按照此原理实现。另外Hadoop的文件系统HDFS也是一类，不过
它采用的方法稍微不同。详见后文
2.大多数的数据分析任务需要以某种方式结合大部分的数据共同完成分析任务,即从一个磁盘读取的
数据可能需要和从99个磁盘中读取的数据结合使用，各种分布式系统允许结合多个来源的数据并实现
分析，但保证其正确性是一个非常大的挑战。Hadoop的MapReduce提出一个编程模型，该模型将上述
问题进行抽象，并转换为一个数据集的计算(键/值对组成)。

简而言之，Hadoop提供了一个可靠的共享存储和分析系统。HDFS实现存储，而MapReduce实现分析处理。
纵然Hadoop还有其他功能，但这两部分是它的核心。


关系型数据库管理系统的对比

我们为什么不能使用数据库来对大量磁盘上大规模的数据进行批量分析？为什么要需要MapReduce？

答案来自磁盘的发展趋势：寻址时间的提高远远慢于传输速率的提高，寻址就是将磁头移动到特定
磁盘位置进行读写的过程。它是导致磁盘延迟的主要原因，而传输速率取决于磁盘的带宽。
如果数据的访问模式中包含大量的磁盘寻址，那么读取大量数据集所花的时间势必会更长(相比流式数据读取模式)，
流式读取主要取决于传输速率。另一方面，如果数据库系统只更新一小部分记录，传统的B树更有优势。
但数据库系统更新大部分数据时，B数的效率比MapReduce低的多。

在很多情况下，可以将MapReduce视为关系型数据库管理系统的补充。MapReduce比较适合以批处理的方式
处理需要分析整个或大部分数据集的问题，尤其是即席查询。RDBMS适用于"点查询"和更新，数据集被索引
后，数据库系统能够提供低延迟数据检索和快速的少量数据更新。MapReduce适合一次写入，多次读取数据
的应用，而关系型数据库更适合持续更新的数据集。

MapReduce和关系型数据库之间的另一个区别是在于它们所操作的数据集的结构化程度。
结构化数据：xml或数据库表
半格式化: 虽然可能有格式，但经常被忽略，只能对数据结构一般指导。如电子表格，各个单元格组成，但
每个单元格自身可保存任何形式的数据。
半结构化数据：没有任何内部结构。比如纯文本或图像数据。

MapReduce对非结构化或半结构化数据非常有效，因为在处理数据时才对数据进行解释。换句话说，MapReduce
输入的键值并不是数据固有的属性，而是由分析数据的人员来选择的。
关系型数据往往是规范的，以保持其数据完整不冗余。但规范化给MapReduce带来了问题，它是记录的读取
称为异地操作，而MapReduce的核心之一就是，它可以进行高速的流式读写操作。

但是在不久的将来，关系型数据库系统和MapReduce之间的差异可能变得模糊，关系型数据库都开始吸收
MapReduce的一些思路(入Aster DATA和GreePlum的数据库)，另一方面，基于MapReduce的高级查询语言
(Pig,HIVE)使MapReduce的系统更接近传统的数据库编程方式。


MapReduce的设计目标是服务于那些只需数分钟或数小时即可完成的作业，并且运行于内部通过高速
网路连接的单一数据中心内，并且该数据中心内的计算机需要可靠的，可定制的硬件组成。