Hadoop学习

Hadoop

HDFS

组成部分

• NameNode（NN）：负责存储元数据，处理用户访问请求， 提供读写路径；

  • Secondary NameNode：主要用于对主节点中的FsImage和追加文件进行合并重写，FsImage和追加文件EditLog的关系类似于Redis中的RDB和AOF；

  • Activate NameNode：负责对外提供服务的Leader节点；

  • Standby NameNode：Follower节点，备用选主，与Activate NameNode保障HA

• DateNode（DN）：负责存储数据的存储节点，定期与NameNode进行心跳数据交换；

  HDFS Federation

  • Why Federation：单个NameNode负责管理集群导致了单点性能瓶颈，即当集群机器数量特别多是元数据会填满NAMseNode的内存，因此需要进行水平扩展（Federation）提高系统扩展性；

    Normal Federation

    • Block Pool存储于DN的内存中，由于某个NS中的Block会存在于多个DN中，因此不同DN中属于该NS的Block Pool共同组成了属于该NS的Block Pools；

    • DN是物理概念，Block Pool是逻辑概念。Block Pool只存储着属于该命名空间中的Block，但DN存储着不同Block Pools中的块信息。也就是说不同的Block Pool共用同一套DataNode集群，Block Pool为不同命名空间中的数据提供了隔离；

    • Namespace和Blocks共同组成Namespace Volume；

    • Datanode中的数据结构都通过块池ID（BlockPoolID）索引，即datanode中的BlockMap，storage等都通过BPID索引。在HDFS中，所有的更新、回滚都是以Namenode和BlockPool为单元发生的。即同一HDFS Federation中不同的Namenode/BlockPool之间没有什么关系；

      缺点：访问不同的NN需要记住并输入不同的地址，非常麻烦。

      ViewFS

      ViewFS类似于Linux的文件系统设计，其将不同NN下管理的资源视为linux中的挂载点，比如NN1视为/tmp，NN2视为/mount1，通过利用挂载映射表其对不同的NN访问路径，同一转化为以根目录为起点的Linux文件路径。

      • 配置默认的文件系统访问路径映射：

          
            
              fs.default.name
              viewfs://ClusterName/
            
        

        注意如果开启了NN的HA，则使用fs.defaultFS，否则使用fs.default.name。

      • 配置挂载目录，以/data和/tmp为例：

          
            fs.viewfs.mounttable.wecluster.link./data
            hdfs://master:9999/user
          
          
            fs.viewfs.mounttable.wecluster.link./tmp
            hdfs://master:9999/tmp
          
        

        此时访问/tmp和/data时就会自动添加上前缀路径。

        缺点：没有负载均衡，且是客户端技术，升级维护后需要将配置文件分发给所有客户端，不易维护。

        Router-Based Federation

        • Router：为解决客户端配置导致的维护繁琐问题，可以考虑使用代理的方式将挂载表与客户端解耦提高集群可维护性，而Router就是该代理服务。Router主要提供以下内容：

          • Federated Interface：与NN有相同的接口，用于解析Client请求并转发到正确的集群；

          • NameNode HeartBeats：接受Router管控的NameNode心跳信息，并将心跳中的集群属性信息存储到State Store；

          • 为了高可用一般Router会监控多个NN节点，这样当本集群的NN万一挂掉可以使用其他Router进行路由；

        • State Store：即可以本地存储，也可以存到zk中，主要存储以下内容：

          • 存储Mount Table，该表保存着文件路径和子集群的关系；

          • 存储Memebership Table：存储Router监控的NN信息，如DN数量、NN的HA状态和Router状态；

          因此，整个RBF的流程可以归纳为如下：

          • Client向Router发出读请求；

          • Router在Mount Table中找到实际的NN路径映射；

          • Router查询Membership Table中进行目标NN检查，确认alive；

          • 向NN转发请求

            Mapreduce

            MapTask

            ReduceTask

            Shuffle

            Yarn

            • Why Yarn：在MRv1中，计算和资源的调度完全由master单点负责进行，master不仅压力过大，而在只要宕机就会导致整个集群计算失败。可以看出，MRv1违背了单一职责这一设计原则，master承担了多个职责，导致系统维护的困难。此外，由于MRv1自己管理自己，因此无法支持其他的计算模型，如Storm和Spark等，系统复用性和兼容性较差，耦合严重。因此，为了提高系统兼容性和可扩展性，MRv2对将资源分配和计算调度进行了分离，并且根据依赖倒转原则设计实现了Yarn资源调度框架。任何计算模型只要实现了Yarn规定的接口即可运行。

              组成

              • ResourceManager（RM）：负责全局的资源分配管控，管理ApplicationMaster，同时处理Client提交的Job请求。RM包含以下两个主要组件：

                • Applications Manager（AM）：负责接收用户的Job提交请求，为Job的AMs协商资源并通知NM启动，同时负责AMs的失败重启；

                • Scheduler：负责提交的Job作业调度，支持FIFO、公平调度和容量调度等策略；

              • NodeManager（NM）：NM主要负责局部（本机）资源管控，管理Container的生命周期并负责与RM进行心跳链接，向RM提交自己管控机器的使用状态；

                • Application Master（AMs）：用户提交的每一个Job都会对应一个AMs，AMs会算出本次Job所需要的资源并进行需求上报；

                • Container：资源分配调度的基本对象（CPU、存储和GPU等资源），对不同任务进行资源隔离。

                流程

                • 向RM(AM)提交计算需求，包括源文件、执行计算逻辑和输出路径，RM返回job_id；

                • RM(AM)找到有空闲资源的NM，通知其打开一个Container运行AMs；

                • AMs管理Job任务调度，计算需要的Task及其需要的资源，出具表单在向RM(AM)注册自己并申请Task计算资源；

                • RM根据AMs提交的资源申请通知相关NM开启Container，并将NM分配情况进行表单开具返回给AMs；

                • AMs根据RM返回的资源分配表找到相应的NM，通知进行Task的异步运行；

                • Task运行完毕后向AMs报告，当所有Task完成任务后AMs向RM(AM)申请注销自己，同时RM通知其余NM回收相关的Container资源。

                  Yarn Federation