hadoop生态系统

大数据4个特征

  1. vloume(大量化) 存储量大、增量大
  2. Variety(多样化) 来源多(搜索引擎、社交、通话)、格式多(结构化、非结构化数据)
  3. Velocity(快速化) 数据产生快、数据处理速度快
  4. Value(价值密度低) 需要处理大量不相关的信息

Hadoop架构

Hadoop是什么?

一个分布式系统基础架构。用户可以不了解底层就能上手开发。

Hadoop的核心构成

HDFS(分布式文件系统)

YARN(资源管理系统)

MapReduce(分布式计算框架)

HDFS(分布式文件系统

  1dataset 无法在单独的机器上进行处理,

HDFS简述

Hadoop Distributed File System 的缩写,Hadoop中的分布式文件系统,指文件系统管理的物理存储资源不一定直接连接在本地节点上,而是通过计算机网络与节点相连。它是一个高度容错性的系统,适合部署在廉价的机器上。HDFS能提供高吞吐量的数据访问,适合那些有着超大数据集(large data set)的应用程序。

HDFS设计用于在商品硬件上运行。

HDFS具有高度容错能力,旨在部署在低成本硬件上。

HDFS提供对应用程序数据的高吞吐量访问,适用于具有大型数据集的应用程序。

 

HDFS优

HDFS优点:

  1.硬件故障:硬件出现故障是必须的,失败是不可忽略的。检测故障并快速恢复(高容错:数据自动保存多个副本,副本丢失后,自动恢复)可构建在廉价的机器上,通过多副本提高可靠性,提供容错和恢复机制。

  2.流数据访问:HDFS的设计更多用于批处理,而不是用户交互式使用。重点是数据访问的高吞吐量,而不是数据访问的低延迟。

  3.存储大量的数据 

  4.移动计算比移动数据更有效

  5.跨异构硬件和软件平台的可移植性

HDFS缺点:

1.不适合低延迟数据访问

2.不适合小文件存取

3.不允许多线程同时进行,不支持文件的随机修改:一个文件只能一个一个写,不允许多线程同时进行;仅支持数据append(追加),不支持文件的随机修改

HDFS分布式文件系统的设计思想

1个文件被拆分成多个Block,

每个block以多副本的方式存储在各个节点上;

保存元数据映射关系;

负载均衡;

分布式并行计算

HDFS Java API操作

创建Maven项目

在pom.xml中添加hdfs所需要的dependency

使用Java API操作HDFS文件系统

HDFS副本机制

Block副本放置策略

HDFS架构

1 Master(NameNode/NN) 带 N个Slaves(DataNode/DN)的架构来存储数据

HDFS架构图:

 

架构组成

  1. HDFS client(客户端)
  1. 文件切分
  2. 与NameNode交互,获取文件的位置信息
  3. 与DataNode交互,读取或者写入数据
  4. Client提供一些命令来管理HDFS,如启动或关闭HDFS
  5. Client通过命令访问HDFS

 

2 NameNode(master、主管者。发送命令)。NameNode是所有HDFS元数据的仲裁者和存储库。该系统的设计方式是用户数据永远不会流经NameNode。

  1. 处理客户端读写请求
  2. 负责元数据的管理:HDFS的名称空间,配置副本策略,Block存放的DN(数据库block映射信息)

 

3  DataNode(salve。接收namenode发出的命令) 

  1. 存储用户的文件对应的数据块block
  2. 执行数据块的读写操作
  3. 定期向NN发送心跳信息,汇报本身及其所有的block信息,健康状况

 

4  Secondary NameNode

  1. 辅助NameNode,分担其工作量
  2. 定期合并fsimage(保存最新的与数据检查点,包含整个HDFS是由于目录和文件的信息)和fsedits,并推送给NameNode
  3. 紧急情况下,辅助恢复NameNode

副本机制

1.第一个副本在客户端相同节点上存放

      如果客户端不在集群内呢?就随机挑选一个节点

2.第二个副本:存放在与第一个不同的随机选择的机架上

3.第三个副本:存放在与第二个副本相同机架但是不同的节点上

4.。。。随机存放

HDFS环境搭建

ssh安装

Linux机器参数设置

HDFS配置文件:hadoop-evn.sh、core-site.xml、hdfs-site.xml

HDFS格式化及启停:格式化:hadoop namenode -format

启动:start-dfs.sh 关闭:stop-dfs.sh

YARN资源管理系统

YARN架构

master/slaves结构:1个ResourceManager对应多个NodeManger构成

 

YARN的核心组件:

  1. ResourceManager

2. NodeManager

3. ApplicationMaster

4. Container

 

  1. ResourceManager

  ResourceManager:在整个集群中处于工作状态的只有1个,负责集群资源的统一管理和调度

  1.处理客户端发起的请求(启动/杀死应用程序)

  2.启动/监控ApplicationMaster,AM挂了,RM将会在另外一个节点上启动该AM

  3.RM监控NM

  4.本节点上的资源管理和任务管理

ResourceManager核心组件:

  1. Scheduler(调度器)
  2. Applications Manager(应用程序管理器)

Scheduler:负责将资源分配给各种正在运行的应用程序。调度程序是纯调度程序,因为它不会监视或跟踪应用程序的状态

ApplicationsManager:负责接受作业提交,协商执行特定于应用程序的ApplicationMaster的第一个容器,并提供失败时重新启动ApplicationMaster容器的服务。

每个应用程序的ApplicationMaster负责从调度程序中协商适当的资源容器,跟踪其状态并监视进度。

 

  1. NodeManager

整个集群中有多个,负责自身节点的资源使用和管理

作用:

 1.定时向RM汇报本节点上的资源使用情况和各个Container的运行情况

 2.接收和处理来自RM的Container启动和停止的各种命令

 3.处理来自AM的命令

 4.本节点上的资源管理和任务管理

 

  1. ApplicationMaster(AM)

每个应用程序一个,负责应用程序的管理

作用:

  1. 数据切分
  2. 为应用程序向RM申请资源(Container),分配任务
  3. 与NM通信以启动/停止任务,Task(作业)都是运行在Container中的
  4. Task容错

  1. Container(容器)

Container是YARN中的资源抽象,分装了某个节点上的多维度资源,如cpu、内存、磁盘、网络等,当AM向RM申请资源时,RM为AM返回的资源便是用Container表示。

YARN会为每个任务分配一个Container,且该任务只能使用该Container中描述的资源。

Yarn执行流程

  1. 用户向YARN(RM)提交作业
  2. RM为该作业分配一个Container
  3. RM与对应的NM通信,让在这个NM的这个Container上启动应用的ApplicationMaster
  4. AM首先向RM注册,用户就可以通过RM来查询该作业的运行状况,然后AM将为各个任务申请资源
  5. AM申请到资源与对应的NM通信,要求NM启动任务
  6. NM启动任务

YARN容错

  1. RM 单点故障-->RM HA /RM Testart
  2. NM 挂了,RM将失败任务告诉AM,AM决定是否处理失败任务
  3. AM 挂了,由RM负责重启

注:有些task运行完成,但是整个作业没有运行完成,会保存已经运行完成的task。重启后无需全部重新运行

YARN环境搭建

YARN配置文件参数设置

yarn-site.xml

mapred-site.xml

YARN启停

Yarn启动:start-yarn.sh

Yarn关闭:stop-yarn.sh

 

 

MapReduce分布式计算框架

什么是MapReduce

 

MapReduce是一个分布式运算程序的编程框架,是用户开发“基于hadoop的数据分析应用”的核心框架

MapReduce核心功能:将用户编写的业务逻辑代码和自带默认组件整合成一个完整的分布式运算程序,并发运行在一个hadoop集群上

为什么需要MapReduce

  1. 硬件资源限制海量数据在单机上处理无法胜任
  2. 单机扩展集群,程序复杂度增加和开发难度大
  3. 引入MapReduce框架后,把分布式计算中的复杂性交给框架处理,人们集中在业务逻辑的开发上

MapReduce优缺点

MapReduce优点

  1. 易于编程
  2. 良好扩展性 计算机资源不够,通过增加机器扩展能力
  3. 高容错性
  4. 适合PB级以上的海量离线数据处理 MapReduce不适合在线数据处理

MapReduce缺点

  1. 不能实时计算 无法像MysqL在毫秒级或秒级返回结果
  2. 不能流式计算 MapReduce的输入数据集是静态的,不能动态变化          

MapReduce自身的设计特点决定了数据源必须是静态的

  1. DAG计算 多个应用程序存在依赖关系,后一个应用程序的输入为前一个的输出。用MapReduce处理的数据集必须:待处理的数据集可以分解成许多小的数据集,而且每一个小数据集都可以完全并行地进行处理

MapReduce执行原理

 

 

 

 MapReduce容错

1)MRAppMaster:运行失败,由YARN的RM负责重新启动,默认启动次数2次

2)Map/Reduce Task

Task会周期性向MRAppMaster发送心跳,汇报运行状况

Task挂了,MRAppMaster会为task重新申请资源,然后重新执行(NM,换一个NM),次数限制,默认4次

使用MapReduce开发WordCount

在pom.xml中添加mapreduce的依赖

<dependency>

  <groupId>org.apache.hadoop</groupId>

  <artifactId>hadoop-mapreduce-client-app</artifactId>

  <version>${hadoop.version}</version>

</dependency>

Map阶段:

1).将一个输入作为一个映射,即 key:value

说明:文件中的每行会执行一次map,针对words.txt文件中的内容会执行三次map,以文件中的第一行为例

 # 行号:一行内容

 Deer Bear River

2).处理value,拆分成独立的单词数组(按空格/tab分隔)

 {Deer}    {Bear}    {River}   {Deer}

3).当单词数组中的每个元素组成一个映射,即 key:value

 

 Deer: 1   Bear: 1    River:1   Deer: 1

 

Reduce阶段:

 

1).将map阶段产生所有key:value通过洗牌排序产生新的key:value

Deer:{1, 1}    Bear{1, 1}    River{1, 1}    Car{1, 1, 1}

2).遍历key,累加value值,最终结果如下

Deer:2

    Bear:2

    River:2

    Car:3

2)开发代码

3) 使用maven进行打包

 mvn clean package -DskipTests

4) 运行mr作业

hadoop jar /home/hadoop/lib/hadoop-test-1.0-SNAPSHOT.jar com.dsj.hadoop.hdfs.WordCountApp  /input    /output

整个过程大致分为:map阶段、(洗牌)、reduce阶段、封装MapReduce作业信息

map阶段,写一个自定义mapper处理类类继承Mapper<LongWritable,Text,Text,LongWritable>,LongWritable,Text是输入的key/value,Text,LongWritable是输出的key/value。重写里面的map方法,Text里面是传进来的文件。读取HDFS中的文件。每一行解析成一个<k,v>。每一个键值对调用一次map函数。在这个方法里写上自己的逻辑,输出结果。

洗牌:这个过程内部封装了洗牌过程,自动洗牌,不用管。

reduce阶段,写一个自定义Reducer处理类类继承Reducer<Text, LongWritable, Text, LongWritable>。map的输出key/value是reduce的输入key/value,map的输入key/value是reduce的输出key/value。在这个方法里写上自己的逻辑,输出结果。

封装MapReduce作业信息,创建一个job,命名子,设置job的处理类、设置作业处理的输入路径、设置map相关的、设置reduce相关的、设置作业处理的输出路径

这样就把map和reduce联系起来。

结合hadoop jar /home/hadoop/lib/hadoop-test-1.0-SNAPSHOT.jar com.dsj.hadoop.hdfs.WordCountApp  /input    /output  来看

Path(args[0])指的是这个命令的第一个路径,输入路径

Path(args[1])指的是这个命令的第二个路径,输出路径

我们可以在one:50070看到文件路径,在one:8088看到上传的wordcount这个文件的状态和信息

zk的架构

1.一个zk集群由一组server节点构成

2.这一组server节点存在一个角色为leader节点,剩下的其他节点都是Follower

3.当客户端client连接到zk集群时,并且执行读/写请求,这些请求会被送到

leader节点上

4.然后leader上数据变更会同步到集群的其他Follower节点,

5.leader节点接收到变更请求之后,首先将变更写入到本地磁盘(为了容错,恢复之用)

才会将变更应用到内存中

6.当当前的leaderf发生故障无法提供服务之后,会从Follower中选择一个做为leader.

 

leader选举算法是采用了-Paxos协议:当多数server写成功,则任务数据写成功

多数server:只要集群中有过半的机器是正常工作的,那么整个集群对外就是可用的。

 

短暂的

   客户端会话结束,那么zk就会将该类型的node删除,该类节点是不可以有子节点

持久的

   就会依赖于客户端会话,只有当客户端明确的使用命令或者API方式要删除该节点时,它才会被删除

 

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值