一、hdfs上传和下载文件流程
- hdfs上传
客户端向namenode发出请求建立通信获得存储文件块的datanode节点,然后客户端将文件按照块的大小进行分块(hadoop2.7.3开始由64MB变成128MB),客户端按照顺序将block逐个传到响应的datanode上,并由接收Black的datanode负责向其它的datanode复制block的副本
详解
1.客户端向namenode请求上传文件,namenode检查目标文件,父目录是否存在
2.namenode返回可使用资源,客户端根据使用资源对要写入的数据进行分块
3.客户端请求第一个Block上传位置
4.namenode返回3个datanode节点,分别是data1,data2,data3
5.客户端请求向第一个data1上传block,data1收到请求会调用data2,然后data2会调用data3,将通道建立完成，逐级响应客户端
6.客户端开始向data1上传第一个block(先从磁盘读取数据放到一个本地内存缓冲),单位为packet(一个packet为64kb),在写入data1的时候会进行数据校验，它并不是通过一个packet进行一次校验而是以chunk为单位进行校验（512byte）,data1收到packet就会传给data2,data2传给data3,第一台每传一个packet会放入一个应答队列等待应答
7.当一个block传输完成之后,datanode进行报告给namenode存储的块信息,同时也告诉客户端写入成功
8.客户端再次请求namenode上传第二个block的服务器（重复执行3-7步）
2.hdfs下载文件
客户端向hdfs读数据,首先要和namenode建立通信来获得需要读取文件的元信息(主要是Block的存放文件位置信息),客户端根据获取的信息找到相应datanode,逐个获取文件的block并在客户端本地进行数据追加,从而获得整个文件
hdfs下载文件
读取步骤详解:
1.client和namenode进行通信查询元数据(block所在的datanode节点),找到block所在的datanode服务器
2.挑选一台datanode,请求建立连接(就近原则,然后随机),请求建立socket流
3.datanode开始发送数据(从磁盘里面读取数据放入流,以packet为单位来做校验)
4.客户达以packet为单位接受,首先在本地缓冲,然后写入目标文件,后面的block追加合并到这个文件,最后合成最终需要的文件
二、mapreduce的shuffle过程
首先shuffle是贯彻整个mapreduce过程,可以分为2部分,map端的shuffle和reduce端的shuffle。map端shuffle,map任务执行后的中间结果”不会立马写入磁盘，而是优先存储到map节点的“环形内存缓冲区”(默认100MB)，当内存缓存区达到一定阈值(默认0.8)就会进行溢写到磁盘文件,溢写之前会先进行分区,然后分区内的排序,如果客户端自定义了Combiner，还会进行合并操作。最后如果有多个溢写文件。会对这个多个溢写文件进行归并生成最终的一个已分区且已排序的大文件。reduce端shuffle先领取不同节点map任务执行结束数据存储到缓存区,当缓存区到达一定阈值,就是发生溢写操作,溢写之前具有相同key的键值对会被归并,如果客户端定义combiner，归并后还可以执行combiner(合并),但溢写文件过多,也会归并成一个大文件。输出给Reduce任务，整个shuffle才最终结束。
三、hadoop1.0跟hadoop2.0区别
- 针对1.0中NameNode的单点故障问题，在2.0中引入了新的HA机制
2.解决jobTracker等弊端,使用yarn资源管理系统
四、hadoop 数据倾斜
就是大量的相同key被partition分配到一个分区里，map /reduce程序执行时，reduce节点大部分执行完毕，但是有一个或者几个reduce节点运行很慢，导致整个程序的处理时间很长，这是因为某一个key的条数比其他key多很多（有时是百倍或者千倍之多），这条key所在的reduce节点所处理的数据量比其他节点就大很多，从而导致某几个节点迟迟运行不完。
解决方案:
1.增加jvm内存,这适用于第一种情况(唯一值非常少，极少数值有非常多的记录值(唯一值少于几千)),这种情况下,往往只能通过硬件的手段来进行调优,增加jvm内存可以显著的提高运行效率。
2.增加reduce的个数,这适用于第二种情况(唯一值比较多，这个字段的某些值有远远多于其他值的记录数，但是它的占比也小于百分之一或千分之一),我们知道,这种情况下,
最容易造成的结果就是大量相同key被partition到一个分区,从而一个reduce执行了大量的工作,而如果我们增加了reduce的个数,这种情况相对来说会减轻很多,毕竟计算的节点多了,就算工作量还是不均匀的,那也要小很多。
3.自定义分区,这需要用户自己继承partition类,指定分区策略,这种方式效果比较显著。
4.重新设计key,有一种方案是在map阶段时给key加上一个随机数,有了随机数的key就不会被大量的分配到同一节点(小几率),待到reduce后再把随机数去掉即可。
5.使用combinner合并,combinner是在map阶段,reduce之前的一个中间阶段,在这个阶段可以选择性的把大量的相同key数据先进行一个合并,可以看做是local reduce,然后再交给reduce来处理,这样做的好处很多,即减轻了map端向reduce端发送的数据量（减轻了网络带宽）,也减轻了map端和reduce端中间的shuffle阶段的数据拉取数量(本地化磁盘IO速率),推荐使用这种方法。
五、hdfs不适合存小文件的原因
1.namenode会记录文件的元数据，如果小文件过多，会造成namenode消耗太大
2.hdfs的设计原理是接近磁盘读取速度，之所以把block块设置很大，是因为想做到寻道时间远小于文件读取数据块的时间，接近磁盘读取速度。
