认识HDFS
HDFS是用来解决什么问题的
HDFS设计与架构
熟悉hdfs常用命令
Python操作HDFS的其他API
观察上传后的文件,上传大于128M的文件与小于128M的文件有何区别?
启动HDFS后,会分别启动NameNode/DataNode/SecondaryNameNode,这些进程的的作用分别是什么?
NameNode是如何组织文件中的元信息的,edits log与fsImage的区别?使用hdfs oiv命令观察HDFS上的文件的metadata
HDFS文件上传下载过程,源码阅读与整理。
这里特别说明一下,在上一个任务中主要是对Hadoop集群进行了搭建,本次任务对Hadoop和HDFS进行深入的学习。
Google三大理论
简单总结下:
1. GFS-2003
2003年,Google发布Google File System论文,这是一个可扩展的分布式文件系统,用于大型的、分布式的、对大量数据进行访问的应用。它运行于廉价的普通硬件上,提供容错功能。从根本上说:文件被分割成很多块,使用冗余的方式储存于商用机器集群上。
紧随其后的就是2004年公布的 MapReduce论文,论文描述了大数据的分布式计算方式,主要思想是将任务分解然后在多台处理能力较弱的计算节点中同时处理,然后将结果合并从而完成大数据处理。
传说中,Google使用它计算他们的搜索索引。而Mikio L. Braun认为其工作模式应该是:Google把所有抓取的页面都放置于他们的集群上,然后每天使用MapReduce来重算。
3. BigTable—-2006
Bigtable发布于2006年,启发了无数的NoSQL数据库,比如:Cassandra、HBase等等。Cassandra架构中有一半是模仿Bigtable,包括了数据模型、SSTables以及提前写日志(另一半是模仿Amazon的Dynamo数据库,使用点对点集群模式)。
4. GFS,MapReduce 和 BigTable三者关系如下
Google的后面两篇论文——MapReduce 和 BigTable都是以GFS为基础。三大基础核心技术构建出了完整的分布式运算架构。
Hadoop是一个开源框架,可编写和运行分布式应用处理大规模数据。 Hadoop框架的核心是HDFS和MapReduce。其中 HDFS 是分布式文件系统,MapReduce 是分布式数据处理模型和执行环境。
随着数据的来源途径越来越多,数据的格式也越来越复杂,数据量越来越大,传统的数据库已经很难满足需求,Hadoop就是为了解决这个问题而诞生的。其底层的分布式文件系统具有高拓展性,通过数据冗余保证数据不丢失和提交计算效率,同时可以存储各种格式的数据。同时其还支持多种计算框架,既可以进行离线计算也可以进行在线实时计算。
Hadoop有三种运行模式:单机模式、伪分布式模式、完全分布式模式。
单机模式
伪分布式模式
完全分布式模式
这里有两篇写的很好的博客
Hadoop之HDFS原理及文件上传下载源码分析(上)
Hadoop之HDFS原理及文件上传下载源码分析(下)
Hadoop RPC机制的使用
RPC,即Remote Procdure Call,中文名:远程过程调用;
RPC的显著特点
(1)透明性:远程调用其他机器上的程序,对用户来说就像是调用本地方法一样;
(2)高性能:RPC Server能够并发处理多个来自Client的请求;
(3)可控性:jdk中已经提供了一个RPC框架—RMI,但是该PRC框架过于重量级并且可控之处比较少,所以Hadoop RPC实现了自定义的PRC框架。
(2)Client端发送一个带有参数的请求信息到Server;
(3)Server接收到这个请求以后,根据发送过来的参数调用相应的程序,然后把自己计算好的结果发送给Client端;
(4)Client端接收到结果后继续运行;
Hadoop中的RPC机制
同其他RPC框架一样,Hadoop RPC分为四个部分:
(1)序列化层:Clent与Server端通信传递的信息采用了Hadoop里提供的序列化类或自定义的Writable类型;
(2)函数调用层:Hadoop RPC通过动态代理以及java反射实现函数调用;
(3)网络传输层:Hadoop RPC采用了基于TCP/IP的socket机制;
(4)服务器端框架层:RPC Server利用java NIO以及采用了事件驱动的I/O模型,提高RPC Server的并发处理能力;
用python写MapReduce函数——以WordCount为例
MapReduce任务—WordCount
1. Python MapReduce 代码
1.1Map阶段:mapper.py
把文件保存到hadoop/test/code/mapper.py
#!/usr/bin/env python
import sys
for line in sys.stdin:
line = line.strip()
words = line.split()
for word in words:
print "%s\t%s" % (word, 1)
增加mapper.py的可执行权限
chmod +x hadoop/test/code/mapper.py
1.2.Reduce阶段:reducer.py
#!/usr/bin/env python
from operator import itemgetter
import sys
current_word = None
current_count = 0
word = None
for line in sys.stdin:
line = line.strip()
word, count = line.split('\t', 1)
try:
count = int(count)
except ValueError:
continue
if current_word == word:
current_count += count
else:
if current_word:
print "%s\t%s" % (current_word, current_count)
current_count = count
current_word = word
if word == current_word:
print "%s\t%s" % (current_word, current_count)
增加reducer.py的可执行权限
chmod +x hadoop/test/code/reducer.py
功能性测试mapper.py 和 reducer.py
cd test/code
//执行命令
echo "foo foo quux labs foo bar quux" | ./mapper.py
//输出内容如下
foo 1
foo 1
quux 1
labs 1
foo 1
bar 1
quux 1
//执行命令
echo "foo foo quux labs foo bar quux" | ./mapper.py | sort -k1,1 | ./reducer.py
//输出内容
bar 1
foo 3
labs 1
2. 在Hadoop上运行python代码
Plain Text UTF-8
Plain Text UTF-8
Plain Text UTF-8
把上面的文件放到hadoop/test/datas/目录下,并把本地的数据文件拷贝到分布式文件系统HDFS中
hdfs dfs -put datas /datas
可以在浏览器里输入:“192.168.1.105:50070”, 在Utilities-Browse the file system里查看上传的文件。
执行MapReduce job
hadoop jar /usr/local/hadoop/share/hadoop/tools/lib/hadoop-streaming-2.5.0-cdh5.3.6.jar \
-input /datas \
-output /test/out \
-mapper "python mapper.py" \
-reducer "python reducer.py" \
-file ./mapper.py \
-file ./reducer.py
第一行是指明用到的streaming包的位置,第二行指明原文件在HDFS上的路径,第三行是输出结果在HDFS上的路径,输出路径原来不能存在,已存在的话会报错,最后两行指明Map方法和Reduce方法程序路径。
查看生成的文件
hdfs dfs -rm -f /datas/out/part-00000
成功!
解决方案:直接在log4j日志中去除告警信息。在/usr/local/hadoop/etc/hadoop/log4j.properties文件中添加
log4j.logger.org.apache.hadoop.util.NativeCodeLoader=ERROR
首先说下Hadoop 的四大组件: HDFS,分布式存储系统;MapReduce,分布式计算系统;YARN: hadoop 的资源调度系统。;Common: 以上三大组件的底层支撑组件,主要提供基础工具包和 RPC 框架等。 Mapreduce 是一个分布式运算程序的编程框架,是用户开发“基于 hadoop的数据分析 应用”的核心框架。 Mapreduce 核心功能是将用户编写的业务逻辑代码和自带默认组件整合成一个完整的分布式运算程序,并发运行在一个 hadoop 集群上。
从整体层面上看,有五个独立的实体: - 客户端,提交 MapReduce 作业。 - YARN 资源管理器(YARN resource manager),负责协调集群上计算机资源的分配。 - YARN 节点管理器(YARN node manager),负责启动和监视集群中机器上的计算容器(container)。 - MapReduce的 application master,负责协调MapReduce 作业的任务。MRAppMaster 和 MapReduce 任务运行在容器中,该容器由资源管理器进行调度(schedule)[此处理解为划分、分配更为合适] 且由节点管理器进行管理。 - 分布式文件系统(通常是 HDFS),用来在其他实体间共享作业文件。
参考:MapReduce执行过程
Yarn是Hadoop集群的资源管理系统。Yarn可以提高资源的利用率。Yarn的另一个目标就是拓展Hadoop,使得它不仅仅可以支持MapReduce计算,还能很方便的管理诸如Hive、Hbase、Pig、Spark/Shark等应用。这种新的架构设计能够使得各种类型的应用运行在Hadoop上面,并通过Yarn从系统层面进行统一的管理,也就是说,有了Yarn,各种应用就可以互不干扰的运行在同一个Hadoop系统中,共享整个集群资源。
参考:Hadoop Yarn详解
深入理解HDFS:Hadoop分布式文件系统
在现代的企业环境中,单机容量往往无法存储大量数据,需要跨机器存储。统一管理分布在集群上的文件系统称为分布式文件系统。而一旦在系统中,引入网络,就不可避免地引入了所有网络编程的复杂性,例如挑战之一是如果保证在节点不可用的时候数据不丢失。
传统的网络文件系统(NFS)虽然也称为分布式文件系统,但是其存在一些限制。由于NFS中,文件是存储在单机上,因此无法提供可靠性保证,当很多客户端同时访问NFS Server时,很容易造成服务器压力,造成性能瓶颈。另外如果要对NFS中的文件中进行操作,需要首先同步到本地,这些修改在同步到服务端之前,其他客户端是不可见的。某种程度上,NFS不是一种典型的分布式系统,虽然它的文件的确放在远端(单一)的服务器上面。
HDFS,是Hadoop Distributed File System的简称,是Hadoop抽象文件系统的一种实现。Hadoop抽象文件系统可以与本地系统、Amazon S3等集成,甚至可以通过Web协议(webhsfs)来操作。HDFS的文件分布在集群机器上,同时提供副本进行容错及可靠性保证。例如客户端写入读取文件的直接操作都是分布在集群各个机器上的,没有单点性能压力。
物理磁盘中有块的概念,磁盘的物理Block是磁盘操作最小的单元,读写操作均以Block为最小单元,一般为512 Byte。文件系统在物理Block之上抽象了另一层概念,文件系统Block物理磁盘Block的整数倍。通常为几KB。Hadoop提供的df、fsck这类运维工具都是在文件系统的Block级别上进行操作。
HDFS的Block块比一般单机文件系统大得多,默认为128M。HDFS的文件被拆分成block-sized的chunk,chunk作为独立单元存储。比Block小的文件不会占用整个Block,只会占据实际大小。例如, 如果一个文件大小为1M,则在HDFS中只会占用1M的空间,而不是128M。
HDFS的Block为什么这么大?
是为了最小化查找(seek)时间,控制定位文件与传输文件所用的时间比例。假设定位到Block所需的时间为10ms,磁盘传输速度为100M/s。如果要将定位到Block所用时间占传输时间的比例控制1%,则Block大小需要约100M。
但是如果Block设置过大,在MapReduce任务中,Map或者Reduce任务的个数 如果小于集群机器数量,会使得作业运行效率很低。
Block抽象的好处
block的拆分使得单个文件大小可以大于整个磁盘的容量,构成文件的Block可以分布在整个集群, 理论上,单个文件可以占据集群中所有机器的磁盘。
Block的抽象也简化了存储系统,对于Block,无需关注其权限,所有者等内容(这些内容都在文件级别上进行控制)。
Block作为容错和高可用机制中的副本单元,即以Block为单位进行复制。
整个HDFS集群由Namenode和Datanode构成master-worker(主从)模式。Namenode复杂构建命名空间,管理文件的元数据等,而Datanode负责实际存储数据,负责读写工作。
Namenode
Namenode存放文件系统树及所有文件、目录的元数据。元数据持久化为2种形式:
namespcae image-
edit log
但是持久化数据中不包括Block所在的节点列表,及文件的Block分布在集群中的哪些节点上,这些信息是在系统重启的时候重新构建(通过Datanode汇报的Block信息)。
在HDFS中,Namenode可能成为集群的单点故障,Namenode不可用时,整个文件系统是不可用的。HDFS针对单点故障提供了2种解决机制:
1)备份持久化元数据
将文件系统的元数据同时写到多个文件系统, 例如同时将元数据写到本地文件系统及NFS。这些备份操作都是同步的、原子的。
2)Secondary Namenode
Secondary节点定期合并主Namenode的namespace image和edit log, 避免edit log过大,通过创建检查点checkpoint来合并。它会维护一个合并后的namespace image副本, 可用于在Namenode完全崩溃时恢复数据。
Secondary Namenode通常运行在另一台机器,因为合并操作需要耗费大量的CPU和内存。其数据落后于Namenode,因此当Namenode完全崩溃时,会出现数据丢失。 通常做法是拷贝NFS中的备份元数据到Second,将其作为新的主Namenode。
在HA中可以运行一个Hot Standby,作为热备份,在Active Namenode故障之后,替代原有Namenode成为Active Namenode。
Datanode
数据节点负责存储和提取Block,读写请求可能来自namenode,也可能直接来自客户端。数据节点周期性向Namenode汇报自己节点上所存储的Block相关信息。
DataNode通常直接从磁盘读取数据,但是频繁使用的Block可以在内存中缓存。默认情况下,一个Block只有一个数据节点会缓存。但是可以针对每个文件可以个性化配置。
作业调度器可以利用缓存提升性能,例如MapReduce可以把任务运行在有Block缓存的节点上。
用户或者应用可以向NameNode发送缓存指令(缓存哪个文件,缓存多久), 缓存池的概念用于管理一组缓存的权限和资源。
我们知道NameNode的内存会制约文件数量,HDFS Federation提供了一种横向扩展NameNode的方式。在Federation模式中,每个NameNode管理命名空间的一部分,例如一个NameNode管理/user目录下的文件, 另一个NameNode管理/share目录下的文件。
每个NameNode管理一个namespace volumn,所有volumn构成文件系统的元数据。每个NameNode同时维护一个Block Pool,保存Block的节点映射等信息。各NameNode之间是独立的,一个节点的失败不会导致其他节点管理的文件不可用。
客户端使用mount table将文件路径映射到NameNode。mount table是在Namenode群组之上封装了一层,这一层也是一个Hadoop文件系统的实现,通过viewfs:协议访问。
在HDFS集群中,NameNode依然是单点故障(SPOF)。元数据同时写到多个文件系统以及Second NameNode定期checkpoint有利于保护数据丢失,但是并不能提高可用性。
这是因为NameNode是唯一一个对文件元数据和file-block映射负责的地方, 当它挂了之后,包括MapReduce在内的作业都无法进行读写。
当NameNode故障时,常规的做法是使用元数据备份重新启动一个NameNode。元数据备份可能来源于:
启动新的Namenode之后,需要重新配置客户端和DataNode的NameNode信息。另外重启耗时一般比较久,稍具规模的集群重启经常需要几十分钟甚至数小时,造成重启耗时的原因大致有:
1) 元数据镜像文件载入到内存耗时较长。
2) 需要重放edit log
3) 需要收到来自DataNode的状态报告并且满足条件后才能离开安全模式提供写服务。
Hadoop的HA方案
采用HA的HDFS集群配置两个NameNode,分别处于Active和Standby状态。当Active NameNode故障之后,Standby接过责任继续提供服务,用户没有明显的中断感觉。一般耗时在几十秒到数分钟。
HA涉及到的主要实现逻辑有
1) 主备需共享edit log存储
主NameNode和待命的NameNode共享一份edit log,当主备切换时,Standby通过回放edit log同步数据。
共享存储通常有2种选择
QJM运行一组journal node,edit log必须写到大部分的journal nodes。通常使用3个节点,因此允许一个节点失败,类似ZooKeeper。注意QJM没有使用ZK,虽然HDFS HA的确使用了ZK来选举主Namenode。一般推荐使用QJM。
2)DataNode需要同时往主备发送Block Report
因为Block映射数据存储在内存中(不是在磁盘上),为了在Active NameNode挂掉之后,新的NameNode能够快速启动,不需要等待来自Datanode的Block Report,DataNode需要同时向主备两个NameNode发送Block Report。
3)客户端需要配置failover模式(对用户透明)
Namenode的切换对客户端来说是无感知的,通过客户端库来实现。客户端在配置文件中使用的HDFS URI是逻辑路径,映射到一对Namenode地址。客户端会不断尝试每一个Namenode地址直到成功。
4)Standby替代Secondary NameNode
如果没有启用HA,HDFS独立运行一个守护进程作为Secondary Namenode。定期checkpoint,合并镜像文件和edit日志。
如果当主Namenode失败时,备份Namenode正在关机(停止 Standby),运维人员依然可以从头启动备份Namenode,这样比没有HA的时候更省事,算是一种改进,因为重启整个过程已经标准化到Hadoop内部,无需运维进行复杂的切换操作。
NameNode的切换通过代failover controller来实现。failover controller有多种实现,默认实现使用ZooKeeper来保证只有一个Namenode处于active状态。
每个Namenode运行一个轻量级的failover controller进程,该进程使用简单的心跳机制来监控Namenode的存活状态并在Namenode失败是触发failover。Failover可以由运维手动触发,例如在日常维护中需要切换主Namenode,这种情况graceful failover,非手动触发的failover称为ungraceful failover。
在ungraceful failover的情况下,没有办法确定失败(被判定为失败)的节点是否停止运行,也就是说触发failover后,之前的主Namenode可能还在运行。QJM一次只允许一个Namenode写edit log,但是之前的主Namenode仍然可以接受读请求。Hadoop使用fencing来杀掉之前的Namenode。Fencing通过收回之前Namenode对共享的edit log的访问权限、关闭其网络端口使得原有的Namenode不能再继续接受服务请求。使用STONITH技术也可以将之前的主Namenode关机。
最后,HA方案中Namenode的切换对客户端来说是不可见的,前面已经介绍过,主要通过客户端库来完成。
单机文件系统的限制:
早期计算机中的文件是由单机的操作系统来进行管理的,单机中的文件管理存在以下不足:
①存储容量的限制。
②读写性能的限制。
③容灾能力不足。
当文件特别大的时候,上面三个问题凸显。
行业现状:
①数据格式多样化。各业务系统数据库中的结构化数据;日志文件等半结构化数据;视频、图片等非结构化数据。传统的数据库已经满足不了我们的存储需求。
②每天各种类型的数据以GB、TB的速度增长。单机的文件系统已管理不了如此大的数据量。
HDFS就是为了解决上面这些问题而生的:
①HDFS是一种允许文件通过网络在多台机器上分享的文件系统。
②HDFS将一个大文件分割成多个数据块,将这些数据块分散存储在多台机器上。
③虽然HDFS会将文件分割成多个数据块,但在程序和用户看来就跟操作本地磁盘中的文件一样。
④针对一个文件,可以并发读取它的数据块,增加了读取的性能。
⑤HDFS存储的容量具有巨大的扩展性。
⑥HDFS可以保证系统中的某些节点脱机时整个系统仍然能持续运行,并保证数据不丢失。
为什么不使用配有大量硬盘的单台机器来存储文件?
①随着计算机硬件技术的发展,单台机器硬盘存储容量不断提升,但硬盘数据读取速度却提升缓慢。
②硬盘寻址速度的提升远远不如网络传输速度的提升。如果数据的访问包含大量的硬盘寻址,那么读取大量数据就会花费更长的时间。
参考:https://www.jianshu.com/p/1a762fb5f842
存储非常大的文件:这里非常大指的是几百M、G、或者TB级别。实际应用中已有很多集群存储的数据达到PB级别。根据Hadoop官网,Yahoo!的Hadoop集群约有10万颗CPU,运行在4万个机器节点上。更多世界上的Hadoop集群使用情况,参考Hadoop官网.
采用流式的数据访问方式: HDFS基于这样的一个假设:最有效的数据处理模式是一次写入、多次读取数据集经常从数据源生成或者拷贝一次,然后在其上做很多分析工作
分析工作经常读取其中的大部分数据,即使不是全部。 因此读取整个数据集所需时间比读取第一条记录的延时更重要。
运行于商业硬件上: Hadoop不需要特别贵的、reliable的机器,可运行于普通商用机器(可以从多家供应商采购) 商用机器不代表低端机器在集群中(尤其是大的集群),节点失败率是比较高的HDFS的目标是确保集群在节点失败的时候不会让用户感觉到明显的中断。
有些场景不适合使用HDFS来存储数据。下面列举几个:
1) 低延时的数据访问
对延时要求在毫秒级别的应用,不适合采用HDFS。HDFS是为高吞吐数据传输设计的,因此可能牺牲延时HBase更适合低延时的数据访问。
2)大量小文件
文件的元数据(如目录结构,文件block的节点列表,block-node mapping)保存在NameNode的内存中, 整个文件系统的文件数量会受限于NameNode的内存大小。
经验而言,一个文件/目录/文件块一般占有150字节的元数据内存空间。如果有100万个文件,每个文件占用1个文件块,则需要大约300M的内存。因此十亿级别的文件数量在现有商用机器上难以支持。
3)多方读写,需要任意的文件修改
HDFS采用追加(append-only)的方式写入数据。不支持文件任意offset的修改。不支持多个写入器(writer)。
hadoop HDFS常用文件操作命令
HDFS常用命令
hdfs version:查看版本
1、查询
hdfs dfs -ls / :列出/目录下的文件和目录
hdfs dfs -ls -R / :列出/目录下的所有文件,由于有-R参数,会在文件夹和子文件夹下执行ls操作。
2、新建文件夹
hdfs dfs -mkdir -p /home/testdata/
3、查看hdfs文件中的内容
hdfs dfs -cat /home/testdata/1.txt
4、删除文件
hdfs dfs -rm -f /home/testdata/1.txt
5、删除文件夹
hdfs dfs -rm -r /home/testdata
1.安装依赖包
pip install hdfs
2.连接
# 连接hdfs服务
from hdfs import InsecureClient
client = InsecureClient('http://183.168.10.11:50070', user='root')
3.列出当前目录下的所有文件
print client.list('/')
4.创建新文件,并写入内容
data = '''
this is new file by lys!
'''
with client.write('/foodir/myfile.txt') as writer:
writer.write(data)
5.读取文件
with client.read('/foodir/myfile.txt') as reader:
data = reader.read()
print data
6.文件追加内容
# 通过设置append参数,向一个已经存在的文件追加写入数据
with client.write('/foodir/myfile.txt', append=True) as writer:
writer.write('this is append text by lys! \n')
7.重命名
client.rename('/foodir/myfile.txt', '/foodir/myfile2.txt')
8.下载到指定目录
# 下载到指定目录/home
client.download('/foodir/myfile.txt', '/home/myfile.txt', n_threads=3)
9.创建文件夹
client.makedirs('/testdiretory')
10.上传文件
client.upload(‘目标路径’, ‘本地源路径’)
client.upload('/testdiretory/myfile.txt','/home/myfile.txt' )
11.设置权限
client.set_permission(filepath, 777)
文件块越大,寻址时间越短,但磁盘传输时间越长;
文件块越小,寻址时间越长,但磁盘传输时间越短。
为什么HDFS中块(block)不能设置太大,也不能设置太小?
如果块设置过大,
一方面,从磁盘传输数据的时间会明显大于寻址时间,导致程序在处理这块数据时,变得非常慢;
另一方面,mapreduce中的map任务通常一次只处理一个块中的数据,如果块过大运行速度也会很慢。
如果块设置过小,
一方面存放大量小文件会占用NameNode中大量内存来存储元数据,而NameNode的内存是有限的,不可取;
另一方面文件块过小,寻址时间增大,导致程序一直在找block的开始位置。
因而,块适当设置大一些,减少寻址时间,那么传输一个由多个块组成的文件的时间主要取决于磁盘的传输速率。
HDFS中块(block)的大小为什么设置为128M?
HDFS中平均寻址时间大概为10ms;
经过前人的大量测试发现,寻址时间为传输时间的1%时,为最佳状态;
所以最佳传输时间为10ms/0.01=1000ms=1s
目前磁盘的传输速率普遍为100MB/s;
计算出最佳block大小:100MB/s x 1s = 100MB
所以我们设定block大小为128MB。
ps:实际在工业生产中,磁盘传输速率为200MB/s时,一般设定block大小为256MB
;磁盘传输速率为400MB/s时,一般设定block大小为512MB
参考::https://blog.csdn.net/wx1528159409/article/details/84260023
(1) Hadoop
namenode : NameNode, SecondaryNameNode, ResourceManager
datanode : DataNode, NodeManager
(2) Zookeeper(安装Zookeeper的机器要为奇数台,这里有3台)
QuorumPeerManager
Fsimage文件:HDFS文件系统元数据的一个永久性的检查点,其中包含HDFS文件系统的所有目录和文件idnode的序列化信息;
Fsimage.md5文件:是镜像文件的 md5 校验文件,这个校验文件是为了判断镜像文件是否被修改;
Edits文件:存放HDFS文件系统的所有更新操作,文件系统客户端执行的所有写操作首先会被记录到Edits文件中
seen_txid文件:它代表的是 namenode 里面的 edits_* 文件的尾数,namenode 重启的时候,会按照 seen_txid 的数字, 循序从头跑 edits_0000001~ 到 seen_txid 的数字
VERSION文件:记录了当前NameNode的一些信息
图解:
VERSION文件内容的含义?
1.namespaceID是文件系统的唯一标识符,格式化文件系统后就会生成这个ID
2.clusterID是系统生成的集群的ID;
3.cTime是namenode存储系统创建是时间,第一次格式化系统就是0,再次格式化时就会更新;
4.storagetype说明文件存储的是什么系统存储的信息,可能是namenode/datanode
5.bolckpoolID是针对每一个namespace对应的bolckpool的ID,包含存储节点的IP等信息
参考:https://blog.csdn.net/qq_39657909/article/details/85233287