1.分布式和集群介绍

分布式: 多台机器做不同的事情, 然后组成1个整体.
集群: 多台机器做相同的事情

多台机器既可以组成中心化模式**(主从模式), 也可以组成去中心化模式(主备模式)**

A.员工1和A.员工2的关系是集群，A.员工1和B.员工1的关系是分布式

1.Hadoop的架构图

Hadoop1.X = HDFS + MapReduce：现在已经不使用了

hadoop2.x和3.x：HDFS+MapReduce+Yarn

2.Hadoop集群环境HDFS

1.HDFS原理--分布式介绍

分布式存储解决了单机存储容量有限的问题, 且带来了比较高的性能提升. 例如: 3台服务器, 就是3倍的传输效率, 读写效率...
细节: 横向扩展 = 加机器, 纵向扩展 = 加配置(硬件)

2.HDFS原理--架构图

namenode:1.管理整个HDFS集群 2.维护和管理元数据

SecondaryNameNode:辅助节点 1.辅助namenode管理元数据

datanode:从节点 1.维护和管理源文件 2.负责数据的读写操作 3.定时向namenode报活

3.高可用模式：

没有SecondName ，多个namenode主备模式宕机一个就zookeeper选举切换到另一。

4.HDFS原理--分块存储

对HDFS的分块存储机制的理解.

分块存储是为了方便统一管理的, 默认的块大小为: 128MB. 细节: Hadoop2.X开始才是128MB, Hadoop1.X是: 64MB.

副本机制是为了提高容错率, 副本数越多, 容错率越高. 带来的弊端是: 磁盘利用率下降了.

实际开发中, 建议副本数为: 2 ~ 5

如果要修改block块的大小和默认的副本数, 可以去: Hadoop的配置文件中修改.
路径为:
/export/server/hadoop/etc/hadoop/hdfs-site.xml
官方配置文档路径为:
https://hadoop.apache.org/docs/r3.3.0
https://hadoop.apache.org/docs/r3.3.0/hadoop-project-dist/hadoop-hdfs/hdfs-default.xml

参考配置信息如下:

 <!---->
            <!--设置: 副本数-->
            <property>
                <name>dfs.replication</name>
                <value>3</value>
            </property>

            <!--设置: 每个块的默认大小-->
            <property>
                <name>dfs.blocksize</name>
                <value>134217728</value>
                <description>设置HDFS块大小，单位是b</description>
            </property>

5.HDFS原理--namenode如何管理元数据

namenode是通过一批Edits(小) 和 1个FSImage(大)两类文件来维护和管理元数据的.

Edits文件相对较小, 操作起来速度相对较快, 它只记录HDFS最近一段状态的元数据信息.
阈值: 1个小时或者 100W次

FSImage文件相对较大, 操作起来速度相对较慢, 它记录的是HDFS集群除最近状态外, 其它所有的元数据信息.

HDFS集群启动的时候, 会自动加载FSImage文件和最新的Edits文件进内存, 用于记录元数据.
整个过程称为HDFS的自检动作, 此状态下, HDFS集群会强制进入到安全模式, 只能读, 不能写.

我们HDFS集群的Edits文件和FSImage文件存储在: /export/data/hadoop/dfs/name/current

6.HDFS原理--SecondaryNameNode如何辅助namenode管理元数据

SecondaryNameNode会间隔60s(秒), 询问一次namenode, edits文件是否满足了阈值(1个小时, 或者100W次)

如果满足条件, 就通知namenode创建新的Edits文件, 继续往里写入元数据信息.

根据http协议, 从namenode上把要合并的edits文件和 fsimage文件拉取到本地进行合并.

将合并后的新的FSImage文件推送给namenode, 用来替换之前旧的FsImage文件.
细节: 旧的FSImage文件并不会被立即删除, 而是达到一定的阈值后, 才会被删除.

对于Edits文件和FSImage文件的合并操作, 是由SecondaryNameNode独立完成的, 全程namenode不参与.

实际开发中, namenode 和 SecondaryNameNode会被部署到不同的服务器上, 配置几乎一致, 只不过SecondaryNameNode的内存要稍大一些.

在紧急情况下, SecondaryNameNode可以用来恢复namenode的元数据.

7.HDFS原理--三大机制详解

三大机制:
副本机制: 默认是3, 可以提高容错率, 但是磁盘的利用率降低.
负载均衡: namenode尽量保证多台datanode资源使用率一致.
心跳机制: 3秒, 630秒, 6个小时.
副本如何存储:
根据副本机制, 负载均衡, 机架感知原理, 网络拓扑图(寻找最近机架)进行计算, 并存储, 结论如下:
第1副本: 优先本机, 否则就近随机.
第2副本: 第1副本所在机架, 就近的某个机架的随机的服务器上.
第3副本: 和第2副本同一机架的不同服务器上.
如果不满足, 则: 随机存储.

8.HDFS原理--HDFS写数据流程

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

namenode接收到客户端请求后, 会校验权限, 并告知客户端是否可以上传.
校验: 客户端是否有写的权限, 及文件是否存在.

如果可以上传, 客户端会按照128MB(默认)对文件进行切块.

Client(客户端)再次请求namenode, 第1个Block块的上传位置.

namenode会根据副本机制, 负载均衡, 机架感知原理及网络拓扑图, 返回给客户端存储该Block块的DataNode列表.
例如: node1, node2, node3

Client(客户端)会先连接就近的datanode机器, 然后依次和其他的datanode进行连接, 形成: 传输管道(Pipeline)

采用数据报包(DataPacket)的形式传输数据, 每个包的大小不超过: 64KB, 并建立: 反向应答机制(ACK机制)

具体的上传动作: node1 -> node2 -> node3, ACK反向应答机制: node3 => node2 => node1

重复上述的步骤, 直至第1个Block块上传完毕.

9.HDFS原理--HDFS读数据流程

1. Client(客户端)请求namenode, 读取文件.
 2. namenode校验该客户端是否有读权限, 及该文件是否存在, 校验成功后, 会返回给客户端该文件的块信息.
     例如:
         block1: node1, node2, node5
         block2: node3, node6, node8
         block3: node2, node5, node6     这些地址都是鲜活的.
         ......
 3. Client(客户端)会连接上述的机器(节点), 并行的从中读取块的数据.
 4. Client(客户端)读取完毕后, 会循环namenode获取剩下所有的(或者部分的块信息), 并行读取, 直至所有数据读取完毕.
 5. Client(客户端)根据Block块编号, 把多个Block块数据合并成最终文件即可.

10.HDFS原理--安全模式介绍

安全模式是HDFS自带的有一种保护机制, 在安全模式下, 只能读, 不能写.
 进入安全模式的方式:
     1. 启动Hadoop集群的时候, 会自动进入到安全模式, 进行自检. 自检没问题后, 会自动关闭安全模式.
     2. 当活跃的节点数 < 默认的副本数时, 会强制进入到安全模式.
     3. 手动进入.
         格式:
             hdfs dfsadmin -safemode get | enter | leave     获取 | 进入 | 离开

11.HDFS原理--归档操作

背景:

HDFS适用于操作海量的大文件, 如果小文件过多, 就会占用多个Block块, 且也有多份元数据, 资源消耗比较大.
针对于这种该情况, 我们可以用归档包来解决它.（归档文件.har）
概述:
归档包类似于压缩包, 但是只有压, 没有缩, 相当于把多个文件合并成1个文件, 这样元数据就只有1份儿了.
格式:
hadoop archive -archiveName 归档包的名字 -p 要被归档的文件名存储归档包的路径

演示步骤:

1. 在Linux中创建 1.txt, 2.txt, 3.txt三个文件.
        echo 'hello world   1' >> 1.txt
        echo 'hello world   2' >> 2.txt
        echo 'hello world   3' >> 3.txt
2. 在HDFS中创建data目录, 然后将上述的3个文件分别上传过来.
        hadoop fs -put *.txt /data
3. 通过上述的命令, 把上述的3个txt文件 压成 归档包.
       需求: 把/data/所有的txt文件 这三个记事本, 创建归档包, 并将归档包存储到:  /output目录下.
       格式如下:
         hadoop archive -archiveName myTest.har -p /data/ /output
4. 查看归档包的内容.
        [root@node1 ~]# hadoop fs -ls /output/myTest.har         -- HDFS路径默认前缀是:  hdfs://node1:8020/
        Found 4 items
        -rw-r--r--   3 root supergroup          0 2024-01-17 15:09 /output/myTest.har/_SUCCESS
        -rw-r--r--   3 root supergroup        250 2024-01-17 15:09 /output/myTest.har/_index
        -rw-r--r--   3 root supergroup         23 2024-01-17 15:09 /output/myTest.har/_masterindex
        -rw-r--r--   3 root supergroup         43 2024-01-17 15:09 /output/myTest.har/part-0

        遇到的问题: 发现, 上述的代码不能直接看到归档包 具体 归档了哪些文件, 那如何查看呢?
        解决方案: 把前缀换成归档包的前缀即可, 用什么前缀, 说明用什么规则来解析按 归档包.
            hadoop fs -ls har:///output/myTest.har

            [root@node1 ~]# hadoop fs -ls har:///output/myTest.har
            Found 3 items
            -rw-r--r--   3 root supergroup         15 2024-01-17 15:05 har:///output/myTest.har/1.txt
            -rw-r--r--   3 root supergroup         14 2024-01-17 15:05 har:///output/myTest.har/2.txt
            -rw-r--r--   3 root supergroup         14 2024-01-17 15:05 har:///output/myTest.har/3.txt
            [root@node1 ~]#
            [root@node1 ~]# hadoop fs -ls har://hdfs-node1:8020/output/myTest.har
            Found 3 items
            -rw-r--r--   3 root supergroup         15 2024-01-17 15:05 har://hdfs-node1:8020/output/myTest.har/1.txt
            -rw-r--r--   3 root supergroup         14 2024-01-17 15:05 har://hdfs-node1:8020/output/myTest.har/2.txt
            -rw-r--r--   3 root supergroup         14 2024-01-17 15:05 har://hdfs-node1:8020/output/myTest.har/3.txt

5. 从 /data目录中, 删除 1.txt, 2.txt, 3.txt这三个文件. 然后解压归档包, 获取到源文件.
       hadoop fs -cp /output/myTest.har/ /data              实现不了想要的效果, 只是把 归档包下所有的内容拷贝过去了.
       hadoop fs -cp har:///output/myTest.har/* /data       这个才是我们要的语句.

细节:
    1. 归档包名的后缀必须是: *.har
    2. 存储归档包的路径必须是: hdfs文件的路径
    3. 归档包路径的前缀要写成:   har://hdfs-node1:8020/
    4. 实际开发中, 大多数公司可以每年, 每季度, 每月, 甚至是每周归档一次, 既可以降低元数据, 也可以提高磁盘利用率(否则1个小文件就要占1个Block块)
       当我们需要使用源文件的时候, 可以很方便的从归档包中提取出我们要的内容.

12.HDFS原理--垃圾桶机制

Hadoop集群, 默认没有开启垃圾桶机制, 每次删除文件, 都是永久删除的, 找不回来了.
这样做比较危险, 我们可以开启垃圾桶机制, 这样删除数据的时候, 就会自动放到垃圾桶中, 保存一定的时间, 超出时间后, 才会自动删除.

在hdfs文件系统中新建一个文件夹/user/用户/.trash/

配置垃圾桶的步骤:

1. 去 /export/server/hadoop/etc/hadoop 的core-site.xml文件中, 加入如下的内容:
        <!-- 如下的时间单位是: 分钟, 即: 1440分钟 = 24小时 -->
        <property>
            <name>fs.trash.interval</name>
            <value>1440</value>
        </property>
    2. 注意: 三台虚拟机都要去修改上述的 core-site.xml文件.
        方式1: 逐个修改.
        方式2: 远程分发, 即: 把node1中修改后的文件, 直接拷贝给node2, node3即可.
            格式:
                scp 数据源文件路径 目的地主机名或者ip:要存储该文件的目录路径
            示例:
                scp core-site.xml node2:/export/server/hadoop/etc/hadoop
                scp core-site.xml node3:$PWD        如果数据源文件所在目录 和 另一台机器的存储目录一致, 可以写成: $PWD
    3. 三台虚拟机都修改完毕后, 记得重启: Hadoop集群.
        stop-all.sh
        start-all.sh

开启垃圾桶机制之后, 代码写法如下:

1. 删除某个文件, 例如:
        [root@node1 hadoop]# hadoop fs -rm /data/2.txt
        2024-01-17 16:03:29,657 INFO fs.TrashPolicyDefault: Moved: 'hdfs://node1.itcast.cn:8020/data/2.txt' to trash
        at: hdfs://node1.itcast.cn:8020/user/root/.Trash/Current/data/2.txt
    2. 现在就可以从垃圾桶中恢复数据了.
        [root@node1 hadoop]# hadoop fs -mv /user/root/.Trash/Current/data/2.txt /data
    3. 如果明确要删除某个文件, 且不走垃圾桶, 删除方式如下.
        [root@node1 hadoop]# hadoop fs -rm -skipTrash /data/1.txt       -- skipTrash意思是: 跳过垃圾桶

3.Hadoop之MapReduce初体验

Hadoop框架提供了MapReduce的测试包, 具体如下

如何使用上述的测试包, 计算圆周率.

建议cd先进入到Hadoop提供的MR的测试包所在的路径下:

cd /export/server/hadoop/share/hadoop/mapreduce

执行MR包(MR任务的)格式:

yarn jar hadoop-mapreduce-examples-3.3.0.jar pi 2 50

上述格式解释:

yarn jar 固定格式, 说明要把某个jar包交给yarn调度执行.
hadoop-mapreduce-examples-3.3.0.jar Hadoop提供的MR任务的测试包
pi 要执行的任务名
2 表示MapTask的任务数, 即: 几个线程来做这个事儿.
50 投点数, 越大, 计算结果越精准.

扩展: MR计算圆周率底层用的是蒙特卡洛算法.

标签： hadoop hdfs 大数据

本文转载自: https://blog.csdn.net/2202_75300139/article/details/135890407
版权归原作者 疲惫的花卷 所有，如有侵权，请联系我们删除。

Hadoop必会面试题

1.分布式和集群介绍

1.Hadoop的架构图

2.Hadoop集群环境HDFS

1.HDFS原理--分布式介绍

2.HDFS原理--架构图

3.高可用模式：

4.HDFS原理--分块存储

5.HDFS原理--namenode如何管理元数据

6.HDFS原理--SecondaryNameNode如何辅助namenode管理元数据

7.HDFS原理--三大机制详解

8.HDFS原理--HDFS写数据流程

9.HDFS原理--HDFS读数据流程

10.HDFS原理--安全模式介绍

11.HDFS原理--归档操作

背景:

演示步骤:

12.HDFS原理--垃圾桶机制

配置垃圾桶的步骤:

开启垃圾桶机制之后, 代码写法如下:

3.Hadoop之MapReduce初体验

建议cd先进入到Hadoop提供的MR的测试包所在的路径下:

执行MR包(MR任务的)格式:

上述格式解释:

扩展: MR计算圆周率底层用的是蒙特卡洛算法.

发表评论

“Hadoop必会面试题”的评论:

关于作者

overfit同步小助手

相关阅读

文章导航

Hadoop必会面试题

1.分布式和集群介绍

1.Hadoop的架构图

2.Hadoop集群环境HDFS

1.HDFS原理--分布式介绍

2.HDFS原理--架构图

3.高可用模式：

4.HDFS原理--分块存储

5.HDFS原理--namenode如何管理元数据

6.HDFS原理--SecondaryNameNode如何辅助namenode管理元数据

7.HDFS原理--三大机制详解

8.HDFS原理--HDFS写数据流程

9.HDFS原理--HDFS读数据流程

10.HDFS原理--安全模式介绍

11.HDFS原理--归档操作

背景:

演示步骤:

12.HDFS原理--垃圾桶机制

配置垃圾桶的步骤:

开启垃圾桶机制之后, 代码写法如下:

3.Hadoop之MapReduce初体验

建议cd先进入到Hadoop提供的MR的测试包所在的路径下:

执行MR包(MR任务的)格式:

上述格式解释:

扩展: MR计算圆周率底层用的是 蒙特卡洛算法.

发表评论

“Hadoop必会面试题”的评论:

关于作者

overfit同步小助手

相关阅读

文章导航

扩展: MR计算圆周率底层用的是蒙特卡洛算法.