我眼中的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中，本着不重现发明轮子的思想，再次用了该方式进行主从元数据同步。

         HDFS通过主从功能实现高可用性最早由facebook实现，实际上facebook的同学们也是借鉴了DRDB（一个用软件实现的、无共享的、服务器之间镜像块设备内容的存储复制解决方案），与mysql。

         还有数据的周期性校验与读写时校验，以及NWR等等。我相信以后虽然还会出现解决各种不同问题的方案，但是都是这些很通用的理论，方案进行组装而成。就像再牛逼的汽车，都是由一系列普通零件组合而成。软件与硬件行业，甚至各行各业都是想通的。

6.没有谁是万能的救世主

6.1.完美在天边

     刚开始接触存储的时候，总想找一个完美的存储方案来解决所有的问题，也觉得存储技术发展很长时间，应该很成熟了，于是就怀着寻找一个能够很好地支持不同大小，不同格式的文件，满足高可用性，高性能，海量存储，并经过业界长时间检验，具备高稳定性的开源存储系统，一句话就是一个完美的系统。很遗憾，到目前为止还没有找到。

     Glusterfs主要适合大文件且不成熟；swift由rackspace开源，据说很多种类型文件存储都适合，但实时性不高，也不成熟；hbase与cassandra只适合存储小于1MB的文件，HDFS只适合存储大文件等等，让人很难抉择，因为哪一个都不是我们想要的可以一劳永逸，解决所有问题的那一个方案，而都是针对某一个。觉得写这些系统的人太弱了嘛！

     随着认识的深入，逐渐明白，不同应用场景的存储需要的解决方案是不一样的，比如小文件与大文件，低延迟与高吞吐量问题。要什么都顾及，可能最后系统变得异常复杂，同时可维护性，规模，性能等问题也变得复杂，运维成本指数上升。甚至最后变成一个“怪物”。

     这个问题让我联系到了汽车，就像你想要一辆牛B的汽车，可以跑得很快，可以拉很多人，最好还可以拉货，如果能变成可以飞的那就更好了。。。其实这一系列条件本来就跟鱼与熊掌不可兼得是一个道理。

      曾经听某君说过，一个牛B人的优点跟他的缺点一样突出，之所以他成功了，是很好地利用了他的优点。

6.1.HDFS不是一个交互式系统

      所谓交互式系统，我的理解是用户向系统发出请求，系统能够给用户一种很友好的体验，所谓体验就是响应速度快且稳定，让用户心情愉悦。比如提供类似dropbox存储服务，就需要满足每个用户访问云端内容类似访问本地机器一样。如果按照这样一种逻辑，HDFS不算一个交互式系统，NN会随着并发增加性能大幅降低，因为它将用户的并行写转换成了串行写。当然还有其他问题，就不一一列举了。              

6.2.HDFS不适合小文件

       HDFS设计的初衷是存储大文件,如果单个DataNode有12块2T的硬盘,则有存储空间24T,如果每个块100M,则可存储251658,如果每个块50M,则可存储503316.DataNode会向NameNode进行两种类型的块报告:增量报告与全量报告,DataNode接收到块,或者删除块会立即向NM报告,这属于增量报告;全量报告周期性发生,定时将当前DN上所有数据块信息报告给NM.NM处理一百万的块报告需要1s左右,这1s左右NM会被锁住,其他的请求会被阻塞.因此单节点存储50万左右对NM影响不会太多，而且hadoop本身是做离线处理，主要在规定时间范围内把任务做完就OK，不关心每次请求的响应时间。DataNode同时也会周期性扫描本地磁盘的目录,验证内存中记录的块信息与磁盘上存储的块元数据是否一致.

如果存储大文件,该设计方式不会有什么问题,如果存储大量小文件，就会暴露出一些问题。小文件可能很小，比如文件平均大小为1M，单DN12块盘工24TB空间，则可存储数据块25165824即2000多万个块。如文件更小，单DN能够存储的数据块更多。这样会引起几个问题：

1、因为DN扫描本地磁盘文件目录时候，会涉及到比对内存记录的文件长度与磁盘上文件长度，整个过程DN会锁住，DN不能进行读写操作，磁盘操作速度本身就是毫秒级，因此如果单DN存储块过多，影响业务就会很长，造成客户端大量的重试。因为DN会周期性向NM发生心跳操作，该过程DN的发送心跳操作也会阻塞，如果超过10分30秒，NM会认为该DN死掉，这样就会引起大量的数据块移动。

2、在普通的Linux文件系统中，读取一个文件包括三次磁盘IO：读取目录元数据到内存，把文件的inode节点装载到内存，最后读取实际的文件内容。由于文件数太多，无法将所有目录及文件的inode信息缓存到内存，就会造成大量的磁盘操作。这个问题业界通用解决办法是将小文件写到大文件内，将随机写变为顺序写。

3、因为单DN数据块多，热点数据可能就会更多，机器就会更忙碌，这样可能会导致客户端读写文件超时。

4、单DN周期性报告太多块，会导致NM中断时间长，按照100万个块需要1s，则1000万需要10s，2000万需要20s，则会导致大量的请求阻塞，比如每秒向NM有1000个请求，则10s会阻塞10000个，如果是响应要求很高的请求，就会悲剧。

5、在数据块报告的时候，每个块会涉及到4个字段，每个都会是long型，每个long型8个字节，则每个块需要占用32个字节，则5百万个块会占用158MB，如果有20个这样规模的DN报告上来，对NM的网卡，机器内存压力都是挺大的。可能导致NM处理速度变慢。

6、单NM存储的元数据太多需要更换更大内存，JVM heap配置太大进行GC会导致NM阻塞，如果是响应要求很高的请求，也是个问题。

基于上面出现的这些问题，可以通过提供选择更大内存，更多core的机器作为NM，同时单节点启动多DN（根据机器实际情况而定，如果太多也会导致DN速度变慢），周期性报告块由全量变为分批进行处理。如果NM压力过大或者响应太低，就需要换成Federation解决方案了。单DN扫描本地目录及其数据块导致长时间锁住的问题可改造成分批次加锁解决。

7.百味的运维

7.1.HDFS常见症状

      Hadoop集群的稳定工作，与运维工作关系相当密切，其实践性要求很强。不同集群规模，不同访问量等情况，遇到的运维问题是不一样的。对于HDFS来说,主要会遇到如下一些常见症状：

       1.NN主从节点硬件配置不一样：如果Standby服务重读日志速度跟不上Active服务写日志的速度，如果此时进行主从切换，可能耗费较长时间。

       2.NFS单点：NFS在业界已经有20多年的成长历史，算是一个比较成熟的数据工具了，软件本身一般不会出现问题，但是如果网络异常，或者NFS server所在机器出问题，则NFS client就不能继续提供服务。如果用NFS来实现主从共享元数据，异常情况可能导致主从服务均宕掉。可以通过QJM等来替代NFS。

       3.fsimage文件太大：如果集群存储太多文件，fsimage就会变很大，一般来说1000万个文件的元数据会占用1GB的存储空间（与文件名长度等有关系），如果太频繁进行checkpoint可能造成active节点机器网络繁忙；同时如果上传fsimage超时时间太短，可能导致上传失败，然后不断重复上传操作，这可能导致standby节点磁盘空间被塞满。建议可以改造该流程，将Active节点备份元数据方式改造成Standby通过NFS方式进行备份，不用再上传fsimage到Active节点，这样可解决这一系列问题。

       4.元数据损坏：对HDFS集群来说，软件修改升级是常事，在升级过程中要检查元数据是否最新（可以通过比对txid），否则可能造成元数据破坏。

       5.client访问DN超时：client可能出现等待DN执行结果而超时，情况有可多，有种情况是由于DN压力太大，DN已经将执行结果写入发送队列，但是client没有收到该结果，该种情况可以通过负载均衡等方式减小该DN压力。

      6.HDFS集群网络不独立：HDFS网络最好与其他应用独立开，因为它对是特别依赖网络IO型应用，可能读写文件导致其他应用网络阻塞。

      7.JVM优化问题：jvm配置可能随着不同集群规模会不断调整，如果很有经验，可以最先就调整好。对于gc来说，不适应选择单线程的串行收集器，该收集器只适合100MB内的heap大小，而应该选择并行收集器（Parallel Old）或者并发收集器（CMS），两者都比较适合作为大型应用的gc收集器。并行收集器偏向吞吐量但可能STW较长，并发收集器偏向做为在线应用的gc收集器，它与应用并行执行，STW较短，但是它能会产生较多内存碎片，因此需要添加内存整理的参数。如果HDFS为大数据计算提供支持，NN与DN可选择并行收集器，如果HDFS是用于存储在线应用的大文件，NN可选择CMS。当然jvm优化是线下测试与线上监控结合起来的。

      8.集群性能与网络监控不力：利用ganglia进行网络等硬件资源监控，可以及时避免一些问题，同时可以自己开发性能监控工具对HDFS集群进行监控。

      9.NN自动切换：如果集群规模小，NN自动切换功能一般不会有问题，如果集群规模大了，需要对其参数做不少优化，否则可能导致不该切换的时候切换，或者切换失败。由于apache版本本身的bug，可能某个NN本身就不具备对外正常提供服务的条件，但也被切为Active，这可能导致集群不可访问。因此对于离线存储来说，可以不启用自动切换，因为一般也不需要自动切换，同时加大了运维难度。

      10.NN速度不稳定：并发数不一样，NN速度波动比较大，这个是hadoop本身设计决定的。

       这儿只列了10点，肯定还有很多其他问题，需要在运维中不断总结。

7.2.运维服务生

       运维工作与hadoop管理员有着太多的联系,作为一个管理员,不同的时间,会有不一样的体会,集群上线前,会有交朋友的感觉,通过功能测试,性能测试与优化,稳定性,甚至源码研究,通过各种方式,从各个角度去了解这个朋友的脾气;开发存活性,性能等各种类型监控,像带小孩一样关心其“冷暖”;集群出问题了,又像照顾病人,想办法尽快让其”早日康复”。因为问题半夜睡不着觉会有，面对使用方催促同样会有。

       除了平常基本的添减机器，关闭启动服务，运维工作的难点主要是面对潜在问题与突发事件如何应对，潜在问题如果不及时发现跟解决，可能转化为突发事件。通过多跟业务部门沟通，及多分析监控数据可以有效避免重大问题发生。

总结起来，运维工作就是做好如下几件事：

1.测试与研究：通过测试了解系统的基本功能，性能，以及参数调优；研究不仅可以验证测试，同时也为分析问题与解决问题服务；

2.监控报警：通过监控系统了解系统的“一举一动”，包含功能正常性，性能是否降低等，方便任何问题可以快速跟踪解决；

3.线上验证：这个步骤很重要，系统重新上线后，可能因为某些失误导致系统出错。；

4.沟通：如果系统有其他使用方，多跟他们沟通，保持双方或者多方信息一致，这样可以及时避免一些问题；

5.分析问题与解决：系统发生问题，首先尽快恢复系统可用性，然后再分析问题；

6.及时复盘：不是问题解决完成后就完事了，一个及时地，好的复盘，不仅避免类似问题再发生，而且可以找出一些潜在的问题，保证系统尽量安全稳定地运行。

欢迎转载，并请注明出处