1. hadoop基本介绍、HDFS架构模型、原理解析

hadoop介绍

官方网站: http://hadoop.apache.org/

官方网站(老版本): https://hadoop.apache.org/old/

hadoop基于分布式的存储(HDFS)计算(MapReduce)的开源框架数。

hadoop 基于lucene(倒排索引)框架 。小知识点: 第一个分布式搜索开源框架 nutch

技术思想

Google一篇论文: Openstack NASA 数据切分为块,分布到集群中,计算向数据移动计算。

Google三大理论:

  • GFS (Google File System)
  • Map-Reduce
  • Bigtable

HDFS 架构模型

1. hadoop基本介绍、HDFS架构模型、原理解析

HDFS 1.x 采用了主从架构模型,下面是hdfs主从架构角色说明

  • NameNode : 主节点 负责接收客户端读写服务,收集DataNode中文件Block元数据(MateData)
  • DataNode : 从节点 负责保存维护文件数据(切分后的block块)
  • HdfsClient : 客户端 负责读取操作数据文件.HdfsClient与NameNode交互获取文件元数据信息,再通过元数据信息与DataNode交互操作Block数据
  • SecondaryNameNode(HDFS1.x 架构) : 该节点主要工作是帮助NameNode合并editslog,减少NameNode启动时间。(不是NameNode的备份,也可以作为备份)

Block 存储模型

HDFS 分布式文件存储系统,会把文件切割成(Block) 块,分散在集群hdfs节点中,单一文件bolck 块大小一致 (除最后一个bolck),文件与文件可以不一致,block块可以设置副本数,副本数无序分布在不同节点中(副本数不超过节点数量)。

存储方式: 字节存储(二进制)

HDFS 2.x 默认Block大小128M 文件上传时可以指定block大小,最小设置1M。Block **默认副本数为3,**副本数可以调整。

HDFS 只支持一次写入多次读取,可以append数据,同一时间只能有一个写入者

1. hadoop基本介绍、HDFS架构模型、原理解析

MateData 存储信息

MateData存储信息包括

  • 文件owership(所有者)和permissions(权限)
  • 文件大小,时间等信息
  • Bolck 列表、Bolck偏移量 ,Bolck 位置信息(持久化时候不会存储
  • Bolck(包括副本)位置信息由DataNode上报到NameData
  • md5验证信息

NameNode持久化

NameNode 基于内存存储MateData等相关数据,不会和磁盘发生数据交换。由于NameBode 基于内存存储属,为数据安全性会进行持久化操作。

Hadoop采用了2种持久化方式配合完成:

  • 磁盘镜像快照(file system image):通过时点备份, 文件名为 fsimage。特点:序列化操作慢,反序列化操作较快
  • 日志方式(edits log):把客户端对MateData每条操作指令写入操作日志。特点:写入日志较快,恢复操作需要执行所有操作命令,所以速度慢。

HDFS 1.x 持久化

1. hadoop基本介绍、HDFS架构模型、原理解析

HDFS 1.x 通过SecondaryNameNode角色完成NameNode持久化

  1. NameNode 第一次启动产生一个空的 edits 和 fsimage 文件
  2. 客户端发送操作指令由edits 记录,当edits 文件达到所设置的文件大小时或达到一定时间时触发合并
  3. 此时NameNode会把edits 和fsimage 发送到 SecondaryNameNode中 进行合并操作。同时会创建新的edits.new(清空edits) 继续记录客户端操作
  4. SecondaryNameNode拿到 edits和fsimage会合并成fsimage.ckpt返还给NameNode(可以理解为覆盖原有fsimage),循环执行上述操作
  5. 当服务器重启,启动hadoop时,会先对fsimage 反序列化,再执行edits中的操作

相关配置参数:

  • 根据配置文件设置的时间间隔fs.checkpoint.period 默认3600秒

  • 根据配置文件设置edits log大小 fs.checkpoint.size 规定edits文件的最大值默认是64MB

Hadoop 1.x 中的不足

HDFS 1.0 HDFS和MapReduce 在高可用、扩展性方面存在不足

  • NameNode的单点故障(SecondaryNameNode 只做到了日志合并工作,没有解决NameNode 单点故障问题),单点瓶颈问题。

  • MapReduce JobTracker访问压力大,影响系统扩展性。不能支持其他计算框架,比如spark、Strom等

DataNode

  • 基于本地文件系统以文件的形式存储Block
  • DataNode 也会维护一份Block元数据信息 主要保存文件完整性验证码(md5),用于保障文件的完整性
  • 启动DataNode 时会向NameNode 汇报一次Block 信息
  • DataNode会向NameNode发送心跳(默认每隔3秒),若NameNode超过10分钟没有收到DataNode发送的心跳信息,则认为改节点已lost,会copy其他节点中该DataNode节点的Block备份到其他DataNode(保证副本数量)

HDFS 文件写流程

1. hadoop基本介绍、HDFS架构模型、原理解析

  1. Client 发送上传文件命令
  2. NameNode根据上传指令创建Block块以及副本的位置路径元信息 ,并将第一个Block位置信息发送给Clent
  3. Client 切割文件生成block 依据NameNode Block位置路径信息上传到DataNode(block上传时会再次切分为KB级(64k)的小块通过管道的方式流式传输,每个Block只选择位置信息中的第一个DataNode传输)
  4. 当block传输完毕,DataNode会发送当前Blcok传输完成的消息给Client,并向NameNode汇报该Block信息。
  5. Clinet向NameNode汇报该Blcok传输完成信息,等待NameNode返回下一个Blcok的位置信息重复上述操作,直至所有Blcok传输完成,Client汇报完成
  6. DataNode 会通过NameNode中Block位置信息(Blcok或Blcok副本位置信息)通过流式传输的方式把Block传到其他DataNode上

流式传输举例 : NN1 与 NN2 建立管道,NN2与NN3 建立管道,NN1 收到64K 数据保存并发送NN2,NN2收到后保存并发送给NN3 。

HDFS 文件读流程

1. hadoop基本介绍、HDFS架构模型、原理解析

  1. Client 从 NameNode获知文件Block位置信息
  2. Client 根据位置信息根据系统资源或就近原则选择Block或Block副本线性读取Blcok,最终合并为一个文件(读取过程中验证Block MD5完成性)

安全模式

  • namenode启动的时候,首先将映像文件(fsimage)载入内存,并执行编辑日志(edits)中的各项操作。
  • 一旦在内存中成功建立文件系统元数据的映射,则创建一个新的fsimage文件(这个操作不需要SecondaryNameNode)和一个空的编辑日志。
  • 此时namenode运行在安全模式。即namenode的文件系统对于客户端来说是只读的。(显示目录,显示文件内容等。写、删除、重命名都会失败,尚未获取动态信息)。
  • 在此阶段Namenode收集各个datanode的报告,当数据块达到最小副本数以上时,会被认为是“安全”的, 在一定比例(可设置)的数据块被确定为“安全”后,再过若干时间,安全模式结束
  • 当检测到副本数不足的数据块时,该块会被复制直到达到最小副本数,系统中数据块的位置并不是由namenode维护的,而是以块列表形式存储在datanode中。

HDFS文件权限

采用POSIX标准(可移植操作系统接口)

  • 与Linux文件权限类似

    r: read; w:write; x:execute

    权限x对于文件忽略,对于文件夹表示是否允许访问其内容

  • 如果Linux系统用户zhangsan使用hadoop命令创建一个文件,那么这个文件在HDFS中owner就是zhangsan。

  • HDFS的权限目的:阻止误操作,但不绝对。(HDFS相信,你告诉我你是谁,我就认为你是谁)

HDFS优点

  • 高容错性

    数据自动保存多个副本,副本丢失后,自动恢复。

  • 适合批处理

    移动计算而非数据移动

    数据位置暴露给计算框架**(Block偏移量)**

  • 适合大数据处理
    GB 、TB 、甚至PB 级数据、百万规模以上的文件数量(单节点block大小要求10K+)

  • 可构建在廉价机器上
    通过多副本提高可靠性、提供了容错和恢复机制

HDFS缺点

  • 低延迟数据访问

    无法做到毫秒级低延迟(hdfs分钟级别)、对吞吐率有要求(block不能低于1m)

  • 小文件存取
    小文件存储过多会造成NameNode大量内存占用、元数据过多寻道时间超过读取时间

  • 并发写入、文件随机修改
    一个文件只能有一个写者,仅支持append

Hadoop 2.x 架构

1. hadoop基本介绍、HDFS架构模型、原理解析

Hadoop 2.x由HDFS、MapReduce和YARN三个分支构成;

  • HDFS:NN Federation(联邦)、HA;2.X:只支持2个节点HA,3.0实现了一主多从
  • MapReduce:运行在YARN上的MR;离线计算,基于磁盘I/O计算
  • YARN:资源管理系统

Hadoop 2.x仅是架构上发生了变化,使用方式不变

HDFS 2.x 架构

1. hadoop基本介绍、HDFS架构模型、原理解析

NameNode

  • 节点中有多个(hdfs2.x 2个 3.x 支持多个)NameNode 中由一个Active状态 和一个或多个 Standby 状态节点 ,处于Active状态的NameNode对外提供服务,Standby状态的NameNode为Active状态NameNode的备,起到了高可用(HA)的作用

  • Standby 状态的NameNode 取代了SecondaryNameNode 的工作,对进行edits 和SImage 进行合并工作并推送回Active NameNode

JN(JournalNode):

  • 负责储存静态元数据信息(edits 操作日志,不包括Block信息,Block动态元数据信息由DataName实时汇报),用于同步Active 和 Standby状态NameNode节点信息

  • JournalNode 使用3台以上服务器实现高可用。JN之间采用弱一致性(过半机制)确认edits 是否成功上传。

DN(DataName): 作用与上述 DataName 一致。但在汇报block块信息时会向所有NameNode节点进行汇报。

ZK (Zookeeper): 使用ZK分部式协调系统实现NameNode 主备间切换

FalloverController (ZKFC)

  • FalloverController 故障控制转移物理进程(ZKFC)即Zookeeper客户端,负责检测NameNode健康状态,当Active健康状态异常则进行切换操作

  • 当Hadoop 集群启动时先注册到Zookeeper的NameNode 为Active 状态

  • 当处于Active 状态的NameNode 节点发生异常时,Zookeeper会通过投票选举机制来决定哪个 Standby 状态的NameNode节点切换为Active 状态对外提供服务

联邦 federation

为 hadoop 解决了横向扩展能力

情况一:

2组Hadoop集群中的 NameNode 节点组成联邦,可以互相使用底层存储资源。集群与集群业务不冲突。

情况二:

1组集群搭建了一组Hadoop集群 ,在集群中添加独立的NameNode共享集群中DataNode节点,达到底层存储资源共享

情况三:

1组集群 DataNode 服务器数量庞大 NameNode 维护元数据造成内存满载,此时可增加一台NameNode节点 与集群中NameNode组成联邦联合并行

弊端:NameNode 节点不能掌握所有元数据,Clinet读取数据需要访问文件写入时的NameNode节点

解决方案:NameNode 上层提供服务平台接口对操作进行分类,Client访问平台接口,获取数据所在NameNode节点地址