Hadoop-HDFS、MapReduce、YARN

分布式文件存储HDFS

存储模型：字节

• 文件按照字节切割成块（block）默认128MB，最小1M（可修改），每个 block 块有偏移量 offset，block块分散存储在集群结点中。横向扩展
• 同一文件的block块大小相同，不同文件的block块大小可以不同。

• block块可以设置副本，默认三个副本（可修改）。纵向扩展

  • 副本放置策略：

    • 第一个副本：放在上传文件的DataNode
    • 第二个副本：放在与第一个副本不同的机架的节点上
    • 第三个副本：放在与第二个副本相同机架的其他节点上
    • 更多副本：随机节点
• 只支持一次写入多次读取，不可修改块内容，
• 可以append追加数据，同一时刻只有一个写入者

架构模型1.x：主从

NameNode（主结点）：

• 管理文件的元数据信息（MetaData）：block块大小，offset偏移量等等
• 接收客户端的读写服务
• 基于内存存储（不会和磁盘发生交换）
• 收级DataNode汇报的block列表

DataNode（从结点）：

• 负责维护管理放在本节点的block块的元数据信息（MD5：保证数据完整性）
• 与NameNode保持心跳，并向NameNode汇报block块信息

NameNode持久化：

• fsimage（时点备份）：metadata存储到磁盘文件的名字
• EditsLog：记录对metedata的操作
• fsimage和editsLog 在达到一定条件（check point）会进行合并，形成一个新的fsimage

SecondaryNameNode（SNN）

• 它不是NameNode的备份（但是可以做备份）它的主要工作是帮助NN合并editsLog和fsimage
• SNN合并流程

HDFS优点：

• 高容错性

  • 数据自动保存多个副本
  • 副本丢失后自动恢复（从良好节点上拷贝）

• 适合批处理

  • 计算向数据移动
  • 数据位置（offset）暴露给计算框架

• 适合大数据处理

  • GB、TB、PB、百万规模文件
• 可构建在廉价机器上

HDFS写流程：

HDFS读流程：

Hadoop2.x

产生背景

• Hadoop1.x中HDFS和MapReduce存在高可用、扩展性的问题

• HDFS问题

  • NameNode单点故障。通过主备NameNode解决（HA）
  • NameNode压力过大，联邦Federation

架构模型2.x

• Hadoop 2.x 由HDFS，MapReduce和Yarn三个分支组成

  • HDFS 2.x:只支持2个节点HA ，3.x支持一主多备

分布式计算MapReduce

MR原语：map + reduce

• map数量由什么确定？

  • map --- split 与split片数量一一对应
  • block块是真正被切割开的物理块，
  • split片是在block块基础上再切割的逻辑片，由block块决定
  • 一个job作业中map数量与split片数量有关
• map 拿到数据后进行中间集映射(K，V)，同时生成分区partition编号

• reduce数量由什么决定？

  • 常规：一个 K 对应一个 reduce
  • 也可以把多个 K 对应到一个 reduce，但是不能把一个 K 对应多个 reduce（相同的 K 必须交给同一个 reduce）

• 先获取split片，交给map（默认split片大小 == block块大小，128M）

• map映射成（K,V）中间集后，先将数据写入内存缓冲区buffer in memory

  • 一次排序：在缓冲区中按照分区partition（有几个reduce就有几个分区partition）进行排序，相同分区的数据放在一起
  • 二次排序：分区内按照K 进行排序，相同的K 放到一起（一个reduce可能对应多个K）
  • 数据压缩combiner ：在map端进行一次迭代计算后再发送给reduce 减少reduce计算量

• 内存缓冲区写满后，先译写成小文件存到磁盘，当map数据处理完之后会形成一堆小文件，

  • 三次排序：众多小文件还要进行排序，并合并成大文件
  • 四次排序：众多map产生的大文件再进行排序，合并成更大的文件
  • 最后合并成的更大的文件交给reduce处理

分布式资源管理YARN

MRv1角色

• JobTracker

  • 核心，主，单点
  • 调度所有作业
  • 监控整个集群的资源负载

• TaskTracker

  • 从，自身节点资源管理
  • 和JobTracker心跳，汇报资源，主动获取Task

• Client

  • 作业为单位
  • 规划作业计算分布
  • 提交作业资源到HDFS
  • 最终作业提交到JobTracker

弊端

• JobTracker：负载过重，单点故障
• 资源管理与计算调度强耦合，其他计算框架需要重复实现资源管理
• 不同框架对资源不能全局管理

YARN

• 客户端client将任务提交给ResourceManager（资源的完全掌控者，长服务）
• ResourceManager找一台资源空闲的服务器启动一个进程：ApplicationMaster（任务调度者，短服务）
• ApplicationMaster不了解集群资源，需要向ResourceManager申请任务资源
• ApplicationMaster找到对应节点启动创建容器Container
• NodeManager（长服务）向ResourceManager汇报Container信息和节点资源情况

MRv2 On YARN

• Yarn：解耦资源与计算

  • ResourceManager

    • 主，核心
    • 集群节点资源管理

  • NodeManager

    • 与ResourceManager汇报资源
    • 管理Container生命周期

• MR

  • MR-ApplicationMaster-Container

    • 作业为单位，分配到不同节点，避免单点故障
    • 创建Task需要向ResourceManager申请资源
  • Task-Container

YARN : Yet Another Resource Negotiater

• 核心思想：将JobTracker和资源管理和任务调度两个功能分开。分别由ResourceManager和ApplicationMaster进程实现。
• ResourceManager：负责整个集群的资源管理
• ApplicationMaster：负责应用程序的任务调度，任务监控

• YARN的引入，使得多个计算框架可运行在一个集群中

  • MapReduce,Spark,Strom
  • 每个应用程序对应一个ApplicationMaster