在部署hadoop集群时，core-site.xml中的fs.defaultFS项的value不可包含下划线，否则会报以下错误
俗话说的好，没有高可用，如何敢抗双十一？ 今天就来简单分析下，Hadoop集群中关于QJM高可用NamdeNode-HA的原理： 关于NameNode高可靠需要配置的文件有core-site.xml和
1.移走集群中所有JournalNode节点目录下的同一个edits文件，比如下面图片中的文件 edits_0000000000001904836-0000000000001904904
HDFS是Apache Hadoop的分布式文件系统，由NameNode和DataNode组成。在HDFS中，NameNode是HDFS的主要组件之一，它负责维护文件系统的命名空间和访问控制信息。同时，NameNode也负责管理所有DataNode节点的元数据信息，包括文件和目录的层次结构，文件块的位置信息以及访问控制列表等。因此，NameNode是整个HDFS系统的中心控制器。
首先secondary namenode不是namenode的备份，而是辅助namenode管理的，分担namenode的压力。
Secondary NameNode 是合并 NameNode 的 edit logs 到 fsimage 文件中； 它的具体工作机制： （1）Secondary NameNode 询问 NameNode 是否需要 checkpoint。直接带回 NameNode 是否检查结果 （2）Secondary NameNode 请求执行 checkpoint （3）NameNode 滚动正在写的 edits 日志 （4）将滚动前的编辑日志和镜像文件拷贝到 Secondary NameNode （5）Secondary NameNode 加载编辑日志和镜像文件到内存，并合并 （6）生成新的镜像文件 fsimage.chkpoint （7）拷贝 fsimage.chkpoint 到 NameNode （8）NameNode 将 fsimage.chkpoint 重新命名成 fsimage 所以如果 NameNode 中的元数据丢失，是可以从 Secondary NameNode 恢复一部 分元数据信息的，但不是全部，因为 NameNode 正在写的 edits 日志还没有拷贝 到 Secondary NameNode，这部分恢复不了
在Hadoop 中，NameNode 所处的位置是非常重要的，整个HDFS文件系统的元数据信息都由NameNode 来管理，NameNode的可用性直接决定了Hadoop 的可用性，一旦NameNode进程不能工作了，就会影响整个集群的正常使用。
最近有朋友问我Secondary NameNode的作用，是不是NameNode的备份？是不是为了防止NameNode的单点问题？确实，刚接触Hadoop，从字面上看，很容易会把Secondary NameNode当作备份节点；其实，这是一个误区，我们不能从字面来理解，阅读官方文档，我们可以知道，其实并不是这么回事，下面就来赘述下Secondary NameNode的作用。
Fayson在最近写了很多关于NameNode恢复，或者NameNode角色迁移相关的文章，但都是基于HDFS已经启用HA的情况来操作的包括你将要阅读的本文，这也是Hadoop作为一个生产系统所必须的，当然假如万一你没有启用HDFS HA，涉及单个NameNode的备份恢复或者迁移节点，可以参考Fayson很早之前的一篇文章《NameNode Metadata备份和恢复最佳实践》。
前一篇文章介绍了Hadoop2.0（hadoop2.0架构，具体版本是hadoop2.2.0）的安装和最基本的配置（见 http://www.linuxidc.com/Linux/2014-05/101173.htm ），并没有配置HA（High Avalability，高可用性），接下来的文章中会介绍hadoop2.0HA的配置。在介绍hadoop2.0的HA配置之前，本文先介绍hadoop2.0HA的基本原理和2种方式。 1 概述 在hadoop2.0之前，namenode只有一个，存在单点问题（虽
HDFS 集群节点以master/slave（管理者－工作者模式）运行，namenode就是一个master , 而datanode就是slave 。
HDFS的元数据信息存储在NameNode数据目录（由配置项“dfs.namenode.name.dir”指定）中的FsImage文件中。standby NameNode会周期将已有的FsImage和JournalNode中存储的Editlog合并生成新的FsImage，然后推送到active NameNode的数据目录。这个周期由HDFS的配置项“dfs.namenode.checkpoint.period”指定，默认为3600秒，即1个小时。如果active NameNode数据目录的FsImage没有更新，则说明HDFS元数据合并功能异常，需要修复
前一篇文章介绍了Hadoop2.0（hadoop2.0架构，具体版本是hadoop2.2.0）的安装和最基本的配置（见 http://www.linuxidc.com/Linux/2014-05/101173.htm ），并没有配置HA（High Avalability，高可用性），接下来的文章中会介绍hadoop2.0HA的配置。在介绍hadoop2.0的HA配置之前，本文先介绍hadoop2.0HA的基本原理和2种方式。
HDFS作为分布式文件系统的代表性产品，在大数据学习当中的重要性是不言而喻的，基于Hadoop基础架构，HDFS更是得到了广泛的认可，在大规模离线数据处理上，提供稳固的底层支持。今天的大数据开发技术分享，我们就主要来讲讲HDFS Namenode元数据管理。
上一篇文章《Hadoop2.0 federation介绍》（见http://www.linuxidc.com/Linux/2014-05/101179.htm ）介绍了hadoop2.0 federation的基本架构和基本原理，本文接着先介绍单独配置federation，在下一篇文章中会继续介绍同时配置HA和federation。 1 准备
Hadoop的发展至今已经有十余年的历史了，其核心设计HDFS和MapReduce，分别解决了海量数据的存储和计算这两个问题。
（1）健康检测：zkfc会周期性的向它监控的namenode（只有namenode才有zkfc进程，并且每个namenode各一个）发生健康探测命令，从而鉴定某个namenode是否处于正常工作状态，如果机器宕机，心跳失败，那么zkfc就会标记它处于不健康的状态；
NameNode：存储文件的元数据。作用：管理HDFS的名称空间；配置副本策略；管理数据块（Block）映射信息；处理客户端读写请求。NameNode两个重要文件（内存中的镜像=fsimage+edits）。
NameNode 保存了整个 HDFS 的元数据信息，一旦 NameNode 挂掉，整个 HDFS 就无法访问。为了提高HDFS的高可用性，在 Hadoop2.0 中，HDFS NameNode支持了高可用架构，如下图。
HDFS（Hadoop Distributed File System）分布式文件存储系统，主要为各类分布式计算框架如Spark、MapReduce等提供海量数据存储服务，同时HBase、Hive底层存储也依赖于HDFS。HDFS提供一个统一的抽象目录树，客户端可通过路径来访问文件，如hdfs://namenode:port/dir-a/a.data。HDFS集群分为两大角色：Namenode、Datanode（非HA模式会存在Secondary Namenode）
我们知道hadoop集群搭建之后，并不能马上启动集群进行使用，需要对namenode做格式化。具体执行的命令：hadoop namenode -format。namenode格式化是删除hdfs-site.xml中dfs.namenode.name.dir指定目录下已有的文件信息（包含fsimage和edit文件），然后在该目录下创建VERSION等文件。初次使用集群必须执行，但对已有数据的集群，会导致集群不可用。如若是非HA集群，会导致丢失所有数据的严重后果。
在Hadoop 1.x 中，Namenode是集群的单点故障，一旦Namenode出现故障，整个集群将不可用，重启或者开启一个新的Namenode才能够从中恢复。
这次文章是记录一下数据恢复。 上周五在调试Spark数据的时候发现了一个问题，就是一直显示No lease的问题，我们的实时处理程序升级之后，处理的数据量在一个小时内暴增1T。我们的小时程序Spark，有的单个key数据重复导致value值增大，程序运行卡住，根据网上查的参数进行调整。 Hadoop 在调整前，将Hadoop进行关闭 . stop-all.sh 进行关闭 我们在第一步进行关闭的时候这里就出现问题。。。关闭hadoop.sh 出现异常，关闭失败。只好使用linux 上的kill 强制杀
概述 HDFS（Hadoop Distributed File System ）Hadoop分布式文件系统的简称。HDFS被设计成适合运行在通用硬件(commodity hardware)上的分布式文件系统。DFS是一个高度容错性的系统，适合部署在廉价的机器上。HDFS能提供高吞吐量的数据访问，非常适合大规模数据集上的应用。HDFS放宽了一部分POSIX约束，来实现流式读取文件系统数据的目的。HDFS在最开始是作为Apache Nutch搜索引擎项目的基础架构而开发的。HDFS是Apache Hadoop
Windows 7 环境下启动 HDFS，执行 start-dfs.cmd 出现 org.apache.hadoop.io.nativeio.NativeIO$Windows.access0(Ljava/lang/String;I)Z报错信息如下：
（1）首次启动需要格式化NameNode，创建Fsimage和Edits文件。如果不是第一次启动，直接加载编辑日志和镜像文件到内存。
本文主要介绍HDFS Federation（联邦）相关知识，为后续文章《如何为CDH集群启用Federation（联邦）》做一个简单的铺垫。Federation即为“联邦”，该特性允许一个HDFS集群中存在多组Namenode同时对外提供服务，分管一部分目录（水平切分），彼此之间相互隔离，但共享底层的Datanode存储资源。
当 Hadoop 的集群当中, NameNode的所有元数据信息都保存在了 FsImage 与 Eidts 文件当中, 这两个文件就记录了所有的数据的元数据信息, 元数据信息的保存目录配置在了 hdfs-site.xml 当中
故障检测：每个NameNode在ZooKeeper中维护了一个持久会话，如果机器崩溃，ZooKeeper中的会话将终止，ZooKeeper通知另一个NameNode需要触发故障转移。
HDFS HA(High Availability)高可用配置官方参考网址 http://hadoop.apache.org/docs/r2.7.3/hadoop-project-dist/hadoop-hdfs/HDFSHighAvailabilityWithQJM.html
环境 操作系统: Windows 7 Hadoop版本: 2.6.0 问题描述 Windows执行hdfs namenode -format报如下错误 20/10/13 13:58:04 ERROR namenode.NameNode: Failed to start namenode. java.lang.IllegalArgumentException: URI has an authority component at java.io.File.<init>(File.java:423
hadoop集群中一般有两个namenode，一个处于active激活状态，另一个处于StandBy状态，Active状态的NameNode负责集群中所有的客户端操作，这么设置的目的，其实HDFS底层的机制是有关系的，同一时刻一个文件，只允许一个写入方占用，如果出现多个，那么文件偏移量便会混乱，从而导致数据格式不可用，当然状态为Standby的NameNode这时候仅仅扮演一个Slave的角色，以便于在任何时候Active的NameNode挂掉时，能够第一时间，接替它的任务，成为主NameNode，达到一个热备份的效果。在HA架构里面SecondaryNameNode这个冷备角色已经不存在了，为了保持从NameNode时时的与主NameNode的元数据保持一致，他们之间交互通过一系列守护的轻量级进程JournalNode，当任何修改操作在主NameNode上执行时，它同时也会记录修改log到至少半数以上的JornalNode中，这时状态为Standby的NameNode监测到JournalNode里面的同步log发生变化了会读取JornalNode里面的修改log，然后同步到自己的的目录镜像树里面，当发生故障时，Active的NameNode挂掉后，Standby的NameNode会在它成为Active NameNode前，读取所有的JournalNode里面的修改日志，这样就能高可靠的保证与挂掉的NameNode的目录镜像树一致，然后无缝的接替它的职责，维护来自客户端请求，从而达到一个高可用的目的。
1.Unable to determine local hostname -falling back to "localhost"
HDFS 是 Hadoop 中存储数据的基石，存储着所有的数据，具有高可靠性，高容错性，高可扩展性，高吞吐量等特征，能够部署在大规模廉价的集群上，极大地降低了部署成本。有意思的是，其良好的架构特征使其能够存储海量的数据。本篇文章，我们就来系统学习一下，Hadoop HDFS的架构！
在使用python做大数据和机器学习处理过程中，首先需要读取hdfs数据，对于常用格式数据一般比较容易读取，parquet略微特殊。从hdfs上使用python获取parquet格式数据的方法(当然也可以先把文件拉到本地再读取也可以)：
单NameNode的架构使得HDFS在集群扩展性和性能上都有潜在的问题，当集群大到一定程度后，NameNode进程使用的内存可能会达到上百G，NameNode成为了性能的瓶颈。因而提出了namenode水平扩展方案-- Federation。
我们在刚开始学习HDFS的时候,知道HDFS主要由管理者NameNode和DataNode组成。其中还有一个SecondaryNameNode在HDFS中扮演着辅助的作用,负责辅助NameNode管理
This document is a starting point for users working with Hadoop Distributed File System (HDFS) either as a part of a Hadoop cluster or as a stand-alone general purpose distributed file system. While HDFS is designed to "just work" in many environments, a
HDFS由四部分组成，HDFS Client、NameNode、DataNode和Secondary NameNode。 HDFS是一个主/从（Mater/Slave）体系结构，HDFS集群拥有一个NameNode和一些DataNode。NameNode管理文件系统的元数据，DataNode存储实际的数据。
Hadoop分布式文件系统（HDFS）是Apache Hadoop生态系统的核心组件之一，它是一个高可靠、高可扩展的分布式文件系统，适用于大数据处理和分析。HDFS的组成架构包括NameNode、DataNode、Secondary NameNode和客户端。
1）client 客户端发送上传请求，通过 RPC 与 namenode 建立通信，namenode 检查该用户是否有上传权限，以及上传的文件是否在 hdfs 对应的目录下重名，如果这两者有任意一个不满足，则直接报错，如果两者都满足，则返回给客户端一个可以上传的信息
HDFS 是一个主从（Master/Slaves）的架构，它由一个 NameNode 和一些 DataNode 组成。其中，NameNode 是主，DataNode 是从。文件元数据由 NameNode 负责存储和管理，且它维护了一个层次型的文件目录树；文件的数据由 DataNode 来按照 block 进行存储，并按照 block 进行读写。DataNode 与 NameNode 通过心跳来维持，DataNode 会向 NameNode 汇报自己持有的 block 信息。当客户端和 NameNode 交互文件元数据，和 DataNode 交互 block 数据。
NameNode在内存中保存着整个文件系统的名字空间和文件数据块的地址映射(Blockmap)。如果NameNode宕机，那么整个集群就瘫痪了。
今天小白接着来探究hadoop2.0下，架构发生了哪些变化？前文也对1.0的架构进行了浅谈，【小白看架构 · HDFS1.0架构】，文中若有错误之处，欢迎大家留言讨论，谢谢大家。
secondaryNamenode对namenode当中的fsimage和edits进行合并时，每次都会先将namenode的fsimage与edits文件拷贝一份过来，所以fsimage与edits文件在secondarNamendoe当中也会保存有一份，如果namenode的fsimage与edits文件损坏，那么我们可以将secondaryNamenode当中的fsimage与edits拷贝过去给namenode继续使用，只不过有可能会丢失一部分数据。这里涉及到几个配置选项 namenode保存fsimage的配置路径
下面是成功信息，出现 has been successfully formatted.
安全模式是Namenode的一种状态（Namenode主要有active/standby/safemode三种模式）。
1）客户端向namenode请求上传文件，namenode检查目标文件是否已存在，父目录是否存在。
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
实时音视频
即时通信 IM
对象存储
