Hadoop相关原理

1.为什么使用分布式存储?

• 解决单机存储容量有限的问题,采用横向扩展的方式(加机器),来通过分布式的方式实现跨机存储.且可以提高传输效率.

2. HDFS简介, 及其架构组成?

• HDFS全称Hadoop Distributed File System,Hadoop的分布式存储系统,就是用来实现分布式存储的.

• 它由三种角色组成,分别是: namenode,SecondaryNameNode,datanode,作用如下:

  • namenode: 它是HDFS集群的主节点

    • 1.管理整个HDFS集群.

    • 2.维护和管理元数据(描述数据的数据)

  • SecondaryNameNode: 辅助节点

    • 辅助namenode维护和管理元数据.

  • datanode: 从节点

    • 1. 负责存储具体的数据.

    • 2.负责数据的读写操作.

3. HDFS是如何存储文件的?

• 为了统一管理,会按照128MB/块,将文件切割成N个块,为了提高容错,每个块的副本数默认是 3.

• 即:副本机制是 3 ,每个块默认大小:128MB,实际开发中 ,建议副本数2~5.

• 副本数越高:

  • 好处是: 数据的容错率越高,安全性越高.

  • 弊端是:磁盘的利用率降低.

• 每个块的大小, 越大:

  • 好处是: 相同文件大小的情况下,块的数量减少了,元数据也会减低,减少内存空间占用,提高效率.

  • 弊端是: 如果操作的是大量的小文件,块越大,效率越低.

4. namenode如何管理元数据?

1. namenode是通过Edits文件和FsImage文件来维护和管理HDFS的元数据的.

2. 当用户操作HDFS文件的时候(写,改,删),相应的元数据就会发生变化,然后会实时写入到Edits文件中.

   Edits相较于FsImage文件,比较小,所以修改起来速度比较快,记录的是HDFS集群的最新的(最近一段时间)的元数据.

3. 当Edits文件达到一定的阈值(1个小时 或者 100w次),就会将其和FsImage文件合并,形成新的FsImage文件,

   FsImage文件相对较大 ,记录的是HDFS集群所有的元数据(不包括最新的元数据)

4. 对Edits文件 和FsImage文件合并的动作 是有SecondaryNameNode来完成的,全程namenode不参与.

5. 当我们启动Hadoo集群的时候,namenode会去加载FsImage文件 和 最新的 那个 edits文件内容到内存,并启动自检程序,此时HDFS集群会强制进入到安全模式,自检没问题后,会自动退出安全模式.

   

5.SecondaryNameNode如果辅助name管理元数据?

1. SecondaryNameNode会间隔一定时间(60秒)检测namenode的Edits文件的状态.

2. 当其(Edits文件)达到一定的阀值(一个小时或者100w次),就会通知namenode形成新的Edits,并禁用之前旧的Edits文件.

3. SecondaryNameNode会通过http协议将namenode的最近的 Edits文件和FsImage文件拉取到本地进行合并,全程namenode不参与.

4. SecondaryNameNode将合并后的新的FsImage文件推送给namenode.

5. namenode不会立即删除旧的Edits文件和FsImage文件,而是在重启服务器集群或者达到一定的阈值的时候才会自动删除.

   

6.namenode如何管理datanode?

副本机制,心跳机制,负载均衡

7.HDFS的写流程.

1. Client(客户端)请求namenode,进行文件上传.

2. namenode检验该客户端是否有写入数据的权限,且文件是否存在,合法后,会告知该客户端可以上传.

3. Client对HDFS文件进行切块(默认:128MB/块).

4. Client重新请求namenode,第一个Blockde上传位置.

5. namenode接受到请求后,会根据副本机制,负载均衡,机架感知原理,返回该客户端1个datanode列表,例如:node1,node2

6. Client于datanode列表的,第一个datanode进行连接(最近的datanode).

7. Client依次和其他的datanode进行连接,形成传输通道(pipeline),并建立反向应答机制(ACK机制).

8. 采用数据报包(每个包不超过64kb)的形式发送数据,根据传输管道依次发送,并给出Ack回执信息.

9. 重复此步骤,直至第一个Block块的数据上传完毕.

10. Client重新请求namenode,第二个块的上传路径,然后返回第四步,重新往下执行,直至所有的Block块传输完毕,至此,HDFS写数据流程结束.

8.HDFS的读数据流程.

1. 客户端请求namenode,读取文件数据.

2. namenode接收到客户端请求后,会校验文件是否存在.,以及该客户端对此文件是否有读权限,校验合法后,namenode会返回给客户端 该文件的 全部或者部分的块的地址(datanode列表),这些地址都是鲜活的.

3. 客户端根据上述的datanode列表,进行连接,并行的从中读取数据.

4. 当上述的Block读取完毕后,客户端会重新请求namenode剩下的部分或者全部的块信息,然后重复执行上述步骤,直至所有的块数据读取完毕.

5. 客户端按照Block块的编号,把这些块数据拼接到一起,就得到了最终的完整文件,至此,HDFS读数据流程完毕.

9.HDFS的安全模式

1. 概述/解释:

   安全模式是HDFS的一种数据保护机制,在安全模式下,只能读,不能写.

   如何进入安全模式:

   方式1: 当启动HDFS集群的时候,会自动进入到安全模式,自检没问题后,会自动退出.

   方式2: 当副本数 大于 当前 工作状态 的节点(服务器)总数量时,就会强制进入到安全模式.

   方式3: 手动强制进入到安全模式.

   和安全模式相关的命令:

   hdfs dfsadmin -safemode get 查看安全模式的状态(开启,关闭)

   hdfs dfsadmin -safemode enter 手动开启安全模式

   hdfs disadmin -safemode leave 手动关闭安全模式

10.HDFS归档(Archive)问题

1. 概述/解释:

HDFS适合存储大量的大文件,不适合于存储海量的小文件,如果要存储小文件,可以通过归档(archive )操 作, 归档类似于压缩包,但是只有压,没有缩.

格式:

hadoop archive -archiveName 归档包名.har -p 要归档的文件的目录 存放归档文件的目录

11.HDFS的垃圾桶(Trash)机制

概述/作用:
        HDFS默认情况下, 删除文件是永久删除的, 为了提高容错性, 我们可以开启HDFS的垃圾桶机制, 将永久删除改为 放文件到 垃圾桶中(类似于windows系统的 回收站)
    开启垃圾桶的设置如下:
        1. 关闭Hadoop集群.
            stop-all.sh
        2. 去 node1的 /export/server/hadoop/etc/hadoop/ 这个目录下的 core-site.xml 文件中, 加入如下的内容:
            <property>
                <name>fs.trash.interval</name>
                <value>1440</value>
            </property>
        3. 上述的1440是垃圾桶的保存时间, 单位是: 分钟, 所以 1440分 = 1天(24小时), 即: 垃圾桶默认保存1天, 1天后自动(永久)删除.
        4. 把node1的 core-site.xml 远程拷贝给node2, node3
             cd /export/server/hadoop/etc/hadoop/
             scp core-site.xml node2:$PWD           将node1的 core-site.xml 拷贝到node2中, 且放到相同的目录下.
             scp core-site.xml node3:$PWD
        5. 重新启动Hadoop集群, 然后测试删除, 发现: 再删除文件, 就不是永久删除了, 而是放到垃圾桶中.
            start-all.sh
        6. 扩展: 如果我明确知道就是要永久删除这个文件(或者目录), 怎么办呢?
            hadoop fs -rm -skipTrash /data/2.txt        跳过垃圾桶, 直接删除. 相当于永久删除, 不往垃圾桶中放.
​

12.hadoop框架之 Mapreduce相关原理。

1.简述MR的核心8步?
    1.封装输入组件,读取数据源,获取k1,v1.
        k1: 行偏移量,默认从 0 开始.
        v1: 整行数据.
    2.自定义MapTask任务,负责:拆分,获取 K2,v2.
        k2: 单词
        v2:单词的次数,默认记录为1.
    3.分区.
        默认是哈希取模分区法,就是给数据打标记,标记着这个数据将来被哪个ReduceTask任务处理.
        默认只有1个分区,即:只有一个ReduceTask任务,所以分区标记默认是:0;
    4.排序.默认按照k2,进行升序排列.
    5.规约. 默认对Map端的数据做局部合并,目的是:降低Reduce端拉取的数据量,减少输出,提高计算效率.
    6.分组. 默认按照k2分组,获取到k2,v2的集合.
    7.自定义的ReduceTask任务,负责:合并.获取k3,v3.
    8.封装输出组件,把结果写出到目的地目录中.
    
细节:
    1.MapReduce程序中,MapTask负责: 分, ReduceTask 负责: 合.
    2.1个切片(默认和Block大小一样,128MB) = 1个MapTask任务 = 1个分好区,排好序,规好约,分好组的文件.
    3.1个分区(默认只有一个分区)=1个ReduceTask任务=1个最终的结果文件.
    4.如果简单划分,MapReduce程序由Map阶段和reduce阶段组成.
      如果详细划分,MapReduce程序 Map阶段Shuffle阶段(指的是: 分区,排序,规约,分组)Reduce阶段组成.
    5.Hadoop是1个IO(Iuput输入/output输出)密集型框架,涉及到大量的内存和磁盘之间的交互,所以Hadoop(MapReduce)计算效率相对较低.
​
2.简述MR的执行流程.
    1.MR程序由MapTask任务(负责拆分) 和 ReduceTask任务(负责合并)组成,其中:
        1个切片(默认和Block大小一样,128MB) = 1个MapTask任务 = 1个分好区,排好序,规好约,分好组的文件.
        1个分区(默认只有一个分区)=1个ReduceTask任务=1个最终的结果文件.
    2.先对文件进行切片,每个切片由1个MapTask任务(线程)来处理,且MapTask是逐行从该切片中读取数据,逐行处理的.
    3.MapTask任务会将处理后的数据放到环形缓冲区(默认大小:100MB,溢写比:0.8),当达到80%的时候,就会触发溢写线程(spill),将该部分数据(80M)写到磁盘,形成 磁盘小文件.
    4.随着MapTask不断的处理,不断的溢写,磁盘小文件不断的增加,当该切片的数据处理完毕后,MapTask任务会对这些磁盘小文件做合并,默认:10个/次,最终形成1个分好区,排好序,规好约,分好组的文件.
    5.ReduceTask会开启1个拷贝线程(Copy),从上述的(多个)文件中,拉取属于自己的数据(根据分区编号识别),然后做合并,排序,统计,获取最终结果.
    6.将ReduceTask任务处理后的结果数据,写到磁盘文件中,至此:MR程序执行完毕.

13.Yarn相关原理

1.什么是资源调度.
    指的是当系统繁忙的时候,如果有多个程序申请分配资源,如何进行资源划分,分配,如何最大化实现资源利用率,就是资源调度做的事.
    简单来说: 资源调度就是提高资源利用率的, 核心是: 调度策略,调度算法.
2.Yarn简介及架构介绍.
    Yarn属于Hadoop组件的一部分,是: 大数据分布式任务接收 和 资源调度器. 负责资源接收 和 任务调度的.
    细节: Yarn负责计算任务的资源调度,至于是什么任务,Yarn根本不关心,只要符合Yarn规则即可.
    Yarn架构:
        ResourceManager:   主节点
            1.负责管理整个Yarn集群(的资源)
            2.负责任务的接收.
            3.负责资源的调度.
        NodeManager:
            1.负责管理本机的资源.            用Container资源容器的方式管理.
            2.负责具体任务的执行.
        Appmaster:
            1个计算任务 = 1个AppMaster进程(Application Master, 应用程序管理者)
            由该AppMaster进程来管理该计算任务,包括该计算任务的监控,协调,申请资源等一系列操作.

14.为什么需要MAPREDUCE？

（1）海量数据在单机上处理因为硬件资源限制，无法胜任。
​
（2）而一旦将单机版程序扩展到集群来分布式运行，将极大增加程序的复杂度和开发难度。
​
（3）引入mapreduce框架后，开发人员可以将绝大部分工作集中在业务逻辑的开发上，而将分布式计算中的复杂性交由框架来处理。