摘要： 本文主要记录📝Hadoop生态圈学习过程中的笔记（基础版），笔记内容主要参考看尚硅谷视频🍃
一、从Hadoop框架讨论大数据生态
1.Hadoop是什么？
- 广义：Hadoop生态圈的代名词
- 狭义：Apache旗下的一款开源免费软件
2.Hadoop发展历史
- 作者：卡大爷
- 需求：基于早期搜索业务对海量数据的存储和计算的遇到的瓶颈
- 创作源泉：谷歌提出的大数据论文
3.Hadoop的版本发展
- 学习阶段：重点掌握Apache的基础版本
- 生产领域一般使用商业版或者社区（CDH版本）
4.Hadoop的优势（4高）
- 高可靠性
- 高扩展性
- 高效性
- 高容错性
5.Hadoop的组成部分
HDFS (hadoop的组成部分-负责海量数据的存储)
- NameNode（nn）:管理真实数据的元数据的（hdfs集群中的老大）
- DataNode（dn）:主要负责对真实数据块存储（hdfs集群中的小弟）
- SecondaryNameNode（2nn）：主要为NameNode进行一些数据备份，一般恢复数据的时候才会用到它，它也不能保证完全数据恢复。
YARN （hadoop的组成部分，主要负责资源调度）
- ResourceManager（rm）:统筹管理每一台机器上的资源，并且负责接收处理客户端作业请求。
- NodeManager（nm）:负责单独每一台机器的资源管理，实时保证和大哥(ResourceManager）通信。
- ApplicationMaster：针对每个请求job的抽象封装
- Container：将来运行在YARN上的每一个任务都会给其分配资源，Container就是当前任务所需资源的抽象封装
MapReduce（hadoop的组成部分，主要负责数据的计算分析）
- Map阶段：就是把需要计算的数据按照需求分成多个MapTask任务来执行
- Reduce阶段: 把Map阶段处理完的结果拷贝过来根据需求进行汇总计算
6.大数据的技术生态体系和推荐系统实现思路
目的：提前了解大数据项目的技术栈
二、Hadoop的运行模式介绍
1.本地模式
hadoop默认安装后启动就是本地模式，就是将来的数据存在Linux本地，并且运行MR程序的时候也是在本地机器上运行
2.伪分布式模式
伪分布式其实就只在一台机器上启动HDFS集群，启动YARN集群，并且数据存在HDFS集群上，以及运行MR程序也是在YARN上运行，计算后的结果也是输出到HDFS上。本质上就是利用一台服务器中多个java进程去模拟多个服务
3.完全分布式
完全分布式其实就是多台机器上分别启动HDFS集群，启动YARN集群，并且数据存在HDFS集
群上的以及运行MR程序也是在YARN上运行，计算后的结果也是输出到HDFS上。
三、Hadoop的 HA
1.现有集群存在哪些问题？
HDFS集群 单个NN场景下
问题：hdfs单节点故障
NN如果故障了，整个HDFS集群就不可用（中心化集群）
解决方案：配置多个NN
- 多个NN的场景下由哪一台对外进行服务？
当HDFS实现多NN的高可用后，但是只有一台 NN 对外提供服务，其他的NN都是替补（Standby），当正在提供服务的NN宕机故障，其他的NN自动切换成Active状态 - 当一台NN故障后，其他NN如何争抢上位？
采用高可用集群中的自动故障转移机制来完成切换。 - 2NN 在高可用的集群中还要不要？
不要啦！元数据的维护策略还继续保证原样。但是高可用集群中，会添加一个新的服务（JournalNode）JournalNode:本身自己也要搭建成一个集群的状态，他和Zookeeper集群很像，存活机器数量过半，就能正常提供服务。它主要负责编辑日志文件的内容的共享。
YARN集群 单个RM场景下
问题：yarn单节点故障
解决方案：ResourceManager High Availability
2.HA概述
（1）所谓HA（High Availablity），即高可用（7*24小时不中断服务）。
（2）实现高可用最关键的策略是消除单点故障。HA严格来说应该分成各个组件的HA机制：HDFS的HA和YARN的HA。
（3）Hadoop2.0之前，在HDFS集群中NameNode存在单点故障（SPOF）。
（4）NameNode主要在以下两个方面影响HDFS集群
- NameNode机器发生意外，如宕机，集群将无法使用，直到管理员重启
- NameNode机器需要升级，包括软件、硬件升级，此时集群也将无法使用HDFS HA功能通过配置Active/Standby两个NameNodes实现在集群中对NameNode的热备来解决上述问题。如果出现故障，如机器崩溃或机器需要升级维护，这时可通过此种方式将NameNode很快的切换到另外一台机器。
3.HDFS高可用实现
HDFS高可用实现方式是通过配置了：对活动-备用（active-standby）NameNode。如果主NameNode发生故障，则切换到备用的NameNode上，通过双NameNode消除单点故障，同时：
Active NN会把edits文件写到JN集群中的每一台机器上，active和standby的NN都可以读取edits文件，共享的edits文件放在一个共享存储中管理。fsimage文件会在格式化时产生并会被推送给其他的NN节点。
FailoverController Active和FailoverController Standby分别对Active NN和Standby NN进行健康检查，把心跳数据传给ZooKeeper。如果Active NN掉线了，ZooKeeper会进行选举，选举出来后，由FailoverController进行切换。
DN中的信息会同时发给Active NN和Standby NN。
4.HDFS-HA工作要点
（1）元数据管理方式需要改变
- 内存中各自保存一份元数据；
- Edits日志只有Active状态的NameNode节点可以做写操作；
- 所有的NameNode都可以读取Edits；
- 共享的Edits放在一个共享存储中管理（qjournal和NFS两个主流实现）；
（2）需要一个状态管理功能模块
- 实现了一个zkfailover，常驻在每一个namenode所在的节点，每一个zkfailover负责监控自己所在NameNode节点，利用zk进行状态标识，当需要进行状态切换时，由zkfailover来负责切换，切换时需要防止brain split现象的发生。
（3）必须保证两个NameNode之间能够ssh无密码登录
（4）隔离（Fence），即同一时刻仅仅有一个NameNode对外提供服务
四、Zookeeper（入门）
1. 大概设计模式
- 文件系统 + 通知机制
2.特点
- Zookeeper:一个领导者（Leader），多个跟随者（Follower）组成的集群
- 集群中只要有半数以上节点存活，Zookeeper集群就能正常服务
- 全局数据一致：每个Server保存一份相同的数据副本，Client无论连接到哪个Server，数据都是一致的
- 更新请求顺序进行，来自同一个Client的更新请求按其发送顺序依次执行
- 数据更新原子性，一次数据更新要么成功，要么失败
- 实时性，在一定时间范围内，Client能读到最新数据
3.数据结构
- ZK中的数据保存的格式（树状结构）
- 注意：ZK中没有文件的概念，节点下直接存的就是内容。
4.应用场景
- 服务的管理（服务的上下线）
- 统一管理的域名
- 软负载均衡
- 统一管理配置信息
5.ZooKeeper之仲裁模式
standlone模式运行ZooKeeper，便于评估，开发，测试和学习。但是在实际生产中，使用ZooKeeper均以仲裁模式（quorum mode）运行，quorum mode具有一组ZooKeeper服务器，这一组服务器同时服务客户端的请求。具体可划分为两类：分布式模式（即多个服务器在不同计算机上）、伪分布式模式（即多个服务器在同一计算机上）。客户端与服务器之间的关系如下图所示：
法定人数
在quorum mode模式下，ZooKeeper复制集群中所有服务器的数据树。但是，如果让一个客户端等待每个服务器完成数据保存后再继续，那么可能导致的延迟问题将无法接受。所以，必须指定保证ZooKeeper正常提供服务的最小服务器数量。类似于公共管理领域中的法定人数（进行一项投票所需立法者的最小数量）。一般情况下，在ZooKeeper分布式模式中，服务器数量为奇数个。
Leader选举
Leader作为整个ZooKeeper集群的主节点，负责响应所有对ZooKeeper状态变更的请求和进行选举投票的发起和决议，保证服务器数据一致性。它会将每个状态更新请求进行排序和编号，以便保证整个集群内部消息处理的FIFO。
服务器具有4种状态
LOOKING：寻找Leader状态。当服务器处于该状态时，当前集群中没有Leader，因此需要进入Leader选举状态。
FOLLOWING：跟随者状态。表明当前服务器角色是Follower。
LEADING：领导者状态。表明当前服务器角色是Leader。
OBSERVING：观察者状态。表明当前服务器角色是Observer，Observer不参与投票和选举过程。
ZooKeeper的leader选举过程
分为两种，服务器初始化启动和服务器运行期间无法和leader保持连接。选举过程如下图所示：
服务器初始化启动leader选举
分为以下几步：
每个Server发出一个投票。投票信息包含myid（服务器编号）和ZXID（Zookeeper状态发生改变的序号），然后发给集群中其他机器。
接受来自各个服务器的投票。
处理投票。 优先检查ZXID。ZXID大的服务器被选举为Leader。如果ZXID相同，myid较大的服务器被选举为Leader。
统计投票。每次投票后，服务器都会统计投票信息，判断是否已经有过半服务器接受到相同的投票信息。
改变服务器状态。当确定了leader后，服务器更新当前状态，如果是Follower，则更新为FOLLOWING，如果是leader，则更新为LEADING。
服务器运行期间无法和leader保持连接的leader选举分为以下几步：
变更状态。非Observer首先将服务器状态变更为LOOKING，然后进入Leader选举过程。
其余步骤与服务器初始化启动leader选举过程相同
五、HDFS高可用各节点介绍
1．NameNode（NN）
NameNode节点主要有两种状态：active和standby。
2．FailoverController（ZKFC）
FailoverController节点用于监控和控制NameNode的状态切换，当一个集群中的Active NameNode“挂掉”后，会把Standby NameNode状态切换成active。
3．JournalNode（JN）
JournalNode节点共享edits日志文件，因为edits文件一旦丢失，就会导致元数据丢失，数据也就丢失了，这里的JN往往是一个集群，来保障edits不会丢失。
4．DataNode（DN）
DataNode节点定时和NameNode进行通信，接受NameNode的指令就会导致元数据丢失，同时DataNode之间还会相互通信，执行数据块复制任务。
5．ZooKeeper（ZK）
选择其中一个备用的NameNode为active。在这里需要注意的是，在搭建HA HDFS高可用时，可以没有Secondary NameNode节点，在搭建完全分布式时的Secondary NameNode合并edits文件的功能由Standby的NameNode替代了
🌱未完待续……
参考资料
【尚硅谷】Hadoop2.x框架入门教程丨案例实战，好评如潮】
-------------本文结束感谢您的阅读-------------
本文链接： http://example.com/2023/01/26/Hadoop知识点汇总/
版权声明： 本作品采用 知识共享署名-非商业性使用-相同方式共享 4.0 国际许可协议 进行许可。转载请注明出处！