hdfs详解

1. 基本概念

• 设计思想，分而治之。
  将大文件、批量文件，分布式存放在大量服务器上，以便于采取分而治之的方式对海量数据进行运算分析
• 在大数据系统中的作用：为各类运算框架（mapreduce、spark、...）提供数据存储服务。
• 重点概念：文件分块，副本存储、元数据

2. 概念和特性

• 首先，是一个文件系统，通过统一命名空间-目录树来定位和存储文件。其次，是分布式的，由多台服务器联合起来实现其功能

3. hdfs读数据的流程

4. hdfs写数据流程

5. 元数据存储机制

• namenode对数据的管理采用了三种存储形势 ：
  内存元数据（metadata）
  元数据磁盘镜像文件（fsimage，在那么node的工作目录中）
  数据操作日志文件edits.log（通过和fsimage合并可以运算出内存元数据）
• 机制：
  当客户端对hdfs中的文件进行新增、修改或删除的时候，操作记录首先被记录在edits日志文件中，客户端操作成功后，将相应的元数据更新到内存中。

6. 元数据的checkpoint

• hdfs的SecondaryNamenode和Namenode之间有心跳通信，每隔时间，SecondaryNamenode会将NameNode中的最新的fsimage和积累的edits文件下载到本地，并加载到内存中进行merge。（这个过程称之为checkpoint）
• checkpoint的详细过程
  
• checkpoint的附带作用：
  namenode和secondarynamenode的目录存储结构是完全相同的，所以，当namenode故障退出需要重新恢复时，可以从secondarynamenode的工作目录中拷贝fsimage到namenode的工作目录中，namenode启动时，会通过将fsimage和edits合并运算出元数据（可能有部分数据丢失）

7. 元数据目录结构

• namenode格式化之后会在$dfs.namenode.name.dir/current目录下生成如下文件结构，
• VERSION：保存了集群的一些描述信息
  
• seen_txid
  seen_txid非常重要，是存放transactionId的文件，format之后是0，它代表的是namenode里面的edits_*文件的尾数，namenode重启的时候，会按照seen_txid的数字，循序从头跑edits_0000001~到seen_txid的数字。所以当你的hdfs发生异常重启的时候，一定要比对seen_txid内的数字是不是你edits最后的尾数，不然会发生重启namenode时metaData的资料有缺少，导致误删Datanode上多余Block的资讯。