【大数据入门笔记系列】第四节 NameNode元数据缓存机制

NameNode如何防止内存中的元数据无限膨胀？

• 客户端向分布式文件系统请求上传文件，NameNode需要写入Socket的相关元数据；
• 客户端向分布式文件系统请求下载文件，NameNode要访问元数据区域并返回元数据；
  由此看来，NameNode作为分布式文件系统的管理者，它所要做的一件事就是经常性更新及访问元数据，要保证客户端的请求能够并快速响应，则元数据不能完全放在磁盘上（完全放磁盘上太慢），要放在内存中。
  但是NameNode将元数据放入内存中，随着元数据的不断更新，元数据的规模也越来越大，要是元数据的规模大到NameNode宕机了怎么办？
  要防止NameNode内存中的元数据无限膨胀下去，就需要将内存中的元数据定时写到磁盘文件中，整个内存的元数据的镜像文件被称为fsimage，单条元数据约159Byte；
  但是，NameNode既要响应客户端请求，又要负责收集、记录与维护元数据，若客户端请求频繁，元数据数据量过大，将会给NameNode造成很大负担，从而降低集群的可用性与安全性。

如何降低元数据丢失风险？

为降低宕机等情况带来的元数据丢失风险，引进edits（操作日志）机制。

• edits日志记录包含什么？
  每一次元数据更新，将这个元数据更新之前的操作（即更新操作步骤）连同元数据本身写入edits日志，那么每一条edits日志就包含了旧元数据的路径以及与它相关的操作。
• edits机制解决了什么样的问题？
  最大化降低了NameNode元数据的丢失风险，采用定期合并的方式来合并edits与fsimage，这样即使NameNoe内存崩了，当重启之后，只需要加载处edits文件，并按上面的记录对旧元数据进行操作，就能还原出宕机前内存中的元数据。

SecondaryNameNode

• 为什么引入SecondaryNameNode？
  由于将edits与fsimage进行合并的任务比较繁重，需要使用大量的内存空间，因此为了不影响NameNode的性能，同时降低元数据丢失的风险，就引进了SecondaryNameNode，将edits操作日志与fsimage元数据文件合并的任务交由SecondaryNameNode执行。
• 什么叫checkpoint？
  checkpoint指的是SecondaryNameNode中将edits与fsimage合并的过程，checkpoint有一定触发条件，SecondaryNameNode通过检查NameNode的edits，请求是否需要checkpoint。
• 如何触发checkpoint？
  在NameNode上，如果edits的记录满足条件（达到定时时间或者edits中数据写满），就会触发edits.inprogress（新的操作默认是写在edits.inprogress内的，当edits.inprogress满足滚动条件，就会生成一个edits操作日志文件，同时edits.inprogress清空继续记录新的操作）滚动，生成一个edits操作日志文件，这时候触发checkpoint。
• 触发checkpoint时会发生些什么？
  能够触发checkpoint后，SecondaryNameNode就将新生成的edits以及其他未合并的edits和fsimage下载至本地（SecondaryNameNode只在第一次合并操作下载fsimage，第二次及以后就不会再下载fsimage），然后这些文件就在SecondaryNameNode的内存中运算、合并生成新的元数据存储为fsimage.chkpoint，所以操作完成以后，由SecondaryNameNode将fsimage.chkpoint拷贝给NameNode，NameNode得到fsimage.chkpoint后将其重命名为fsimage，然后替换掉原来的fsimage（合并操作，求同存异）。
• 为什么SecondaryNameNode只在第一次合并操作下载fsimage，第二次及以后就不会再下载fsimage？
  因为第一次SecondaryNameNode本地没有fsimage，只能去NameNode那里去下载，而之后SecondaryNameNode本地已经存在上一次合并的fsimage，故不需要再下载了。
  综上所述，NameNode元数据缓存机制总结如下（注意fsimage只在初次与NameNode处下载一次）：
  1. 开机时，NameNode将本地的edits操作日志和fsimage镜像文件加载至内存；
  2. 客户端可以对分布式文件系统发送各类操作请求 ，如hadoop dfs -put/get/rm/mkdir等；
     
  3. 记录客户端的请求给元数据带来的操作过程至edits.inprogress；
  4. 当edits.inprogress达到条数阈值或时间阈值后，回滚生成edits日志，edits.inprogress清空（开始进行Checkpoint后续步骤）；
     
  5. 另一边，SecondaryNameNode定时向NameNode请求是否发动checkpoint；
  6. edits.inprogress达到时间阈值或者条数阈值就表示可以进行checkpoint，SecondaryNameNode请求进行checkpoint，edits.inprogress立即回滚生成新的edits日志，并自我清空（也可以理解成其更名为edits，然后生成了一个新的edits.inprogress），SecondaryNameNode下载未合并的edits日志（初次还会下载fsimage）；
  7. SecondaryNameNode在本机内存合成fsimage.chkpoint；
     
  8. SecondaryNameNode将fsimage.chkpoint拷贝给NameNode后；
  9. NameNode得到fsimage.chkpoint后将其重命名为fsimage，然后替换掉原来的fsimage（合并操作，求同存异），同时SecondaryNameNode将fsimage.chkpoint与本地的fsimage合并（求同存异），这样以后的checkpoint就不用再从NameNode处下载fsimage了。
     

checkpoint触发条件设定

• 时间阈值

在“hdfs-default.xml”中设定：

<!-- 一小时一次 -->
<property>
  <name>dfs.namenode.checkpoint.period</name>
  <value>3600</value>
</property >

• 操作数阈值
  在“hdfs-default.xml”中设定：

<!-- 两分钟检测edits.inprogress内操作数是否达到500000 -->
<property>
  <name>dfs.namenode.checkpoint.check.period</name>
  <value>120</value>
<description> 检测时间 </description>
</property >
<property>
  <name>dfs.namenode.checkpoint.txns</name>
  <value>500000</value>
<description>操作数</description>
</property>

后记

对NameNode的元数据机制就交代到这里，后面再扒一扒MapRduce，个人理解恐有失偏颇，欢迎留言指正。

跳转

【大数据入门笔记系列】写在前面
【大数据入门笔记系列】第一节 大数据常用组件
【大数据入门笔记系列】第二节 Zookeeper简介
【大数据入门笔记系列】第三节 Hdfs读、写数据处理流程
【大数据入门笔记系列】第四节 NameNode元数据缓存机制