大数据课程记录


HDFS体系架构

Hadoop1.0中的HDFS采用了主从模型,一个HDFS集群是由一个NameNode和多个DataNode组成。其中NameNode作为主,管理FileSystem的NameSpace和客户端对文件的访问操作;DataNode则是管理存储的数据。HDFS允许用户以文件的形式存储数据,从内部来看,文件被分成若干个data block,而且这些data block存放在一组DataNode上。
Hadoop2.0中的HDFS在Hadoop1.0的基础上增加了高可用性和联邦机制:
在一个集群中,一般设置两个NameNode,其中一个处于Active状态,另一个处于Standby状态。处于Active状态的NameNode负责对外处理所有Client请求;处于Standby状态的NameNode作为热备份节点,当Active状态的节点故障时,立即切换到Active状态并对外提供服务。Active状态节点的状态信息会实时同步到Standby状态节点。状态同步通过共享存储系统来实现,Standby状态节点会一直监听该系统,一旦发现有更新的状态信息写入,就立即从共享存储系统中读取这些状态信息,从而保证与Active节点状态的一-致性。此外,为了实现故障时的快速切换,必须保证Standby节点中也包含最新的块映射信息,为此需要给DataNode配置Active节点和Standby节点两个地址,把block的位置和Heartbeat同时发送到两个节点上。另外,通过ZooKeeper来监测两个元数据节点的状态,确保任何时刻只有一个节点处于Active状态。

HDFS读操作

首先Client要与NameNode建立TCP连接并发起读取文件的请求,然后NameNode根据用户请求返回相应的Block信息,最后Client再向对应Block所在的DataNode发送请求并取回所需要的数据块。HDFS读取文件流程为首先初始化FileSystem,客户端调用FileSystem的open函数打开文件,然后FileSystem通过RPC调用NameNode并得到文件的数据块与DataNode信息。FileSystem返回FSDatalnputStream给客户端,客户端调用FSDatalnputStream的read函数,选择最近的DataNode建立连接并读取数据。当一个数据块读取完毕时,FSDataInputStream关闭和此DataNode的连接,然后连接离下一个数据块最近的DataNode。当客户端读完全部数据块后,调用FSDataInputStream的close函数,关闭输入流,完成对HDFS文件的读操作。在读取数据块的过程中,如果客户端与数据节点的通信出现错误,则尝试连接包含此数据块的下一个数据节点,失败的数据节点将被记录,以后不再连接。

HDFS写操作

首先client与NameNode建立TCP连接,并发起写入文件请求,然后跟NameNode确认可以写文件并获得相应的DataNode信息,最后客户端按顺序逐个将数据块传递给相应的DataNode,并由接收到数据块的DataNode负责向其他DataNode复制数据块的副本。HDFS写入文件流程为首先初始化FileSystem,客户端调用FileSystem的create函数来创建文件。然后FileSystem通过RPC调用NameNode,在文件系统的Namespace中创建一个文件条目,NameNode首先确定文件是否已存在以及客户端的操作权限,创建成功后返回文件的相关信息。FileSystem返回FSDataOutputStream给客户端并开始写入数据。FSDataOutputStream将文件分成数据块后写人数据队列,数据队列由Data Streamer读取并通知NameNode分配DataNode,用来存储数据块,其中分配的数据节点放在一个管道里。 Data Streamer将数据块写入管道中的第一个数据节点,第一个数据节点将数据块发送给第二个数据节点,第二个数据节点将数据发送给第三个数据节点。 FSDataOutputStream为发出去的数据块保存了确认队列,等待管道中的DataNode告知数据块已经写入成功。当管道中的DataNode都表示已经收到的时候,确认队列会把对应的数据块移除。当客户端完成写数据后,则调用FSDataOutputStream的close函数,此时客户端将不会向流中写入数据,当所有确认队列返回成功后通知NameNode写入完毕。如果DataNode在写入的过程中失败,则关闭管道,已经发送到管道但是没有收到确认的数据块都会被重新放入数据队列中。随后联系 NameNode,给失败节点上未完成的数据块生成一个新的标识,失败节点重启后察觉该数据块是过时的会将其删除。失败的数据节点从管道中移除,另外的数据块则写入管道中的另外两个DataNode,NameNode会被通知此数据块复制块数不足,然后再安排创建第三份备份。

HBase的预写日志机制

借助HDFS+WAL机制保证数据可靠性 •

  • 为了防止Region服务器发生故障时,MemStore 缓存中还没有被写入文件的数据会全部丢失,HBase 采用 HLog 来保证系统发生故障时能够 恢复到正常的状态
  • 每个 Region 服务器都有一个 HLog 文件,同一个 Region 服务器的 Region 对象共用一个 HLog,HLog 是一种预写日志(Write Ahead Log) 文件
  • 用户更新数据必须先被记入日志后 才能写入 MemStore 缓存,当缓存内容对应的日志已经被写入磁盘后, 即日志写成功后,缓存的内容才会被写入磁盘
  • ZooKeeper 会实时监测每个 Region 服务器的状态,当某个 Region 服务器 发生故障时,ZooKeeper 会通知 Master,Master 首先会处理该故障 Region 服务器上遗留的 HLog 文件
  • 由于一个 Region 服务器上可能会维护着多个 Region 对象,这些 Region 对象共用一个 HLog 文件,因此这个遗留的 HLog 文件中包含了来自多个 Region 对象的日志记录。
  • 系统会根据每条日志记录所属的 Region 对象对 HLog 数据进行拆分,并分 别存放到相应 Region 对象的目录下。
  • 再将失效的 Region 重新分配到可用的 Region 服务器中,并在可用的 Region 服务器中重新进行日志记录中的各种操作, 把日志记录中的数据写 入 MemStore 然后刷新到磁盘的 StoreFile 文件中,完成数据恢复。

HBASE物理存储模型

HBase采用Master/Slave架构搭建集群

  • 主节点HMaster(为了HA高可用性,也会部署多个 Master节点,其中一个为active节点,其他standby节 点),管理节点,负责对HRegionServer的数据范围进 行分配
  • 若干个从节点HRegionServer,用户数据实际存储和管理节点,负责数据的写入、查询、缓存和故障恢复
  • ZooKeeper集群:HBase借助Zookeeper集群来实现节 点监控和容错
  • HDFS:数据最终以文件形式存在HDFS上,涉及到HDFS 的NameNode、DataNode

Client:

  • 是HBase功能的使用者,HBase Client使用HBase的RPC机制与HMaster和HRegionServer进行通信
  • 对于管理类操作,Client与HMaster进行RPC
  • 对于数据读写类操作,Client与HRegionServer进行RPC

Zookeeper:

  • 是HBase体系中的协同管理节点,提供分布式协作,分布式同步,配置管理等功能
  • ZookeeperQuorum中存储的信息包括:
  • 存储-ROOT-表的地址:/hbase/root-region-server
  • 存储HMaster的地址:/hbase/master
  • 存储所有HRegionServer的状态:HRegionServer会把自己以短暂的方式注册到 Zookeeper 中:/hbase/rs

HMaster:

  • 是整个框架中的控制节点, 负责:

  • 管理用户对table的增、删、改、 查操作

  • 管理HRegionServer的负载均 衡,调整region分布

  • 在region split后,负责新region的分配

  • 在HRegionServer停机后,负责失效HRegionServer上的 region迁移

  • HDFS的垃圾文件回收

  • 处理schema更新请求

  • HBase中可以启动多个HMaster, 通过Zookeeper的Master Election机制保证总有一个HMaster运行

HRegionServer:

  • 负责维护HMaster分配给它的region, 响应用户I/O请求,向HDFS文件系统中读写数据
  • HRegionServer内部管理了一系列HRegion对象
  • HRegion:一个HRegion可以包含多个Store
  • Store:每个Store包含一个Memstore和若干个StoreFile
  • StoreFile:表数据真实存储的地方,HFile是表数据在 HDFS上的文件格式
  • Hlog:多个Store1个HLog;Hlog保障可靠性; MemStore数据镜像,持久化到文件

HBASE体系架构

HBase采用Master/Slave架构搭建集群

  • 主节点HMaster(为了HA高可用性,也会部署多个 Master节点,其中一个为active节点,其他standby节 点),管理节点,负责对HRegionServer的数据范围进 行分配
  • 若干个从节点HRegionServer,用户数据实际存储和管理节点,负责数据的写入、查询、缓存和故障恢复
  • ZooKeeper集群:HBase借助Zookeeper集群来实现节 点监控和容错
  • HDFS:数据最终以文件形式存在HDFS上,涉及到HDFS 的NameNode、DataNode

Client:

  • 是HBase功能的使用者,HBase Client使用HBase的RPC机制与HMaster和HRegionServer进行通信
  • 对于管理类操作,Client与HMaster进行RPC
  • 对于数据读写类操作,Client与HRegionServer进行RPC

Zookeeper:

  • 是HBase体系中的协同管理节点,提供分布式协作,分布式同步,配置管理等功能
  • ZookeeperQuorum中存储的信息包括:
  • 存储-ROOT-表的地址:/hbase/root-region-server
  • 存储HMaster的地址:/hbase/master
  • 存储所有HRegionServer的状态:HRegionServer会把自己以短暂的方式注册到 Zookeeper 中:/hbase/rs

HMaster:

  • 是整个框架中的控制节点, 负责:

  • 管理用户对table的增、删、改、 查操作

  • 管理HRegionServer的负载均 衡,调整region分布

  • 在region split后,负责新region的分配

  • 在HRegionServer停机后,负责失效HRegionServer上的 region迁移

  • HDFS的垃圾文件回收

  • 处理schema更新请求

  • HBase中可以启动多个HMaster, 通过Zookeeper的Master Election机制保证总有一个HMaster运行

HRegionServer:

  • 负责维护HMaster分配给它的region, 响应用户I/O请求,向HDFS文件系统中读写数据
  • HRegionServer内部管理了一系列HRegion对象
  • HRegion:一个HRegion可以包含多个Store
  • Store:每个Store包含一个Memstore和若干个StoreFile
  • StoreFile:表数据真实存储的地方,HFile是表数据在 HDFS上的文件格式
  • Hlog:多个Store1个HLog;Hlog保障可靠性; MemStore数据镜像,持久化到文件

NoSQL数据库有哪些不同种类的数据库?

NoSQL模型主要有4类,即Key-Value 模型、Key-Document模型、Key-Column模型和图模型。

  1. Key-Value 模型

    • Key-value存储模型的设计理念来自于哈希表,在key与value之间建立映射关系,通过key可以 直接访问value,进而进行增删改等基本操作
    • “值”只是数据库存储的一块数据,它并不关心也无需知道其中的内容
    • 应用程序负责理解所存数据的含义
  2. Key-Document模型

    • Key-Document模型是“面向集合”的,即数据被分组存储在数据集中,这个数据集称为集合。每个集合都有一个唯一标识,并且存储在集合中的文档没有数量限制。Key-Document 模型中的集合类似于关系型数据库中的表结构。有所不同的是, Key-Document模型中无须定义模式。
  3. Key-Column模型

    • Key-Column 模型是一个稀疏的、分布式的、持久化的多维排序图,并通过字典顺序来组织数据,支持动态扩展,以达到负载均衡。
    • 存储在Key-Column 模型中的数据可以通过行键、列键和时间戳进行检索。
    • 其中,列族是最基本的访问单位,存放在相同列族下的数据拥有相同的列属性,并使用时间戳来索引不同版本的数据,以避免数据的版本冲突问题。同时,用户可以通过指定时间戳来获得不同版本的数据。
  4. 图模型:

    • 图模型基于图论来存储和表示实体间的关系。图模型是一种良好的数据表现形式,并提供多种查询方法,例如最短路径查询、子图同构等。图模型的应用十分广泛,如社交网络、知识图谱、时序数据管理等。基本的图模型可以分为无向图模型和有向图模型。随着研究的进展,图模型又细分为不确定图模型、超图模型、时序图模型。
    • 图数据库遍历“链接”及“关系”非常快

MapReduce的体系架构,并详细介绍各组成部分的功能。

  • Client:用户可以编写MapReduce程序,通 过Client提交到JobTracker端

    1. 每一个 Job 都会在用户端通过 Client 类将应用程序以及配置參数 Configuration 打包成 JAR 文件存储在 HDFS,并把路径提交到 JobTracker 的 master 服务,然后由 master 创建每一个 Task(即 MapTask 和 ReduceTask) 将它们分发到各个 TaskTracker 服务中去执行一个MapReduce程序可对应若干个作业,而每个作业会被分解成若干个 Map/Reduce任务(Task)
  • JobTracker主要负责资源监控和作业调度

    1. JobTracker监控所有TaskTracker与作业的健康状况,一旦发现失败情况后,其会将相应的任务转移到其他节点
    2. JobTracker会跟踪任务的执行进度、资源使用量等信息,并将这些信息告诉任务调度器, 而调度器会在资源出现空闲时,选择合适的 任务使用这些资源
  • TaskTracker负责作业的执行

    1. 周期性地通过Heartbeat将本节点上资源的使用情况和任务的运行进度汇报给JobTracker
    2. 接收JobTracker发送过来的命令并执行相应的操作(如启动新任务、杀死任务)
    3. TaskTracker使用“slot”等量划分本节点上的资源量
  • slot是 Hadoop的资源单位代表计算资源 (CPU、内存等)

    1. slot是一个逻辑概念,一个节点的slot的数量用 来表示某个节点的资源的容量或者说是能力的 大小;一个Task获取到一个slot后才有机会运 行,而Hadoop调度器的作用就是将各个 TaskTracker上的空闲slot分配给Task使用
    2. Task分为Map Task和Reduce Task两种,slot分为Map slot和Reduce slot两种,分别供Map Task和Reduce Task使用
    3. TaskTracker通过slot数目(可配置参数)限定 Task的并发度

map task和reduce task的执行过程

  • Map Task先将对应的split迭代解析成一个个key/value对,依次调用用户自定义的map()函数进行处理

  • Map Task将临时结果存放到本地磁盘上,其中临时数据被分成若干个 partition

  • Reduce Task过程分为三个阶段

    1. 从远程节点上读取Map Task中间结果(称为“Shuffle阶段”)
    2. 按照key对key/value对进行排序 (称为“Sort阶段”)
      1. 依次读取<key, value list>,调 用用户自定义的reduce()函数处 理,并将最终结果存到HDFS上 (称为“Reduce阶段”)

MapReduce1.x的缺点和2.x的改进

1.x缺点:

  1. 单点故障&节点压力大&不易扩展
    • JobTraker受内存限制,导致扩展性受限
    • 中心化架构的通病,一旦JobTraker崩溃,会导致整个集群崩溃
    • TaskTraker的MapSlot和ReduceSlot是固定的,不是动态分配的资源
  2. 资源调度和作业管理功能全部都放到一个进程中完成
    • 集群的扩展性差,集群的规模容易受限
    • 新的调度策略难以融入现有的代码,容易发生性能瓶颈和单 点故障

2.x改进

  1. 引入YARN集群资源管理系统
    • YARN:由ResourceManager、 NodeManager和ApplicationMaster三部分组 成
    • ResourceManager(RM):主节点服务,负责维护节点信息和负责资源管理与作业调度, 可以部署两台并利用Zookeeper 实现高可用
    • NodeManager (NM) :计算节点服务, 负责接收RM请求分配Container并管理 Container的生命周期;向RM汇报所在节点 信息;可以部署1~N台
    • ApplicationMaster(AM):用户每提交一个 应用都会包含一个ApplicationMaster,负责与RM通信,申请或释放资源;与NM通信启 动和停止Task;监控任务的运行状态
    • Client:负责提交作业,同时提供一些命令行工具

Yarn集群资源管理系统架构,以及Yarn的调度流程

系统架构

YARN:由ResourceManager、 NodeManager和ApplicationMaster三部分组成

  • ResourceManager(RM):主节点服务,负 责维护节点信息和负责资源管理与作业调度, 可以部署两台并利用Zookeeper 实现高可用
  • NodeManager (NM) :计算节点服务, 负责接收RM请求分配Container并管理 Container的生命周期;向RM汇报所在节点 信息;可以部署1~N台
  • ApplicationMaster(AM):用户每提交一个 应用都会包含一个ApplicationMaster,负责 与RM通信,申请或释放资源;与NM通信启 动和停止Task;监控任务的运行状态
  • Client:负责提交作业,同时提供一些命令行 工具
  • Container:Container是YARN中的资源抽象,它封装了多个维度的资源,如CPU、内存、磁盘、网络等
    1. 当 AM 向 RM 申请资源时,RM 为 AM 返回的资源是用 Container 表示的
    2. YARN 会为每个任务分配一个 Container,该任务只能使用该 Container 中描述的资源ApplicationMaster 可在 Container 内运行任何类型的任务
    3. MapReduce ApplicationMaster 请求一个容器来启动 map 或 reduce 任务
    4. Spark ApplicationMaster请求一个容器来运行Spark任务

调度流程

  1. Client 提交作业到 YARN 上
  2. Resource Manager 选择一个 Node Manager,启动一个 Container 并运行 ApplicationMaster 实例
  3. Application Master 根据实际需要向 Resource Manager 请求更多的 Container 资源(如果作业很小, 应用管理器会选择在其自己的 JVM 中运行任务)
  4. Application Master 通过获取到的 Container 资源执行分布式计算

调度器

  1. FIFO Scheduler

  2. Capacity Scheduler

    • 用户共享集群能力:支持多用户共享集群和多应用 程序同时运行,每个组织可以获得集群的一部分计 算能力;防止单个应用程序、用户或者队列独占集 群中的资源
    • 给不同队列(即用户或用户组)分配一个预期最小 容量,在每个队列内部用层次化的FIFO来调度多个 应用程序。
    • 为了避免某个队列过多的占用空闲资源,导致其它 队列无法使用这些空闲资源可以为队列设置一个最 大资源使用量
    • 弹性队列(queue elasticity):在正常的操作中, Capacity调度器不会强制释放Container,当一个队 列资源不够用时,这个队列能获得其它队列释放后 的Container资源
  3. Fair Scheduler

    • Fair调度器比较适用于多用户共享的大集群,设计目标 是为所有的应用分配公平的资源(对公平的定义可以 通过参数来设置)

    • 当只有一个 job 在运行时,该应用程序最多可获取所 有资源,再提交其他 job 时,资源将会被重新分配分 配给目前的 job,这可以让大量 job 在合理的时间内完 成,减少作业 pending 的情况

      • 假设有两个用户A和B,他们分别拥有一个队列
      • 当A启动一个job而B没有任务时,A会获得全部集群资源
      • 当B启动一个job后,A的job会继续运行,不过一会儿之 后两个任务会各自获得一半的集群资源
      • 如果此时B再启动第二个job并且其它job还在运行,则 它将会和B的第一个job共享B这个队列的资源,也就是B 的两个job会用于四分之一的集群资源,而A的job仍然 用于集群一半的资源
      • 结果就是资源最终在两个用户之间平等的共享

文章作者: nihileon
版权声明: 本博客所有文章除特別声明外,均采用 CC BY 4.0 许可协议。转载请注明来源 nihileon !
 上一篇
新 Blog 记 新 Blog 记
我为什么要重新开一个博客上一个博客是在2018年11月搭建的,那个时候比较悠闲,用 WordPress+搬瓦工一个一个坑地踩,在踩了一大堆的坑后,一个只能称为『能用』的博客搭建完成了,在此之后我就再也没有去对自己的博客做一些优化。自己搭建的
2020-03-28 nihileon
本篇 
大数据课程记录 大数据课程记录
HDFS体系架构Hadoop1.0中的HDFS采用了主从模型,一个HDFS集群是由一个NameNode和多个DataNode组成。其中NameNode作为主,管理FileSystem的NameSpace和客户端对文件的访问操作;DataNo
2020-03-27
  目录