hadoop学习课程（第二天）

分布式文件系统与HDFS

HDFS体系结构与基本概念

HDFS的shell操作

java接口及常用api

HADOOP的RPC机制

HDFS源码分析

NN元数据管理机制：

什么是元数据呢？百度百科的解释是这样的，描述数据的数据（data about data），主要是描述数据属性（property）的信息，用来支持如指示存储位置、历史数据、资源查找、文件记录等功能。元数据算是一种电子式目录，为了达到编制目录的目的，必须在描述并收藏数据的内容或特色，进而达成协助数据检索的目的。说了这么了多，简单地说，就是管理数据的数据。

      在hadoop中有两个角色，namenode(一个主节点),datanode（多个从节点），datanode主要是存储数据的，namenode一是管理文件系统文件的元数据信息（包括文件名称、大小、位置、属性、创建时间、修改时间等等），二是维护文件到块的对应关系和块到节点的对应关系，三是维护用户对文件的操作信息（文件的增删改查）。

存储细节

 

      现在我们假设一下，如果元数据仅以文件的形式存储在namenode本地硬盘，这样行不行？因为大批量的客户端同时在进行上传、下载等各种操作时，都要对元数据进行读写及修改操作，仅仅以文件的形式来存储元数据显然不行，因为无法做到对各种操作的快速响应，把元数据放在内存中呢，确实能够提高系统响应速度，但是一旦断电就完全丢失了，这肯定也不行，那么如果把内存的数据定期flush到磁盘文件的方法行不行呢？一旦断电，没来得及的刷到磁盘的内存数据肯定也是要丢失的，显然也不行，那么在实际环境中，hadoop是怎么管理元数据的呢？

      首先，磁盘确实有块空间，对元数据进行持久化存储的，名为fsimage,如果直接读取磁盘文件，速度肯定跟不上，内存中也要放一些元数据信息，虽然很容易丢失，但可以提供查询服务，实际上就是读写分离，由读写分离就有了数据一致性的问题，因为写入数据，没有写入内存中，最新的元数据记录在哪呢？实际上是记录在一个很小的文件中，这个文件不提供修改，只提供追加，以日志的形式记录，一直都保持着几十兆大小，名为edits***.log，比如在上传一个文件时，先对NAMENODE进行询问，往哪里写，NAMENODE一边分配一边记录，将空间分配信息记录edits**.log，当完成一个副本的写入工作后，通知NAMENODE,被认为是写入成功，这时，将edits**.log的数据更新至内存，此时，内存中的数据是最新的，即使现在断电，最新的元数据在edits**.log也有保存。

      回顾一下这个过程

      1、  客户端写入文件时，NAMENODE首先往edits**.log文件中记录元数据操作

      2、  客户端开始上传文件，完成后成功信息给NAMENODE,NAMENODE就在内存中写入这次上传操作的新产生的元数据信息，edits**.log文件大小有一定的范围，比较小， fsimage文件就是内存的镜像文件，fsimage是最全的，edits**.log是最新的，更新的顺序是先edits**.log,其次是内存，最后是fsimage，那fsimage什么时候更新呢，内存和fsimage如何保持一致性？只要edits**.log在没有写满时不需要同步，这里提一下check point操作，是指每当edits**.log写满时，需要将这一段时间的新的元数据刷进fsimage，将edits**.log与fsimage合并

      3、  为防止影响响应速度，由SecondaryNamenode来做edit**.log与fsimage的合并工作，当edits**.log写满时，通知SecondaryNamenode进行checkpoint操作，停止往edits文件中写数据，SecondaryNamenode下载fsimage和edits文件，合并生成新的fsimage,将新的内存镜像上传给Namenode,替换老的fsimage,删除老的edit**.log,将edits new文件命名为edits**.log

      通过上述操作，可以看出在任务进行时，在任务时间点断电，都不会丢失数据了。

转：https://blog.****.net/lepton126/article/details/53183037

NN工作机制：注意：当NN出现故障时，如何重新使集群开始工作

在Hadoop1中NameNode存在一个单点故障问题，如果NameNode所在的机器发生故障，整个集群就将不可用(Hadoop1中虽然有个SecorndaryNameNode，但是它并不是NameNode的备份，它只是NameNode的一个助理，协助NameNode工作，SecorndaryNameNode会对fsimage和edits文件进行合并，并推送给NameNode，防止因edits文件过大，导致NameNode重启变慢),这是Hadoop1的不可靠实现。

在Hadoop2中这个问题得以解决，Hadoop2中的高可靠性是指同时启动NameNode,其中一个处于active工作状态，另外一个处于随时待命standby状态。这样，当一个NameNode所在的服务器宕机时，可以在数据不丢失的情况下， 手工或者自动切换到另一个NameNode提供服务。

这些NameNode之间通过共享数据，保证数据的状态一致。多个NameNode之间共享数据，可以通过Network File System或者Quorum Journal Node。前者是通过Ｌinux共享的文件系统，属于操作系统的配置；后者是Ｈadoop自身的东西，属于软件的配置。

我们这里讲述使用Quorum Journal Node的配置方式，方式是手工切换。

集群启动时，可以同时启动2个NameNode。这些NameNode只有一个是active的，另一个属于standby状态。active状态意味着提供服务，standby状态意味着处于休眠状态，只进行数据同步，时刻准备着提供服务，如图2所示。

转：https://www.cnblogs.com/followyourdream/p/6884037.html

在一个典型的HA集群中，每个NameNode是一台独立的服务器。在任一时刻，只有一个NameNode处于active状态，另一个处于standby状态。其中，active状态的NameNode负责所有的客户端操作，standby状态的NameNode处于从属地位，维护着数据状态，随时准备切换。

两个NameNode为了数据同步，会通过一组称作JournalNodes的独立进程进行相互通信。当active状态的NameNode的命名空间有任何修改时，会告知大部分的JournalNodes进程。standby状态的NameNode有能力读取JNs中的变更信息，并且一直监控edit log的变化，把变化应用于自己的命名空间。standby可以确保在集群出错时，命名空间状态已经完全同步了，如图3所示。

为了确保快速切换，standby状态的NameNode有必要知道集群中所有数据块的位置。为了做到这点，所有的datanodes必须配置两个NameNode的地址，发送数据块位置信息和心跳给他们两个。

对于HA集群而言，确保同一时刻只有一个NameNode处于active状态是至关重要的。否则，两个NameNode的数据状态就会产生分歧，可能丢失数据，或者产生错误的结果。为了保证这点，JNs必须确保同一时刻只有一个NameNode可以向自己写数据。

DN工作机制

• 提供真实文件数据的存储服务。
• 文件块（block）：最基本的存储单位。对于文件内容而言，一个文件的长度大小是size，那么从文件的０偏移开始，按照固定的大小，顺序对文件进行划分并编号，划分好的每一个块称一个Block。
• HDFS默认Block大小是128MB，以一个256MB文件，共有256/128=2个Block. 不同于普通文件系统的是，HDFS中，如果一个文件小于一个数据块的大小，并不占用整个数据块存储空间。ruc

      (这样设置可以减轻namenode压力，因为namonode维护者文件与数据块列表的对应大小)

• Replication。多复本。默认是三个。（hdfs-site.xml的dfs.replication属性）

NN的职责

1.  维护元数组的信息

2.  维护hdfs的目录树

3.  响应客户端请求