大数据基础篇_02

快打钱！

已于 2024-06-22 17:56:28 修改

阅读量1.2k

点赞数 23

文章标签：大数据

于 2024-06-22 17:55:20 首次发布

本文链接：https://blog.csdn.net/a666b777/article/details/139885237

版权

说明

该篇文章用于大数据的初学人群进行交流学习

本章内容主要是对hive的概念与使用做一个简述（之后一章会有更详细的介绍），mapreduce执行流程的介绍，Yarn的执行流程的介绍及Zookeeper的相关介绍

HIVE概述

Hive的主要功能

因为hadoop的分布式计算的本质其实是java程序的运行，hive相当于一个编译器，将我们写好的sql语句编译成Mapreduce

分布式sql的两个部分：

元数据处理：帮助记录各类元数据

sql解析器：完成sql到Mapreduce程序的转换

Hive 架构图

Hive的核心架构:

元数据管理：即metastore服务，推荐远程模式

sql解析器：即Driver驱动程序，完成sql解析、执行优化、代码提交等功能

用户接口：提供用户和Hive的交互功能

Hive的核心组件 metastore Hiveserver2

Metastore元数据存储：服务配置有三种模式：内嵌模式、本地模式、远程模式

Hive的使用

启动hive

#1.启动metastore服务
nohup bin/hive --service metastore &
nohup bin/hive --service metastore > /tmp/hive-metastore.log &

#2.启动Hiveserver2服务
nohup bin/hive --service hiveserver2 &
nohup bin/hive --service hiveserver2 > /tmp/hive-hiveserver2.log &

#3.校验Hive是否启动
jps

#注意
Hiveserver2服务的启动需要等待一段时间，也就是说，虽然上述jps命令校验能看到进程，但是不代表Hiveserver2就启动成功了。
要想确保Hiveserver2已经启动OK，最稳妥的办法就是查看端口是否占用。
metastore服务，如果正常运行，会占用9083端口，而Hiveserver2服务，如果正常运行，会占用10000端口。
因此，也可以通过命令来校验这2个端口是否被占用，来进一步判断Hive是否启动OK。
netstat -naltp | grep 9083
netstat -naltp | grep 10000&

（注：该过程一定要先跑hadoop集群代码即：start-all.h）
#4 bin/hive

访问hive

第一代客户端命令：beeline/hive

第二代客户端命令：！connect jdbc:hive2://虚拟机地址名:10000

注：第二代以后客户端使用时一定要确保启动了hiveserver2

DaraGrip链接：有手就行

配置hive环境变量

#第一步打开配置环境变量的文件
vim /etc/profile
#第二步 添加以下内容至profile
#HIVE_HOME
export HIVE_HOME=/export/server/hive
export PATH=$PATH:$HIVE_HOME/bin
#第三步 重新加载环境变量
source /etc/profile
#第四步 切换至根目录。检查是否成功
cd ~
hive

hive的三种模式的区别

内嵌模式：不同的元数据，不共享，不启动metastore，数据存在dearby中

本地模式：相同的元数据，共享，不启动metastore，数据存在mysql中

远程模式：相同的metastore，可以远程连接Hive，数据存在mysql中

Mapreduce 的执行流程

分布式计算概述

当数据太大，一台计算机无法处理的时候采取分布式处理。

常见的俩种模式：

分散->汇总模式（Mapreduce）| 中心调度->步骤执行模式（spark,flink）

分散->汇总模式：

将数据分片，多台服务器各自负责一部分数据处理
然后将各自的结果，进行汇总处理
最终得到想要的计算结果

MapReduce的思想核心: 分而治之。

MapReduce的执行流程

作业提交（Job Submission）: 用户将作业（Job）提交给MapReduce系统。作业包含了一系列的Map和Reduce任务，以及处理数据所需的其他配置信息。
作业初始化（Job Initialization）: MapReduce框架接收到作业后，会进行初始化操作，包括解析作业配置、计算输入数据的分割点等。
任务分割（Splitting）: 输入数据被分割成多个小块，称为splits。这些splits将分别由不同的Map任务处理。
Map阶段（Map Phase）: Map任务开始执行，每个Map任务处理一个split，并生成一系列的键值对（key-value pairs）。Map阶段通常用于数据的过滤、转换和聚合。
分区（Partitioning）: Map阶段输出的键值对会根据键（key）进行分区，以便将具有相同键的所有数据传给同一个Reduce任务。
归并（Shuffling）: 不同Map任务生成的数据可能会分布在不同的节点上。Shuffling阶段负责将数据按照分区传输到对应的Reduce任务所在的节点上，并在传输过程中进行必要的排序和合并操作。
Reduce阶段（Reduce Phase）: Reduce任务开始执行，它接收来自Map任务的输出，并将具有相同键的所有数据进行汇总和归并，最终生成最终的键值对结果。
输出（Output）: Reduce阶段的输出会被写入到磁盘或其它存储系统中，这标志着数据处理的完成。
作业完成（Job Completion）: 所有任务完成后，MapReduce框架会进行清理工作，并通知用户作业已经完成。

注：精简版本
1. 作业提交：用户提交作业到MapReduce系统。
2. Map阶段：输入数据被分割，每个片段由Map任务处理并生成键值对。
3. Shuffle阶段：Map生成的键值对按键分区并传输到对应的Reduce任务。
4. Reduce阶段：Reduce任务对同一键的值进行汇总，生成最终结果。

YARN的执行流程

1.客户端提交一个MR程序给ResourceManager

2.请求如果合法，ResourceManager随机选择一个NodeManager生成appmaster

3.appmaster会主动向ResourceManager应用管理器(application manager)注册自己,告知自己的状态信息,并且保持心跳

4.appmaster会根据任务情况计算自己所需要的container资源(cpu,内存),主动向ResourceManager资源调度器(resource scheduler)申请并获取这些container资源

5.appmaster获取到container资源后,把对应指令和container分发给其他NodeManager,让NodeManager启动task任务(maptask,reducetask)

6.NodeManager要和appmaster保持心跳,把自己任务计算进度和状态信息等同步给appmaster,(注意当maptask任务完成后会通知appmaster,appmaster接到消息后会通知reducetask去maptask那儿拉取数据)直到最后任务完成

7.任务完成以后，appmaster会主动向ResourceManager注销自己(告知ResourceManager可以把自己的资源进行回收了,回收后自己就销毁了)

Zookeeper

概念

ZooKeeper概念: Zookeeper是一个分布式协调服务的开源框架。本质上是一个分布式的小文件存储系统

ZooKeeper作用: 主要用来解决分布式集群中应用系统的一致性问题。

ZooKeeper结构: 采用树形层次结构，ZooKeeper树中的每个节点被称为—Znode。且树中的每个节点可以拥有子节点

环境准备

1.提前准备好zookeeper集群环境

2.配置zookeeper环境变量(注意三台都可以配置下)
[root@node1 ~]# echo 'export ZOOKEEPER_HOME=/export/server/zookeeper' >> /etc/profile
[root@node1 ~]# echo 'export PATH=$PATH:$ZOOKEEPER_HOME/bin' >> /etc/profile
[root@node1 ~]# source /etc/profile

3.启动zookeeper服务
# 启动服务
[root@node1 bin]# zkServer.sh start
# 查看状态
[root@node1 bin]# zkServer.sh status
# 如果想关闭可以使用stop
[root@node1 bin]# zkServer.sh stop

注：zookeeper: 分布式协调服务,搭建高可用时,至少需要两个hadoop服务,一主一备,主服务对外提供业务功能,备用等待主服务不可用时,启用备用服务器对外提供业务功能

zookeeper的服务角色

leader: 管理者 ,负责管理follower,处理所有的事务请求(数据的保存,修改,删除)

follower: 追随者,负责选举(选举leader)和数据的同步及获取

observer: 观察者,负责数据的同步及获取(需要在配置文件中指定才能生效)

客户端操作

连接服务
# 方式1:直接连接本地
[root@node1 ~]# zkCli.sh
# 方式2:连接其他节点
[root@node1 ~]# zkCli.sh -server node2

查看所有shell命令：help
常见命令解释:
    ls path [watch] : 查看节点信息
    get path [watch]: 获取数据
ls2 path [watch]: 查看节点详情信息
create [-s] [-e] path data acl: 创建数据节点
delete path [version]: 删除节点
rmr path: 删多层除节点
    set path data [version] ：设置/修改节点数据
    history: 查看操作历史
    quit: 退出

zookeeper的类Linux特点

1.Znode兼具文件和目录两种特点: Znode没有文件和目录之分,Znode既有像文件一样存储数据,也能像目录一样作为路径标识的一部分

2.Znode具有原子性操作: 读操作将获取与节点相关的所有数据，写操作也将替换掉节点的所有数据

3.Znode存储数据大小有限制: 每个Znode的数据大小至多1M，当时常规使用中应该远小于此值

4.Znode通过路径引用: 路径必须是绝对的，因此他们必须由斜杠字符来开头。除此以外，他们必须是唯一的，也就是说每一个路径只有一个表示，因此这些路径不能改变。默认已经提供了/zookeeper节点,用以保存关键的管理信息。

zookeeper的节点类型

分为永久节点和临时节点两种

创建永久节点|临时节点 create /节点名节点值|create -e /节点名节点值

创建永久序列化节点|创建临时序列化节点 create -s /节点名节点值 |create -s -e/节点名节点值

节点属性

cZxid ：Znode创建的事务id。
ctime ：Znode创建时的时间戳.
mZxid ：Znode被修改的事务id，即每次对当前znode的修改都会更新mZxid。
mtime ：Znode最新一次更新发生时的时间戳.
pZxid ：Znode的子节点列表变更的事务ID，添加子节点或删除子节点就会影响子节点列表
cversion ：子节点进行变更的版本号。添加子节点或删除子节点就会影响子节点版本号
dataVersion：数据版本号，每次对节点进行set操作，dataVersion的值都会增加1（即使设置的是相同的数据），可有效避免了数据更新时出现的先后顺序问题。
aclVersion : 权限变化列表版本 access control list Version
ephemeralOwner : 字面翻译临时节点拥有者，持久节点值为0x0，非持久节点不为0（会话ID）
dataLength : Znode数据长度
numChildren: 当前Znode子节点数量(不包括子子节点）

Zookeeper特性

全局数据一致：集群中每个服务器保存一份相同的数据副本，client无论连接到哪个服务器，展示的数据都是一致的，这是最重要的特征；
可靠性：如果消息被其中一台服务器接受，那么将被所有的服务器接受。
顺序性：包括全局有序和偏序两种：全局有序是指如果在一台服务器上消息a在消息b前发布，则在所有Server上消息a都将在消息b前被发布；偏序是指如果一个消息b在消息a后被同一个发送者发布，a必将排在b前面。
数据更新原子性：一次数据更新要么成功（半数以上节点成功），要么失败，不存在中间状态；
实时性：Zookeeper保证客户端将在一个时间间隔范围内获得服务器的更新信息，或者服务器失效的信息。