1.client发起文件上传请求，通过RPC与NameNode建立通讯，NameNode检查目标文件是否已存在，父目录是否存在，返回是否可以上传文件
2.client请求第一个block该传输到哪些DataNode服务器上
3.NameNode根据配置文件汇总指定的备份数量及机架感知原理进行文件分配，返回可用的DataNode的地址如：A/B/C
注：hadoop在设计时考虑到数据的安全与高校， 数据文件默认在HDFS上存放三份，存储策略为本地一份，同机架内其他节点存一份，不同机架的某一节点上存一份
5.client开始往A上传第一个block（先从磁盘读取数据放到一个本地内存缓存），以packet为单位（默认64k），A收到一个packet就会传给B， B传给C；A每传一个packet会放入一个应答队列等待应答。
6.数据被分割成一个个packet数据包在pipeline上依次传输，在pipeline反方向上， 逐个发送ack（命令正确应答），最终由pipeline中第一个DataNode节点A将pipeline ack 发送给client
7.当一个block传输完成之后，再次请求NameNode上传第二个block到服务器，与第一个block步骤一致。直到所有的block都上传完成。
1.client向Namenode发起RPC请求，来确定请求文件block所在的位置
2.NameNode会视情况返回文件的部分或者全部block列表，对于每个block，NameNode都会返回含有该block副本的DataNode地址
3.这些返回DataNode地址，会按照集群拓扑结构得出DataNode与客户端的距离，然后进行排序，排序两个规则：网络拓扑结构中距离client近的排靠前；心跳机制中超时汇报的DataNode状态为STALE，这样的排靠后
4.client选取排序靠前的DataNode来读取block，如果客户端本身就是DataNode，那么将从本地直接获取数据；
5.底层上本质是建立Socket Stream（FSDataInputStream），重复的调用父类DataInputStream的read方法，直到这个块上的数据读取完毕
6.当读完列表的block后，若文件读取还没有结束，客户端会继续向NameNode获取下一批的block列表
7.读取完一个block都会进行checksum验证，如果读取DataNode时出现错误，客户端会通知NameNode，然后再从下一个拥有该block副本的DataNode继续读
8、read方法是并行的读取block信息，不是一块一块的读取；NameNode只是返回client请求包含块的DataNode地址，并不是返回请求块的数据
9.最终读取来所有的block会合并成一个完整的最终文件
HDFS是解决海量数据存储问题的存储系统，具有高可靠，读写效率高等特点。通过将大问你件拆分成一个一个block块，Hadoop2.x默认是128M。分布式的存储到各个DataNode节点汇总并且备份，通过横向扩展解决了纵向扩展的问题，大大提升了读写的效率和降低了成本。同时，通过设置NameNode主节点来记录每个block的元数据信息，包括块名，所在DataNode节点，备份所在位置，大小等信息，实现文件的高可靠存储和高效率读取，而且在Hadoop2.x以上版本，通过HA解决了NameNode的单点故障问题，使得HDFS更为可靠
NameNode管理者文件系统的NameSpace，它维护着文件系统树以及文件树中所有的文件和文件夹的元数据（metadata），比如命名空间信息，块信息等。管理这些信息的文件有两个，分别是NameSpace镜像文件（NameSpace image）和操作日志文件（edit log），这些信息被Cache在RAM中，这两个文件也会被持久化存储在本地硬盘，NameNode记录着每个文件中各个块所在的数据节点的位置信息，但是它并不持久化存储这些信息，这些信息会在系统启动时从数据节点重建。
fsimage -- 它是在NameNode启动时对整个文件系统的快照
edit log -- 它是在NameNode启动后，对文件系统的改动序列
如果NameNode挂掉了，那么就丢失了很多改动因为此时的fsimage文件非常旧，因为丢失的改动应该是还在内存中但是没有写到edit logs的这部分，因此为了克服这个问题，我们需要一个易于管理的机制来帮助我们减小edit logs文件的大小和得到一个最新的fsimage文件，这样会减小在NameNode上的压力。
一、是将持久化存储在本地硬盘的文件系统元数据备份， Hadoop可以通过配置来让NameNode将他的持久化状态文件写到不同的文件系统中，这种写操作时同步并且是原子化的，比较常见的配置是在持久化状态写到本地硬盘的同时，也写入到一个远程挂在的网络文件系统（NFS）
二、是运行在一个辅助的NameNode（Secondary NameNode）。
Secondry NameNode并不能被用作NameNode。它的主要作用是定期的将NameSpace镜像与操作日志文件（edit log）合并，以防止操作日志文件（edit log）变得过大。通常 Secondary NameNode运行在一个单独的物理机上，因为合并操作需要占用大量的CPU时间以及和NameNode相当的内存。辅助NameNode保存着合并后的Namespace镜像的一个备份。如果NameNode宕机了，这个备份就可以用上了。
但是辅助Namenode总是落后于主Namenode，所以在Namenode宕机时，数据丢失是不可避免的。在这种情况下，一般的，要结合第一种方式中提到的远程挂载的网络文件系统(NFS)中的Namenode的元数据文件来使用，把NFS中的Namenode元数据文件，拷贝到辅助Namenode，并把辅助Namenode作为主Namenode来运行。
它的作用是合并NameNode的edit logs 到fsimage文件中。
NameNode在宕机后重启时会使用这个新的fsimage文件，从而减少重启的时间。
Secondary NameNode的整个目的是在HDFS中提供一个检查点，它只是NameNode的一个助手节点。而不是取代掉NameNode也不是NameNode的备份
首先由client 提出读、写需求 -- namenode：协调与把控 ---datanodes 数据存储所以数据存储由datanode负责
load data inpath ‘hdfs://hdfs_server01:8020/input/test.txt‘ into table test_hdfs_to_hive;
//把HDFS文件中的内容映射到hive表中
load data inpath ‘hdfs://hadoop01:9000/tmp/sales_info.txt‘ overwrite into table sales_info partition(dt = ‘20191215‘);
一个MapReduce作业由map阶段和reduce阶段两部分组成，这两阶段会对数据排序，MapReduce框架本质就是一个Distributed Sort。
在map阶段，Map Task会在本地磁盘输出一个按照key排序（快速排序）的文件（可能中间会产生多个文件，但最终会合并成一个）
在reduce阶段，每个reduce task会对收到的数据排序，数据变按照key分成了若干组，之后以组为单位交给reduce() 处理，很多人的误解在Map阶段，如果不适用Combiner便不会排序，这是错误的，不管用不用Combiner，Map Task均会产生的数据排序（当然如果没有Reduce Task，则不会排序，实际上Map阶段的排序就是为了减轻Reduce端排序负载），
原文：https://www.cnblogs.com/yzqyxq/p/12776133.html