【Hadoop】 No.3 Hdfs详解

大数据概念

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

 

大数据的特点

1. Volume 大量
2. Velocity 高速
3. Variety 多样
4. Value 低价值密度

大数据能做什么

（1）商品推荐

        淘宝 京东 猜你喜欢

（2）探索价值  数据挖掘

案例 啤酒尿不湿

        沃尔玛一家分店的营销经理对超市的销售数量进行设定跟踪，有一次他发现了一个很奇怪的现象：啤酒与尿不湿的销量在周末总会出现成比例增长 他们立即对这个现象进行了分析和讨论，并且派出专门的人员在卖场内进行全天候的观察。他们发现这些顾客有几个共同的特点：

一般是周末出现这种情况

1. 购买者以已婚男士为主
2. 他们家中有孩子且不到两岁，有尿不湿的刚需
3. 他们喜欢看体育比赛节目，并且喜欢边喝啤酒边看，顾客有喝啤酒的需求
4. 周末是体育比赛扎堆的日子，所以出现这种关联销售多在周末的时候

 

这位营销经理从中受到启发，他对超市的物品摆放进行了调整，将卖场内原来相隔很远的妇婴用品区与酒类饮料区的空间距离拉近，减少顾客的行走时间，将啤酒与尿不湿摆放在一起，同时将牛肉干等一些简便的下酒食品也摆放在一起，这样全年下来，营业额增加了几百万美元

（3）保险

海量数据挖掘及风险预测，助力保险行业精准营销，提升精细化定价能力，相当于保险公司的精算师，问题来了什么是精算师？我的理解就是精心算计咱们的师傅

（4）金融

多维度体现用户特征，帮助金融机构推荐优质客户，防范欺诈风险

（5）机器学习

机器学习是人工智能的一个分支

机器学习需要大量的数据作为其基础 通过一定的算法实现让机器学习的能力

 

什么是Hadoop

① Hadoop最早起源于Nutch，Nutch的设计目标是构建一个大型的全网搜索引擎，包括网页 抓取、索引、查询等功能，但随着抓取网页数量的增加，遇到了严重的可扩展性问题—— 如何解决数十亿网页的存储和索引问题

② 2003-2004 谷歌发表的两篇论文为该问题提供了可行的解决方案 分布式文件系统（GFS），可用于处理海量网页的存储
分布式计算框架MapReduce，可用于处理海量网页的索引计算问题，由此可见谷歌还是技术解决方案的领头羊

③ Nutch的开发人员完成了相应的开源实现Hdfs和MapReduce，并从Nutch中剥离成为独 立项目Hadoop，到2008年1月，Hadoop成为Apache顶级项目

④ 狭义上讲 Hadoop就是一个软件 包括 hdfs,mapreduce,yarn

⑤ 广义上讲 Hadoop是一个生态系统 包括 hive,hue,flume,sqoop,kafka,spark...等等

Hadoop的作者

Hadoop的作者是 Doug Cutting  而Hadoop则是他儿子的一只玩具象的名字，这不禁让我想起了unix之父 丹尼斯·里奇 只是为了玩便创建了举世闻名的unix系统，境界不一样啊

 

重点@分布式文件系统HDFS

1. hdfs是什么 

        ① hdfs 是一个高容错性的系统,适合部署在廉价的机器上

        ② hdfs 提供高吞吐量的数据访问,非常适合大规模数据集上的应用 

        ③ hdfs 放宽了一部分 posix约束,来实现流式读取文件系统数据的目的 

        ④ hdfs 在最开始是作为apache Nutch搜索引擎项目的基础框架而开发的 

        ⑤ hdfs 是apache hadoop core项目的一部分

2. 适用场景

        存储非常大的文件 这里非常大指的是几百M、G、或者TB级别 需要高吞吐量 对延时没有要求

3. 不适用场景

        低延时的数据访问 对延时要求在毫秒级别的应用 不适合采用HDFS HDFS是为高吞吐数 据传输设计的 因此可能牺牲延时

4. hdfs四个重要组件

        ① HdfsClient

        ② NameNode

        ③ DataNode

        ④ SecondaryNameNode

4.1 HdfsClient 

它是客户端（Linux命令行 浏览器界面）

        ① 文件切分 文件上传Hdfs的时候，Client将文件切分成一个一个的Block 然后进行存储

        ② 与Namenode交互 获取文件位置信息

        ③ 与DataNode交互 读取或写入数据

        ④ Client提供一些命令来管理和访问Hdfs 比如启动或者关闭Hdfs

4.2 Namenode

它是master 一个管理者（master代表这是一个主节点 类似于zookeeper主从机制 后面会单独讲解zk 因为分布式高可用集群zk是必不可少）

        ① NameNode上保存着HDFS的名字空间

        ② 对任何文件系统元数据产生修改的操作，Namenode都会使用一种称为EditLog的是我日志记录下来

        ③ Namenode在本地操作系统的文件系统中存储这个EditLog

        ④  整个文件系统的名字空间，包括数据块到文件的映射，文件属性等 都存储在一个称为Fsimage的文件中，这个文件也放在Namenode所在的本地文件系统上

        ⑤ NameNode在内存中保存着整个文件系统的名字空间和文件数据块映射(blockmap)的映像(一个4G的内存足够支撑大量的文件和目录)

        ⑥ NameNode启动时 从硬盘中读取EditLog和Fsimage将所有EditLog中的事务作用在内存中的Fsimage上，并将这个新版本的Fsimage从内存中保存到本地磁盘，然后删除旧的EditLog，这个过程称为检点(checkpoint)，在当前实现中，检点只发生在NameNode启动时

        ⑦ NameNode负责维护文件系统命名空间，任何文件系统名字空间属性的修改，都将被Namenode记录下来应用程序可以设置HDFS保存的文件的副本数目，文件副本数目成为文件副本系数，这个信息是由Namenode来保存

NameNode心跳机 

        全权管理数据块的复制 周期性接受心跳的状态报告信息 包含DataNode上所有数据块表 若接受到心跳信息NameNode认为DataNode工作正常 如果在10分钟后还接受到不到DN的心跳 那么NameNode认为DataNode已经宕机 这时候NN准备要把DN上的数据块进行重新的复制 块的状态报告包含了一个DN上所有数据块的列表 blocks report 每个1小时发送一次

4.3 DataNode  

它是Slave随从  NameNode下达命令DataNode执行实际的操作

        DataNode 将hdfs数据以文件的形式存储在本地文件系统中，它并不知道有关hdfs文件的信息，它把每个HDFS数据块存储在本地文件系统的一个单独的文件中 DataNode 并不在同一个目录创建所有的文件，实际上它用试探的方法来确定每个目录的最佳文件数目，并且在适当的时候创建子目录 在同一个目录中创建所有的本地文件并不是最优的选择，这是因为本地文件系统可能无法高效地在单个目录中支持大量的文件 当一个Datanode启动时，它会扫描本地文件系统，产生一个这些本地文件对应的所HDFS数据块的列表，然后作为报告发送到NameNode这个报告就是块状态

4.4 SecondNamenode  

它不是NameNode 的备胎 当NameNode挂掉的时候它并不能马上替换 NameNode 并提供服务 它是辅助 NameNode 分担其工作量 定期合并 fsimage和fsedits 并推送给NameNode 在紧急情况下可辅助恢复 NameNode

        ① NameNode响应SecondNamenode请求，将EditLog推送给SecondNameNode，开始重新写一个新的EditLog

        ② SecondaryNameNode收到来自NameNode的 Fsimage文件和EditLog

        ③ SecondaryNameNode将Fsimage加载到内存中 应用EditLog并生成一个新的Fsimage文件

        ④ SecondaryNameNode将新的Fsimage推送给Namenode

        ⑤ NameNode 用新的Fsimage取代旧的Fsimage并在Fstime文件中记下检点发生时间 

5. HDFS通信协议

        所有HDFS通信协议都是构建在TCP/IP协议上 客户端通过一个可配置的端口连接到Namenode通过ClientProtocol与NameNode交互而DataNode是使用DataNodeProtocol与Namenode交互，在设计上DateNode通过周期性的向Namenode发送心跳和数据块来保持和Namenode的通信 数据块报告的信息包括数据块的属性(既数据块属于哪个文件) 数据块ID，数据块修改时间，Namenode的DataNode和数据块的映射关系就是通过系统启动时DataNode的数据块报告建立的 从clientProtocol和DataNodeProtocol抽象出一个远程过程调用(RPC) 在设计上，NameNode不会主动发起RPC，而是响应来自客户端和DataNode的RPC请求

6. Hdfs工作机制概述

        ① Hdfs分为两大角色，Namenode，Datanode(Secondary Namenode)

        ② Namenode负责管理整个文件系统的元数据

        ③ Datanode负责管理用户的文件数据块

        ④ 文件会按照固定的大小(blockSize)切成若干后分布式存储在若干台Datanode上

        ⑤ 每一个文件块可以有多个副本，并存放在不同的Datanode上

        ⑥ Datanode会定期向Namenode汇报自身所保存的文件block信息，而Namenode,则会负责保持文件副本数量

        ⑦ Hdfs的内部工作机制对客户端保持透明，客户端请求访问Hdfs都是通过Namenode申请来进行

7. Hdfs机架感知

        HDFS分布式文件系统的内部有一个副本存放策略 以默认的副本数 等于3 为例

        第一个副本块存本机

        第二个副本块存跟本机同机架内的其他服务器节点

        第三个副本块存不同机架的一个服务器节点上

重点@HDFS常用命令

说了这么多理论的东西 我们来实际操作一下Hdfs

1. 创建需要操作的文件

        首先我们在 /usr/local/apps 目录下创建一个 fileData.txt 文件，通过vi命令向里面输入几行数据

vim fileData.txt

cat fileData.txt

 

2. 将fileData.txt文件上传到Hdfs上 

hdfs dfs -put fileData.txt  /

注意 这段命令分为两部分

        前一部分 hdfs dfs -put fileData.txt 是选取本地文件并上传

        后一部分 / 代表的不是linux根目录 而是Hdfs的根目录

        如果执行这段命令没有出现错误异常 那证明我们上传文件成功 

        提示 在linux上如果没有提示那就代表问题不大 一般出错了才会有提示

3. 在浏览器中查看已上传文件

首先通过浏览器访问我们的集群

mini-01:50070

mini-01 是我在 windwos  /etc/hosts 配置的IP于域名映射（该地址在windows上的目录如下）

C:\Windows\System32\drivers\etc

 

进入Hdfs根目录

查看根目录下fileData.txt文件是否存在（我这里已经上传成功了）

问题来了 fileData.txt 内容也就是几个字母为啥 blockSize 是128M？

上面已经讲过 hdfs 默认切割文件大小是128M 也就是说只要这个文件小于128M都按照128M处理

当然我们也可以在 hdfs-site.xml 文件中对这个默认值进行配置,，大家要记住这组数字 134217728（字节）转换后就是128M

 

4. 列出根目录下的所有文件目录

hdfs dfs -ls /

 

5. 在整个目录下递归执行ls

hdfs dfs -lsr /

 

6. 将Hdfs根目录下的fileData.txt文件拷贝到Linux本机的/usr/local目录下

hdfs dfs -get /fileData.txt /usr/local/

 

7. 在Hdfs根目录下创建文件夹 

 hdfs dfs -mkdir /fileDataDir

 

8. 将根目录下的fileData.txt文件移动到 fileDataDir目录下

hdfs dfs -mv /fileData.txt /fileDataDir

 

9. 查看文件内容（这里是查看Hdfs上的文件内容）

hdfs dfs -cat /fileDataDir/fileData.txt

 

10. 改变文件权限 如果使用 -R 选项则对整个目录有效递归执行 使用这一命令的用户必须是文件的所属用户或者超级用户

hdfs dfs -chmod -R 777 /fileDataDir/fileData.txt

11. 改变文件的所属用户和用户组 如果使用 -R 选项则对整个目录有效递归执行 使用这一命令的用户必须是文件的所属用户或者超级用户

hdfs dfs -chown -R hadoop:hadoop /fileData.txt

12. 将 /fileDataDir/fileData.txt 拷贝到/fileDataDirCp目录下并重命名为ins.txt

hdfs dfs -cp /fileDataDir/fileData.txt /fileDataDirCp/ins.txt

 

13. 删除目录及目录下的文件

hdfs dfs  -rm  -r /fileDataDirCp

14. appendToFile 追加一个或者多个文件到hdfs指定文件中也可以从命令行读取输入

hdfs dfs -appendToFile a.txt b.txt /fileDataDirCp/ins.txt

 

重点@Hdfs高级命令

上面我们已经了解了命令行中hdfs的简单使用 下面我们来看看hdfs的高级命令

1. 数量限额

① 创建Hdfs文件夹

hdfs dfs -mkdir -p /count/main/dir

② 给文件夹下面设置最多上传两个文件 发现只能上传一个文件 因为在Hdfs看来 dir也算一个文件 所以文件可上传数量为 n-所以这里设置为2 其实只能上传一个文件

hdfs dfsadmin -setQuota 2 /count/main/dir

③ 清除文件数量限制

hdfs dfsadmin -clrQuota /count/main/dir

2. 空间大小限额

        在设置空间配额时，设置的空间至少是block_size * 3大小

        默认设置配额空间必须是大于等于 128M * 3 = 384M

        如果一个文件是129M 空间大小为两个空间大小 最小设置空间大小为 128M * 6 = 768M

限制空间大小4kb

hdfs dfsadmin -setSpaceQuota 4k /count/main/dir

清除空间大小限额

hdfs dfsadmin -clrSpaceQuota /count/main/dir

 

3. Hdfs的安全模式

        安全模式是Hadoop的一种保护机制 用于保证集群中的数据块的安全性 当集群启动的时候 会首先进入安全模式 当系统处于安全模式时会检查数据块的完整性 副本率 实际副本数/设置的副本数

        hdfs官方文档  hdfs默认副本率 0.999

https://hadoop.apache.org/docs/r2.7.5/ 

        ！！！在安全模式状态下 文件系统只能接受读数据请求 而不接受删除 修改等变更请求 在整个系统达到安全标准时 Hdfs自动离开安全模式

安全模式操作命令

① 查看安全模式状态

hdfs dfsadmin -safemode get

② 进入安全模式

hdfs dfsadmin -safemode enter

③ 离开安全模式

hdfs dfsadmin -safemode leave

Hdfs文件写入过程

         ① Client 发起文件上传请求通过 RPC 与NameNode建立通讯 ，NameNode 检查目标文件是 否已存在，父目录是否存在返回是否可以上传

        ② Client 请求第一个block该传输到哪些 DataNode服务器上

        ③ NameNode 根据配置文件中指定的备份数量及机架感知原理进行文件分配，返回可用的 DataNode 的地址如  A，B，C Hadoop 在设计时考虑到数据的安全与高效 数据文件默认在 HDFS 上存放三份 存储策略为本地一份，同机架内其它某一节点上一份，不同机架的某一节点上一份

        ④ Client 请求3台DataNode中的一台A上传数据（本质上是一个 RPC 调用 建立 pipeline）A收到请求会继续调用B，然后B调用 C，将整个pipelin 建立完成后逐级返回client

        ⑤ Client 开始往A上传第一个block（先从磁盘读取数据放到一个本地内存缓存）以packet 为单位（默认64K） A收到一个packet 就会传给B，B传给C，A 每传一个packet会放入一个应答队列等待应答

        ⑥ 数据被分割成一个个 packet 数据包在pipeline上依次传输 在pipeline反方向上，逐个发送 ack（命令正确应答）最终pipeline中第一个 DataNode节点A将pipelineack发送给Client

        ⑦ 当一个block传输完成之后，Client 再次请求NameNode上传第二个block到服务

HDFS文件读取过程

        ① Client向nameNode发起RPC请求，来确定请求文件block所在的位置

        ② nameNode会视情况返回文件的部分或者全部block列表，对于每个block，nameNode都会返回含有该 block 副本dataNode地址， 这些返回的 dataNode地址，会按照集群拓扑结构得出 dataNode与客户端的距离，然后进行排序，排序两个规则：网络拓扑结构中距离 Client 近的排靠前，心跳机制中超时汇报的DataNode状态为STALE，这样的排靠后

        ③ Client 选取排序靠前的dataNode来读取 block，如果客户端本身就是dataNode，那么将从本地直接获取数据(短路读取特性)

        ④ 底层上本质是建立 Socket Stream（FSDataInputStream），重复的调用父类DataInputStream的read方法，直到这个块上的数据读取完毕

        ⑤ 当读完列表的block后，若文件读取还没有结束，客户端会继续向NameNode获取下一批的block列表

        ⑥ 读取完一个block都会进行checksum验证，如果读取dataNode时出现错误，客户端会通知nameNode，然后再从下一个拥有该block副本的DataNode继续读

        ⑦ Read 方法是并行的读取block信息，不是一块一块的读取，nameNode只是返回Client请求包含块的dataNode地址，并不是返回请求块的数据

        ⑧ 最终读取来所有的block会合并成一个完整的最终文件

Edits和FsImage 

1. Edits

        Edits 存放了客户端最近一段时间的操作日志 客户端对 HDFS 进行写文件时会首先被记录在 edits 文件中 Edits 修改时元数据也会更新

2. Fsimage
         ① NameNode 中关于元数据的镜像 一般称为检查点  fsimage 存放了一份比较完整的 元数据信息

         ② 因为 fsimage 是 NameNode 的完整的镜像, 如果每次都加载到内存生成树状拓扑结构 这是非常耗内存和CPU 所以一般开始时对 NameNode 的操作都放在 Edits 中

         ③ Fsimage 内容包含了 NameNode 管理下的所有 DataNode 文件及文件 block 及 block 所在的 DataNode 的元数据信息

         ④ 随着 edits 内容增大  就需要在一定时间点和 fsimage 合并

3. Fsimage 中的文件信息查看 首先进入如下目录

cd /usr/local/apps/hadoop-2.7.5/hadoopDatas/namenodeDatas/current

        生成xml文件

hdfs oiv -i fsimage_0000000000000038574 -p XML -o myFsImage.xml

 

通过文件传输助手将其导出 使用notepad++打开即可查看（我只截取一部分）

 

4. SecondaryNameNode 如何辅助管理 fsimage 与 edits 文件
        ① SecondaryNameNode 定期合并 fsimage 和 edits 把 edits 控制在一个范围内

        ② 配置 SecondaryNameNode  SecondaryNameNode 在 conf/masters 中指定，在 masters 指定的机器上, 修改 hdfs-site.xml 修改 core-site.xml

// 如果使用复制请把注释去掉
// 修改hdfs-site.xml
<property>
  <name>dfs.http.address</name>
  <value>mini-01:50070</value>
</property>


// 修改 core-site.xml 这一步不做配置保持默认也可以 
// 多久记录一次HDFS镜像默认1小时
<property>
  <name>fs.checkpoint.period</name>
  <value>3600</value>
</property>

// 一次记录多大默认64M
<property>
  <name>fs.checkpoint.size</name>
  <value>67108864</value>
</property>

        ③ SecondaryNameNode 通知NameNode切换Editlog
        ④ SecondaryNameNode 从NameNode中获得Fsimage和Editlog(通过http方式)
        ⑤ SecondaryNameNode 将Fsimage载入内存然后开始合并Editlog合并之后成为新的 Fsimage
        ⑥ SecondaryNameNode 将新的Fsimage发回给NameNode
        ⑦ NameNode 用新的Fsimage替换旧的Fsimage 

特点
        ① 完成合并的是 SecondaryNameNode会请求NameNode停止使用edits，暂时将新写操作放入一个新的文件中Edits.new

        ② SecondaryNameNode从nameNode 中通过 Http GET 获得edits因为要和Fsimage合并所以也是通过Http Get的方式把Fsimage 加载到内存，然后逐一执行具体对文件系统的操作与Fsimage合并生成新的Fsimage然后通过Http POST的方式把Fsimage发送给NameNode，NameNode从SecondaryNameNode 获得了Fsimage后会把原有的Fsimage替换为新的Fsimage把Edits.new变成 Edits. 同时会更新Fstime

        ③ Hadoop 进入安全模式时需要管理员使用dfsadmin的save namespace来创建新的检查点

        ④ SecondaryNameNode 在合并Edit和Fsimage时需要消耗的内存和NameNode 差不多所以一般把NameNode和 SecondaryNameNode 放在不同的机器上

 

 

以上 ~感谢！