Hadoop MetaData(元数据) 介绍. 和Block File 信息获得

本文深入解析了Hadoop元数据管理机制,包括数据存储方式、读写流程及更新删除方法。详细介绍了元数据镜像文件(FSImage)与日志文件(edits)的备份机制,阐述了NameNode的初始化过程与内存镜像数据结构的初始化。重点分析了元数据应用的场景,如格式化时、Hadoop启动时、元数据更新操作时及配合SecondaryNameNode、BackupNode或checkpointNode时的检查点操作。

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

hadoop 管理数据的机制

     hadoop 用来存储文件是很好,但是要去对存储好的文件进行update,delete,操作,相对就不是那么好操作了,但是非要
做这样的操作,该如何办呐 ?
     a. 先去看hadoop 存文件是怎么存的,是怎么读|写的,
     b.根据a 的结论,找到读|写的方式也就找到了如何去delete,update 的方式了.
     hadoop 的数据都是被 namenode 管理在内存和文件系统中的,用hadoop metadta来标记数据存储的位置,名字,目录等信息.
    hadoop 写数据的实例是:https://sites.google.com/site/hadoopandhive/home/how-to-write-a-file-in-hdfs-using-hadoop 
    hadoop 读数据的实例是:https://sites.google.com/site/hadoopandhive/home/hadoop-how-to-read-a-file-from-hdfs
    hadoop 元数据介绍:
     http://www.dummies.com/how-to/content/hadoop-distributed-file-system-hdfs-for-big-data-p.html
     http://zh.hortonworks.com/blog/hdfs-metadata-directories-explained/

    以下是在 hadoop hdfs 上 输出某个文件目录下的所有的Block File 的信息

      FileSystem myFs = FileSystem.get(“hdfs://localhost:9000”, new Configure());

         //get all files in the directory
         RemoteIterator<LocatedFileStatus> localFiles = myFs.listFiles(myPath, false);
         while (localFiles.hasNext()) {
            LocatedFileStatus localFile = (LocatedFileStatus) localFiles.next();
            String tagPath = localFile.getPath().toString();
            int index = tagPath.lastIndexOf("/");
            String blockFileName  = tagPath.substring(index+1, tagPath.length());
            String blockPath = tagPath.substring(0,index);
            System.err.println(blockPath );
            System.err.println(blockFileName);
         }

      如此就可以将所有的Block File 的信息罗列出来,还能知道每个Block的Size 。

    分析:hdfs 其实和 windows 的文件系统是一个道理,因为都是文件系统,

    理论都是一样的。不管怎么变化,万变不离其宗...



以下为转载整理内容

1、元数据(Metadata)

维护HDFS文件系统中文件和目录的信息,分为内存元数据和元数据文件两种。NameNode维护整个元数据。
HDFS实现时,没有采用定期导出元数据的方法,而是采用元数据镜像文件(FSImage)+日子文件(edits)的备份机制。

2、Block:文件内容而言。

寻路径流程:
          路径信息                         bocks[]                                   triplets[]          
Client ------------》INode---------------------》BlockInfo --------------------------》DataNode。
INode:文件的基本元素:文件和目录
BlockInfo: 文件内容对象
DatanodeDescriptor:具体存储对象。

3 、 FSImage和edits的checkPoint。

FSImage有2个状态,分别是FsImage和FsImage.ckpt,后者表示正在checkpoint的过程中,上传后将会修改为FSImage文件,同理edits也有两个状态,edits和edits.new。

4、NameNode format情景分析:

  • 遍历元数据存储目录,提示用户是否格式化?(NameNode.java里format函数)
[java]  view plain copy print ? 在CODE上查看代码片 派生到我的代码片
  1. private static boolean format( Configuration conf ,  
  2.                                 boolean isConfirmationNeeded )  
  3.       throws IOException {  
  4.     Collection<URI > dirsToFormat = FSNamesystem. getNamespaceDirs(conf );  
  5.     Collection<URI > editDirsToFormat =  
  6.                  FSNamesystem .getNamespaceEditsDirs (conf );  
  7.     for( Iterator< URI> it = dirsToFormat.iterator (); it. hasNext() ;) {  
  8.       File curDir = new File (it .next (). getPath()) ;  
  9.       if (! curDir. exists())  
  10.         continue;  
  11.       if (isConfirmationNeeded ) {  
  12.         System .err .print ("Re-format filesystem in " + curDir + " ? (Y or N) ");  
  13.         if (! (System .in .read () == 'Y')) {  
  14.           System .err .println ("Format aborted in " + curDir );  
  15.           return true ;  
  16.         }  
  17.         while(System .in .read () != '\n') ; // discard the enter-key  
  18.       }  
  19.     }  
  20.   
  21.     FSNamesystem nsys = new FSNamesystem (new FSImage(dirsToFormat ,  
  22.                                          editDirsToFormat ), conf) ;  
  23.     nsys.dir.fsImage .format ();  
  24.     return false;  
  25.   }  
  • 创建元数据内存镜像,包括类FSNamesystem实例化对象,类FSDirectory实例化对象,类FSImage对象,类Edits对象。创建FsNameSystem对象主要完成:BlockManager,FSDirectory对象以及初始化成员变量。FSImage对象主要完成对layoutVersion、namespaceID,CTime赋值为0,实例化FSEditLog。在类FSDirectory,创建了HDFS根目录节点rootDir。
[java]  view plain copy print ? 在CODE上查看代码片 派生到我的代码片
  1. FSNamesystem( FSImage fsImage, Configuration conf ) throws IOException {  
  2.     this. blockManager = new BlockManager (this, conf) ;  
  3.     setConfigurationParameters (conf );  
  4.     this. dir = new FSDirectory(fsImage , this, conf );  
  5.     dtSecretManager = createDelegationTokenSecretManager (conf );  
  6.   }  
  7.   
  8.   FSImage( Collection< URI> fsDirs , Collection< URI> fsEditsDirs )  
  9.       throws IOException {  
  10.     this() ;  
  11.     setStorageDirectories( fsDirs, fsEditsDirs );  
  12.   }  
  13.   
  14.  void setStorageDirectories(Collection <URI > fsNameDirs,  
  15.                              Collection< URI> fsEditsDirs ) throws IOException {  
  16.     this. storageDirs = new ArrayList <StorageDirectory >() ;  
  17.     this. removedStorageDirs = new ArrayList <StorageDirectory >() ;  
  18.      
  19.    // Add all name dirs with appropriate NameNodeDirType  
  20.     for (URI dirName : fsNameDirs ) {  
  21.       checkSchemeConsistency (dirName );  
  22.       boolean isAlsoEdits = false;  
  23.       for (URI editsDirName : fsEditsDirs) {  
  24.         if (editsDirName .compareTo (dirName ) == 0) {  
  25.           isAlsoEdits = true;  
  26.           fsEditsDirs .remove (editsDirName );  
  27.           break;  
  28.         }  
  29.       }  
  30.       NameNodeDirType dirType = (isAlsoEdits ) ?  
  31.                           NameNodeDirType .IMAGE_AND_EDITS :  
  32.                           NameNodeDirType .IMAGE ;  
  33.       // Add to the list of storage directories, only if the  
  34.       // URI is of type file://  
  35.       if(dirName .getScheme (). compareTo( JournalType.FILE .name (). toLowerCase())  
  36.           == 0){  
  37.         this.addStorageDir (new StorageDirectory(new File(dirName. getPath()) ,  
  38.             dirType ));  
  39.       }  
  40.     }  
  41.      
  42.     // Add edits dirs if they are different from name dirs  
  43.     for (URI dirName : fsEditsDirs ) {  
  44.       checkSchemeConsistency (dirName );  
  45.       // Add to the list of storage directories, only if the  
  46.       // URI is of type file://  
  47.       if(dirName .getScheme (). compareTo( JournalType.FILE .name (). toLowerCase())  
  48.           == 0)  
  49.         this.addStorageDir (new StorageDirectory(new File(dirName. getPath()) ,  
  50.                     NameNodeDirType .EDITS ));  
  51.     }  
  52.   }  
  • 对内存镜像数据中的数据结构进行初始化:主要有FSImage的format函数完成,layoutVersion:软件所处的版本。namespaceID:在Format时候产生,当data node注册到Name Node后,会获得该NameNode的NameSpaceID,并作为后续与NameNode通讯的身份标识。对于未知身份的Data Node,NameNode拒绝通信。CTime:表示FSimage产生的时间。checkpointTime:表示NameSpace第一次checkpoint的时间。  
[java]  view plain copy print ? 在CODE上查看代码片 派生到我的代码片
  1. public void format () throws IOException {  
  2.    this. layoutVersion = FSConstants .LAYOUT_VERSION ;  
  3.    this. namespaceID = newNamespaceID ();  
  4.    this. cTime = 0L ;  
  5.    this. checkpointTime = FSNamesystem .now ();  
  6.    for (Iterator <StorageDirectory > it =  
  7.                           dirIterator (); it. hasNext() ;) {  
  8.      StorageDirectory sd = it .next ();  
  9.      format (sd );  
  10.    }  
  11.  }  
  • 对内存镜像写入元数据备份目录。FSImage的format方法会遍历所有的目录进行备份。如果是FSImage的文件目录,则调用saveFSImage保存FSImage,如果是Edits,则调用editLog.createEditLogFile,最后调用sd.write方法创建fstime和VERSION文件。VERSION文件通常最后写入。
[java]  view plain copy print ? 在CODE上查看代码片 派生到我的代码片
  1. void format(StorageDirectory sd ) throws IOException {  
  2.     sd.clearDirectory (); // create currrent dir  
  3.     sd.lock ();  
  4.     try {  
  5.       saveCurrent (sd );  
  6.     } finally {  
  7.       sd .unlock ();  
  8.     }  
  9.     LOG.info ("Storage directory " + sd. getRoot()  
  10.              + " has been successfully formatted.");  
  11.   }  
最后分析一下元数据应用的场景:
1、格式化时。
2、Hadoop启动时。
3、元数据更新操作时。
4、如果NameNode与Secondary NameNode、Backup Node或checkpoint Node配合使用时,会进行checkPoint操作。


<think>好的,用户之前问了关于Secondary NameNode的作用,现在他想了解Hadoop元数据的存储方式,特别是NameNode的存储机制。我需要结合之前的回答提供的引用内容来组织信息。 首先,用户之前的问题里,我已经详细解释了Secondary NameNode如何合并fsimageedit logs,所以现在需要深入元数据存储的具体机制。根据引用[2],元数据分为fsimageedit logs,其中fsimage是持久化的检查点,而edit logs记录操作。同时,NameNode在内存中维护完整的元数据,包括文件块的位置信息,这些信息不存储在fsimage中,而是通过DataNode汇报获得。 用户可能想知道元数据在磁盘内存中的存储方式,以及两者的协同工作流程。需要解释fsimageedit logs的作用、存储路径以及合并过程,这部分之前提到过Secondary NameNode的合并流程,现在可以更详细地说明。 另外,引用[3]提到NameNodeSecondary NameNode的协作,所以需要强调两者的分工,比如NameNode负责实时记录edit logs,而Secondary NameNode定期合并。同时,要注意内存中的元数据结构磁盘存储的不同,比如文件块位置信息只存在于内存中,这点需要明确说明。 可能用户还关心高可用性(HA)模式下的元数据存储变化,比如在HA中如何通过JournalNode管理edit logs,避免依赖Secondary NameNode。这部分在之前的回答里提到过HA替代方案,现在可以补充说明。 需要确保回答结构清晰,分点列出内存存储磁盘存储,然后详细说明两者的协作流程,并加入关键配置参数,帮助用户理解如何调整存储路径合并策略。最后,生成的相关问题要围绕元数据管理、HA的影响以及性能优化等方面,引导用户深入探索。</think>### Hadoop NameNode 元数据存储机制详解 #### 一、元数据的组成与存储架构 Hadoop NameNode 的元数据存储采用 **内存+磁盘双模式**,具体分为以下两类: 1. **内存元数据** - **数据结构**:维护完整的文件系统树(`INode` 结构),包含文件名、目录结构、权限、副本数、**文件块与DataNode的映射关系**[^2]。 - **动态更新**:实时响应客户端操作(如创建/删除文件),更新内存中的元数据。 - **特点**:访问速度快,但数据易失(重启后丢失)。 2. **磁盘元数据** - **fsimage(镜像文件)** - 持久化的元数据检查点,存储文件系统目录结构、权限等静态信息,**不包含文件块位置信息**[^2]。 - 文件格式:二进制序列化数据(可通过 `hdfs oiv` 命令解析)。 - 存储路径:由 `dfs.namenode.name.dir` 配置(默认 `file://${hadoop.tmp.dir}/dfs/name`)。 - **edit logs(操作日志)** - 增量记录所有修改元数据的操作(如 `mkdir`、`delete`)。 - 文件格式:二进制日志(可通过 `hdfs oev` 命令解析)。 - 存储路径:与 `fsimage` 同目录,文件名为 `edits_<start_txid>-<end_txid>`。 ```plaintext 元数据存储关系图: +---------------------+ | NameNode 内存 | | - 文件系统树 | | - 块位置映射表 | ← 通过DataNode心跳动态更新 +---------------------+ | 定期持久化 ↑ 实时记录操作 V | +---------------------+ | 磁盘存储 (fsimage) | ← 静态元数据 | + edits_0001-0005 | ← 动态操作日志 +---------------------+ ``` #### 二、元数据协作流程 1. **启动阶段** - NameNode 加载最新的 `fsimage` 到内存。 - 按顺序重放 `edit logs` 中的所有操作,恢复完整元数据[^3]。 - *示例*:若 `fsimage` 记录截止到事务ID 1000,则需加载 `edits_1001-...`。 2. **运行阶段** - 客户端操作(如写入文件)触发元数据变更: 1. 将操作追加到当前 `edit logs`(例如 `edits_1001-2000`)。 2. 更新内存中的元数据(文件系统树、块映射表)。 - **关键限制**:`edit logs` 仅追加写入,不可修改。 3. **检查点合并(Checkpoint)** - Secondary NameNode 或 Standby NameNode(HA模式)定期执行: 1. 下载当前 `fsimage` 新增的 `edit logs`。 2. 在内存中合并生成新 `fsimage`(如 `fsimage_2000`)。 3. 回传新镜像并重置 `edit logs`[^1]。 - *合并频率*:由 `dfs.namenode.checkpoint.period` 控制(默认1小时)。 #### 三、关键设计细节 1. **块位置信息的特殊性** - **不持久化**:文件块与DataNode的映射关系**仅存储在内存中**,通过DataNode周期性心跳汇报(间隔默认3秒)重建。 - **恢复逻辑**:NameNode重启后,通过DataNode的块报告(`BlockReport`)重新构建块位置表。 2. **元数据一致性保障** - **写前日志(WAL)**:所有元数据修改**先写edit logs**,再更新内存,避免断电导致数据不一致。 - **fsimage 多副本**:通过配置多个 `dfs.namenode.name.dir` 路径实现本地多副本存储。 3. **HA模式下的变化** - **JournalNode 集群**:替代 `edit logs` 本地存储,将操作日志写入分布式日志系统(至少3节点)[^1]。 - **共享存储**:Active Standby NameNode 通过共享存储(如QJM)同步元数据。 #### 四、配置参数与优化 | **参数** | **作用** | **推荐值** | |------------------------------|----------------------------------|----------------------------| | `dfs.namenode.name.dir` | fsimage edit logs 存储路径 | `/data1/nn,/data2/nn` | | `dfs.blocks.metadata.enabled` | 是否启用块元数据持久化(实验性) | `false` | | `dfs.namenode.num.checkpoints.retained` | 保留的历史fsimage版本数 | `2` | **优化建议**: - 使用 **SSD存储** 加速 `fsimage` 加载合并。 - 配置 **多磁盘路径** 分散I/O压力(如 `dfs.namenode.name.dir=/ssd/nn,/hdd/nn`)。 - 监控 `edit logs` 增长率,避免合并延迟导致NameNode启动时间过长。 --- ### 相关问题 1. **为什么NameNode不将块位置信息持久化到磁盘?** 2. **Hadoop HA模式下edit logs如何实现高可用?** 3. **如何手动触发Secondary NameNode执行检查点合并?** 4. **fsimage文件损坏时有哪些恢复手段?** 5. **HDFS Federation架构对元数据存储机制有何影响?** [^1]: NameNode通过内存+磁盘双模式管理元数据,依赖Secondary NameNode或HA机制保障数据可靠性。 [^2]: 文件块位置信息动态维护于内存,通过DataNode心跳机制实现最终一致性。 [^3]: Checkpoint机制通过合并fsimage与edit logs优化元数据恢复效率。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值