Wiley大数据-大数据开发基础上-笔记

1、HDFS简介

1）计算机集群的基本架构

实现目标：

• 兼容廉价的硬件设备
• 流数据读写
• 大数据集
• 简单的文件模型
• 强大的跨平台兼容性

局限性：

• 不适合低延迟数据访问
• 无法高效存储大量小文件
• 不支持多用户写入及任意修改文件

2）HDFS简介

块概念：HDFS默认一个块64MB，一个文件分为多个块，以块作为存储单位，大小远大于普通文件系统，可以最小化寻址开销。

好处有：

• 支持大规模文件存储
• 简化系统设置
• 适合数据备份

HDFS主要组件的功能

NameNode

DataNode

存储元数据

存储文件内容

元数据保存在内存中

文件内容保存在磁盘

保存文件，block，datanode之间的映射关系

维护了block id到datanode本地文件的映射关系

a)     Namenode（核心数据结构FsImage和EditLog）

FsImage：维护文件系统树以及文件树种所有的文件和文件夹的元数据

EditLog：记录了所有针对文件的创建、删除、重命名等操作

名称节点：记录了每个文件中各个块所在的数据节点的位置信息

启动名称节点时：将FsImage文件中内容加载到内存中，之后再执行EditLog文件中的各项操作，使得内存中的元数据和实际的同步，存在内存在的元数据支持客户端的读操作；

在内存中成功建立文件系统元数据的映射，则创建一个新的FsImage文件和一个空的EditLog文件；

HDFS的更新操作会重新写到EditLog文件中，提高效率。

第二名称节点可解决EditLog不断变大的问题

b)    SecondaryNameNode的工作情况：

新的文件操作会写入Edit.new的文件中；

原来的EditLog和FsImage文件会读取到第二名称节点上，然后进行合并；

再将合并后的FsImage文件发送到NameNode里面，同时，名称节点会将Edit.new改为EditLog；

如此，就解决了EditLog变大的问题。

c)     DataNode

负责数据的存储和读取，

根据客户端或名称节点的调度来进行数据的存储和检索，

向名称节点定期发送自己所存储的块的列表；

每个节点的数据会被保存在各自节点的本地Linux文件系统中

HDFS1.0体系结构的局限性：       

命名空间的限制；

性能的瓶颈；

隔离问题；

集群的可用性。

冗余数据保存：

优点：加快数据传播速度；容易检查数据错误；保证数据可靠性。

数据存储策略：

a）数据存放：

第一个副本：集群外提价，随机挑选一台磁盘不太慢、CPU不太忙的节点；

第二个副本：放置在与第一个副本不同的机架的节点上；

第三个副本：与第一个副本相同机架的其他节点上；

更多副本：随机节点。

b）数据读取：

就近读取，HDFS提供了一个API可以确定一个数据节点所属的机架ID，客户端也可以调用API获取自己所属的机架ID；如果客户端和副本在相同机架上，优先选择该副本读取数据，如果没有发现，随机选择一个副本。

数据错误与恢复：

1、名称节点出错：

1.0版本会暂停，利用第二名称节点恢复；

2、数据节点出错：

名称节点无法收到来自一些数据节点的心跳信息，这些数据节点会被标记为“宕机”，名称节点会第七检查这种情况，一旦发现会，冗余复制。

3、数据出错：

读取数据时，客户端会对数据块进行校验，

在文件被创建时，客户端就会对每一个文件块进行信息摘录，并把这些信息写入到同一个路径的隐藏文件里面，

当客户端读取文件时，会先读取改信息文件，然后利用该信息文件对每个读取的数据块进行校验，如果校验出错，客户端就会请求到另外一个数据节点读取该文件块，如果校验出错，客户端就会请求到另外一个数据节点读取该文件块，并向名称节点报告这个文件块有错误，名称节点会定期检查并且重新复制这个块。

HDFS数据读写过程：

1、读过程

2、写过程

HDFS常用命令：

有三种Shell命令方式

• hadoop fs适用于任何不同的文件系统，比如本地文件系统和HDFS文件系统；
• hadoop dfs只能适用于HDFS文件系统；
• hdfs dfs跟hadoop dfs的命令作用一样，也只适用于HDFS文件系统。

hadoop fs -ls <path>:显示<path>指定的文件的详细信息

hadoop fs-mkdir <path>：创建<path>指定的文件夹

hadoop fs-cat <path>：将<path>指定的文件内容输出到标准输出

hadoop fs -copyFromLocal<localsrc> <dst>：将本地源文件<localsrc>复制到路径<dst>指定的文件或文件夹中

2、YARN原理

1）Hadoop版本的演变

 

Hadoop框架中最核心的设计是为海量数据提供存储的HDFS和对数据进行计算的MapReduce

MapReduce的作业主要包括：（1）从磁盘或从网络读取数据，即IO密集工作；（2）计算数据，即CPU密集工作

Hadoop集群的整体性能取决于CPU、内存、网络以及存储之间的性能平衡。

一个基本的Hadoop集群中的节点主要有：

• NameNode：负责协调集群中的数据存储
• DataNode：存储被拆分的数据块
• JobTracker：协调数据计算任务
• TaskTracker：负责执行由JobTracker指派的任务
•  SecondaryNameNode：帮助NameNode收集文件系统运行的状态信息

2）YARN结构

ApplicationMaster

ResourceManager接收用户提交的作业，按照作业的上下文信息以及从NodeManager收集来的容器状态信息，启动调度过程，为用户作业启动一个ApplicationMaster

ApplicationMaster的主要功能是：

（1）   当用户作业提交时，ApplicationMaster与ResourceManager协商获取资源，ResourceManager会以容器的形式为ApplicationMaster分配资源；

（2）   把获得的资源进一步分配给内部的各个任务（Map任务或Reduce任务），实现资源的“二次分配”；

（3）   与NodeManager保持交互通信进行应用程序的启动、运行、监控和停止，监控申请到的资源的使用情况，对所有任务的执行进度和状态进行监控，并在任务发生失败时执行失败恢复；

（4）   定时向ResourceManager发送“心跳”消息，报告资源的使用情况和应用的进度信息；

（5）   当作业完成时，ApplicationMaster向ResourceManager注销容器，执行周期完成。

NodeManager

NodeManager是驻留在一个YARN集群中的每个节点上的代理，主要负责：

• 容器生命周期管理
• 监控每个容器的资源使用情况
• 跟踪节点健康状况
• 以“心跳”的方式与ResourceManager保持通信
• 向ResourceManager汇报作业的资源使用情况和每个容器的运行状态
• 接收来自ApplicationMaster的启动/停止容器的各种请求

YARN的体系结构：

YARN的工作流程

步骤1：用户编写客户端应用程序，向YARN提交应用程序，提交的内容包括ApplicationMaster程序、启动ApplicationMaster的命令、用户程序等；

步骤2：YARN中的ResourceManager负责接收和处理来自客户端的请求，为应用程序分配一个容器，在该容器中启动一个ApplicationMaster；

步骤3：ApplicationMaster被创建后会首先向ResourceManager注册；

步骤4：ApplicationMaster采用轮询的方式向ResourceManager申请资源；

步骤5：ResourceManager以“容器”的形式向提出申请的ApplicationMaster分配资源；

步骤6：在容器中启动任务（运行环境、脚本）；

步骤7：各个任务向ApplicationMaster汇报自己的状态和进度；

步骤8：应用程序运行完成后，ApplicationMaster向ResourceManager的应用程序管理器注销并关闭自己。

YARN框架相对于MapReduce1.0框架的优势：

1）大大减少了承担中心功能的ResourceManager的资源消耗；

2）MapReduce1.0只能支持MapReduce编程模型，而YARN则是一个纯粹的资源调度管理框架，可以运行包括MapReduce在内的不同类型的计算框架；

3）YARN中的资源管理比MapReduce1.0更加高效，以容器为单位而不是slot为单位。

3、MapReduce原理

MapReduce采用“分而治之”的策略，将大数据数据集切分成独立的分片，由多个Map并行处理；

MapReduce设计的一个理念就是“计算向数据靠拢”，

MapReduce采用了Master/Slave架构，运行的分别是Jobtracker和Tasktracker

1） 结构：Client，JobTracker，TaskTracker以及Task。

1）Client

用户编写的MapReduce程序通过Client提交到JobTracker端

用户可通过Client提供的一些接口查看作业运行状态

2）JobTracker

JobTracker负责资源监控和作业调度

JobTracker监控所有TaskTracker与Job的健康状况，一旦发现失败，就将相应的任务转移到其他节点

JobTracker会跟踪任务的执行进度、资源使用量等信息，并将这些信息告诉任务调度器（TaskScheduler），而调度器会在资源出现空闲时，选择合适的任务去使用这些资源

3）TaskTracker

会周期性的发送“心跳”给JobTracker，同事接受JobTracker发送过来的命令并执行相应的操作

TaskTracker使用“slot”等量划分本节点上的资源量，slot分为Map slot和Reduceslot两种

4）Task

分为Map Task和Reduce Task两种，均由TaskTracker启动

2） 工作流程

输入——Map任务——Shuffle——Reduce任务——输出

• 不同的Map任务之间不会进行通信
• 不同的Reduce任务之间也不会发生任何信息交换
• 用户不能显式地从一台机器向另一台机器发送消息
• 所有的数据交换都是通过MapReduce框架自身去实现的

3） MapReduce的执行过程

split是一个逻辑概念，只包含一些元数据信息

split的多少决定了Map任务的数量

Reduce任务个数取决于集群中可用的reduce任务槽的数目，设置通常比reduce任务槽数目稍微小一些Reduce任务个数

4） Shuffle过程简介

过程如下：

• 输入数据和执行Map任务
• 写入缓存：默认100MB缓存，每个Map任务分配一个缓存
• 溢写（分区、排序、合并）：溢写比例0.8,分区默认采用哈希函数，分区后自动排序，排序后可能会合并
• 文件归并：归并可以设置预定值，溢写文件数量大于预定值（默认3），则可以再次启动Combiner，少于3不需要
• Reduce端的Shuffle过程

过程如下：

• Reduce任务通过RPC向JobTracker询问Map任务是否已经完成，若完成，则领取数据；
• Reduce领取数据先放入缓存没来自不同Map机器，先归并，再合并，写入磁盘；
• 多个溢写文件归并成一个或多个大文件，文件中的键值对是排序的；
• 当数据很少时，不需要溢写到磁盘，直接在缓存中归并，然后输出给Reduce。