文章
22
标签
20
主页
文章总览
标签
分类
友情链接
目录
  1. 1. Hadoop
  2. 2. 初识
    1. 2.1. HDFS
      1. 2.1.1. 核心思想
      2. 2.1.2. 设计目标
      3. 2.1.3. 架构
      4. 2.1.4. 核心设计
        1. 2.1.4.1. 心跳机制
          1. 2.1.4.1.1. HDFS的启动流程：
        2. 2.1.4.2. 安全模式
        3. 2.1.4.3. 副本机制
        4. 2.1.4.4.
      5. 2.1.5. 副本机制
        1. 2.1.5.1. 副本存放策略
        2. 2.1.5.2. 副本分布规则
      6. 2.1.6. 传统文件系统
      7. 2.1.7. 优缺点
      8. 2.1.8. 相关操作
    2. 2.2. YARN
      1. 2.2.1. 产生背景
      2. 2.2.2. 概述
      3. 2.2.3. 架构
      4. 2.2.4. 执行流程
    3. 2.3. MapReduce
      1. 2.3.1. MapReduce模型
      2. 2.3.2. 执行步骤
      3. 2.3.3. 核心功能
      4. 2.3.4. 核心概念
      5. 2.3.5. 1.x
      6. 2.3.6. 分区组件Partitioner
      7. 2.3.7. 排序组件 WritableComparable
      8. 2.3.8. 局部合并组件 Combiner
      9. 2.3.9. 分组组件 group
      10. 2.3.10. Shuffler
        1. 2.3.10.1. Map Shuffler
          1. 2.3.10.1.1. 环形缓冲区
      11. 2.3.11. Reduce Shuffer
  3. 3. 优势
    1. 3.1. 高可靠性
    2. 3.2. 高扩展性
    3. 3.3. 其他
  4. 4. ZooKeeper
    1. 4.1. 概述
    2. 4.2. ZNode (ZooKeeper Node)
      1. 4.2.1. 类型
        1. 4.2.1.1. 持久节点 persistent zNode
        2. 4.2.1.2. 临时节点 ephemeral zNode
        3. 4.2.1.3. 区别
    3. 4.3. 监听机制
    4. 4.4. 功能
    5. 4.5. 集群角色
      1. 4.5.1. Leader 主
      2. 4.5.2. Learner 从
      3. 4.5.3. Client
    6. 4.6. 设计目的/特点
      1. 4.6.1. 数据复制的好处:
        1. 4.6.1.1. 容错
        2. 4.6.1.2. 扩展性
        3. 4.6.1.3. 高性能
      2. 4.6.2. 特点
        1. 4.6.2.1. 最终一致性
        2. 4.6.2.2. 可靠性
        3. 4.6.2.3. 实时性
        4. 4.6.2.4. 等待无关(wait-free)
        5. 4.6.2.5. 原子性
        6. 4.6.2.6. 顺序性
    7. 4.7. 选举Leader
      1. 4.7.1. 全新集群选举
      2. 4.7.2. 非全新集群选举
    8. 4.8. Paxos
Hadoop相关
阅读量:

看了老是忘系列

Hadoop

初识

概念：
狭义：适合大数据分布式存储（HDFS）、分布式计算（MapReduce）和资源调度（YARN）的ing台
广义：Hadoop生态系统，

HDFS

分布式文件系统
来源：GFS的克隆版本
特点：扩展性&容错性&海量数据存储
将文件切分成指定大小的数据块(block)并以多副本的形式存储在多个设备上 默认128M
默认3个备份

核心思想

  1. 分散存储
    一个大文件的存储，借助分布式的存储系统，大文件进而分而治之的存储
  2. 冗余备份
    为保证在低成本设备上的数据安全，采用副本冗余策略

设计目标

巨大的分布式文件系统。

运行在廉价的硬件上

易扩展、性能不错的文件存储服务

架构

主从结构

官方架构

官方架构图

1个Master(NameNode/NN) 带N个Slaves(DataNode/DN)
HDFS/YARN/HBase 基于这种模式

一个文件会拆分成多个Block(存放块大小+副本个数) 通过blocksize (默认128M) 。
例如一个130M 的文件 => 2个Block: 128M + 2M

NN:

  1. 负责客户端的响应 为客服端分配对应的DataNode
  2. 负责元数据(文件名称、副本系数、Block存放DN的地址 = 描述数据的数据)管理、维护元数据
    　　WAL: (Write Ahead Log) 预写日志系统,所有的事务操作都会记录日志
    　　元数据存放位置：
    　　　　metedata: 内存中存放一份完成的原数据信息（目录树结构（文件位置信息） + 文件块映射（文件分成了几个块及对应的block id ） + 数据块和dataNode映射）
    　　磁盘当中: fsimage + edits + edits_inprogress（目录树结构 + 文件块映射）
    　　edits_inprogress会不断的变大 因为存放了相关的操作记录。通过分裂来避免单文件过大, 但是因为文件多过导致加载过慢,所以有了fsimage 将相关的edits日志合并
    　　元数据合并：
    　　　　1. 缩小了操作日志的大小
    　　　　2. 方便nameNode快速的将元数据加载到内存中 　　　　
  3. 主从模式，由于一个NN 需要负责多个DN， 导致NN 能够管理的从节点数量是有限的。

DN:

  1. 存储维护NameNode分配给它的数据块（Block）
  2. 定期向NN 发送心跳, 汇报其本身及其他所有block信息、健康状况
  3. 真正为客户端操作数据提供辅助

SecondeNode:
　　在分布式集群中才会出现

  1. 分担NameNode元数据合并压力, 不要和NameNode在同个节点上

核心设计

心跳机制

HDFS心跳：
　　DataNode 每隔固定的时长，和NameNode通信以证明自己是存活的 （原因DataNode 运行在廉价机器中不可靠）
　　让NameNode 知道当前集群还有多少DataNode存活
　　发包作用：
　　1. 让NameNode识别各个DataNode存活状态
　　2. 心跳包数据
　　　　DataNode自身状态 可在主节点上 使用 hadoop dfsadmin -report 查看各个节点信息
　　　　DataNode节点保存的所有Block信息
　　　　　　例如 file.txt 分成了 blk-001 blk-002 两个块
　　　　　　心跳包中会上送告诉NameNode blk-001: hadoop01,hadoop02 blk-002:hadoop02,hadoop03
　　　　超时标准：timeout(超时时长) = 10 * 心跳时长（dfs.heartbeat.intercal = 3s） + 2 * 检查心跳机制是否正常的时间(heartbeat.recheck.intercal = 300s) = 630s

HDFS的启动流程：
1、先启动namenode进程
2、加载namenode存储的磁盘的元数据信息
3、namenode在启动之后，会在自己的节点启动一个服务，这个服务：等待所有的datanode的上线和汇报他们的数据块的内容。
4、datanode一旦上线，就通过心跳机制进行汇报。
5、只有当namenode等到了所有的datanode的上线以及把所有的块信息都汇报完毕，最后namenode才能得知整个集群中文件的数据块的副本的存放状况

安全模式

进入安全模式：
1. 当HDFS集群的部分datanode节点宕机之后，HDFS启动一些服务，做自我恢复
2. 当丢失的数据达到0.1%比例的时候会进入安全模式 

命令：
    hdfs dfsadmin -safemode enter //进去安全模式
    hdfs dfsadmin -safemode leave //离开安全模式
    hdfs dfsadmin -safemode get //查看安全模式
    hdfs dfsadmin -safemode wait //等待

副本机制

定义：决定一个数据块的多个副本（默认是3）到底是应该选取哪些服务器节点进行存储
策略：
1、第一个副本块选取和客户端相同的节点上
2、第二个副本块选取跟第一副本的存储节点相邻机架上的任意一个节点
3、第三个副本块在和第二个副本块所在机架不同的节点上 

实际：选取不忙的节点。

副本机制

因为HDFS可以采用廉价设备导致有数据丢失的可能所以需要有效的副本机制
官方架构图

副本存放策略

鸡蛋不要都放在一个篮子里
多副本

副本分布规则

  1. 数据备份数量由客户端指定
    如果集群有3个节点，但是数据需要存放4份，最后系统只能存放3份。
  2. 同个文件备份不放在一个节点中暨HDFS集群中的任何节点, 没有完全相同的两份数据。

传统文件系统

A.0.5T B.20G C.50G D.1T

1号盘存A

2号盘存A B

3号盘存A B C

4号盘存A B C D

5号盘存B C D

6号盘存C D

7号盘存D

这种方式类似 Raid1

缺点：

  1. 不管文件多大都存在一个节点上, 在进行数据处理的时候很难并行处理。
  2. 存储负载不容易均衡,导致节点利用率比较低

优缺点

  1. 优点：
    数据冗余备份、硬件容错
    适合存储大文件
    处理流式的数据访问
    可构架在廉价的设备上
  2. 缺点
    低延迟的数据访问
    不适合小文件存储 文件元数据存在NN 中，小文件多元数据也很多那NN 内存占用大压力大
    单点故障问题：高可用集群方案（ZooKeeper）
    内存受限：联邦集群

相关操作

其实和Linux 中的文件操作比较类似
hadoop fs ***
可以直接通过 hadoop fs 查看相关命令
比如 hadoop fs -cat /test.txt = cat /test.txt

YARN

资源调度系统
特点：扩展性&容错性&多框架资源统一调度
负责集群资源的管理和调度

产生背景

MapRduce1.x 单节点故障+单节点压力大不容易扩展(JobTracker任务重压力大)+不能够支持MapReduce外的框架引擎

资源利用率&运维成本

YARN:
不同的计算框架可以共享同一个HDFS集群上的数据，享受整体的资源调度
XXX on YARN
XXX : Spark/MapReduce/Storm/Flink
好处： 与其他计算框架共享集群资源，按资源需要分配,进而提高集群资源的利用率

概述

Yet Another Resoutce Negotiator  
通用的资源管理系统  
为上层应用提供同意的资源管理和调度

架构

官方架构图

  1. ResourceManager -> RM
    一个RM 带多个NM
    整个集群同一时间提供服务的RM只有一个，负责集群资源的统一管理和调度
    处理客户端的请求：提交一个作业、杀死一个作业
    监控NM 一旦某个NM挂了， 那么该NM上运行的任务需要告诉AM来如何处理
    调度器（Schedule）常见的有： 

     FIFO                先进先出(First in First out)  
 Fair Schedule       公平调度(各个任务平分资源 不管任务大小)  
 Capacity Schedule   容量调度(任务调度分配)

  2. NodeManager -> NM
    整个集群中有多个， 负责本身节点资源管理和使用。
    定时汇报向RM 汇报本节点的资源使用情况
    接手并处理来自RM 的各种命令：启动Container
    处理来自AM的命令
    单个节点的资管管理

  3. ApplicationMater -> AM
    每个应用程序（MR、Spark）对应一个,负责应用程序的管理
    为应用程序向RM 申请资源（core、memory）, 分配个内部task
    需要与NM通信：启动/停止task， task是运行在container里面，AM也是运行在container里面

  4. Container
    封装了CPU、Memory等资源的容器
    是一个任务运行环境的抽象

  5. Client
    提交作业
    查询作业的运行进度
    杀死作业

执行流程

Client 提交作业 -> RM 为作业分配第一个Container(运行在一个 A NM) -> RM 与 NM 通信 要求在这个NM 启动一个container 用于启动AM -> AM 与RM 进行注册 （保持通信） 进行资源申请（RM） 汇报状态 -> 在对应的NM 启动任务

MapReduce

分布式计算框架/编程模型

特点：扩展性&容错性&海量数据离线处理
缺点：无法实时流计算

MapReduce模型

任务的并发 + 结果的汇总
将作业拆分为Map阶段(并发)和Reduce阶段(汇总)  
Map阶段: 一堆的Map Tasks  
Reduce阶段: 一堆的Reduce Tasks  
每个任务都有个主调度程序MRAppMaster (MapReduct Application Master)

执行步骤

  1. 准备Map处理的输入数据
  2. Mapper处理
  3. Shuffle 汇总清洗数据(将相同的key 发送到相同到节点中) 包含分区、排序、局部合并、分组
  4. Reduce处理
  5. 结果输出

核心功能

将用户编写的业务逻辑代码和自带默认组件整合成一个完整的分布 式运算程序，并发运行在一个 Hadoop 集群上。

核心概念

  1. Split: 交由MapReduce作业来处理的数据块 （与HDFS的BlockSize的区别 是HDFS 最小的存储单元）, 是MapReduce的最小计算单元. 默认与HDFS的BlockSize一一对应
  2. InputFormat: 将输入数据进行分片(Split)
  3. OutputFormat: 将分片处理后的数据合并输出

1.x

2.x开始 这部分功能迁移到YARN中处理

  1. JobTracker: (管理者)
    　　负责资源管理和作业调度
    　　将作业分解为一堆任务:Task (MapTask和ReduceTask)
    　　将任务分派给TaskTracker运行
    　　作业的监控、容错处理
    　　在一定的时间间隔内, JT没有收到TT的心跳消息, TT可能挂了, TT上运行的任务会被JT 指派到其他TT上执行
  2. TaskTracker：(干活的)
    　　定期向JT汇报本节点的健康状况、资源使用情况、作业执行情况；
    　　接收来自JT的命令：启动任务、杀死任务
    　　在TT上执行Task(MapTask、ReduceTask)
    　　与JT 交互信息: 执行、停止、启动, 发送心跳信息给JT。
    、

分区组件Partitioner

根据单词的长度给单词出现的次数的结果存储到不同文件中，以便于在快速查询

排序组件 WritableComparable

序列化 (Serialization) :结构化对象转化为字节流      
反序列化 (Deserialization):把字节流转为结构化对象。  
Java 的序列化是一个重量级序列化框架(Serializable)，一个对象被序列化后，会附带很多额 外 的信息(各种校验信息，header，继承体系等)，不便于在网络中高效传输;所以，hadoop 自己开发 了一套序列化机制(Writable)，更加精简高效。

Writable 有一个子接口是 WritableComparable，WritableComparable 是既可实现序列化， 也可以对key进行比较，我们这里可以通过自定义 Key 实现 WritableComparable 来实现我们的排序功 能。

局部合并组件 Combiner

Combiner 是 MapReduce 程序中 Mapper 和 Reducer 之外的一种组件，它的作用是在 maptask 之后给 maptask 的结果进行局部汇总，以减轻 reducetask 的计算负载，减少网络传输
写法类似Reducer

分组组件 group

* 实现分组有固定的步骤：
     * 1、继承WritableComparator
     * 2、调用父类的构造器
     * 3、指定分组的规则，重写一个方法

Shuffler

数据汇洗,将 maptask 输出的处理结果数据，分发给 reducetask。
map 阶段处理的数据如何传递给 reduce 阶段，是 MapReduce 框架中最关键的一个流程，这个流程就叫 Shuffle

Map Shuffler

Mapper 阶段的数据进行分区，做完了分区之后 每个ReduceTask 只需要取对应分区编号的数据(ReduceTask怎么知道要取哪个分区的)
mapper context.write 会将写入的数据放到 环形缓冲区 中
环形缓冲区
内存中一种收尾相连的数据结构(内存区域)，用于存放mapper中处理的数据, 每个MapTask独立使用一个环形缓冲区在MapTask初始化时创建(对数据进行分析分区)。
主要维护了一个 kvbuffer的字节数组 默认100m
>100m 了触发溢写: 内存中数据超过100m 后会将数据持久化到硬盘中
溢写流程：
    1. 初始化的时候对数据分区
    2. 分区前排序 快排
    3. 如果设置了Combiner 会先调用Combiner进行合并 减少数据量

Reduce Shuffer

主动读取Map Shuffler后的数据

优势

高可靠性

  1. 数据存储：数据块多副本
  2. 数据计算：重新调度作业计算

    高扩展性

  3. 存储、计算资源不够时，可以横向的限行扩展机器
  4. 一个集群中可以包含数以千计的节点

    其他

  5. 存储在链家机器上，降低成本
  6. 成熟的生态圈

ZooKeeper

概述

分布式应用程序协调服务  
用来解决分布式系统中一些业务协调问题

基于Google的 Chubby 分布式锁
底层算法Paxos

ZNode (ZooKeeper Node)

可用于存储数据(key-value的形式 key:节点的绝对路径 value:该节点值)、也能挂载子节点
只能存储小量数据 (1M)

类型

不管什么节点都会创建会话 session

持久节点 persistent zNode

1. 带顺序编号的持久节点 (create -s xxxx)
2. 不带顺序编号的持久节点 (create xxxx)

临时节点 ephemeral zNode

1. 带顺序编号的临时节点
2. 不带顺序编号的临时节点

区别

临时节点删除随着session断开而自动删除
临时节点下面不能有其他子节点(因为上一点 节点删除时间未知的。)

监听机制

client对哪个节点感兴趣对哪个节点注册一个监听、改节点有数据变化时通知client  
组成  
1. client
2. client WatcherManageer
3. ZooKeeper服务器

功能

  1. 命名服务

  2. 配置管理

  3. 集群管理

  4. 分布式锁

  5. 队列管理

集群角色

Leader 主

集群主节点  
负责投票的发起和决议,更新系统状态。其他节点写入操作的时候会通过Leader发起请求

Learner 从

Follower: 跟随者
    普通节点
    用于接受客户端请求和返回客户端请求结果，参与选主投票  
Observer: 观察者
    Observer可以接受客户端（Client）连接，并将客户端请求转发给Leader,不参与选主投票,只同步Leader状态,其主要作用为了扩展系统,提高读取速度(ZooKeeper压力过大时想临时添加节点用于负载峰值过后可撤走 这时候的节点就可以是 Observer节点 因为没有选举权和被选举券不会变成Leader节点所以能随时撤走)

Client

发起相关请求

设计目的/特点

ZooKeeper 作为一个集群提供数据一致的协调服务，自然，最好的方式就是在整个集群中的各服务节

点进行数据的复制和同步

数据复制的好处:

容错

一个节点出错，不至于让整个集群无法提供服务。

扩展性

通过增加服务器节点能提高 ZooKeeper 系统的负载能力，把负载分布到多个节点上。

高性能

客户端可访问本地 ZooKeeper 节点或者访问就近的节点，依次提高用户的访问速度。

特点

最终一致性

client 不论连接到哪个 Server，展示给它都是同一个ZNode视图，这是 ZooKeeper 最重要 的性能。

可靠性

具有简单、健壮、良好的性能，如果消息 m 被到一台服务器接受，那么它将被所有的服务 器接受。

实时性

ZooKeeper 保证客户端将在一个时间间隔范围内获得服务器的更新信息，或者 服务器失 效的信息。但由于网络延时等原因，ZooKeeper 不能保证两个客户端能同时得到刚更新的数据，如果 需要最新数据，应该在读数据之前调用 sync()接口。

等待无关(wait-free)

慢的或者失效的 client 不得干预快速的 client 的请求，使得每个 client 都 能有效的等待

原子性

更新只能成功或者失败，没有中间状态。

顺序性

包括全局有序和偏序两种:全局有序是指如果在一台服务器上消息 a 在消息 b 前发布，则 在所有 Server 上消息 a 都将在消息 b 前被发布;偏序是指如果一个消息 b 在 消息 a 后被同一个发送者 发布，a 必将排在 b 前面。

选举Leader

全新集群选举

serverId （就是配置里面的 myid 0-255 权威指南里面说1-255 但是0 实际过程中也能用） 
serverId 大的就是Leader

非全新集群选举

根据 数据版本、全局时钟、serverId 三个因素决定  
优先级：数据版本 > 全局时钟 > serverId
集群中超过半数同意,就能选举出Leader 所以建议节点数是奇数 不会出现平票

Paxos

一种基于消息传递且具有高度容错性的一致性算法
文章作者: Fibonacci
文章链接: http://sovwcwsfm.com/blog/page/hadoop.html
版权声明: 本博客所有文章除特别声明外，均采用 CC BY-NC-SA 4.0 许可协议。转载请注明来自 Blog！
Hadoop 大数据
相关推荐
Flume相关
HBase相关
Hive相关
Kafka相关
Spark相关
数仓相关
繁