Hadoop-2

最新推荐文章于 2020-10-09 18:58:10 发布

Denovo丶

最新推荐文章于 2020-10-09 18:58:10 发布

阅读量440

点赞数

CC 4.0 BY-SA版权

分类专栏： Hadoop

本文链接：https://blog.csdn.net/qq_39210208/article/details/87887778

Hadoop 专栏收录该内容

16 篇文章

订阅专栏

本文详细介绍了Hadoop一致性模型，包括文件创建后数据何时可见以及如何使用sync()确保数据写入。此外，还阐述了NameNode的工作机制，包括启动过程、元数据存储及Secondary NameNode的角色。内容涵盖了 Namenode 的元数据更新、内存中元数据管理、Secondary NameNode 的 checkpoint 过程以及相关的配置参数。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

一致性模型

HDFS某些地方为了性能可能会不符合POSIX（是的，你没有看错，POSIX不仅仅只适用于linux/unix，Hadoop 使用了POSIX的设计来实现对文件系统文件流的读取），所以它看起来可能与你所期望的不同，要注意。
　　创建了一个文件以后，它是可以在命名空间（namespace）中可以看到的：
　　　　Path p = new Path(“p”);
　　　　fs.create§;
　　　　assertThat(fs.exists§, is(true));
　　但是任何向此文件中写入的数据并不能保证是可见的，即使你flush了已经写入的数据，此文件的长度可能仍然为零：
　　　　Path p = new Path(“p”);
　　　　OutputStream out = fs.create§;
　　　　out.write(“content”.getBytes(“UTF-8”));
　　　　out.flush();
　　　　assertThat(fs.getFileStatus§.getLen(), is(0L));
　　这是因为，在Hadoop中，只有满一个block数据量的数据被写入文件后，此文件中的内容才是可见的（即这些数据会被写入到硬盘中去），所以当前正在写的block中的内容总是不可见的。
　　Hadoop提供了一种强制使buffer中的内容冲洗到datanode的方法，那就是FSDataOutputStream的sync()方法。调用了sync()方法后，Hadoop保证所有已经被写入的数据都被冲洗到了管道线中的datanode中，并且对所有读者都可见了：
　　　　Path p = new Path(“p”);
　　　　FSDataOutputStream out = fs.create§;
　　　　out.write(“content”.getBytes(“UTF-8”));
　　　　out.flush();
　　　　out.sync();
　　　　assertThat(fs.getFileStatus§.getLen(), is(((long) “content”.length())));
　　这个方法就像POSIX中的fsync系统调用（它冲洗给定文件描述符中的所有缓冲数据到磁盘中）。例如，使用java API写一个本地文件，我们可以保证在调用flush()和同步化后可以看到已写入的内容：
　　　　FileOutputStream out = new FileOutputStream(localFile);
　　　　out.write(“content”.getBytes(“UTF-8”));
　　　　out.flush(); // flush to operating system
　　　　out.getFD().sync(); // sync to disk（getFD()返回与该流所对应的文件描述符）
　　　　assertThat(localFile.length(), is(((long) “content”.length())));
　　在HDFS中关闭一个流隐式的调用了sync()方法：
　　　　Path p = new Path(“p”);
　　　　OutputStream out = fs.create§;
　　　　out.write(“content”.getBytes(“UTF-8”));
　　　　out.close();
　　　　assertThat(fs.getFileStatus§.getLen(), is(((long) “content”.length())));

由于Hadoop中的一致性模型限制，如果我们不调用sync()方法的话，我们很可能会丢失多大一个block的数据。这是难以接受的，所以我们应该使用sync()方法来确保数据已经写入磁盘。但频繁调用sync()方法也是不好的，因为会造成很多额外开销。我们可以再写入一定量数据后调用sync()方法一次，至于这个具体的数据量大小就要根据你的应用程序而定了，在不影响你的应用程序的性能的情况下，这个数据量应越大越好。

**以上转自：**http://www.cnblogs.com/beanmoon/archive/2012/12/17/2821548.html

NameNode工作机制

1）第一阶段：namenode启动
（1）第一次启动namenode格式化后，创建fsimage和edits文件。如果不是第一次启动，直接加载编辑日志和镜像文件到内存。
（2）客户端对元数据进行增删改的请求
（3）namenode记录操作日志，更新滚动日志。
（4）namenode在内存中对数据进行增删改查

元数据存储机制：
A、内存中有一份完整的元数据(内存meta data)
B、磁盘有一个“准完整”的元数据镜像（fsimage）文件(在namenode的工作目录中)
C、用于衔接内存metadata和持久化元数据镜像fsimage之间的操作日志（edits文件）
注：当客户端对hdfs中的文件进行新增或者修改操作，操作记录首先被记入edits日志文件中，当客户端操作成功后，相应的元数据会更新到内存meta.data中

2）第二阶段：Secondary NameNode工作
（1）Secondary NameNode询问namenode是否需要checkpoint。直接带回namenode是否检查结果。
（2）Secondary NameNode请求执行checkpoint。
（3）namenode滚动正在写的edits日志
（4）将滚动前的编辑日志和镜像文件拷贝到Secondary NameNode
（5）Secondary NameNode加载编辑日志和镜像文件到内存，并合并。
（6）生成新的镜像文件fsimage.chkpoint
（7）拷贝fsimage.chkpoint到namenode
（8）namenode将fsimage.chkpoint重新命名成fsimage

元数据的checkpoint：
在这里插入图片描述

3）web端访问SecondaryNameNode
（1）启动集群
（2）浏览器中输入：http://slave2:50090/status.html
（3）查看SecondaryNameNode信息
在这里插入图片描述
4）chkpoint检查时间参数设置
（1）通常情况下，SecondaryNameNode每隔一小时执行一次。
检查触发条件是否满足的频率，60秒
[hdfs-default.xml]

dfs.namenode.checkpoint.period
3600

dfs.namenode.checkpoint.dir=file://${hadoop.tmp.dir}/dfs/namesecondary

#以上两个参数做checkpoint操作时，secondary namenode的本地工作目录
dfs.namenode.checkpoint.edits.dir=${dfs.namenode.checkpoint.dir}

（2）一分钟检查一次操作次数，当操作次数达到1百万时，SecondaryNameNode执行一次。
#两次checkpoint之间最大的操作记录

dfs.namenode.checkpoint.txns
1000000
操作动作次数

#两次checkpoint之间的时间间隔3600秒

dfs.namenode.checkpoint.check.period
60
1分钟检查一次操作次数

（3）dfs.namenode.checkpoint.max-retries=3 #最大重试次数

镜像文件和编辑日志文件
1）概念
namenode被格式化之后，将在/opt/module/hadoop-2.7.2/data/tmp/dfs/name/current目录中产生如下文件
edits_0000000000000000000
fsimage_0000000000000000000.md5
seen_txid
VERSION
（1）Fsimage文件：HDFS文件系统元数据的一个永久性的检查点，其中包含HDFS文件系统的所有目录和文件idnode的序列化信息。
（2）Edits文件：存放HDFS文件系统的所有更新操作的路径，文件系统客户端执行的所有写操作首先会被记录到edits文件中。
（3）seen_txid文件保存的是一个数字，就是最后一个edits_的数字
（4）每次Namenode启动的时候都会将fsimage文件读入内存，并从00001开始到seen_txid中记录的数字依次执行每个edits里面的更新操作，保证内存中的元数据信息是最新的、同步的，可以看成Namenode启动的时候就将fsimage和edits文件进行了合并。

2）oiv查看fsimage文件
（1）查看oiv和oev命令
[atguigu@hadoop102 current]$ hdfs
oiv apply the offline fsimage viewer to an fsimage
oev apply the offline edits viewer to an edits file
（2）基本语法
hdfs oiv -p 文件类型 -i镜像文件 -o 转换后文件输出路径
（3）案例实操
[atguigu@hadoop102 current]$ pwd
/opt/module/hadoop-2.7.2/data/tmp/dfs/name/current

[atguigu@hadoop102 current]$ hdfs oiv -p XML -i fsimage_0000000000000000025 -o /opt/module/hadoop-2.7.2/fsimage.xml

[atguigu@hadoop102 current]$ cat /opt/module/hadoop-2.7.2/fsimage.xml
将显示的xml文件内容拷贝到eclipse中创建的xml文件中，并格式化。

3）oev查看edits文件
（1）基本语法
hdfs oev -p 文件类型 -i编辑日志 -o 转换后文件输出路径
（2）案例实操
[atguigu@hadoop102 current]$ hdfs oev -p XML -i edits_0000000000000000012-0000000000000000013 -o /opt/module/hadoop-2.7.2/edits.xml
[atguigu@hadoop102 current]$ cat /opt/module/hadoop-2.7.2/edits.xml
将显示的xml文件内容拷贝到eclipse中创建的xml文件中，并格式化。

namenode版本号
1）查看namenode版本号
在/opt/module/hadoop-2.7.2/data/tmp/dfs/name/current这个目录下查看VERSION
namespaceID=1933630176
clusterID=CID-1f2bf8d1-5ad2-4202-af1c-6713ab381175
cTime=0
storageType=NAME_NODE
blockpoolID=BP-97847618-192.168.10.102-1493726072779
layoutVersion=-63
2）namenode版本号具体解释
（1）namespaceID在HDFS上，会有多个Namenode，所以不同Namenode的namespaceID是不同的，分别管理一组blockpoolID。
（2）clusterID集群id，全局唯一
（3）cTime属性标记了namenode存储系统的创建时间，对于刚刚格式化的存储系统，这个属性为0；但是在文件系统升级之后，该值会更新到新的时间戳。
（4）storageType属性说明该存储目录包含的是namenode的数据结构。
（5）blockpoolID：一个block pool id标识一个block pool，并且是跨集群的全局唯一。当一个新的Namespace被创建的时候(format过程的一部分)会创建并持久化一个唯一ID。在创建过程构建全局唯一的BlockPoolID比人为的配置更可靠一些。NN将BlockPoolID持久化到磁盘中，在后续的启动过程中，会再次load并使用。
（6）layoutVersion是一个负整数。通常只有HDFS增加新特性时才会更新这个版本号。

SecondaryNameNode目录结构
Secondary NameNode用来监控HDFS状态的辅助后台程序，每隔一段时间获取HDFS元数据的快照。
在/opt/module/hadoop-2.7.2/data/tmp/dfs/namesecondary/current这个目录中查看SecondaryNameNode目录结构。
edits_0000000000000000001-0000000000000000002
fsimage_0000000000000000002
fsimage_0000000000000000002.md5
VERSION

(1)
VERSION文件是Java属性文件，内容大致如下：
#Fri Nov 15 19:47:46 CST 2013
namespaceID=934548976
clusterID=CID-cdff7d73-93cd-4783-9399-0a22e6dce196
cTime=0
storageType=NAME_NODE
blockpoolID=BP-893790215-192.168.24.72-1383809616115
layoutVersion=-47
其中
　　（1）、namespaceID是文件系统的唯一标识符，在文件系统首次格式化之后生成的；
　　（2）、storageType说明这个文件存储的是什么进程的数据结构信息（如果是DataNode，storageType=DATA_NODE）；
　　（3）、cTime表示NameNode存储时间的创建时间，由于我的NameNode没有更新过，所以这里的记录值为0，以后对NameNode升级之后，cTime将会记录更新时间戳；
　　（4）、layoutVersion表示HDFS永久性数据结构的版本信息，只要数据结构变更，版本号也要递减，此时的HDFS也需要升级，否则磁盘仍旧是使用旧版本的数据结构，这会导致新版本的NameNode无法使用；
　　（5）、clusterID是系统生成或手动指定的集群ID，在-clusterid选项中可以使用它；如下说明

（2）
$dfs.namenode.name.dir/current/seen_txid非常重要，是存放transactionId的文件，format之后是0，它代表的是namenode里面的edits_*文件的尾数，namenode重启的时候，会按照seen_txid的数字，循序从头跑edits_0000001~到seen_txid的数字。所以当你的hdfs发生异常重启的时候，一定要比对seen_txid内的数字是不是你edits最后的尾数，不然会发生建置namenode时metaData的资料有缺少，导致误删Datanode上多余Block的资讯。

（3）
$dfs.namenode.name.dir/current目录下在format的同时也会生成fsimage和edits文件，及其对应的md5校验文件。

补充：
seen_txid
文件中记录的是edits滚动的序号，每次重启namenode时，namenode就知道要将哪些edits进行加载edits
.
.
.
SecondaryNameNode的namesecondary/current目录和主namenode的current目录的布局相同。
好处：在主namenode发生故障时（假设没有及时备份数据），可以从SecondaryNameNode恢复数据。
方法一：将SecondaryNameNode中数据拷贝到namenode存储数据的目录；
方法二：使用-importCheckpoint选项启动namenode守护进程，从而将SecondaryNameNode用作新的主namenode。

1）案例实操（一）：
模拟namenode故障，并采用方法一，恢复namenode数据
（1）kill -9 namenode进程
（2）删除namenode存储的数据（/opt/module/hadoop-2.7.2/data/tmp/dfs/name）
rm -rf /opt/module/hadoop-2.7.2/data/tmp/dfs/name/*
（3）拷贝SecondaryNameNode中数据到原namenode存储数据目录
cp -R /opt/module/hadoop-2.7.2/data/tmp/dfs/namesecondary/* /opt/module/hadoop-2.7.2/data/tmp/dfs/name/
（4）重新启动namenode
sbin/hadoop-daemon.sh start namenode
慎用慎用，，，我就毁了我的集群！！！

2）案例实操（二）：
模拟namenode故障，并采用方法二，恢复namenode数据
（0）修改hdfs-site.xml中的

<property>
  <name>dfs.namenode.checkpoint.period</name>
  <value>120</value>
</property>

<property>
  <name>dfs.namenode.name.dir</name>
  <value>/opt/module/hadoop-2.7.2/data/tmp/dfs/name</value>
</property>

（1）kill -9 namenode进程
（2）删除namenode存储的数据（/opt/module/hadoop-2.7.2/data/tmp/dfs/name）
rm -rf /opt/module/hadoop-2.7.2/data/tmp/dfs/name/*
（3）如果SecondaryNameNode不和Namenode在一个主机节点上，需要将SecondaryNameNode存储数据的目录拷贝到Namenode存储数据的平级目录。
[atguigu@hadoop102 dfs]$ pwd
/opt/module/hadoop-2.7.2/data/tmp/dfs
[atguigu@hadoop102 dfs]$ ls
data name namesecondary
（4）导入检查点数据（等待一会ctrl+c结束掉）
bin/hdfs namenode -importCheckpoint
（5）启动namenode
sbin/hadoop-daemon.sh start namenode
（6）如果提示文件锁了，可以删除in_use.lock
rm -rf /opt/module/hadoop-2.7.2/data/tmp/dfs/namesecondary/in_use.lock

Namenode多目录配置
1）namenode的本地目录可以配置成多个，且每个目录存放内容相同，增加了可靠性。
2）具体配置如下：
hdfs-site.xml

<property>
    <name>dfs.namenode.name.dir</name>
<value>file:///${hadoop.tmp.dir}/dfs/name1,file:///${hadoop.tmp.dir}/dfs/name2</value>
</property>