第I部分Hadoop基础知识

第1章初识Hadoop.

比较喜欢这句极其形象的比喻。

“在古时候，人们用牛来拉重物。当一头牛拉不动根圆木时，人们从来没有考虑过要想方设法培育出一种更强壮的牛。同理，我们也不该想方设法打造什么超级计算机，而应该千方百计综合利用更多计算机来解决问题。”

-葛蕾丝·霍珀(Grace Hopper)

 

1TB=1024GB

1PB=1024TB

1EB=1024PB

1ZB=1000EB

 

有句话说得好:“大数据胜于好算法。”意思是说对于某些应用(譬如根据以往的偏好来推荐电影和音乐),不论算法有多牛，基于小数据的推荐效果往往都不如基于大量可用数据的一般算法的推荐效果。

 

当然现在我们拥有这些大量的数据，所以如何存储和分析这些数据，成了我们要讨论和研究的。

 

经典问题：1TB的硬盘，其传播速度为100MB/S,读完整个硬盘中的数据至少得花2.5小时。怎么解决短时间内读取完这1TB数据？

读完整个硬盘中的数据需要更长时间，写入数据就别提了。一个很简单的减少读取时间的办法是同时从多个硬盘上读数据。试想，如果我们有100个硬盘，每个硬盘存储1%的数据，并行读取，那么不到两分钟就可以读完所有数据。

仅使用硬盘容量的1%似乎很浪费。但是我们可以存储100 个数据集，每个数据集1TB,并实现共享硬盘的读取。可以想象，用户肯定很乐于通过硬盘共享来缩短数据分析时间;并且，从统计角度来看，用户的分析工作都是在不同时间点进行的，所以彼此之间的干扰并不太大。

虽然如此，但要对多个硬盘中的数据并行进行读/写数据，还有更多问题要解决。

第一个需要解决的是硬件故障问题。一旦开始使用多个硬件，其中个别硬件就很有可能发生故障。为了避免数据丢失，最常见的做法是复制(replication):系统保存数据的复本(replica)，一旦有系统发生故障，就可以使用另外保存的复本。例如，冗余硬盘阵列(RAID)就是按这个原理实现的，另外，Hadoop 的文件系统(Hadoop Distributed FileSystem, HDFS)也是一类，不过它采取的方法稍有不同，详见后文的描述。

第二个问题是大多数分析任务需要以某种方式结合大部分数据来共同完成分析，即从一个硬盘读取的数据可能需要与从另外99个硬盘中读取的数据结合使用。各种分布式系统允许结合不同来源的数据进行分析，但保证其正确性是一个非常大的挑战。MapReduce提出.个编程模型，该模型抽象出这些硬盘读/写问题并将其转换为对一个数据集(由键-值对组成)的计算。后文将详细讨论这个模型，这样的计算由map和reduce两部分组成，而且只有这两部分提供对外的接口。与HDFS类似，MapReduce自身也有很高的可靠性。

简而言之，Hadoop 为我们提供了一个可靠的且可扩展的存储和分析平台。此外，由于Hadoop运行在商用硬件上且是开源的，因而可以说Hadoop的使用成本是在可承受范围内的。

 

我的理解：也就是说既然1TB的文件一台机器的话，读取需要2.5小时，那么，我们用100台机器去进行读取，每台机器读取其百分之一的数据，并且100台机器同时进行读取，那么时间会减少至1.5分钟。不过由于是100台机器，我们不敢确认100台机器永远不会出错，万一某台机器宕机，数据就会丢失，这里我们采用复制的方法，如果这台机器宕机，那么我们就使用保存的副本进行读取。那么这分散的100份数据如何结合使用，也就到了我们的分布式计算框架MapReduce.

 

从MapReduce 的所有长处来看，它基本上是一个批处理系统，并不适合交互式分析。你不可能执行一条查询并在几秒内或更短的时间内得到结果。典型情况下，执行查询需要几分钟或更多时间。因此MapReduce更适合那种没有用户在现场等待查询结果的离线使用场景。

 

随着Hadoop的发展，已经超越了批处理本身，实际上，名词"Hadoop" 有时被用于指代一个更大的、多个项目组成的生态系统，而不仅仅是HDFS和MapReduce。这些项目都属于分布式计算和大规模数据处理范畴。这些项目中有许多都是由Apache软件基金会管理，该基金会为开源软件项目社区提供支持，其中包括最初的HTTP server项目(基金会的名称也来源于这个项目)。

如 HBase : 一种使用HDFS做底层存储的键值存储模型。

       YARN ：集群管理系统

       等等

 

无论Hadoop上出现了多少不同的处理框架，就批处理而言，MapReduce 仍然有着一席之地。 MapReduce提出的一些概念更具有通用性(例如， 输入格式、数据集分片等)，因此最好是能够了解MapReduce的工作机制。

这段话也说出了为什么用一章去写MapReduce.

 

根据系统之间差异提出问题，

1.为什么不能用配有大量硬盘的数据库来进行大规模数据分析?我们为什么需要Hadoop?

这两个问题的答案来自于计算机硬盘的另一个发展趋势:寻址时间的提升远远不敌于传输速率的提升。寻址是将磁头移动到特定硬盘位置进行读/写操作的过程。它是导致硬盘操作延迟的主要原因，而传输速率取决于硬盘的带宽。

如果数据访问模式中包含大量的硬盘寻址，那么读取大量数据集就必然会花更长的时间(相较于流数据读取模式，流读取主要取决于传输速率)。另方面，如果数据库系统只更新一小部分记录，那么传统的B树(关系型数据库中使用的这种数据结构，受限于寻址的速率)就更有优势。但数据库系统如果有大量数据更新时，B树的效率就明显落后于MapReduce, 因为需要使用“排序/合并" (sort/merge)来重建数据库。

简单来说MapReduce 适合一次写入、多次读取数据的应用，关系型数据库则更适合持续更新的数据集。

 

---

 

Hadoop尽量在计算节点上存储数据，以实现数据的本地快速访问。“数据本地化(data locality)特性是Hadoop数据处理的核心，并因此而获得良好的性能。意识到网络带宽是数据中心环境最珍贵的资源(到处复制数据很容易耗尽网络带宽)之后，Hadoop通过显式网络拓扑结构来保留网络带宽。注意，这种排列方式并没有降低Hadoop对计算密集型数据进行分析的能力。

MapReduce有三大设计目标:(1)为只需要短短几分钟或几个小时就可以完成的作业提供服务; (2)运行于同一个内部有高速网络连接的数据中心内; (3)数据中心内的计算机都是可靠的、专门的硬件。