BigData day 2
HDFS联邦：
HDFS本身如果说在3个节点上进行相关的部署，那么如果不使用混合部署，那么最多只能部署1个HDFS实例，那么提供的业务也就会 比较单一，这个时候我们可以采用HDFS的联邦机制进行混合部署，每个节点既承担了NameNode的主进程，也承担了其他HDFS实例的备进程。这样做就可以在3台节点上最多部署3个HDFS实例，可以保证业务的多样性，这样做可以节省设备数，但是对于设备的性能和容量都有一定的开销，并且如果3个HDFS的实例业务压力过大，那么可能节点设备会受到一定的业务开销影响。那么在实际的使用阶段，三台服务器共享了底层的DataNode存储存储空间，这样做可以提升整体存储空间的利用率。
强制机架组存储：
在HDFS上，有些情况中，可能会存在有机架异构的情况，比如一个机架使用的是某厂商的设备，另外一个机架使用的是其他厂商的设备，那么这个时候，我们可以选择配置强制机架组，那么强化机架组的安全性要求必须是最高的。在这种情况下，我们在写入3副本数据的时候，系统会强制要求第一份副本写入到强制机架组中，剩下两份副本在按照规则随机写入，如果其中的副本就已经存在于强制机架组中，那么我们就可以不再写强制机架组。
所以整体的写入策略如下：
如果源数据没有在强制机架组上，那么第一份副本一定要在强制机架组上，后边的副本，遵循距离为0,2,4的原则进行存放。其实也就相当于，如果源数据不在 强制机架组上，第一份副本的距离为4，所以后边的两份副本要遵循0,2的距离写
如果源数据在强制机架组上，那么本身强制机架组对源数据就已经提供了保护，那么第一份副本依旧写到强制机架组上和源数据在一起的服务器上，也就是距离为0，第二份副本原则上应该写在 强制机架组的和源数据不同的服务器上，距离为2，但是由于所有的数据都必须在强制机架组上留存有备份，所以为了节省空间那么第二份副本就不在按照距离为2去写，而是按照和第三份副本一样的距离4去写，所以源数据在强制机架组上的情况是一个特例，它的三副本为0,4,4、
HDFS的副本重建机制
如果DataNode没有周期性的上报自己所维护的数据的信息给NameNode，那么NameNode就认为DataNode失效，这个时候NameNode就会启动副本重建机制。如果是源数据所在的DataNode损坏，首先NameNode会把元数据的映射，改动到第二份副本上，之后NameNode会通知其他的副本进行拷贝（首先NameNode会重新分配一块写空间在第二份副本所在的服务器上，之后拷贝一份数据生成新数据的第一份副本，在然后就进行下一次复制，在新数据所在的机架组上分配一块写空间然后创建第二份副本，第三份副本可以直接使用源数据的第三份副本无需改动）
如果损坏的是副本的数据，那么直接重建副本。
集群负载均衡：
在写3副本的时候，为了保证数据可以均匀的写入到Datanode上，那么我们在写第二个和第三个副本的时候，我们会选择当前集群中负载压力最小的节点，然后将数据按照规则写入到相关的Datanode中。但是此策略只对普通的写入生效，如果集群配置了强制机架组，则第一份副本强制写到强制机架组，后边的副本按如上规则写入。并且后边的2/3副本在进行负载选择的时候，也不会选择强制机架组内的节点。
安全模式
当HDFS中有Datanode出现故障，那么这个时候，HDFS就自动的进入到了安全模式中，在安全模式里HDFS是不允许用户进行写操作的，只可以进行只读操作。那么这样做就可以保证在故障出现的时候，故障不会影响到其他的节点，并且故障不会进行扩散。
HDFS回收站机制
HDFS的回收站 其实和普通电脑的回收站是一样的。回收站其实删除的是元数据，那么恢复的时候其实也只是将元数据恢复到对应初始位置。一旦回收站被清空，那么在一定的时间内，数据还是可以找回的。
MapReduce的缺陷和Yarn的背景：
由于MapReduce出现的要比Hadoop要早，所以早期的MapReduce是独立开发的。那么这样做就会产生相关的问题。由于MapReduce在进行资源添加的时候，还需要浪费部分开销进行管理。那么随着集群内的节点数目越来越多，管理节点的资源开销就会越来越大。当某个时间点下，新加入的节点带来的资源和管理该节点消耗的资源相等的时候，这个时候如果再加入新的节点不仅不会造成性能的提升还会使性能有所下降。所以MapReduce的拓展性会受限。
在v1版本中，如果一个任务需要计算30天，那么在29天23小时的时候如果计算节点出现故障，这样的话所有的计算任务和计算结果全部失效。
对于MapReducev1而言，其由于是一个独立组件，所以仅支持MR的计算，而且各个计算引擎之间底层并不互通，所以资源无法共享。
Yarn叫做轻量级的弹性计算平台
在早期的MR中，MR需要部署在新加入的节点中，由于需要对整个集群内所有的节点进行维护，所以开销比较大。在这种情况下MR既是资源的拥有者，也是 资源的使用者
但是Yarn独立于节点之外，每个节点的资源由自身来进行维护，这个时候Yarn只是资源的分配者（Yarn有资源的分配权，但是没有资源的所有权），但不是资源的使用者，资源的维护由节点 自己进行
基本流程
1.用户下发请求
2.Client下发请求给RM
3.RM拉起Appmaster
4.AppMaster申请应用需要消耗的资源
5.RM分配资源
6.AppMaster要求NM拉起资源封装container
7.应用下发到容器内执行
8.计算结果反馈AppMaster，反馈给Client，反馈给用户
9.资源回收，关闭应用
MapReduce详细流程
1.用户将自身的请求封装成为应用（要进行的计算，AppMaster客户端）然后下发到Client。
2.Client收到请求之后 ，首先会找RM中的Appmanager下发提交请求，AppManager收到请求之后，会根据RS中提示的当前负载最小的NM，向其下发请求，要求该负载最小的NM在自身拉起一个Container，然后在其中运行Appmaster。并且APPManager会为该应用分配一个jobID。
3.AppMaster拉起之后 ，下一步AppMaster会向APPManager进行注册，保证其自身的合法性
4.AppMaster会对应用中进行的计算进行资源的按步申请，RS收到请求之后，会查询当前集群中的NM综合负载 ，选择负载最低的NM，分配资源的使用权给AppMaster。
5.AppMaster在收到使用权之后，下一步对应用进行切分，将计算切分成为一个一个的task。之后AppMaster会联系对应的NM，要求NM在自身按照需要拉起Container。
6.容器拉起之后，AppMaster会将切分好的task下发到容器中进行执行。
7.执行完毕之后，结果会返回给AppMaster，然后容器被NM回收，之后NM会将资源空闲的消息 传送给RS。
8.AppMaster最终将结果合并然后反馈给Client。然后AppMaster会向APPManager注销自己。整个任务执行完毕，NM回收资源。
如果用户需要查询进度，那么就通过client直接下发请求到达AppMaster
MapReduce过程详解（逻辑）
1.MapReduce如果想要执行相关的计算，首先要保证数据一定在HDFS上
2.提交：Client提交请求到达RM中的APPManager，APPManager分配一个jobID。用于区分不同应用提交的计算请求。
3.Split：Client在提交应用之前首先会将文件进行切片操作，将文件切分成固定大小的块，默认一个数据块就是一个分片，那么块的大小由用户指定。每个分片中都会携带jobID。
4.下一步Client将job提交给RM中的APPManager，APPManager会查询RS，找到当前集群中负载压力最小的NM，并且将APpMaster下发到该NM中，NM收到请求之后首先会封装一个Container，然后把AppMaster放入其中运行，AppMaster之后会进行资源的计算，并且将job切分为task。之后向RS申请资源，然后将task下发到对应的NM中的容器里。
5.Map-task负责对task进行数据的输入以及任务的执行，然后将map计算的结果放入到一个环形内存缓冲区中，当缓冲区溢出的时候，我们就需要将数据写入到硬盘中。写入硬盘之前，我们有几步操作可以做
5.1分区：我们根据Map输出的结果将数据按照task的个数进行分区操作。具备有相同key（每个task都会携带有一个key值）的记录会被放到同一个分区
5.2排序：比如我们指定了结果按照升序进行排序，那么结果就会排序，该过程是可选的
5.3组合：将结果可以组合起来的，进行组合操作 ，该过程可选
5.4合并：MOF文件（Map out File）溢出的文件比较碎片化而且重复率会比较高，那么为了节省存储空间，我们会将文件先行合并，之后 在写入到硬盘（Hadoop的存储空间-HDFS）中
注：所以分区是以task为单位的，排序可选，组合是针对文件中的内容进行的，合并是针对文件为单位所做的。
6.当Map的环形内存缓冲区输出3%到本地磁盘中的时候，这个时候我们会开始启动Reduce进程。Reduce根据MOF文件的分区数的设置，指定和MOF分区相同个数的Reduce-task。然后负责接收Map任务输出的临时文件。
7.MOF由于其是从环形内存缓冲区中溢出的数据生成的，所以即使经过了分区、排序、组合、合并操作之后，仍然是碎片化的文件，Reduce进程在接收MOF的文件的时候，同样会对MOF文件做相关的合并操作。通过后台的线程，将文件合并成为一个有序的大文件，那么随着最后的maptask计算完成，那么缓冲区中所有的临时文件都会交由reduce处理，reduce在对输出 的mof文件做最后一次合并操作之后，其实相当于是得到了最终的结果，该结果直接输出到用户的输出参数
MapReduce详解流程（终极版）
1.在提交应用之前首先需要保证要计算的文件在HDFS上
2.用户向Client下发一个请求，提交一个应用
3.Client收到用户的请求之后，首先会找到RM中的APPManager申请jobID。
4.Client会将源数据进行切片操作，每一个分片其实就是一个数据块（默认）
5.Client向RM中的APPManager提交请求下发应用。APPManager收到请求之后会找RS查询当前集群的资源使用情况，RS会反馈当前集群中负载最小的节点（NM）然后APPManager会要求该NM在自身拉起一个container，之后将AppMaster下发到该容器中执行。
6.AppMaster启动之后，首先会找APPManager进行注册，保障在自身的合法性。
7.下一步AppMaster会对需要进行的计算以task为单位，向RM中的RS申请资源，RS会根据集群负载选择压力相对较小的几个NM，将该NM中的资源使用权下发给AppMaster
8.AppMaster收到资源使用权之后，会联系NM，要求其在自身按照要求封装容器。然后AppMaster会将task下发到容器中执行。
9.容器中首先收到的任务应该是Map-task，Maptask主要执行的是数据分片的输入和计算，之后会生成临时结果。然后将该结果存入环形内存缓冲区
10.当环形内存缓冲区溢出的时候，就会启动相关进程将内存中的临时文件存储到本地磁盘中，在输出之前需要执行以下几步操作：
10.1分区：根据Map-task的数量设置相同的分区，将来源于相同maptask的结果放入到相同的分区中。
10.2排序：该过程可选，临时结果按照用户的要求进行排序
10.3组合：针对文件中的内容进行组合，将相同的结果进行组合操作，之后减小临时文件的大小
10.4合并：以文件级为单位进行多文件的合并，将多个碎片化的文件合并成一个整体的文件
经过如上的几步操作，那么生成出的文件叫做MOF（Map out file）
11.当MOF文件输出占到总任务执行进度的3%（默认）时，那么就启动Reduce进程（AppMaster需要申请资源…………），reducetask的个数取决于MOF的文件分区数
12.MOF文件被不断地输出到Reduce-task，那么Reduce-task会对MOF文件做进一步的排序和合并，直到最终整合成一个最大的MOF文件，然后将其转发给AppMaster。
13.AppMaster做最后一次文件合并，然后将结果反馈给Client。之后AppMaster会向APPManager注销自己 ，然后NM会回收资源，然后关闭App。
14.NM会向RS上报资源空闲。
Yarn的队列选择
1.基于队列的分配任务数
2.基于已分配的资源
3.基于优先级
3.1基于任务数
3.2基于资源
yarn.nodemanager.memeory-mb []
yarn.nodemanager.vmem-pmem-ratio []
yarn.nodemanager.cpu-vcore []
作业饿死
当作业存在有优先级的时候，如果资源一直分配给高优先级的作业，而不分配给低优先级的作业。那么低优先级就会一直排队永远无法执行。那么为了防止作业饿死，我们必须强制指定每当执行N个高优先级作业的时候，必须要给低优先级分配一次资源。
所谓饿死：就是指由于涉及到优先级的控制，低优先级的资源一直被高优先级抢占而导致低优先级作业无法获取资源执行的情况
动态内存管理
Yarn有一个核心的理念，就是已经执行的任务，要尽可能的满足其对资源的需求，让该任务执行完毕，如果容器需要的资源量过大超过了整个NM可分配的物理阈值，那么就直接关闭该容器
基于标签的调度
比如某集群，其中有一些服务器CPU好些，有一些服务器内存大些，有一些服务器很普通。那么我们就可以给这些服务器打上虚拟的标签，标记三种服务器，高IO服务器（消耗CPU），高内存服务器，普通服务器。用户在提交作业的时候，也可以给应用打上对应的标签，高IO应用，高内存应用，不打标签默认普通应用。那么调度器就会根据标签优先进行服务器的资源分配。
Yarn作业保留
由于AppMaster和APPManager之间需要心跳信息保活，那么APPMaster会周期性的上报心跳给APPManager，其实就是上报任务 的执行情况。那么一旦两者之间的心跳断开，那么APPManager就认为AppMaster失效或损坏，这样，APPManager就会重新找一个NM拉起一个新的容器，然后将AppMaster进行故障恢复，将AppMaster恢复到上一次心跳的状态，此特性通过快照实现
