1. hdfs基本工作流程
1. hdfs初始化目录结构
hdfs namenode -format 只是初始化了namenode的工作目录
而datanode的工作目录是在datanode启动后自己初始化的
namenode在format初始化的时候会形成两个标识：
blockPoolId：
clusterId：
新的datanode加入时，会获取这两个标识作为自己工作目录中的标识
一旦namenode重新format后，namenode的身份标识已变，而datanode如果依然
持有原来的id，就不会被namenode识别
2. hdfs的工作机制
- hdfs集群分为两大角色:NameNode,DataNode (Secondary NameNode)
- NameNode负责管理整个文件的元数据(命名空间信息，块信息) 相当于Master
- DataNode负责管理用户的文件数据块 相当于Salve
- 文件会按照固定的大小（block=128M）切成若干块后分布式存储在若干个datanode节点上
- 每一个文件块有多个副本（默认是三个），存在不同的datanode上
- DataNode会定期向NameNode汇报自身所保存的文件block信息，而namenode则会负责保持文件副本数量
- hdfs的内部工作机制会对客户的保持透明，客户端请求方法hdfs都是通过向namenode申请来进行访问
- SecondaryNameNode有两个作用，一是镜像备份，二是日志与镜像的定期合并
3. hdfs写入数据流程
1.客户端要向hdfs写入数据，首先要跟namenode通信以确认可以写文件并获得接收文件block的datanode，然后，客户端按照顺序将文件block逐个传给相应datanode，并由接收到block的datanode负责向其他datanode复制block副本
4. 写入数据步骤详细解析
- 客户端向namenode通信，请求上传文件，namenode检查目标文件是否已经存在，父目录是否存在
- namenode返回给客户端，告知是否可以上传
- 客户端请求第一个block该传输到那些datanode服务器上
- namenode返回3个datanode服务器abc
- 客户端请求3台datanode的一台a上传数据（本质上是一个rpc调用，建立pipeline），A收到请求后会继续调用b，然后b调用c，将整个pipeline建立完成，逐级返回客户端。
- 客户端开始忘a上传第一个block（先从磁盘读取数据放入本地内存缓存），以packet为单位，a收到一个packet将会传给b，b传给c，a每传一个packet会放入一个应答队列等待应答
- 宕一个block传输完之后，客户端再次请求namenode上传第二个block的服务器
5. hdfs读取数据流程
- 客户端将要读取的文件路径发送给namenode
- namenode获取文件的元信息（主要是block的存放位置信息）返回给客户端
- 客户端根据返回的信息找到相应的datanode逐个获取文件的block
- 客户端本地进行数据的追加合并从而获得整个文件
6. 读取数据详细步骤解析
- 客户端跟namenode通信查询元数据，找到文件块所在的datanode服务器
- 挑选一台datanode（就近原则，然后随机）服务器，请求建立socket流
- datanode开始发送数据（从磁盘里面读取数据放入流，以packet为单位做校验）
- 客户端以packet为单位接收，先在本地缓存，然后写入目标文件。
2. namenode工作机制
1. namenode常见问题
- 集群启动后，可以查看文件，但是上传文件报错，打开web页面看到namenode正在处于sofemode状态，怎么处理？
- namenode服务器磁盘故障导致namenode宕机，如何解决？
- namenode是否可以有多个？
- namenode内存要配置多大？
- namenode跟集群数据存储能力有关系吗？
- 文件的blocksize究竟调大好，还是调小好？
2. namenode的工作职责
- 负责客户端的请求及相应
- 元数据的管理（查询，修改）
3. 元数据管理
- namenode对数据的管理采用三种存储形式
- 内存元数据（NameSystem）
- 磁盘元数据镜像文件
- 数据操作日志文件（可通过日志运算出元数据）类似于mysql的binlog
4. 元数据存储机制
- 内存中有一份完整的元数据（内存 metadata）
- 磁盘有一个 “准完整” 的元数据镜像（fsimage）文件（在namenode工作目录中）
- 用于衔接内存metadata和持久化元数据镜像fsimage之间的操作日志（edits log文件）
- 当客户端对hdfs中的文件进行新增或者修改操作，操作记录首先被记入edits日志文件中，当客户端操作成功后，相应的元数据会更新到内存metadata中
5. 元数据查看
- hdfs oev -i edits_0000000000000000162-0000000000000000163 -o edits.xml
- hdfs oiv -i fsimage_0000000000000000262 -p XML -o fsimage.xml
6. 元数据的checkpoint
- 每隔一段时间，secondary namenode 将namenode上积累的所有edits和一个最新的fsimage下载到本地，并加载到内存进行merge（这个过程为checkpoint）
- 详细过程
7. 解决namenode的灾难性错误的方法
-
首先在hdfs-site.xml配置
<property> <name>dfs.name.dir</name> <value>/data/hadoop/name1,/data/hadoop/name2</value> </property> -
停止集群
-
重新格式化
hadoop namenode -format -
开始集群
8. checkpoint操作的触发条件配置参数
#dfs.namenode.checkpoint.check.period=60 #检查触发条件是否满足的频率，60秒
#hdfs.namenode.checkpoint.dir=file://${hadoop.tmp.dir}/dfs/namesecondary
#以上两个参数做checkpoint操作时，secondary namenode的本地工作目录
#dfs.namenode.checkpoint.edits.dir=${dfs.namenode.checkpoint.dir}
#dfs.namenode.checkpoint.max-retries=3 #最大重试次数
#dfs.namenode.checkpoint.period=3600 #两次checkpoint之间的时间间隔3600秒
#dfs.namenode.checkpoint.txns=1000000 #两次checkpoint之间最大的操作记录
9. checkpoint的附带作用
- namenode和secondary namenode的工作目录存储结构完全相同，所以当namenode故障退出需要重新恢复时，可以从secondary namenode 的工作目录将fsimage拷贝到namenode的工作目录。以恢复namenode的元数据
10. 元数据目录说明
-
当第一次部署好hadoop集群的时候，在namenode上格式化硬盘后会在${dfs.namenode.name.dir}/current目录产生如下文件结构:
#ls /tmp/hadoop-root/dfs/name/current ---VERSION ---edits_* ---fsimage_* ---seen_txid -
dfs.namenode.name.dir在hdfs-site.xml文件中配置
<property> <name>dfs.namenode.name.dir</name> <value>file://${hadoop.tmp.dir}/dfs/name</value> </property>
注:dfs.namenode.name.dir的属性可以配置多个目录，每个目录存在的文件结构和内容都是一样的，相当于备份，好处是其中有一个目录损坏了，也不会影响到hadoop的元数据。
-
hadoop.tmp.dir在core-site.xml文件中配置
<property> <name>hadoop.tmp.dir</name> <value>/tmp/hadoop-${user.name}</value> <description>A base for other temporary directories.</description> </property> -
VERSION文件是java属性文件
[root@hadoop-1 current]# cat VERSION #Thu Jun 22 11:42:19 EDT 2017 namespaceID=1169207959 clusterID=CID-ce01b250-9850-4da5-b81f-ab24905fbdd7 cTime=0 storageType=NAME_NODE blockpoolID=BP-1786918471-172.16.1.207-1498146139482 layoutVersion=-63-
namespace
文件系统的唯一标识符，在文件系统首次格式化后生成的
-
StorageType
说明这个文件存储的是什么进程的数据结构信息（如果是DataNode，storageType=DATA_NODE）；
-
cTime
NameNode存储时间的创建时间，由于我的NameNode没有更新过，所以这里的记录值为0，如果NameNode升级后，cTime将会记录更新时间戳
-
layoutVersion
HDFS永久性数据结构的版本信息，只要数据结构变更，版本号也要递减，此时的hdfs也需要升级，否则磁盘仍旧是使用旧版本的数据结构，这会导致新版本的NameNode无法使用。
-
clusterID
系统生成或者手动指定的集群id，在-clusterid选项中可以使用它
1. $HADOOP_HOME/bin/hdfs namenode -format [-clusterId <cluster_id>] 选择一个唯一的cluster_id，并且这个cluster_id不能与环境中其他集群有冲突。如果没 有提供cluster_id，则会自动生成一个唯一的ClusterID。 2. 使用如下命令格式化其他Namenode： $HADOOP_HOME/bin/hdfs namenode -format -clusterId <cluster_id> 3. 升级集群至最新版本。在升级过程中需要提供一个ClusterID，例如: $HADOOP_PREFIX_HOME/bin/hdfs start namenode --config $HADOOP_CONF_DIR -upgrade -clusterId <cluster_ID> 如果没有提供ClusterID，则会自动生成一个ClusterID。 -
blockpoolID
针对每一个NameSpace所对应的blockpool的ID，上面的这个
BP-1786918471-172.16.1.207-1498146139482 就是我在ns1的namespace下的存储块池的ID，这个id包括了对应的namenode节点服务器ip地址
-
-
seen_teid文件
存放transactionid的文件，format之后是0，它代表的是namenode里面的edits_*文件的尾数，namenode重启的时候，会按照seen_txid的数字，循序从头跑edits_0000001~到seen_txid的数字。所以当你的hdfs发生异常重启的时候，一定要比对seen_txid内的数字是不是你edits最后的尾数，不然会发生建置namenode时metaData的资料有缺少，导致误删Datanode上多余Block.
文件中记录的是edits滚动的序号，每次重启namenode时，namenode就知道要将哪些edits进行加载edits -
current目录下在format的同时也好生成fsimage和edits文件及其对应的md5校验文件，
3. DataNode的工作机制
-
Datanode工作职责:
存储管理用户的文件块数据
定期向namenode汇报自身所持有的block信息（通过心跳信息上报） -
Datanode掉线判断的时限参数：
datanode进程死亡或网络故障造成datanode无法与namenode通信，namenode不会立即把该节点判断为死亡，要经过一段时间，它这段时间暂称为超时时长,hdfs默认的超时时长为10分钟+30秒，如果定义超时时间为timeout，则超时时长的计算公式为:
timeout = 2* heartbeat.recheck.interval + 10 * dfs.heartbeat.interval默认的heartbeat.recheck.interval 大小为5分钟，dfs.heartbeat.interval默认为3秒
需要注意的是 hdfs-site.xml配置文件中的heartbeat.recheck.interval的单位为毫秒
dfs.heartbeat.interva的单位为秒，所以，举个例子，如果heartbeat.recheck.interval设置为5000（毫秒），dfs.heartbeat.interval设置为3（秒，默认），则总的超时时间为40秒。 -