Hadoop原理

HDFS原理:

问题1: 为什么要用分布式?

答案:解决单机存储容量有限的问题,可以通过分布式解决(即:横向扩展,加机器)

问题2:HDFS是什么?有几种角色?各自作用是什么?

答案: HDFS是分布式文件存储系统,采用分布式的方式存储数据.HDFS是主从架构,主要角色有三个:

        NameNode: 主节点

               1. 管理整个HDFS集群

               2. 维护和管理元数据

        SecondaryNameNode: 从节点

                辅助nameNode管理元数据

        DataNode: 从节点

                1. 负责数据的读写操作

                2. 负责存储具体的数据(Block块)

问题3: HDFS的默认副本是几,默认的块大小是多少?

答案: 默认节点是3, 每个Block块的大小是128MB(Hadoop 2.x 之后为128MB,Hadoop1.x为64MB).实际开发中, 副本数一般是2-5, 副本数越高带来的好处是容错率越高, 带来的弊端是磁盘的利用率降低.

问题4:nameNode如何管理Block块? / nameNode如何管理元数据?

答案:   1. namenode通过管理 Edits文件 和 FsImage文件来实现管理元数据的目的.
            2. Edits文件, 相对较小, 修改起来速度较快, 记录的是最近一段时间的元数据信息.
            3. FSImage文件, 相对较大, 记录的是HDFS的所有元数据.
            4. HDFS集群启动的时候, namenode会去加载FsImage文件 和 最近的那个 Edits文件的元数据进内存.

问题5:  SecondaryNameNode如何辅助namenode管理元数据?

答案:  1. SecondaryNameNode会实时监听(间隔60秒)Edits文件的状态, 当其(Edits文件)达到一定的阈值(1个小时或者100W次),
       SecondaryNameNode就会通知namenode禁用该Edits文件, 然后创建1个新的Edits文件, 继续往里写入.
    2. SecondaryNameNode会通过Http协议将namenode中的Edits文件 和 FsImage文件拉取到本地进行合并, 形成新的FsImage文件.
       合并全程, namenode不参与.
    3. 然后SecondaryNameNode会将合并后的新的FsImage文件推送给namenode, 用来替代旧的FsImage文件.
    4. namenode上会有大量的Edits文件和一堆的FsImage文件, 这些文件不会被立马删除, 而是在服务重启的时候, 或者达到一定阈值的时候, namenode才会删除.

问题6:  namenode如何管理datanode?

答案: 副本机制(默认是3) , 心跳机制( 3秒 , 60秒 , 6个小时 ) , 负载均衡

问题7:  HDFS的默认副本数是3, 请问这3个副本是如何存储的?

答案:  第1副本: 优先本机, 否则就近随机.
    第2副本: 和第1副本相邻的不同机架的某个服务器上.
    第3副本: 和第2副本相同的机架的不同服务器上.
    如果不满足上述情况, 则 随机存储.

问题8: HDFS写数据的流程?

答案:  1. Client请求namenode, 上传文件.
    2. namenode接收到请求后, 校验权限, 然后告知Client是否可以写数据.
    3. 假设可以写数据, 此时, Client对文件进行切块(默认: 128MB/块)
    4. Client重新请求namenode, 第1个Block的上传位置.
    5. namenode返回第1个块的上传位置, 即: datanode列表, 例如: node1, node2, node3
    6. Client和最近的那个datanode建立连接, 并依次和其它的datanode建立连接, 形成 传输管道(pipeline)
    7. 采用数据报包(默认: 64KB)的方式传输数据, 并建立反向应答机制(Ack).
    8. 依次传输, 直至第1个Block块传输完毕.
    9. 回到第4步, Client重新请求第2个Block的上传位置, 重复后续动作, 直至所有的Block传完.
    10. 至此, HDFS写数据流程结束.

问题9: HDFS读数据的流程?
答案:  # 核心词: 并行.
    1. Client请求namenode, 读取文件数据.
    2. namenode校验权限合法后, 返回该文件的部分或者全部的Block块信息(即: 这些块在哪些datanode上存储)
    3. Client连接这些datanode, 并行的从中读取这些Block块的信息.
    4. 当上述的块信息读取完毕后, Client会请求namenode获取剩下的全部或者部分的块信息, 直至所有的块读取完毕.
    5. 按照块的编号, 对读取到的数据做合并, 获取最终结果文件, 至此HDFS读数据流程完毕.

HDFS的安全模式(Safemode)介绍
    概述:
        安全模式是HDFS的一种保护机制, 其特点是: 在安全模式下, 只能读, 不能更新(因为更新会修改元数据)
    问题: 什么时候会进入到安全模式?
    答案:
        情况1: 启动HDFS集群的时候, namenode会去读取Edits文件 和 FsImage文件的元数据信息到内存中, 该过程中会强制进入到安全模式.
              过程结束(HDFS自检动作没问题), 会自动退出安全模式.
        情况2: 当datanode的数量 小于 副本数的时候, 会强制进入到安全模式.
        情况3: 手动进入到安全模式, 一般用于排错.
    涉及到的命令如下:
        hdfs dfsadmin -safemode get         查看安全模式的状态, OFF:关, ON:开
        hdfs dfsadmin -safemode enter       进入到安全模式
        hdfs dfsadmin -safemode leave       退出安全模式

HDFS的归档(Archive)介绍:
    概述:
        HDFS适用于存储海量的大文件, 那如果要用HDFS存储大量的小文件时, 每个小文件都会占用1个Block块, 就会导致元数据过多, 针对于这种情况,
        就可以用 归档 技术来解决.
    本质:
        归档相当于把大量的小文件放到一起, 形成1个整体, 类似于压缩包的动作, 但是只有压, 没有缩.
    好处:
        n个小文件 = n个Block块 = N份元数据    => 归档后,  n个小文件 = 1个归档包(文件) = 1个Block块 = 1份元数据信息
    相关操作:
        1. 在HDFS下创建data文件夹, 里边有1.txt, 2.txt, 3.txt三个文件.
            hadoop fs -put *.txt /data
        2. 把 /data目录下的 3个txt文件 合并成 1个归档包, 放到 /output目录下.
            细节: 归档的底层其实是MR程序.
            格式如下:
                hadoop archive -archiveName 归档包名 -p 要归档的文件路径 存放归档包的路径
            例如:
                hadoop archive -archiveName myTest.har -p /data /output
        3. 去 /output目录下查看内容, 发现(直接)看不到 1.txt, 2.txt, 3.txt的信息.
            hadoop fs -ls /output/myTest.har            -- 看不到 1.txt, 2.txt, 3.txt的信息. 因为文件系统前缀是  hdfs://ndoe1:8020/
            hadoop fs -cat /output/myTest.har/1.txt
        4. 如何去归档包中查看归档前的内容内? 命令如下:
            hadoop fs -ls har:///output/myTest.har     -- 可以看到, 因为用的是 har:///这个前缀, 全称是:  har://hdfs-node1:8020/
            hadoop fs -cat har:///output/myTest.har/1.txt

            hadoop fs -ls har://hdfs-node1:8020/output/myTest.har
            即: 写不同的前缀, 意味着用不同的文件系统来识别该文件.
        5. 删除/data目录下的 3个txt文件, 然后从 /output 的归档包中拷贝 3个txt文件 到 /data目录下.
            hadoop fs -cp /output/myTest.har/ /data           -- 把归档包拷贝到 /data目录下, 拷贝的是 myTest.har包下的内容, 达不到我们要的效果.

            hadoop fs -cp har:///output/myTest.har/ * /data     -- 把归档包拷贝到 /data目录下, 归档拷贝.
    结论:
        归档操作实际开发中, 一般是一周或者1个月做一次, 把该周或者该月所有的数据放到1个归档包中, 降低元数据, 且后期需要单独使用的时候, 也可以很方便的从归档包拷贝数据出来.

HDFS的垃圾桶(Trash)机制:
    概述:
        如果没有开启HDFS的垃圾桶机制, 默认是直接删除文件或者文件夹的, 不走垃圾桶(不可恢复, 相当于永久删除).
        如果开启了HDFS的垃圾桶机制, 则删除数据(文件或者目录)的时候, 本质是将该 文件/目录 移动到垃圾桶中(可恢复的).
    开启垃圾桶的方式:
        1. 修改 /export/server/hadoop/etc/hadoop/core-site.xml 文件, 加入如下内容:
    <property>
        <name>fs.trash.interval</name>
        <value>1440</value>     # 垃圾桶保留多长时间, 单位是: 分钟, 即: 1天.
    </property>
        2. 记得将 core-site.xml文件分发给node2, node3, 即: 三台机器都要修改.
            scp core-site.xml node2:$PWD
            scp core-site.xml node3:$PWD
           如果你不想拷贝, 就手动逐个机器修改, 修改node1的core-site.xml, 修改node2的, 修改node3的...
        3. 重启Hadoop集群.
            stop-all.sh
            start-all.sh        # 这两个命令均是在 node1中执行的.
        4. 之后就可以测试删除的功能了, 涉及到的HDFS Shell命令如下.
            hadoop fs -rm /data/2.txt                                      -- 此时的删除就是 剪切到 垃圾桶中.
            hadoop fs -mv /user/root/.Trash/Current/data/2.txt /data       -- 从垃圾桶中恢复源文件.
            hadoop fs -rm -skipTrash /data/2.txt                           -- 跳过垃圾桶, 相当于永久删除.

MapReduce

问题1. 什么是计算, 什么是分布式计算?
答案:
    计算指的是从海量数据中提取出有效的价值信息的过程(广义上解释), 狭义上指的是 1 + 1 = 2 即: 数学运算.
    分布式计算指的是 多台机器协调, 共同完成同1个计算任务.

问题2: 分布式计算的两种模式?
答案:
    分散汇总模式:
        大家各自做各自的, 最后交由主节点汇总.  例如: MR程序就属于这种.
    中心化模式, 步骤执行:
        由老大(主节点)统筹安排各机器的计算任务, 第一步, 第二步等..., 最后将结果交由主节点汇总.

问题3: 我们知道MR是一种分布式计算架构, 采用的是 分而治之 的思想, 那么是不是所有的场景都适合用分而治之呢?
答案:
    不一定, 看需求, 如果把大任务拆分成n个小任务之后, 小任务之间的依赖度比较高的情况下, 就不适合用分而治之思想.
    例如: 求平均数.

问题4: 请简述MR的核心八步?
答案:
    1. 定义输入组件, 负责读取数据源. 逐行读取.
    2. 自定义MapTask任务, 负责 分.
    3. 分区.
    4. 排序.
    5. 规约.
    6. 分组.
    7. 自定义ReduceTask任务, 负责 合.
    8. 定义输出组件, 将结果写到目的地文件中.

问题5: 请简述MR程序的执行流程?
答案:
    1. MR程序分为MapTask阶段 和 ReduceTask阶段, 且:
        1个切片 = 1个Block块 = 1个MapTask任务 = 1个分好区, 排好序, 规好约的文件.
        1个分区 = 1个ReduceTask任务 = 1个结果文件.
    2. 先对文件切片, 每个片的大小默认和Block块大小一致(即: 128MB), 且每个切片的数据会交由1个MapTask任务来处理.
    3. MapTask任务采用逐行的方式从切片中读取数据, 逐行处理, 且会将处理后的数据放到 环形缓冲区(默认大小:100MB, 溢写比:0.8)
    4. 当环形缓冲满(80MB)的时候, 会触发溢写线程(spill), 对该部分数据做分区, 排序, 规约的操作, 然后存储到磁盘上(小文件)
    5. 对上述的小文件进行合并(默认: 10个一合并), 获取最终的文件, 即: 1个MapTask = 1个分好区, 排好序, 规好约的文件.
    6. 当MapTask任务执行结束后, ReduceTask会开启1个拷贝线程, 从各个MapTask的结果文件中, 拷贝属于自己的数据(根据分区编号识别).
    7. ReduceTask对数据进行 合并, 排序的操作, 获取最终结果数据.
    8. ReduceTask将处理好的结果数据写到磁盘文件中, 1个ReduceTask = 1个结果文件, 至此, MR程序执行结束.
 

Yarn

问题1: 什么是资源?
答案:
    资源指的是硬件资源, 例如: CPU, 内存, 磁盘, 声卡, 网卡, 显卡...

问题2: 什么是调度, 目的是什么?
答案:
    调度指的是当程序执行的时候, 所需资源有我们来集中管理分配, 目的是: 提高资源利用率.

问题3: 我们知道Yarn是大数据分布式集群 统一任务接收 和 资源调度器, 怎么理解统一呢?
答案:
    Yarn是负责调度计算任务的, 至于计算任务是什么, Yarn根本就不关心, 只要符合Yarn规范即可.
    即: 无论是MapReduce计算任务, Spark计算任务, Flink计算任务, Yarn都能调度.

问题4: Yarn架构角色介绍 及 功能?
答案:
    Yarn属于大数据分布式集群 统一任务接收 和 资源调度器, 由 ResourceManager 和 NodeManager两种角色组成.
    ResourceManager作用:
        1. 负责管理整个集群的资源.
        2. 负责任务的接收.
        3. 负责资源的调度 和 分配.
    NodeManager作用:
        1. 管理本机的资源.
        2. 负责具体任务的执行.
    所谓的管理资源, 其实就是开辟容器空间, 也叫: 资源空间, 资源容器(Container).

问题5: 请简述Yarn调度MR程序的流程? 也可能问: Yarn调度job(计算任务)流程.
答案:
    8步, 详见随堂图片.

问题6: 请简述你对Yarn的三种调度策略的理解?
答案:
    FIFO Scheduler: 先进先出调度器, 类似于: 单车道,  目前几乎不用.
        优点: 每个计算任务都独享集群 100%的资源.
        缺点: 当小任务前有大任务在执行时, 小任务可能迟迟无法执行结束, 必须等待大任务执行完毕.

    Capacity Scheduler: 容量调度器, 类似于: 多车道.    Apache Hadoop(社区版)默认用的调度策略.
        优点:
            1. 支持多任务并行执行.
            2. 且支持资源借调.
        缺点:
            1. 可能存在资源无法归还的情况.
            2. 存在资源浪费的情况, 即: 任务无法独享集群100%的资源.

    Fair Scheduler: 公平调度器, 类似于: 潮汐车道.     最早是由FaceBook研发的, 后续我们要用的 商业版Hadoop, Yarn的调度策略就是这一种.
        优点:
            1. 支持多任务并行执行.
            2. 且支持资源借调.
                当有第1个任务执行的时候, 它独占集群100%的资源,
                当有第2个任务执行的时候, 它(第1个任务)会分一半的资源给到第2个任务.
                第有第3个任务执行的时候, 会再分一半的资源出去, 即: 三个任务的资源使用率都是 33.333%...
        缺点:
            当有大量小任务执行的时候, 存在大任务迟迟无法执行结束的情况.