hadoop总结之HDFS（一）_hdfs dfsadmin -safemode enter

最近又学习了hadoop，准备好好整理一下这一部分的学习内容。

---

11.04 hadoop生态圈
hadoop是能够对大量数据进行分布式处理的软件框架。apache的开源平台，相当于一个中间件。
hadoop利用服务集群，根据用户自定义的业务逻辑，对海量数据的分布式处理。
更广泛的来说，hadoop 是指一个hadoop生态圈。

其中重点组件：
HDFS：分布式文件系统；
MapReduce：分布式运算程序开发框架；
Yarn：资源管理框架，为上层应用提供统一的资源管理和调度；
Sqoop：SQL-to-Hadoop，数据同步工具，主要用于传统数据库和Hadoop之间传输数据；
Mahout：数据挖掘算法库；
Hbase：分布式列存数据库，针对结构化数据的可伸缩、高可靠、高性能、分布式和面向列的动态模式数据库；
Zookeeper：分布式协作服务，主要解决分布式环境下的数据管理问题：统一命名，状态同步，集群管理，配置同步等；
Pig：基于hadoop的数据流系统；
Hive：基于hadoop的数据仓库，类似Sql的查询语言（Hql），将SQL转化为MapReduce任务在hadoop上执行；
Flume：日志收集工具；
Oozie：工作流调度框架；
Spark：专为大规模数据处理而设计的快速通用的计算引擎；
Tez：针对hadoop数据处理应用程序的新分布式执行框架；
Storm:分布式实时计算。

刚才是hadoop生态圈，而hadoop中的重要组成模块有HDFS、MapReduce、Yarn。

HDFS（hadoop distributed file system）：
分布式文件系统，提供副本进行高容错以及可靠性保证。
适用于：
（1）存储非常大的文件；
（2）采用流式的数据访问方式：通过流的方式访问，批量处理
（3）检测和快速应对硬件故障；
（4）简单一致性模型：一次写入，多次读取，支持追加，不支持修改
不适用于：
（1）低延时的数据访问；
（2）大量小文件；
（3）多方读写，需要任意的文件修改

HDFS核心：

1 Blocks
块的概念，HDFS的block块默认为64M，HDFS文件被拆分成块大小的独立单元存储，比block小的文件不会占用整个block，只会占据实际大小。block作为容错和高可用机制中的副本单元，以block为单位进行复制。

1.1 block的大小设置
HDFS中block大小的设置是为了最小化查找时间，控制定位文件与传输文件所用的时间比例。如果block设置过大，map或reduce任务的个数小于集群机器数量，会导致作业运行时间效率很低。

1.2 block的抽象
block抽象简化了存储系统，无需关注其权限、所有者等内容（在文件级别上控
制）。

1.3 block缓存
Datanode通常直接从磁盘读取数据，其中频繁使用的block可以在内存中缓存。
默认情况下，一个block只会有一个数据节点缓存。但可以针对每个文件进行个性化配置。
作业调度器利用缓存提升性能，MapReduce把任务运行在有block缓存的节点上。
用户或者应用可以向Namenode发送缓存指令（缓存谁，多久）,缓存池的概念用来管理一组缓存的权限和资源。

2 Namenode和Datanode
HDFS采用master/slave架构，一个HDFS集群包含一个单独的NameNode和多个DataNode。

Namenode
1.1 Namenode作为master服务，负责管理文件系统的命名空间和客户端对文件的访问。
1.2 Namenode会保存文件系统的具体信息，包括文件信息、文件被分割成具体block块的信息，以及每个block块归属的Datanode信息。
1.3 HDFS通过Namenode为用户提供了一个单一的命名空间。
1.4 Namenode持久化有两种：namespace image 、edit log。
持久化数据中不包括block所在的节点列表，文件的block分布在集群中的哪些节点上，这些信息会在系统重启的时候重新构建（通过Datanode汇报block信息）。
1.5 HDFS中，Namenode可能成为集群的单点故障，Namenode不可用的时候，整个文件系统是不可用的。针对单点故障提供了以下两种机制：
（1）备份持久化元数据
将文件系统的元数据同时写到多个文件系统中，且备份都是同步的、原子的。
（2）Secondary Namenode
Secondary节点定期合并namespace image和edit log，避免edit log过大，通过创建检查点来合并（checkpoint）。它会维护一个合并后的namespace image副本，可用于Namenode完全奔溃的时候恢复数据。Secondary Namenode通常运行在另一台机器中，因为合并需要耗费大量CPU和内存。其数据落后于Namenode，所以当Namenode完全崩溃时，会出现数据丢失，通常的做法是拷贝NFS中的备份元数据到Secondary Namenode，将其作为新的主Namenode。
在HA中可以运行一个Hot Standby，作为热备份，在Active Namenode故障之后，替代原有Namenode成为Active Namenode。

Datanode
2.1 Datanode作为slave服务，可以存在多个，通常每个Datanode对应于一个物理节点。
2.2 Datanode负责管理节点上他们拥有的存储，将存储划分为多个block块，管理block块信息，周期性的将其所有block块信息发送给Namenode。

3 HDFS FedFederation（联合）
由于Namenode内存有限，HDFS Federation提供了一种横向扩展Namenode的方式。在模式中，每个Namenode管理命名空间的一部分；每个Namenode管理一个namespace volumn，所有volumn构成文件系统的元数据；每个Namenode同时维护一个block pool，保护block的节点映射等信息。
各个Namenode之间相互独立，一个节点的失败不会导致其他节点管理的文件不可用。
客户端使用mount table将文件路径映射到Namenode，mount table是在Namenode群组之上封装了一层，这一层也是一个Hadoop文件系统的实现，通过viewfs：协议访问。

11.7
4 HDFS HA
HA即High Available 高可用，Hadoop HA通过同时配置两个处于Active/Passive模式的Namenode来解决单点故障问题（Namenode一旦出现故障，整个集群将不可用），分别为Active Namenode 和Standby Namenode。其中Standby Namenode作为热备份，使其能够快速故障转移。
Namenode只能配置一主一备，不能多于两个Namenode。
主Namenode处理所有请求，Standby作为slave，维护尽可能同步的状态，为了能够快速切换。为了保持数据同步，两个Namenode都与一组Journal Node进行通信，当主Namenode进行任务的namespace操作时，会将确保持久，修改日志到Journal Node节点中，Standby Namenode持续监控这些edit，当监控到变化时，将这些修改应用自己的namespace中。
当故障转移时，Standby Namenode成为Active Namenode之前，会确保已经读取Journal Node中的所有edit之日，而保持数据状态与之前一致。
确保故障快速转移，Standby Namenode 需要维护最新的block位置信息（每个block副本存放在集群的哪些节点上），Datanode会同时配置主备两个Namenode，并同时发送block报告和心跳到两台Namenode上。
任何时刻只有一个Namenode处于Action状态，否则可能出现数据丢失或者损坏。为了防止两个Namenode都认为自己是Active，Journal Node只允许一个写入数据，内部通过维护epoch数来控制。

两种进行edit log共享方式：
使用NFS共享edit log（存储在NAS/SAN）
使用QJM共享edit log
（未完）

//RPC（remote procedure call）远程过程调用
HDFS读流程
1.客户端使用FileSystem对象的open方法打开文件（其实获取的是一个DistributedFileSystem实例）；
2.DistributedFileSystem用RPC向Namenode发起请求，得到文件的数据块的位置信息，同一数据块按照备份数返回多个DataNode位置信息，根据集群的网络拓扑结构排序，距离客户端近的排在前面；
3.DistributedFileSystem类返回一个FSDataInputStream对象给客户端，通过read函数读取数据；
4.FSDataInputStream连接保存文件第一个数据块的最近的数据节点；
5.数据从数据节点读取到客户端；
6.当前数据块读取完毕时，FSDataInputStream关闭和断开与数据节点的连接，连接文件下一数据块的最近的数据节点；
7.客户端文件读取完毕后，调用FSDataInputStream的close函数；
#读取过程中，如客户端和数据节点通信出现错误，则尝试连接包含此数据块的下一数据节点。失败的数据节点被记录，以后不再连接。

HDFS写流程

1. 使用HDFS提供的客户端开发库，向远程的Namenode发起RPC请求；

2. Namenode会检查要创建的文件是否已经存在，创建者是否有权限进行操作，成功则会为文件创建一个记录，否则会让客户端抛出异常；

3. 当客户端开始写入文件的时候，开发库会将文件切分成多个packets（信息包），并在内部以"data queue"的形式管理这些packets，并向Namenode申请新的blocks，获取用来存储replicas（复制品）的合适的datanodes列表，列表的大小根据在Namenode中对replication的设置而定。

4. 开始以pipeline（管道）的形式将packet写入所有的replicas中。开发库把packet以流的方式写入第一个datanode，该datanode把该packet存储之后，再将其传递给在此pipeline（管道）中的下一个datanode，直到最后一个datanode，这种写数据的方式呈流水线的形式。

5. 最后一个datanode成功存储之后会返回一个ack packet，在pipeline里传递至客户端，在客户端的开发库内部维护着"ack queue"，成功收到datanode返回的ack packet后会从"ack queue"移除相应的packet。

6. 如果传输过程中，有某个datanode出现了故障，那么当前的pipeline会被关闭，出现故障的datanode会从当前的pipeline中移除，剩余的block会继续剩下的datanode中继续以pipeline的形式传输，同时Namenode会分配一个新的datanode，保持replicas设定的数量。

---

作者：菜鸟级的IT之路
来源：CSDN
原文：https://blog.csdn.net/wypersist/article/details/79797565
版权声明：本文为博主原创文章，转载请附上博文链接！

以上是HDFS的内容，下面讲一下Namenode安全模式和RPC机制。

NameNode安全模式：
分布式文件系统启动后，开始时会有安全模式，这时候的文件不允许有上传、修改、删除等操作，能只读一直到安全模式结束。
1）NameNode启动，先将映射文件（fsIamge）载入内存，执行编辑日志（edits）中的各项操作；
2）一旦内存中成功建立文件系统元数据映射，则创建一个新的fsImage文件和一个空白的日志文件（edits）；
3）NameNode开始监听RPC和HTTP；
4）这个时候NameNode处在安全模式，对于客户端来说文件系统是只读的；
5）系统中的数据块位置不是NameNode维护的，是以块列表的形式存储在DataNode中；
6）在正常操作期间，NameNode在内存中保留所有块的映射信息；
7）在安全模式下，各个DataNode会向namenode发送块列表信息；

查看namenode处于哪个状态：
hadoop dfsadmin -sagemode get

进入安全模式
hadoop dfsadmin -sagemode enter

离开安全模式
hadoop dfsadmin -sagemode leave

RPC机制：
hadoop的RPC机制（四部分）
1.序列化层：Client与Server端通信传递的信息采用了Hadoop提供的序列化类或自定义Writable类；
2.函数调用层：通过动态代理以及Java反射实现函数调用；
3.网络传输层：采用了基于TCP/IP的socket机制；
4.服务器端框架层：RPC Server利用java NIO以及采用了事件驱动的I/O模型，提高RPC Server的并发处理能力。