hadoop 学习小结（2）

小小的原因，中间看了些东西，但没有时间整理。今天整理如下：小结（1）中对Google的云平台三大技术发表了一些粗浅的认识。这篇文章里，我们回来认识下Hadoop ：

Hadoop原来是Apache Lucene下的一个子项目，它最初是从Nutch项目中分离出来的专门负责分布式存储以及分布式运算的项目。简单地说来，Hadoop是一个可以更容易开发和运行处理大规模数据的软件平台。下面列举hadoop主要的一些特点：

1         扩容能力（Scalable）：能可靠地（reliably）存储和处理千兆字节（PB）数据。

2         成本低（Economical）：可以通过普通机器组成的服务器群来分发以及处理数据。这些服务器群总计可达数千个节点。

3         高效率（Efficient）：通过分发数据，hadoop可以在数据所在的节点上并行地（parallel）处理它们，这使得处理非常的快速。

4         可靠性（Reliable）：hadoop能自动地维护数据的多份复制(一般三份)，并且在任务失败后能自动地重新部署（redeploy）计算任务。

Hadoop项目实现了一个分布式文件系统（Hadoop Distributed File System），简称HDFS。HDFS有着高容错性（fault-tolerent）的特点，并且设计用来部署在低廉的（low-cost）硬件上。而且它提供高传输率（high throughput）来访问应用程序的数据，适合那些有着超大数据集（large data set）的应用程序。HDFS放宽了（relax）POSIX的要求（requirements）这样可以流的形式访问（streaming access）文件系统中的数据。

Hadoop还实现了MapReduce分布式计算模型。MapReduce将应用程序的工作分解成很多小的工作小块(small blocks of work)。HDFS为了做到可靠性（reliability）创建了多份数据块（data blocks）的复制（replicas），并将它们放置在服务器群的计算节点中（compute nodes），MapReduce就可以在它们所在的节点上处理这些数据了。（体现一种分而治之的思想）

Hadopp  也实现了其他的一些伴随项目，如Hbase，Pig，Zookeeper等

为了提供分布式的文件支持，仿制google的GFS Hadoop 实现了自己的文件系统HDFS（Hadoop Distributed File System）。

什么是分布式文件系统，顾名思义，就是分布式+文件系统。基本架构包括：

主控服务器（Master/NameNode），数据服务器（ChunkServer/DataNode），

和客户服务器。

主控服务器主要有三类数据：文件系统的目录结构数据，各个文件的分块信

息，数据块的位置信息。

数据服务器真正存放数据的地方。每一个文件数据块，在数据服务器上都表

征为出双入队的一对文件（这是普通的Linux文件），一个是数据文件，一个是

附加信息的元文件，在这里，不妨把这对文件简称为数据块文件。

•  客户端：为用户提供的一系列的API。

•  至于每个文件存取的份数可以预先配置 

对于分布式：服务器间的通信 

在Hadoop中，每一对服务器间的通信协议，都定义成为一个接口。服务端的类实现该接口并且建立RPC服务，监听相关的接口，在独立的线程处理RPC请求。客户端则可以实例化一个该接口的代理对象，调用该接口的相应方法，执行一次同步的通信，传入相应参数，接收相应的返回值。基于此RPC的通信模式，是一个消息拉取的流程。 

对目录的操作：

文件目录的信息，全部放在主控服务器（NameNode）上，因此，所有对文件目录的操作，只会直接涉及到客户端和主控服务器。整个目录相关的操作流程基本都是这样的：客户端DFSClient调用ClientProtocol定义的相关函数，该操作通过RPC传送到其实现者主控服务器NameNode那里，NameNode做相关的处理后（很少...），调用FSNamesystem的相关函数。在FSNamesystem中，往是做一些验证和租约操作，具体的目录结构操作交由FSDirectory的相应函数来操作。最后，依次返回，经由RPC传送回客户端。 

对文件的读取操作：

在文件读写操作中，最主要的通信，发生在客户端与数据服务器之间。它们之间跑的协议是ClientDatanodeProtocol。在Hadoop中，读写操作是不走RPC机制的，而是独立搭了一套通信框架。 在数据服务器一端，DataNode类中有一个DataXceiverServer类的实例，它在一个单独的线程等待，请求一旦接到，就启动一个DataXceiver的线程，处理此次请求。对于数据服务器来说，一个请求一个线程。文件的读取具体过程是：在客户端DFSClient中，有一个DFSClient.DFSInputStream类。当需要读取一个文件的时候，会生成一个DFSInputStream的实例。它会先调用ClientProtocol的getBlockLocations接口，提供给NameNode文件路径、读取位置、读取长度信息，从中取得一个LocatedBlocks类的对象，这个对象包含一组LocatedBlock，那里面有所规定位置中包含的所有数据块信息，以及数据块对应的所有数据服务器的位置信息。当读取开始后，DFSInputStream会先尝试从某个数据块对应的一组数据服务器中选出一个，进行连接。这个选取算法，非常简单，就是选出第一个活跃的数据服务器，并没有加入客户端与数据服务器相对位置的考量。读取的请求，发送到数据服务器后，自然会有DataXceiver来处理，数据被一个包一个包发送回客户端，等到整个数据块的数据都被读取完了，就会断开此链接，尝试连接下一个数据块对应的数据服务器，依次如此反复。

对文件的写入操作：

在HDFS中，并发写入的次序控制，是由主控服务器来把握的。当创建、续写一个文件的时候，该文件的节点类，由INodeFile升级成为INodeFileUnderConstruction，INodeFileUnderConstruction是INodeFile的子类，它起到一个锁的作用。如果当一个客户端想创建或续写的文件是INodeFileUnderConstruction，会引发异常，因为这说明这个此处忙碌会另找DataNode，从而保持了并发写入的次序性。同时，INodeFileUnderConstruction有包含了此时正在操作它的客户端的信息以及最后一个数据块的数据服务器信息，当追加写的时候可以更快速的响应。

•   与读取类似，DFSClient也有一个DFSClient.DFSOutputStream类，写入开始，会创建此类的实例。DFSOutputStream会从NameNode上拿一个LocatedBlock，这里面有最后一个数据块的所有数据服务器的信息。这些数据服务器每一个都需要能够正常工作（对于读取，只要还有一个能工作的就可以实现），它们会依照客户端的位置被排列成一个有着最近物理距离和最小的序列（物理距离，是根据机器的位置定下来的），这个排序问题类似于著名旅行商问题，属于NP复杂度，但是由于服务器数量不多。

•   文件写入，就是在这一组数据服务器上构造成数据流的双向流水线。DFSOutputStream，会与序列的第一个数据服务器建立Socket连接，发送请求头，然后等待回应。DataNode同样是建立DataXceiver来处理写消息，DataXceiver会依照包中传过来的其他服务器的信息，建立与下一个服务器的连接，并生成类似的头，发送给它，并等待回包。此流程依次延续，直到最后一级，它发送回包，反向着逐级传递，再次回到客户端。如果一切顺利，那么此时，流水线建立成功，开始正式发送数据。数据是分成一个个数据包发送的，所有写入的内容，被缓存在客户端，当写满64K，会被封装成DFSOutputStream.Packet类实例，放入DFSOutputStream的dataQueue队列。DFSOutputStream.DataStreamer会时刻监听这个队列，一旦不为空，则开始发送，将位于dataQueue队首的包移动到ackQueue队列的队尾，表示已发送但尚未接受回复的包队列。同时启动ResponseProcessor线程监听回包，直到收到相应回包，才将发送包从ackQueue中移除，表示成功。每一个数据服务器的DataXceiver收到了数据包，一边写入到本地文件中去，一边转发给下一级的数据服务器，等待回包，同前面建立流水线的流程。。。当一个数据块写满了之后，客户端需要向主控服务器申请追加新的数据块。这个会引起一次数据块的分配，成功后，会将新的数据服务器组返还给客户端。然后重新回到上述流程

 容错性考虑：

•       客户端：租约机制，就是当客户端需要占用某文件的时候，与主控服务器签订的一个短期合同。

•       NameNode： (仅生成本地日志)备用NameNode定期下载并处理日志和镜像

•       DataNode：数据服务器DataNode会在主循环中，不停的调用NameNode实现DatanodeProtocol接口中的sendHeartbeat方法，向NameNode汇报状况。并中期性的调用blockReport报告期数据块信息。

•       数据正确性保证：签名机制：根据Java SDK提供的CRC算法算得的，其实就是一个奇偶校验。