设为首页 加入收藏

TOP

Hadoop-HDFS-学习日志-20181213
2019-03-19 00:11:25 】 浏览:47
Tags:Hadoop-HDFS- 学习 日志 -20181213
版权声明:本文为博主原创文章,未经博主允许不得转载。 https://blog.csdn.net/qq_1018944104/article/details/84994222

目录

1、三道海量数据面试题目

2、大数据

3、大数据中几个核心概念

4、Hadoop简单介绍

5、Hadoop安装

6、集群中遇到的问题

7、集群的安装模式

8、HDFS设计思想

9、HDFS的架构-主从架构

10、HDFS优缺点

11、HDFS的使用-shell

12、HDFS的使用-API

14、HDFS的四大机制

15、HDFS的两大核心-上传、下载(有一张流程图是重点)

16、HDFS元数据合并-硬盘上的元数据合并

17、HDFS的各个角色


1、三道海量数据面试题目

1、一个超大文件(一台机器计算不了),里面存放的都是IP地址,一行存放一个。求这个文件中哪一个IP出现的次数最多?

思路:

假设这是一个小文件该如何处理?

首先,一个输入流和一个map集合;然后,将文件中的ip地址,加载到map集合中,key:ip地址,value:相同ip的数量;接着,按照ip的数量进行排序;最后,取出数量最大的ip。

现在,这是一个超大文件,肯定是无法全部存储加载到内存,该怎么办呢?

那就考虑将大文件分拆成小文件进行数量统计。如何分拆小文件?根据ip地址,使用hash散列,将相同的ip散列到同一个文件中,然后按照小文件的处理方式(统计数量并按照数量降序排序),来统计数量,并将结果存入新的文件中。最后,读取结果文件中的第一条记录,进行比较,去最大的ip地址。

注意:若只有一台机器,那就一个文件一个文件的进行处理。若有多台机器,那就多台机器并行进行处理,并最终使用一台机器汇总结果。

以上就是Mapreduce的核心精髓。

2、两个超大文件,里面存放的都是url,一行存放一个,求两个文件中相同的url?

思路:

如何是两个小文件该如何处理呢?

首先,定义两个输入流 和 两个List集合;然后,通过输入流将两个小文件的内容分别加载到两个List集合中;接着,遍历其中一个集合,到另一个集合中查找是否存在。若存在,则将ip存入第三个List集合中;若不存在,则继续遍历下一个元素。最后,将第三个List集合的ip输出,就是两个文件中相同的url(可以去重)。

现在是两个超大文件,那该如何处理呢?

被无它法,然后还是拆分成小文件。怎么进行拆分?比如可以把两个文件分别拆分成1000个小文件,并编号0-999,那么使用hash散列,就能将相同的ip散列到相同编号的文件中。然后,再对两个文件对应的相同编号文件的内容做关联,按照小文件的处理方式,即可得到相同的url

总结:hash散列

3、一个超级大的文件,里面存放的都是url,一行一个,用户给定一个url,如何快速判断url是否在文件中?

思路:

如果是一个小文件该如何处理?

排序+二分查找:使用快排的话,时间复杂度O(nlogn),二分查找的时间复杂度是O(logn)

散列表:将url存入散列表,查找的时间复杂度几乎是O(1)。这需要构建散列表。

位图bitmap:因为知识判断存在与否,也就两个状态,故可以用0、1表示,0表示不存在,1表示可能存在。这需要构建位图。

如果是超大文件呢?

hash散列 + 位图bitmap实现。具体如下:???

2、大数据

1、概念

指无法在一定时间范围内用常规软件工具进行捕捉、管理和处理的数据集合,是需要新处理模式才能具有更强的决策力、洞察发现力和流程优化能力的海量、高增长率和多样化的信息资产。

总结:

数据量大——常规存储工具、计算软件无法承担

高增长率——数据产生速度快

多样化——数据种类多样化,比如文本音频、视频、图片等

2、特点-4v

数据量大——企业级数据量在PB级别,全球数据总量在ZB级别。注:B——KB——MB——GB——TB——PB——EB——ZB

数据种类多——绝大多数集中在非结构化数据,而我们需要分析结构化数据。

数据增长速度快

数据价值密度低——整体价值高

3、数据分类

结构化数据——二维表数据,比如Excel、关系型数据库中的数据

半结构化数据——HTML、XML、CSS、JSON

非结构化数据——音频、视频、图片等

4、数据来源

自己的业务数据

自己的服务器日志

网络爬虫

第三方数据买卖

5、数据处理方式

1)缺失字段的数据

不影响业务分析的情况下——删除

影响最终分析,比如工业大数据(数据量小)、传感器(灵敏度高)——这种数据需要补全,比如根据经验、平均值等

和金钱有关的数据——慎重处理,一定要保护好,不能出任何问题

2)敏感数据

用户隐私数据,比如淘宝账号、地址、联系方式、姓名等,需进行脱敏处理、加密处理,比如通过MD5进行加密

6、数据价值

数据仓库——数据辅助决策

数据挖掘——用户画像(消费习惯、社交、性别等)做商业营销

机器学习——推荐系统、个性化营销等

3、大数据中几个核心概念

1、集群

一个任务(存储/计算)无法在一台机器上完成,需要多台机器(不同网络)之间相互配合来完成。我们把多台机器组成的组织/群体称为集群,比如redis集群、hadoop集群、hbase集群、spark集群等。

2、分布式

分布式的思想精髓是分治思想,即分而治之。

把一个大任务分成很多小任务分别在不同的机器(节点)上运行。这个大任务就是分布式执行的。

分布式相关的系统:

分布式文件系统——一个超大的文件,一个节点无法存储,需要将这个文件进行切分分别存储在不同的节点上,这个文件的存储方式就是分布式文件系统。

分布式计算系统——一个超大的计算任务,一个节点无法计算,需要分散到多个节点进行计算,每个节点只负责一部分计算任务,这种计算方式就是分布式计算。

分布式数据库——当一个表的数据很大时,需要将表中的数据进行切分到多个节点分别存储,每个节点上存储表的一部分数据,这个数据库就是分布式数据库。

3、负载均衡

在分布式存储/计算系统中,集群中的每个节点承担的存储/计算的任务相当,整个集群处于负载均衡状态。

负载均衡和每个节点的硬件性能有关。如何理解?

比如3个节点,存储数据量为6T

1)三个节点的硬件配置完全一样:每个节点2T,这时是负载均衡的。

2)三个节点的硬件配置不一样,具体如下

情况一:

节点1:磁盘总量4T,若存储2T数据,那么磁盘占用率为50%

节点2:磁盘总量2T,若存储2T数据,那么磁盘占用率为100%

节点3:磁盘总量2T,若存储2T数据,那么磁盘占用率为100%

以上不是负载均衡的。

情况二:

节点1:磁盘总量4T,若存储3T数据,那么磁盘占用率为75%

节点2:磁盘总量2T,若存储1.5T数据,那么磁盘占用率为75%

节点3:磁盘总量2T,若存储1.5T数据,那么磁盘占用率为75%

以上就是负载均衡的。

所以,负载均衡,表示的是硬件资源的使用量比例是否一致,比如磁盘使用量比例是否一致。

值得注意的是不存在绝对的负载均衡,只需尽可能趋近负载均衡状态即可。

4、扩展能力

纵向扩展

单个节点硬件上的扩展,比如加大内存、磁盘容量等。

存在性能瓶颈,摩尔定律决定了的,因此不能解决根本问题。

横向扩展

分布式集群的节点数量上的扩展,即通过增加节点的数量,来提升存储能力和计算能力,理论上是没有上线的。

4、Hadoop简单介绍

1、产生背景

搜索引擎公司Google面临的问题是海量数据存储、海量数据计算、海量数据快速查询,因此设计了三大核心技术来解决这3类问题。

这三大核心技术于2003以论文形式公诸于世,分别是:

GFS——Google File System 解决海量数据存储

MapReduce——解决海量数据计算

BigTable——Google分布式数据库 解决海量数据快速查询

开源搜索引擎Nutch的创始人Doug Cutting根据这三篇论文用java语言开发了Hadoop并开源出来,大数据时代就此开始。

GFS——Hadoop HDFS

MapReduce——Hadoop MapReduce

BigTable——Hadoop HBase

2、Hadoop是什么

Apache Hadoop软件库是一个框架,允许使用简单的编程模型跨计算机集群分布式处理大数据集。它旨在从单台服务器扩展到数千台计算机,每台计算机都提供本地的存储与计算。Hadoop不依赖硬件来提供高可用性,而是在软件层面自动检测和处理应用程序故障。

hadoop构建在廉价的机器之上,并可进行横向扩展,将硬件故障作为常态。hadoop提供了分布式存储和计算的能力。特点是高可靠、高扩展、高可用。

3、Hadoop的组成模块

hadoop1.0:HDFS 和MapReduce

hadoop2.0:

hdfs

mapreduce

yarn

common 工具包,为上面的3个模块提供功能资源服务,比如RPC通信

5、Hadoop安装

1、版本选择

2、集群规划

3、依赖准备

4、安装集群

具体步骤https://blog.csdn.net/qq_1018944104/article/details/85062823

6、集群中遇到的问题

1、格式化的时候配置文件错

2、格式化问题

3、集群再启动的过程中某一个进程启动失败,或者集群运行一段时间后,某一个进程死了?进程缺失

4、集群的环境变量的配置文件问题

具体描述及解决方案https://blog.csdn.net/qq_1018944104/article/details/85062918

7、集群的安装模式

1、单击模式

解压即可用。没有分布式的文件系统,也没有namenode、datanode、secondarynamenode、resourcemanager、nodemanager。文件系统就是Linux/windows的本地文件系统

作用:代码调试

2、伪分布式

只有一个节点,有相关的hdfs或yarn的进程,这些进程全部在一个节点上。存在分布式的文件系统,只不过在一个节点上。

作用:搭建比较简单,容易上手。个人学习、测试的时候使用。

3、完全分布式

多个节点上搭建,每个节点都会承担相应的角色。有分布式文件系统,分布式文件系统是多节点的。

其中,

hdfs的主机节点namenode只有一个

yarn的主节点resourcemanager只有一个

从节点(datanode/nodemanager)有多个

用途:个人学习,测试,生产中很少使用,节点个数少的时候

4、高可用

完全分布式的缺陷:主节点(namenode/resourcemanager)存在单点故障

高可用集群同时可以有多个主节点。一般我们使用的集群有2个主节点,即namenode 2个,resourcemanager 2个,但同一时刻对外提供服务的主节点只有一个,我们将这个主节点称为active namenode,另外一个主节点时刻处于热备状态,称为standby namenode。当集群中的active namenode宕机的时候,standby namenode可以立即切换为active namenode,整个集群可以持续对外提供服务,这是namenode是高可用的。

standy namenode 要想代替active namenode对外提供服务,必须保证两个namenode时刻保持一致,才能保证standby namenode接替active namenode的时候数据不丢失,即数据的一致性,集群可以持续对外提供服务。

用途:生产中使用的最广泛的方式

5、联邦模式

高可用集群的缺陷:虽然集群中有两个namenode,但是这两个namenode同一时刻只能有一个对外提供服务,两个namenode存储的数据是一致的,当集群中的从节点个数过多的时候,namenode的压力很大,namenode的压力是没法分担的。

联邦模式中,同一个时刻对外提供服务的namenode可以有多个,这多个namenode都处于active状态,但是这多个分别管理datanode上面的不同数据,多个namenode共同管理所有的datanode。

多个namenode之间管理的数据是通过blockpool ID进行区分的,每一个namenode都会在格式化的时候生成一个自己的blockpoolID,datanode在进行数据存储的时候,也会将数据存储在不同的blockpoolID中。每一个namenode只管理自己的blockpoolID的数据。

用途:超大集群,联邦 加 高可用

8、HDFS设计思想

问题:HDFS负责海量数据的分布式存储,它是如何做到的呢?

例如:数据3T,节点3个,节点配置128G内存 2T磁盘

1、切块存储

每一个块的大小如何切?

1T 不合理的 块太大 容易造成负载不均衡

1kb 不合理 块太小 块的数量多 namenode的压力过大

事实上hdfs在进行设计的时候已经考虑到了这个问题。hdfs底层进行切块设置的时候默认一个块大小128M,这个大小是比较合理的,既不会负载均衡,也不会造成namenode的压力太大。

在hadoop1.0 这个值默认的 64M

在hadoop2.0 这个值默认是 128M

在hadoop3.0 这个值的默认值 256M

这个大小可以手动配置:

默认配置项:hdfs-default.xml

<property>

<name>dfs.blocksize</name>

<value>134217728</value>

</property>

如果需要修改这个值:在hdfs-site.xml 添加下面内容

<property>

<name>dfs.blocksize</name>

<value>134217728</value>

</property>

对于切块,需要注意一个文件的最后一个块即使不够128M 也会被切分为一个独立的块,不会和别的文件进行拼接,这个块的大小就是实际大小,比如

一个文件300M,切3个块:

blk0:0-128 M 128M

blk1:129-256M 128M

blk2:257-300M 44M 这个块独立成一个块 大小就是44M

对于所有的配置项如果我们没有配置,使用的就是默认配置。hadoop的默认配置文件4个,分别是:

core-default.xml

hdfs-default.xml

mapred-default.xml

yarn-default.xml

这几个配置文件在hadoop的相关jar包中。

2、冗余存储/备份存储/多副本存储

对每一个数据块进行备份多份存储,每一个数据块的每一份数据就叫做一个数据副本。

副本:同备份的概念也是拷贝出来的一个文件备份,不同于备份的特点是副本概念没有主次之分的,所有的副本和原始文件相同地位,所有副本和原始文件相互互为副本的。

副本个数应该是多少?1个 不合理 数据的安全性没有办法保证的;100个 不合理 占用大量的存储空间。

默认的副本个数:hdfs-default.xml ——> dfs.replication 3

自定义副本个数:hdfs-site.xml

<property>

<name>dfs.replication</name>

<value>2</value>

<description>HDFS 的数据块的副本存储个数</description>

</property>

注意:

1)存储策略:

同一个数据块的多个副本分别存储在不同的节点上的

同一个节点上不允许存储同一个数据块的多个副本的,没有意义的

同一个节点上可以存储多个不同的数据块的副本

2)异常

假设副本个数配置的是3个,节点数4个,集群的运行过程中,有一个数据块的一个副本宕机了,丢失数据块副本个数变为2,这个时候副本个数就会小于配置的个数,这个时候集群就会再复制出来一个副本,最终达到配置的副本个数。

如果集群复制完成缺失的副本,原来宕机的节点又活了,原来的数据块的副本又回来了,就会造成这个数据块的副本个数4,集群会在1h之后对这个数据块的副本进行复查,如果还是4个副本,就会删除一个副本。

3)副本的个数设置的3个,节点个数只有2个,这个时候集群中的实际的副本个数是2个,另外一个会进行记账,当集群中新添加节点的时候在进行复制另外一个副本。

9、HDFS的架构-主从架构

1、主节点 namenode

第一个作用:存储元数据

元数据:描述数据的数据

hdfs的元数据包括3部分内容:

1)抽象目录树

抽象:代表的是所有的datanode共同组成的存储体系,而不是代表某一个datanode节点的存储。

为了表明hdfs文件系统中存储的文件的目录结构。抽象目录树的根节点为 /,代表的是 hdfs://hadoop01:9000/。比如 /mapred-site.xml 和 /hadoop-2.7.6.tar.gz,是两个文件的完整名称。

2)数据和块的对应关系

/mapred-site.xml 实质上是存储在datanode上的,存储的时候是分块多副本存储的,数据在存储的时候会为每一个数据块分配一个全局唯一的blockid。比如

/mapred-site.xml blk_1073741825

/hadoop-2.7.6.tar.gz [blk_1073741826 blk_1073741827]

3)数据块的存储位置,即数据块和节点的对应关系

blk_1073741826 [hadoop01,hadoop03]

blk_1073741827 [hadoop01,hadoop03]

第二个作用:接受客户端的读写请求

客户端要想进行读写,需先请求namenode

2、从节点 datanode

1)真正的负责数据的存储

数据到底存储在哪里?最终肯定存储在datanode的本地

<property>

<name>dfs.datanode.data.dir</name>

<value>/home/hadoop/data/hadoopdata/data</value>

<description>datanode 的数据存储目录</description>

</property>

最终的存储目录:

/home/hadoop/data/hadoopdata/data/current/BP-1983787495-192.168.191.201-1541627433389/current/finalized/subdir0/subdir0

blk_1073741825 原始的真实数据

blk_1073741825_1001.meta 原始数据的元数据

分块多副本存,每一个块都有一个唯一的id,id还是全局顺序递增的。

2)真正处理客户端的读写请求

3、secondarynamenode

1)备份主节点的元数据信息

主节点宕机的时候帮助主节点进行数据恢复。

数据存储目录:/home/hadoop/data/hadoopdata/dfs/namesecondary/current

2)帮助主节点减轻压力,帮助namenode做一些非核心工作,比如元数据合并

10、HDFS优缺点

优点:

1)hadoop基于普通廉价机设计的,可构建在廉价机器上,成本低

2)通过多副本提高可靠性,提供了容错和恢复机制

高容错性-----多副本存储策略

数据自动保存多个副本,副本丢失后,自动恢复

3)适合批处理----适合离线处理

4)移动计算而非数据,数据位置暴露给计算框架

5)适合大数据处理----hadoop本身就是为了解决海量数据设计的

GB、TB、甚至 PB 级数据,百万规模以上的文件数量,10K+节点规模

6)流式文件访问:一次写入,不支持文件修改;一次性写入,多次读取,保证数据一致性

缺点:

1)数据访问的延时性比较高,不适合低延时的数据访问,不适合实时的数据访问

2)不擅长存储大量小文件,原因如下

会造成寻址时间过长,不划算,即数据找的时间远远大于数据读的时间

namenode的存储元数据的压力过大,读写的压力也会大。一个数据块id一条元数据,小文件过多,数据块过多,元数据条数过多

一条元数据理论 150byte,那么10w个1kb的小文件元数据大小是多少呢?

元数据:100000*150byte=15000000byte=15M ---namenode

原始数据:10w*1kb=100000kb=100M --datanode 多个

3)不支持数据修改,修改的成本太高

一旦上传成功,存储就是切块多副本存储的

一旦进行修改,多个数据块的副本都要进行修改

11、HDFS的使用-shell

最关键的内容:如何进入hdfs客户端,如何查看帮助,如何退出客户端

hadoop fs 或 hadoop version 的含义解释:

hadoop 启动一个hadoop的客户端

fs 开启文件系统客户端 filesystem

version 打印hadoop版本

1)查看hdfs的目录结构

hadoop fs -ls hdfs的路径

hadoop fs -ls / 查看根目录下有哪些文件或文件夹

文件权限 用户 组 大小 文件名

-rw-r--r-- 2 hadoop supergroup 216745683 2018-11-08 06:09 /hadoop-2.7.6.tar.gz

-rw-r--r-- 2 hadoop supergroup 840 2018-11-08 05:52 /mapred-site.xml

注意:hdfs的路径访问方式只有绝对路径的访问方式

级联查看 -R

hadoop fs -ls -R hdfs的路径

2)创建目录

hadoop fs -mkdir hdfs的目录(从/开始) 只能创建一级目录(父目录必须存在的)

hadoop fs -mkdir -p hdfs的目录 级联创建

3)文件上传 本地文件传到hdfs上

hadoop fs -put 本地文件路径(绝对/相对的) hdfs路径(绝对)

hadoop fs -put NOTICE.txt /aa

hadoop fs -put /home/hadoop/apps/hadoop-2.7.6/NOTICE.txt /aa/bb

注意:

文件上传的时候给定的hdfs的路径是一个存在的目录,则会上传到这个目录下,名字是源文件的名。

文件上传的时候给定的hdfs的路径是不存在的,就会认为给的路径是最后一级路径是文件名,对本地文件进行重命名。

hadoop fs -copyFromLocal 本地路径 hdfs路径

hadoop fs -copyFromLocal NOTICE.txt /bb01

等同于put 将本地文件复制到hdfs上

hadoop fs -moveFromLocal 本地路径 hdfs路径

hadoop fs -moveFromLocal hello.txt /

将本地文件剪切到hdfs上

4)文件下载 hdfs——>本地(linux、windows) 客户端所在本地

hadoop fs -get hdfs路径 本地路径

hadoop fs -get /hello.txt ./ 文件和目录都可以下载的

hadoop fs -copyToLocal hdfs路径 本地路径 从hdfs复制到本地 同get

hadoop fs -copyToLocal /mapred-site.xml ./

hadoop fs -moveToLocal hdfs路径 本地路径 不可用

hadoop fs -moveToLocal /mapred-site.xml ./

Option '-moveToLocal' is not implemented yet.

合并下载

hadoop fs -getmerge hdfs路径 hdfs路径 ..... 本地路径

hadoop fs -getmerge /hello.txt /mapred-site.xml ./merge.txt

将hdfs上的多个路径的文件 合并为一个文件下载到本地

5)文件追加 -appendToFile 追加到末尾

hadoop fs -appendToFile 本地路径 hdfs路径

hadoop fs -appendToFile merge.txt /hello.txt

追加的时候在hdfs原始文件的末尾追加的,原始文件最后一个数据块的末尾直接追加的而不是独立成的一个数据块

6)查看文件

查看文件所有内容

hadoop fs -cat hdfs路径

hadoop fs -cat /hello.txt

查看文件末尾数据 末尾1kb的数据

hadoop fs -tail /hello.txt

7)文件的复制和移动 hdfs——>hdfs

hadoop fs -cp hdfs路径 hdfs另外一个路径

hadoop fs -cp /bb01 /aa

hadoop fs -mv hdfs路径 hdfs另外一个路径

hadoop fs -mv /bb01 /aa/bb

8)新建文件 基本不用

hadoop fs -touchz hdfs文件名

hadoop fs -touchz /cc_tt

9)权限

级联修改给定目录及目录下的所有文件的读写权限的

hadoop fs -chmod -R 777 hdfs路径

级联修改用户名和组

hadoop fs -chown -R 用户:组名 hdfs路径

10)删除 ***

hadoop fs -rm -r -f /aa 删除目录

hadoop fs -rm -f /hello.txt 删除文件

-r 级联

-f 强制 force

11)查看磁盘空间占用情况

hadoop fs -df hdfs路径

hadoop fs -du hdfs路径

13)手动修改副本个数

hadoop fs -setrep 副本个数 hdfs的路径

hadoop fs -setrep 4 /mapred-site.xml

setrep ===> set replication

级联 -R

副本个数设置:

1)hdfs-default.xml 默认设置 3

2)hdfs-site.xml 自己的配置文件中的 2

3)-setrep 4 覆盖hdfs-site.xml

加载顺序:1)——>2)——>3)

12、HDFS的使用-API

1、配置windows下的环境:

1)将eclipse的插件包hadoop-eclipse-plugin-2.7.5.jar放到

eclipse的安装目录的plugins目录下

C:\soft\eclipse\eclipse\plugins

2)配置本地的hadoop环境

1)在windows下解压hadoop的linux的安装包

2)windows配置hadoop的环境变量

系统环境变量中

HADOOP_HOME=C:\soft\hadoop-2.7.6

Path中添加%HADOOP_HOME%\bin;%HADOOP_HOME%\sbin

3)将hadoop.dll放在windows下的System32下

C:\Windows\System32

4)将winutils.exe 放在hadoop安装包的bin目录下

%HADOOP_HOME%\bin

3)配置eclipse的连接界面

1)重启eclipse

2)将hadoop的本地路径添加到eclipse中

eclipse的window--->preferences--->左侧菜单搜索

hadoop-->hadoop map/reduce---->Browse--->hadoop

的windows下的安装目录--->apply--->ok

3)配置eclipse中hadoop的可视化操作界面

window--->show view--->other--->搜索map--->双击

进行连接配置(所有的连接必须保证集群正常启动的)

2、创建工程,导入包

1)工程创建一个lib 右键 build path

优点:工程移动的时候比较方便 不用重新导入依赖

缺点:工程臃肿 不能解决jar包冲突

2)maven进行管理工程 pom.xml

优点:工程比较轻便 可以解决jar包冲突的问题

缺点:工程移动的时候需要重新构建的

3)创建一个本地library

hdfs的开发需要依赖的包:

hdfs的相关依赖包

common的相关包

hdfs文件上传到hdfs的时候会报错:

Caused by: org.apache.hadoop.ipc.RemoteException

(org.apache.hadoop.security.AccessControlException):

Permission denied: user=Administrator, access=WRITE,

inode="/":hadoop:supergroup:drwxr-xr-x

user=Administrator 当前用户

如何解决?在main方法第一行加入代码:System.setProperty("HADOOP_USER_NAME", "hadoop");

14、HDFS的四大机制

1、心跳机制

hdfs集群中namenode负责管理所有的datanode。那namenode是如何管理的呢?

namenode怎么获取datanode存活状况的?通过心跳策略获取的,datanode在集群运行的过程中会定期的向namenode发送自己的心跳报告,目的就是向namenoden报告自己的存活状况。

心跳报告的周期:hdfs-default.xml

<property>

<name>dfs.heartbeat.interval</name>

<value>3</value>

<description>Determines datanode heartbeat i

nterval in seconds.</description>

</property>

表示datanode每隔3s向namenode发送一个心跳报告(注意:心跳周期的单位是秒)。

如果一个datanode宕机了,namenode通过多长时间可以断定?namenode连续10次接受不到datanode的心跳报告时,会认为当前的datanode可能宕机,默认设置如下:

<property>

<name>dfs.namenode.handler.count</name>

<value>10</value>

<description>The number of server threads for the namenode.</description>

</property>

这个时候namenode主动向datanode发送检查(后台守护进程)并等待检查的响应结果

<property>

<name>dfs.namenode.heartbeat.recheck-interval</name>

<value>300000</value>

<description>

This time decides the interval to check for expired datanodes.

With this value and dfs.heartbeat.interval, the interval of

deciding the datanode is stale or not is also calculated.

The unit of this configuration is millisecond.

</description>

</property>

namenode进行datanode的一次检查的时间300000ms=300s=5min,namenode这时候会主动检查两次,如果两次检查都没有响应,时候断定当前的datanode宕机了。因此,namenode断定一个datanode宕机的时间:10*3s+2*5min=10min30s

2、机架策略——副本存放策略

在hdfs中对于一个block默认的存储副本个数3个,这3个副本如何存放的?三个副本分别存储在3个不同的节点上。事实上在实际生产的时候,节点在机架上的,所以,在存放副本时需考虑机架问题的副本存放策略如下:

1)第一个副本通常放在客户端所在节点(客户端是集群中的一个节点),如果客户端不是集群中的一个节点,则第一个副本上传到任意一个节点。

2)第二个副本放在和第一个副本不同机架的任意节点上。

3)第三个副本放在和第二个副本相同机架的不同节点上,便于写数据

实际生产中:副本存放有可能跨节点、跨机架、跨机房,甚至跨数据中心。

3、负载均衡

什么是负载均衡?hdfs集群中的每一个datanode上的存储的数据和自己的硬件占比是相当的,这个时候我们可以认为这个hdfs集群是负载均衡的。集群的运行过程中,有可能造成集群中的从节点的负载不均衡,如果集群规模比较小的时候,集群有自动负载均衡的能力,集群自己在一段时间之后达到相对的负载均衡。

集群实现负载均衡的过程实际上就是数据块移动的过程(跨节点),因此可知负载均衡的带宽配置如下:

<property>

<name>dfs.datanode.balance.bandwidthPerSec</name>

<value>1048576</value>

<description>

Specifies the maximum amount of bandwidth that each datanode

can utilize for the balancing purpose in term of

the number of bytes per second.

</description>

</property>

默认集群负载均衡的带宽1M/s(很慢的),这个速度对于小规模集群还是可以满足的,但集群规模比较大的时候就不可以了,因为太慢了,集群规模大的时候就需要手动负载均衡。如何手动负载均衡呢?

1.start-balancer.sh -t 10% 这个命令不会立即执行,而是提升负载均衡的响应时效

2.调整带宽

<property>

<name>dfs.datanode.balance.bandwidthPerSec</name>

<value>1048576000</value>

<description>

Specifies the maximum amount of bandwidth that each datanode

can utilize for the balancing purpose in term of

the number of bytes per second.

</description>

</property>

/start-balancer.sh -t 10% 参数意义:datanode中最大的存储容量占比减去最小的存储的容量占比不超过10% 时认为是负载均衡的。如下:

hadoop01 2T 1T 50%

hadoop02 2T 1.1T 55%

hadoop03 2T 0.8T 40%

55%-40%=15%>10% 这时是负载不均衡的

4、安全模式

集群的安全模式是集群的一个自我保护的一种模式,在集群的安全模式下,不允许用户对集群进行部分操作的。

集群什么时候会进入安全模式?

1、集群启动的时候,集群会自己进入安全模式

启动顺序:1)namenode 2)datanode 3)secondarynamenode

启动namenode的时候做的事情:

namenode主要作用:存储元数据,即1)抽象目录树 2)数据和块的映射 3)数据块和节点的映射

元数据存储的位置:

1)硬盘上存储 /home/hadoop/data/hadoopdata/name/current

硬盘中的元数据包含:1) 2)但没有3)

2)内存中有全部的元数据

集群正常启动之后,读取的元数据信息都是内存中的,即包含1) 2) 3)

集群再启动namenode的时候:

1)将硬盘中的元数据加载到内存中

元数据信息:

hadoop-2.7.6.tar.gz 206M

1)/hadoop-2.7.6.tar.gz

2)hadoop-2.7.6.tar.gz:blk_12334:[] blk_12335:[]

启动datanode:

1)启动datanode的进程

2)启动完成向namenode进行发送心跳报告

3)datanode在发送心跳报告的时候也会发送块报告

namenode接受到这个块报告信息就会将相应的块id的节点放在元数据的相应位置,比如

hadoop-2.7.6.tar.gz:blk_12334:[hadoop01,hadoop02] blk_12335:[hadoop02,hadoop03]

启动secondarynamenode

集群在整个启动过程中处于安全模式,会进行一系列的检查,符合标准时才会离开安全模式:

1)检查每一个数据块的副本个数,每一个数据块的副本个数至少为1

<property>

<name>dfs.namenode.replication.min</name>

<value>1</value>

<description>Minimal block replication.

</description>

</property>

2)检查合乎标准的数据块占总数据块的比例

<property>

<name>dfs.namenode.safemode.threshold-pct</name>

<value>0.999f</value>

<description>

Specifies the percentage of blocks that should satisfy

the minimal replication requirement defined by dfs.namenode.replication.min.

Values less than or equal to 0 mean not to wait for any particular

percentage of blocks before exiting safemode.

Values greater than 1 will make safe mode permanent.

</description>

</property>

假设集群中的总的数据块的id:1000个

达到副本个数>=1的数据块的id:999 达标的数据块的比例999/1000=0.999

达到副本个数>=1的数据块的id:998 比例:0.998

3)检查存活的datanode个数

<property>

<name>dfs.namenode.safemode.min.datanodes</name>

<value>0</value>

<description>

Specifies the number of datanodes that must be considered alive

before the name node exits safemode.

Values less than or equal to 0 mean not to take the number of live

datanodes into account when deciding whether to remain in safe mode

during startup.

Values greater than the number of datanodes in the cluster

will make safe mode permanent.

</description>

</property>

至少保证0个datanode存活的

4)整个符合上面的标准的状态持续30s之后

<property>

<name>dfs.namenode.safemode.extension</name>

<value>30000</value>

<description>

Determines extension of safe mode in milliseconds

after the threshold level is reached.

</description>

</property>

保证集群的稳定性

集群启动过程中,为什么进入安全模式?

1)namenode将硬盘中的元数据加载到内存中

2)namenode接受datanode的心跳报告

3)namenode接受datanode的块报告

4)namenode会进行一系列的检查

基于以上的原因,集群会进入安全模式,待上面的事情都完成的情况下,集群会自动退出安全模式。

2、集群运行过程中,也会进行检查

1)检查每一个数据块的副本个数,每一个数据块的副本个数至少为1

<property>

<name>dfs.namenode.replication.min</name>

<value>1</value>

<description>Minimal block replication.

</description>

</property>

2)检查合乎标准的数据块占总数据块的比例

<property>

<name>dfs.namenode.safemode.threshold-pct</name>

<value>0.999f</value>

<description>

Specifies the percentage of blocks that should satisfy

the minimal replication requirement defined by dfs.namenode.replication.min.

Values less than or equal to 0 mean not to wait for any particular

percentage of blocks before exiting safemode.

Values greater than 1 will make safe mode permanent.

</description>

</property>

假设集群中的总的数据块的id:1000个

达到副本个数>=1的数据块的id:999 达标的数据块的比例999/1000=0.999

达到副本个数>=1的数据块的id:998 比例:0.998

检查的时候发现不符合要求,也会自动进入安全模式。

3.如果集群处于维护或者是系统升级时可手动进入安全模式

命令:

hdfs dfsadmin -safemode get 获取当前集群的安全模式状态

Safe mode is OFF 离开了安全模式

Safe mode is ON 在安全模式

hdfs dfsadmin -safemode leave 强制离开安全模式

hdfs dfsadmin -safemode enter 强制进入安全模式

hdfs dfsadmin -safemode wait 等待安全模式自行离开(没有意义)

在安全模式下,可以执行的操作,和不可以执行的操作?

可以执行的操作:ls、get、cat、tail

不可以执行的操作:-put、-mkdir、-touchz、-appendToFile、-rm

总结:查询可以(未修改元数据信息),增删改不可以(修改了元数据)。安全模式是一种自我保护的模式,在这个模式下不允许用户修改任何元数据的,只能查询元数据。

15、HDFS的两大核心-上传、下载(有一张流程图是重点)

1、文件上传、写数据

文件上传步骤详述:

1)客户端发送文件上传请求给namenode

2)namenode会进行一系列检查,比如文件是否存在、父目录、权限等

3)检查通过namenode向客户端返回响应

4)客户端开始发送真正的文件上传请求,请求中包含了一个重要的内容,文件长度(分块个数->存储节点)

5)namenode开始进行计算,并向客户端返回每一个数据块的存储节点列表以及块id

200M/128 副本2

blk_172872 hadoop01 hadoop02

blk_172873 hadoop03 hadoop02

6)客户端准备上传

7)客户端先对数据进行逻辑分块

8)客户端开始准备上传第一个数据块

9)客户端开始构建第一个数据块的管道pipline,客户端开启一个后台进程,等待pipline构建完整的响应

10)客户端开始文件上传,以packet为单位(64KB)进行数据写入。过程如下:

客户端——>第一个副本——>第二个副本

先写入内存,再从内存写入到磁盘

11)第一个数据块上传完成,则关闭当前pipline

12)开始准备上传第二个数据块,步骤同8)9)10)

13)所有数据块上传完成,客户响应namenode,namenode接收到数据上传成功的响应后即刻修改元数据信息

物理分块:真实存在的切分,即数据被真正的分成了多个块(多个部分)。hdfs数据的分块存储,比如

hadoop 200M

blk01 128M

blk02 72M

逻辑分块:逻辑上的概念,相当于一个区域、范围的划分,并没有对数据进行真正的切分,为物理切块准备的。

客户端写数据的基本单位:

<property>

<name>dfs.client-write-packet-size</name>

<value>65536</value>

<description>Packet size for clients to write</description>

</property>

文件上传注意的问题:

1)文件上传过程中的物理切块问题:边上传边切分的过程,文件切块客户端负责的。

2)pipline构建的问题:

blk01:hadoop01 hadoop03 hadoop04

客户端--->第一个副本---->第二个副本--->第三个副本

client--->hadoop01--->hadoop03---->hadoop04

如果发现pipline中的某一个节点有问题,比如hadoop03有问题,尝试重试2次,2次通信都有问题,将hadoop03剔除出pipline,重新构建pipline,即client--->hadoop01---->hadoop04

3)上传过程中的最低保障:

每一个数据块至少有一个数据块副本上传成功就认为成功

副本存放策略第一个副本优先放置在客户端所在节点就是为了保证数据上传的成功的几率

第一个副本放在客户端所在节点就相当于本地复制,即将数据从本地的原始路径复制到/home/hadoop/data/hadoopdata/data/current/BP-1983787495-192.168.191.201-1541627433389/current/finalized/subdir0/subdir0

其他副本自己进行异步复制(datanode之间)

节点分配问题:

几个副本则返回这个数据块的几个存储节点,返回节点的时候有优先级问题:距离+空间

1)优先返回客户端所在节点

2)返回同机架节点

3)不同机架的节点

2、文件下载、读数据

文件下载步骤详述:

1)客户端向namenode发送文件下载请求

2)namenode会进行检查,检查通过,向客户端响应数据对应的块及数据库的存储节点。比如

hadoop.tar.gz blk_123:[hadoop01,hadoop02] blk_124:[hadoop02,hadoop03]

3)客户端开始进行第一个数据块的下载,到对应的节点上进行下载,即从datanode上读取并写出到本地文件中

4)第一个数据块下载完成后,再开始下载第二个数据块,即从datanode上读,然后写出到本地文件,注意这里是追加写入到第一个数据块的末尾。

5)所有的数据块下载完成后,文件就下载完毕,最后关闭所有的资源

返回的节点列表顺序:客户端所在存数数据块副本节点、返回同机架、不同机架的

文件下载异常:第一个数据的副本下载失败,重试,不成功,换另一个副本的节点下载,同时客户端将这个节点报告给namenode

注意:文件下载的时候 每一个数据块读取完成都会进行crc文件校验

16、HDFS元数据合并-硬盘上的元数据合并

强调一点:内存中的元数据时刻都是最新的最全的元数据

1、硬盘上存储元数据的文件结构:序列化的文件

edits_0000000000000000001-0000000000000000002 这是元数据的操作日志文件,元数据操作的流水日志,记录的就是元数据的所有操作,仅仅是记录,历史日志文件。

edits_inprogress_0000000000000000235 正在编辑的日志文件,默认情况下edits文件1h回滚一次。

fsimage_0000000000000000225 镜像文件,元数据内容文件,序列化的文件 ,内容包括抽象目录树、数据和块的映射,不是全部的元数据信息,而是部分元数据信息

fsimage_0000000000000000225.md5 加密文件 校验

seen_txid 合并点文件,下一次需要滚动的日志文件的起始编号

VERSION:元数据的版本信息文件

集群id:标识整个集群

块池id:标识块的存储

2、硬盘上的完整元数据的组成部分

fsimage文件的最后的编号和edits文件的编号有一个对应关系的:fsimage_0000000000000000237代表的就是edits文件编号0000000000000000237之前的所有的日志文件记录的内容全部写入到fsimage_0000000000000000237

完整的元数据文件:

fsimage_0000000000000000237+edits_0000000000000000238-0000000000000000239+edits_inprogress_0000000000000000240

或者

fsimage_0000000000000000239+edits_inprogress_0000000000000000240

3、fsimage文件是如何产生的?

namenode进行格式化的时候会产生一个初始的fsimage文件 /,后面的fsimage.new文件是原来的fsimge.old文件+edits文件(fsimage.old_id+1~fsimage.new_id)合并得来的。比如

fsimage_0000000000000000239=fsimage_0000000000000000237+edits_0000000000000000238-0000000000000000239

4、fsimage和edits文件的合并工作是谁做的?

secondarynamenode

5、元数据合并的过程:checkpoint

元数据合并触发的条件:下面两个条件只要满足任意一个条件都会触发元数据合并

1)时间间隔 每隔1h进行一次元数据合并的工作

<property>

<name>dfs.namenode.checkpoint.period</name>

<value>3600</value>

<description>The number of seconds between two periodic checkpoints.

</description>

</property>

2)日志条数间隔 100w

<property>

<name>dfs.namenode.checkpoint.txns</name>

<value>1000000</value>

<description>The Secondary NameNode or CheckpointNode will create a checkpoint

of the namespace every 'dfs.namenode.checkpoint.txns' transactions, regardless

of whether 'dfs.namenode.checkpoint.period' has expired.

</description>

</property>

6、edits文件的作用:

1)记录元数据的操作日志信息

2)帮助进行元数据fsimage文件的恢复

元数据合并过程详述:

执行增删改命令后,首先是将增删改操作写入edits文件中(磁盘上),然后再修改内存中的元数据。

1)secondaryname定期询问namenode是否需要合并元数据

2)namenode达到元数据合并的条件,就会通知secondarynamenode

3)secondarynamenode发送元数据合并的请求

4)namenode先将正在编辑的日志文件进行回滚,同时生成一个新的正在编辑的日志文件(接收信息的读写请求)

5)secondarynamenode将edits文件和fsimage文件拉取到自己的本地。edits文件:fsimage_id + 1~最新回滚的edits的id

edits_001

edits_002

edits_003

fsimage0

6)secondarynamenode将edits文件和fsimage文件加载到内存中进行合并,一旦合并完成就会生成一个新的fsimage文件,命名为fsimage_(edits文件的最大id)

合并:fsimage文件通过edits文件记录的操作修改自己的内容,即根据edits文件记录的操作修改fsimage的内容

7)secondarynamenode将合并完成的fsimage文件发送给namenode

17、HDFS的各个角色

namenode:

1)接收客户端的读写请求

2)存储元数据信息

3)接收datanode的心跳报告

4)负载均衡

5)分配数据块的存储节点

datanode:

1)真正处理客户端的读写请求

2)向namenode发送心跳

3)向namenode发送块报告

4)真正的数据存储

5)副本之间的相互复制

secondarynamenode:

1)备份元数据信息

2)帮助namenode进行元数据合并 减轻namenode的压力

客户端:

1)进行数据块的物理切分

2)向namenode发送读写请求

3)向namenode发送读写响应

18、练习题目(一)

1、删除HDFS上的某个文件夹(级联删除) 自己写递归

2、删除某个路径下特定类型的文件,比如class类型文件,比如txt类型文件

3、删除HDFS集群中的所有空文件和空目录

4、使用流的方式上传文件

5、使用流的方式下载文件

6、从随机地方开始读,读任意长度

7、手动拷贝某个特定的数据块(比如某个文件的第二个数据块)
某一个文件只下载第二个数据块
300M blk1 0-127 blk2 128-255 blk3:256-300

】【打印繁体】【投稿】【收藏】 【推荐】【举报】【评论】 【关闭】 【返回顶部
上一篇HDFS的命令行客户端常用命令 下一篇LeetCode——Set Matrix Zeroes

最新文章

热门文章

Hot 文章

Python

C 语言

C++基础

大数据基础

linux编程基础

C/C++面试题目