文章目录
Hadoop架构
参考:https://cloud.tencent.com/developer/article/1005706
Hadoop如何工作
-
第一阶段:
一个用户/应用程序
能够提交一项作业给Hadoop(hadoop作业客户端),需要指定以下条目进行后续处理。
(1)分布式系统中输入和输出文件的位置。
(2)以jar文件形式存在的java类,包含映射(Map)和缩减(Reduce)功能的实现。
(3)通过设定不同的作业参数来进行作业配置。
-
第二阶段:接着,Hadoop作业客户端
提交一个作业
(jar/可执行文件等)和配置给JobTracker。然后,JobTracker负责将软件/配置分发给从属服务器、调度任务,并进行监控,向作业客户端提供状态和运行诊断信息。 -
第三阶段:不同节点上的TaskTracker根据每一个MapReduce的实现运行任务,减量功能的输出被存储到文件系统的输出文件中。
HDFS体系结构
-
(1) HDFS由
Client
、NameNode
、DataNode
、SecondaryNameNode
组成。 -
(2) Client提供了文件系统的调用接口。
-
(3)NameNode由fsimage(HDFS元数据镜像文件)和editlog(HDFS文件改动日志)组成,NameNode在内存中保存着每个文件和数据块的引用关系。
NameNode中的引用关系不存在硬盘中,每次都是HDFS启动时重新构造出来的。 -
(4) SecondaryNameNode的任务有两个:
1、定期合并
fsimage和editlog,并传输给NameNode。
2、为NameNode提供热备份。 -
(5) 一般是一个机器上安装一个DataNode,一个DataNode上又分为很多
数据块
(block)。 -
(6) DataNode会通过
心跳
定时向NameNode发送所存储的文件块信息。 -
(7) HDFS的副本存放规则
默认的副本系数是3,
1、一个副本存在本地机架的本机器上,
2、第二个副本存储在本地机架的其他机器上,
3、第三个副本存在其他机架的一个节点上。优势
1、这样减少了写操作的网络数据传输,提高了写操作的效率;
2、 另一方面,机架的错误率远比节点的错误率低,所以不影响数据的可靠性
。
HDFS 写文件过程
1.客户端将文件写入本地磁盘
的 HDFS Client 文件中
2.当临时文件大小达到一个 block 大小时,HDFS client 通知 NameNode
,申请写入文件
3.NameNode 在 HDFS 的文件系统中创建一个文件,并把该 block id 和要写入的 DataNode
的列表返回给客户端
4.客户端收到这些信息后,将临时文件写入 DataNodes
4.1 客户端将文件内容写入第一个 DataNode(一般以 4kb 为单位进行传输)
4.2 第一个 DataNode 接收后,将数据写入本地磁盘,同时也传输给第二个 DataNode
4.3 依此类推到最后一个 DataNode,数据在 DataNode 之间是通过 pipeline 的方式进行复制的
4.4 后面的 DataNode 接收完数据后,都会发送一个确认给前一个 DataNode,最终第一个 DataNode 返回确认给客户端
4.5 当客户端接收到整个 block 的确认后,会向 NameNode 发送一个最终的确认信息
4.6 如果写入某个 DataNode 失败,数据会继续写入其他的 DataNode。然后 NameNode 会找另外一个好的 DataNode 继续复制,以保证冗余性
4.7 每个 block 都会有一个校验码,并存放到独立的文件中,以便读的时候来验证其完整性
5.文件写完后(客户端关闭),NameNode 提交文件(这时文件才可见,如果提交前,NameNode 垮掉,那文件也就丢失了。
fsync:只保证数据的信息写到 NameNode
上,但并不保证数据已经被写到DataNode
中)
HDFS 读文件过程
- Client 客户端会申请一个 DistributedFileSystem,向 NameNode 发起下载申请,先看看有没有这 个文件
- NameNode 响应是否存在
- Client 开一个输入流,然后向 Namenode 请求下载第一块 Block
- NameNode 会返回给 client 三个 DN(Client 只会从一个 DN 上下载,就近原则)
- InputStream 向 DN 请求建立通道
- DN 向 Client 返回应答成功
- DN 向 Client 传输 Packet
- NameNode 告诉 Client 数据传输完毕(流对口是一个连续的过程)
HDFS 可靠性
HDFS 的可靠性主要有以下几点:
冗余副本策略、机架策略、心跳机制、安全模式、效验和、回收站、元数据保护、快照机制
- 1.冗余副本策略
可以在 hdfs-site.xml 中设置复制因子指定副本数量
所有数据块都可副本
DataNode 启动时,遍历本地文件系统,产生一份 HDFS 数据块和本地文件的对应关系列表 (blockreport) 汇报给 Namenode
- 2.机架策略
HDFS 的"机架感知",通过节点之间发送一个数据包,来感应它们是否在同一个机架
一般在本机架放一个副本,在其他机架再存放一个副本,这样可以防止机架失效时丢失数据,也可以提高带宽利用率
- 3.心跳机制
NameNode 周期性从 DataNode 接受心跳信息和块报告
NameNode 根据块报告验证元数据
没有按时发送心跳的 DataNode 会被标记为宕机,不会再给他任何 I/O 请求
如果 DataNode 失效造成副本数量下降,并且低于预先设定的值,NameNode 会检测出这些数据库,并在合适的时机重新复制
引发重新复制的原因还包括数据副本本身损坏,磁盘错误,复制因子被增大等
- 4.安全模式
NameNode 启动时会先经过一个 “安全模式” 阶段
安全模式阶段不会产生数据写
在此阶段 NameNode 收集各个 DataNode 的报告, 当数据块达到最小副本数以上时,会被认为是"安全"的
在一定比例(可设置) 的数据块被确定为"安全" 后 ,在过若干时间,安全模式结束
当检测到副本数不足的数据块时,该块会被复制,直到达到最小副本数
- 5.效验和
在文件创立时,每个数据块都产生效验和
效验和会作为单独一个隐藏文件保存在命名空间下
客户端获取数据时可以检查效验和是否相同,从而发现数据块是否损坏
如果正在读取的数据块损坏,则可以继续读取其他副本
- 6.回收站
删除文件时,其实是放入回收站 /trash
回收站里的文件是可以快速恢复的
可以设置一个时间值,当回收站里文件的存放时间超过了这个值,就被彻底删除,并且释放占用的数据块
- 7.元数据保护
映像文件和事物日志是 NameNode 的核心数据.可以配置为拥有多个副本
副本会降低 NameNode 的处理速度,但增加安全性
NameNode 依然是单点,如果发生故障要手工切换
HDFS高可用方案
在 Hadoop 1.0 时代
Hadoop 的两大核心组件 HDFS NameNode
和 JobTracker
都存在着单点问题,这其中以NameNode的单点问题尤为严重。因为NameNode保存了整个HDFS的元数据信息,一旦NameNode挂掉,整个HDFS就无法访问,同时Hadoop生态系统中依赖于HDFS的各个组件,包括MapReduce、Hive、Pig以及HBase等也都无法正常工作,并且重新启动NameNode和进行数据恢复的过程也会比较耗时。这些问题在给Hadoop的使用者带来困扰的同时,也极大地限制了Hadoop的使用场景,使得Hadoop在很长的时间内仅能用作离线存储和离线计算,无法应用到对可用性和数据一致性要求很高的在线应用场景中。
Hadoop1.0—HDFS
由一个NameNode和多个DataNode 组成
,
MapReduce由一个JobTracker和多个TaskTracker 组成
。
Hadoop2.0
针对Hadoop1.0中的单NameNode制约HDFS的扩展性问题
,
提出了HDFSFederation
(联盟),它让多个NameNode分管不同的目录进而实现访问隔离和横向扩展,同时它彻底解决了NameNode单点故障问题。
它将JobTracker中的资源管理
和作业控制
功能分开,分别由组件ResourceManager
和ApplicationMaster
实现,其中,ResourceManager负责所有应用程序的资源分配,ApplicationMaster仅负责管理一个应用程序,
进而诞生了全新的通用资源管理框架YARN
。基于YARN,用户可以运行各种类型的应用程序(不再像1.0那样仅局限于MapReduce
一类应用),从离线计算的MapReduce到在线计算(流式处理)的Storm等YARN不仅限于MapReduce一种框架使用,也可以供其他框架使用,比如Tez、Spark、Storm。
方法一:HDFS联盟
1.1 问题缘由
单个
NameNode节点的局限性:
1、命名空间的限制:NameNode上存储着整个HDFS上的文件的元数据
,NameNode是部署在一台机
器上的,因为单个机器硬件的限制,必然会限制NameNode所能管理的文件个数,制约了数据量的增长。
2、数据隔离问题:整个HDFS上的文件都由一个NameNode管理
,所以一个程序很有可能会影响到整个HDFS上的程序,并且权限控制比较复杂。
3、性能瓶颈:单个NameNode时HDFS文件系统的吞吐量受限于单个NameNode的吞吐量。因为NameNode是个JVM进程,JVM进程所占用的内存很大时,性能会下降很多。
1.2 解决方法
HDFS集群中只有一个NameNode是有很多局限性
的,为了解决单个NameNode的局限,设计了HDFS联盟。
HDFS 联盟是可以在Hadoop集群中设置多个NameNode
,联盟中的多个NameNode是不同的,可以理解为将一个NameNode切分为了多个NameNode,每一个NameNode只负责管理一部分数据
,HDFS Federation中的多个NameNode共用
DataNode。
方法二:HDFS HA
单NameNode的缺陷存在单点故障的问题,如果NameNode不可用,则会导致整个HDFS文件系统不可用
。所以需要设计高可用的HDFS(HadoopHA)来解决NameNode单点故障的问题。解决的方法是在HDFS集群中设置多个NameNode节点
。但是一旦引入多个NameNode,就有一些问题需要解决。
HDFS HA需要保证的四个问题:
1、保证NameNode内存中元数据数据一致
,并保证编辑日志文件的安全性
。
解决:采用Zookeeper来存储编辑日志文件。
2、多个NameNode如何协作
3、客户端如何能正确地访问
到可用的那个NameNode。
4、怎么保证任意时刻只能有一个NameNode处于对外服务状态
。
解决方法
两个NameNode一个是Active
状态的,一个是Standby
状态的,一个时间点只能有一个Active状态的NameNode提供服务
两个NameNode上存储的元数据是实时同步
的,当Active的NameNode出现问题时,通过Zookeeper实时切换
到Standby的NameNode上,并将Standby改为Active状态。
客户端通过连接一个Zookeeper
的代理来确定
当时哪个NameNode
处于active
服务状态
HDFS HA架构中有两台NameNode节点,一台是处于活动状态(Active)为客户端提供服务,另外一台处于热备份状态(Standby)
元数据
文件有两个文件:fsimage
和edits
,备份元数据就是备份这两个文件。
JournalNode用来实时从Active NameNode上拷贝edits
文件,JournalNode有三台也是为了实现高可用
Standby NameNode不对外提供元数据的访问,它从Active NameNode上拷贝fsimage
文件,从JournalNode上拷贝edits
文件,然后负责合并
fsimage和edits文件,相当于SecondaryNameNode的作用。最终目的是保证Standby NameNode上的元数据信息和Active NameNode上的元数据信息一致,以实现热备份
。
Zookeeper来保证在Active NameNode失效时及时将Standby NameNode修改为Active状态
。
ZKFC(失效检测控制)是Hadoop里的一个Zookeeper客户端,在每一个NameNode节点上都启动一个ZKFC
进程,来监控NameNode的状态,并把NameNode的状态信息汇报给Zookeeper集群,其实就是在Zookeeper上创建了一个Znode
节点,节点里保存了NameNode状态信息
。当NameNode失效后,ZKFC检测到报告给Zookeeper,Zookeeper把对应的Znode删除掉,Standby ZKFC发现没有Active状态的NameNode时,就会用shell命令将自己监控的NameNode改为Active状态,并修改Znode上的数据。
Znode是个临时的节点
,临时节点特征是客户端的连接断了后就会把znode删除
,所以当ZKFC失效时,也会导致切换NameNode。
DataNode会将心跳信息和Block汇报信息同时发给两台NameNode,DataNode
只接受Active
NameNode发来的文件读写操作指令。
HDFS 常用操作命令
新建目录
#在HDFS的/tmp/目录下新建文件夹omcs
hadoop fs -mkdir /tmp/omcs
列出内容
#列出HDFS的/tmp/omcs/目录下所有内容
hadoop fs -ls /tmp/omcs
完整写法:
hadoop fs -ls hdfs://主机名:端口号
hadoop fs -ls hdfs://localhost:9000/tmp
上传文件
#将当前目录下t.txt文件上传到hadoop的hdfs的/tmp/omcs/0277目录下
hadoop fs -put t.txt /tmp/omcs/0277
下载文件
#将hdfs的/tmp/omcs/0277目录下的t.txt文件下载到本地的/home/sflog/dxz/目录
hadoop fs -get /tmp/omcs/0227/t.txt /home/sflog/dxz/t.txt
复制文件
hadoop fs -copyFromLocal ./test.txt /test
hadoop fs -copyToLocal /test/test.txt
查看文件内容
hadoop fs -cat /tmp/omcs/0228
hadoop fs -text /tmp/omcs/0228
删除文件
hadoop fs -rm /tmp/omcs/0228
删除文件夹
hadoop fs -rmr /tmp/omcs/0226
hdfs帮忙文档
hadoop fs --help
查看HDFS的状态
hadoop dfsadmin -report