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 架构模型

hdfs采用了具体的块概念为什么错 hdfs采用什么模型_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数据，同一时间只能有一个写入者

hdfs采用了具体的块概念为什么错 hdfs采用什么模型_元数据_02

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 持久化

hdfs采用了具体的块概念为什么错 hdfs采用什么模型_Hadoop_03

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 文件写流程

hdfs采用了具体的块概念为什么错 hdfs采用什么模型_HDFS_04

  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 文件读流程

hdfs采用了具体的块概念为什么错 hdfs采用什么模型_hadoop_05

  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 架构

hdfs采用了具体的块概念为什么错 hdfs采用什么模型_hadoop_06

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 架构

hdfs采用了具体的块概念为什么错 hdfs采用什么模型_hdfs采用了具体的块概念为什么错_07

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 节点组成联邦，可以互相使用底层存储资源。集群与集群业务不冲突。 弊端：NameNode 节点不能掌握所有元数据，Clinet读取数据需要访问文件写入时的NameNode节点

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

情况二：

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

情况三：

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