我眼中的hadoop（5-7）

术业有专攻

5.1.HDFS成也大文件   

        Hadoop主要处理的是大文件，从而HDFS设计的初衷也是存储大文件，及其计算过程中产生的中间文件，以满足mapreduce快速地读写文件的要求，当然前提是机房网络速度给力。为了满足需求，HDFS进行了如下设计：

1.流式写文件，对于上传任何一个文件，Client向一台DN写数据块，再由DN向其他DN写数据块，而不是一个客户端同时向多个DN写数据，这样实现的好处是可以充分利用DN的网卡，而不会造成client网卡已经跑满，而DN网卡还很闲。

2.高吞吐量，由1已经知道，在写文件的时候，可以充分利用client与DN网卡，测试数据表明，文件大于5MB，读写文件均可以把网卡跑满。

3.NN以少写多读为设计原则，NN只有一个单进程，且操作过程通过读写锁控制并发，因此上传文件创建元数据的时候仅允许一个文件进行操作，这样操作就变成了串行。如果并发太多，势必就会有些操作响应时间变长；读操作加读锁，因此可以多个请求并行进行处理，从而NN实现少写多读。

4.DN以高吞吐量为设计原则，上传数据块时，创建数据块文件及其块校验和文件DN加全局锁，真正写数据流的时候不加锁；下载数据块时，读取块文件元数据时加锁，真正读IO流的时候不加锁。同时对于磁盘来说，大文件本身也很容易达到高吞吐量，这样磁盘更多的时间是在处理IO流，而不是不停旋转寻找新地址。但是这也会牺牲节点的高并发。可以通过集群大量的DN节点来满足集群的高并发，但只能说是相对地，还是要看集群规模。

5.DN数据块数量可控，因为HDFS存储的都是大文件，这就注定了单DN上不会存储太多的数据块，因此单DN不会因为块太多而影响存储目录扫描，心跳，块报告等操作。

6.full gc对NN的影响，随着集群文件量增加，NN的heap空间也会大量增加，gc特别是full gc时间会加长，但是作为一个离线计算平台，只要能在规定时间范围内完成计算，fullgc在一定时间范围内是被允许的。

5.2.借鉴与创新

       我们已经知道HDFS可以很好地解决hadoop大数据计算过程中的存储问题，同时也是业界很经典的存储解决方案，但并不是什么地方都是HDFS首创，而是借鉴了业界的一些经典的方案。

         在DHCP中，DHCP服务器通过租约控制一个IP分配给某个机器使用的时间长度，时间到了需要续约，HDFS通过借鉴租约机制来实现分布式锁功能，这样即使在跨机器，跨服务也可以很好控制文件的并发。

         在mysql中，操作日志通过追加到日志文件来记录操作行为，mysql slave节点通过重读操作日志文件重现mysql active节点的数据，从而达到主从数据一致。在HDFS中，本着不重现发明轮子的