hadoop 2.0
对于Hadoop高可用架构节点介绍
NN服务器会出现脑裂(brain-split)情况
什么是脑裂
在hadoop2.x版本中，如果存在两个NameNode节点同时服务，这种情况称之为“脑裂”
为什么会出现脑裂
脑裂出现原因一般发生在主备NamoNode切换，由于网络延迟、设备故障等，备用的StandbyNameNode【备用节点】认为ActiveNameNode【主节点】失效，此时StandbyNameNode会转换为活跃状态【主节点】，这时候如果原来的主节点自己恢复正常，这时候会出现两个主节点同时工作的情况
脑裂的场景
NameNode 可能会出现这种情况，NameNode 在垃圾回收（GC）时，可能会在长时间内整个系统无响应
zkfc客户端也就无法向 zk 写入心跳信息,这样的话可能会导致临时节点掉线,备 NameNode会切换到 Active 状态
这种情况可能会导致整个集群会有同时有两个Active NameNode
解决方案
在两个NameNode节点服务器中，都会有一个进程【ZKFC】监听当前NN服务器的健康状况
在集群启动后，使用第三方组件【这里使用Zookeeper】帮助选举主节点【ANN】，竞选完ANN后，会在Zookerper集群中创建选举成功后ANN信息，一个zookeeper临时节点（主节点服务器挂掉，临时节点就不存在），和一个正zookerper正常节点（在正常关闭ANN，正常节点也会关闭，如果是异常关闭ANN，正常节点存在）
切换主备节点方式
3.1. 当备用节点【SNN】发现zookerper中，ANN的临时节点和正常节点都不存在，自己可以放心切换为新的ANN主节点
3.2. 当SNN发现Zookerper中，原来ANN的临时节点不存在，正常节点存在的时候，如果直接切换自己为新的ANN可能出现脑裂
针对这两种情况，怎么切换主备服务器
4.1 首先就使用RPC远程调用ANN服务器的ActiveBreadCrumb方法，尝试将原来的ANN切换为SNN
4.2. 如果RPC远程调用失败，会执行预定义的隔离措施
隔离措施
5.1. sshfence: 通过SSH（登陆信息在zookerper节点中存放，可以获取到）登陆到目标机器上，执行命令fuser将对应进城杀死
5.2. shellfence：执行用户自定义的shell脚本讲对应的进城隔离
处理完毕原来的ANN服务器后，SNN就会调用becomoActive成为主节点，对外提供服务
新的ANN服务器也会在zookeeper中创建自己的临时节点和正常节点
如果发生脑裂的，防止多条指令的情况
在每次选举之后，ANN都会产生一个新的序列号【可以理解为自增id】然后这个序列号会发送给DN
在每次NN服务器发送指令的时候，如果发生脑裂，多个NN服务器发送指令，DN服务器一最新的指令为准
联邦机制
什么是联邦机制
可以同时让多个NameNode参与数据的管理【这是水平拓展】
为什么使用联邦机制
== 单个NN节点使用存在局限性==
Namespace（命名空间）的限制
- NameNode所能存储的对象（文件+块）数目受到NameNode所在JVM的heap size的限制。
- 50G的heap能够存储20亿（200million）个对象，这20亿个对象支持4000个DataNode，
12PB的存储 - DataNode从4T增长到36T，集群的尺寸增长到8000个DataNode。存储的需求从12PB增长到大于100PB。
性能的瓶颈 - 整个HDFS文件系统的吞吐量受限于单个Namenode的吞吐量
隔离问题 - HDFS上的一个实验程序就很有可能影响整个HDFS上运行的程序
集群的可用性 - Namenode的宕机无疑会导致整个集群不可用。
Namespace和Block Management的紧密耦合
纵向扩展目前的Namenode不可行 - 将Namenode的Heap空间扩大到512GB启动花费的时间太长
- Namenode在Full GC时，如果发生错误将会导致整个集群宕机
联邦机制架构
1：每个NameNode【这里使用高可用架构，存在主备节点】管理指定的文件内容
2：每个NameNode都管理维护一个NameSpace(命名空间池)
3：所有的DN服务器都都共享给全部NameSpace
块池Block Pool
- Block pool(块池)就是属于单个命名空间的一组block(块)管理区域
- 每一个datanode为所有的block pool存储
- Datanode是一个物理概念，而block pool是一个重新将block划分的逻辑概念
- 一个Namenode失效不会影响其下的datanode为其他Namenode的服务
- datanode与Namenode建立联系并开始会话后自动建立Block pool
Namespace Volume（命名空间卷） - 一个Namespace和它的Block Pool合在一起称作Namespace Volume
- Namespace Volume是一个独立完整的管理单元。当一个Namenode/Namespace被删除，与之相对应的Block Pool也也被删除。
通过多个namenode/namespace把元数据的存储和管理分散到多个节点中 - 降低单个NN节点数据压力,计算压力
namenode/namespace可以通过增加机器来进行水平扩展 - 可以让更多的节点参与到运算
- namespace命名空间，通过这种方式确定要处理数据的路径
我们可以通过namenode和namespace组合使用 - 所有的nn共享dn
- 但是每一个namespace会单独管理自己的块
- 会创建一个管理块的机制：blocks pool
随着Hadoop生态的发展，开源社区出现了多种多样的技术组件。有用来构建数据仓库的Hive，也有基于内存的计算框架 Spark，还有我们之前介绍过的NoSQL数据库 HBase等。
这些技术组件的出现，极大地丰富了大数据的生态体系，但同时也引出了一些新的问题。作为一个大数据底层支撑平台，同时部署Hive、HBase和Spark等多种技术组件是一件十分平常的事情。这些为大数据场景设计的技术组件可以说个个都是消耗资源的大户，这些资源包括服务器的CPU和内存。
通常这些技术组件都有一套自己的资源调度系统用来管理任务的资源分配，但当它们同时部署在一起的时候就出问题了。这时会有两种情况产生，第一种情况是某些组件可能申请不到服务器资源。
比如一台拥有32G内存的服务器同时部署了HBase和Spark，HBase的RegionServer启动时占用了20GB内存，这时Spark开始执行某个任务也需要使用20GB内存，但这时发现没有足够的内存资源使用了。因为从每个组件独立的视角来看他们都认为自己能使用100%的服务器资源，但服务器资源的总量就那么多，不可能同时满足所有组件的需求。
第二种是可能会出现资源分配不合理的情况，导致整体资源使用率偏低。我们同样用刚才的场景举例，Spark启动了一个任务申请使用30GB的内存，但是实际上它的程序逻辑并不需要使用这么多资源。这就出现了一种HBase没有资源什么事情也做不了，但Spark占用了资源却没有事情可做的局面。
为了解决类似的问题，我们需要一种通用的资源调度框架，对整个集群的资源进行统筹管理。
YARN就是一款优秀的集群资源调度框架。YARN是Yet Another Resource Negotiator的缩写，它是Hadoop的第二代集群资源调度框架。
解决了Hadoop第一代集群资源调度框架上可靠性差、扩展性差等一系列问题，同时YARN从MapReduce中完全独立出来，从专门支撑MapReduce任务调度升级成为了一个支持多种应用类型的通用集群资源调度框架。
除了MapReduce之外，Spark、Hive等一系列服务都可以作为应用运行在YARN之上，统一使用YARN为整个集群资源进行宏观的调度与分配
02 资源模型和Container
YARN将服务器资源进行了抽象封装，它使用Container对象代表申请资源的基本单元。
这些资源包括资源名称（服务器名称、机架等）、内存和CPU，YARN通过Container机制将服务器资源进行了隔离。每个应用都可以通过ApplicationMaster向ResourceManager申请资源，当ApplicationMaster向ResourceManager申请资源时，ResourceManager返回的资源使用Container的个数来表示，比如一个Spark计算任务需要5个Container资源。
03 ResourceManager
ResourceManager是一个全局的资源管理器，负责整个系统的资源管理和分配以保证整个集群的高效运行。它会根据容量、队列等限制条件（如每个队列分配一定的资源，最多执行一定数量的作业等），将系统中的资源分配给各个正在运行的应用程序。
ResourceManager只负责根据各个应用程序的资源请求进行资源分配，不参与任何与具体应用程序相关的工作，比如不负责监控或者跟踪应用的执行状态等，也不负责重新启动因应用执行失败或者硬件故障而产生的失败任务，这些均交由应用程序相关的ApplicationMaster完成。资源分配单位用的是我们刚才介绍过的Container对象。
此外，ResourceManager还支持一个可插拔的调度器插件来支持多种资源调度策略，比如使用公平调度或是容量调度。
04 ApplicationMaster
每一个想要运行在YARN上的应用都必须有一个相应的ApplicationMaster实现，应用将内部的任务调度逻辑和监控都交由它们自己的ApplicationMaster实现类来处理。
ApplicationMaster是YARN的一个创新设计，YARN通过这种机制将自己打造成了一个扩展性极强的通用资源调度框架，因为它允许用户开发自己的ApplicationMaster实现。
ApplicationMaster进程在运行的过程中主要负责与ResourceManager进行通信，以申请执行任务时所需要的资源，在申请到资源之后再进一步执行自身内部的调度任务。同时ApplicationMaster也负责监控自己运行的内部任务状态，在任务失败的时候重新为任务申请相应资源并重启任务。
ApplicationMaster通常作为一个应用的主进程，主要用来扮演拆分子任务、汇总结果数据这类的总体调度，比如Spark的Driver进程。而真正的执行程序业务逻辑的进程是在NodeManager进程上执行的。
05 NodeManager
NodeManager是每个服务器节点上资源管理器，负责管理自己所处服务器Containers的整个生命周期。
在YARN上运行的应用最终的逻辑执行程序（比如Spark的task、MapReduce的job）都会在NodeManager的Container中运行，可以说NodeManager是YARN计算节点的代理，因为ResourceManager只会将任务分配到启动了NodeManager进程的服务器。
当NodeManager进程启动的时候它会向ResourceManager进行注册，并定时汇报自己所在服务器的资源使用情况和Container运行状态，同时它也接受并处理来自ApplicationMaster的Container启动和停止等各种请求。
06 单一集群架构
通过上面的介绍我们不难发现，ResourceManager、NodeManager和Container组件都不关心具体的应用程序或任务的类型，只有ApplicationMaster才是应用类型相关的。
YARN通过使用开放ApplicationMaster的集成方式，允许第三方应用框架便捷的和YARN进行集成。这才有了像MapReduce On YARN、Storm On YARN、Spark On YARN和Tez On YARN等众多第三方应用集成方案的出现。
通过这种资源共享的单一集群架构，我们在企业内部可以实现服务器资源真正的共享使用，以达到降低技术集成成本和增强资源整体利用率的目的。
07 工作流程
接下来我们简单看一下YARN的整个工作过程，如图2-13所示。
用户向YARN中提交应用程序。
ResourceManager为该应用程找到一个可用的NodeManager并分配第一个Container，然后在这个Container中启动应用程序的ApplicationMaster。
ApplicationMaster向ResourceManager进行注册，这样用户就可以通过ResourceManager查看应用程序的运行状态并对任务进行监控。
ApplicationMaster采用轮询的方式通过RPC协议向ResourceManager申请和领取资源。
ApplicationMaster申请到资源后与对应的NodeManager通信，要求它启动Container并为任务设置好运行环境。
应用程序的任务开始在启动的Container中运行，各个任务向ApplicationMaster汇报自己的状态和进度，以便ApplicationMaster随时掌握各个任务的运行状态，从而可以在任务失败时重新启动任务。
应用在运行的过程中，客户端通过轮询的方式主动与ApplicationMaster通信以获得应用的运行状态、执行进度等信息。
应用程序运行完成后，ApplicationMaster向ResourceManager注销并关闭自己。
▲图2-13 YARN的工作流程
08 使用场景
基于YARN扩展性强、可靠性强、支持多用户和支持多应用的特点，它非常适合于支撑企业内部构建统一的资源共享型大数据平台。借助YARN我们可以真正实现通过一套资源调度系统集成所有应用组件的单一大集群架构。
- Spark任务调度
Spark是一款分布式内存计算框架，Spark可以将自身的任务调度部分委托YARN进行管理，从而实现集群资源高效整合与利用。 - MapReduce任务调度
同样的，MapReduce任务的整个生命周期都可以借助YARN进行管理，包括任务的分配、资源的调度，等等。
HBase分布式架构处理大数据量
https://blog.csdn.net/zih58888888/article/details/124734494
HBase
什么是BigTable？: 把所有的数据保存到一张表中，采用冗余 —> 好处：提高效率
1、因为有了bigtable的思想：NoSQL：HBase数据库
2、HBase基于Hadoop的HDFS的
3、描述HBase的表结构
核心思想是：利用空间换效率
