第一章 Hadoop 分布式文件系统HDFS
第一代大数据框架Hadoop由：HDFS分布式文件系统、MapReduce计算框架和YARN资源调度框架组成，本文为学习HDFS分布式文件系统时记录的学习笔记。
前言
Hadoop作为第一代大数据框架，在大数据行业一直非常热门，直到现在还是有许多企业在使用该框架。尤其对与熟悉Java的同学，Hadoop框架是入门大数据的首选。
一、什么是Hadoop?
1.hadoop的发展历史起源介绍
Hadoop最早起源于Nutch。Nutch的设计目标是构建一个大型的全网搜索引擎，包括网页抓取、索引、查询等功能，但随着抓取网页数量的增加，遇到了严重的可扩展性问题——如何解决数十亿网页的存储和索引问题。
2003年、2004年谷歌发表的两篇论文为该问题提供了可行的解决方案。
——分布式文件系统（GFS），可用于处理海量网页的存储
——分布式计算框架MAPREDUCE，可用于处理海量网页的索引计算问题。
Nutch的开发人员完成了相应的开源实现HDFS和MAPREDUCE，并从Nutch中剥离成为独立项目HADOOP，到2008年1月，HADOOP成为Apache顶级项目(同年，cloudera公司成立)，迎来了它的快速发展期。
Hadoop作者Doug Cutting
Apache Lucene是一个文本搜索系统库
Apache Nutch作为前者的一部分，主要包括web爬虫、全文检索；2003年“谷歌分布式文件系统GFS”论文，2004年开源版本HDFS
2004年“谷歌MapReduce”论文，2005年Nutch开源版MapReduce。
2.hadoop的发展历史起源构
HDFS模块：
namenode：主节点，主要负责集群的管理以及元数据信息管理
datanode：从节点，主要负责存储用户数据
secondaryNameNode：辅助namenode管理元数据信息，以及元数据信息的冷备份
Yarn模块：
ResourceManager：主节点，主要负责资源分配
NodeManager：从节点，主要负责执行任务
二、HDFS分布式文件系统
1.分布式文件系统的理解
图中小王收藏的avi存储于哪台机器上的记录我们称之为元数据，元数据保存在内存中。
最直观的理解便是三个臭皮匠，顶个诸葛亮。
很多的磁盘加一起就可以装下天下所有的avi
类似于你出五毛，我出五毛，我们一起凑一块的效果
2.hdfs的架构详细剖析
1. 文件分块存储&3副本
保存文件到HDFS时，会先默认按
128M的大小对文件进行切分；效果如上图
数据以block块的形式进统一存储管理，每个block块默认最多可以存储128M的文件。
每个block块的元数据大小大概为150字节
所有的文件都是以block块的方式存放在HDFS文件系统当中，在hadoop1当中，文件的block块默认大小是64M，hadoop2当中，文件的block块大小默认是128M，block块的大小可以通过hdfs-site.xml当中的配置文件进行指定
<property><name>dfs.block.size</name><value>块大小 以字节为单位</value><!-- 只写数值就可以 --></property>
为了保证block块的安全性，也就是数据的安全性，在hadoop2当中，文件默认保存
三个副本，我们可以更改副本数以提高数据的安全性，如动图中block2副本所在的机器宕机，namenode在发现后，会通知其他某个block2副本所在机器重新创建一个副本，发送到其他机器，保证每个block都会有3个副本的存在。
在hdfs-site.xml当中修改以下配置属性，即可更改文件的副本数
<property><name>dfs.replication</name><value>3</value></property>
2. 抽象成数据块的好处
1.一个文件可能大于集群中的任何一个磁盘，分成多个块，就可以完整的将文件存在不同磁盘里；
2.文件只考虑块的概念，从而简化了文件系统的设计；
3.抽象成块后便于备份，有利于数据的容错和可用性。
3.HDFS架构
HDFS集群包括，NameNode和DataNode以及Secondary Namenode。
NameNode负责管理整个文件系统的元数据，以及每一个路径（文件）所对应的数据块信息。
DataNode 负责管理用户的文件数据块，每一个数据块都可以在多个datanode上存储多个副本。
Secondary NameNode用来监控HDFS状态的辅助后台程序，每隔一段时间获取HDFS元数据的快照。最主要作用是辅助namenode管理元数据信息
3.hdfs的shell命令
HDFS命令有两种风格：
hadoop fs开头的
hdfs dfs开头的
两种命令均可使用，效果相同
如何查看hdfs或hadoop子命令的帮助信息，如ls子命令
hdfs dfs -help lshadoop fs -help ls #两个命令等价
4.NameNode和SecondaryNameNode功能剖析
namenode与secondaryName解析
NameNode主要负责集群当中的元数据信息管理，而且元数据信息需要经常随机访问，因为元数据信息必须高效的检索，那么如何保证namenode快速检索呢？？元数据信息保存在哪里能够快速检索呢？？如何保证元数据的持久安全呢？？
为了保证元数据信息的快速检索，那么我们就必须将元数据存放在内存当中，因为在内存当中元数据信息能够最快速的检索，那么随着元数据信息的增多（每个block块大概占用150字节的元数据信息），内存的消耗也会越来越多。
如果所有的元数据信息都存放内存，服务器断电，内存当中所有数据都消失，为了保证元数据的安全持久，元数据信息必须做可靠的持久化，在hadoop当中为了持久化存储元数据信息，将所有的元数据信息保存在了FSImage文件当中，那么FSImage随着时间推移，必然越来越膨胀，FSImage的操作变得越来越难，为了解决元数据信息的增删改，hadoop当中还引入了元数据操作日志edits文件，edits文件记录了客户端操作元数据的信息，随着时间的推移，edits信息也会越来越大，为了解决edits文件膨胀的问题，hadoop当中引入了secondaryNamenode来专门做fsimage与edits文件的合并
namenode工作机制
（1）第一次启动namenode格式化后，创建fsimage和edits文件。如果不是第一次启动，直接加载编辑日志和镜像文件到内存。
（2）客户端对元数据进行增删改的请求
（3）namenode记录操作日志，更新滚动日志。
（4）namenode在内存中对数据进行增删改查
Secondary NameNode工作
（1）Secondary NameNode询问namenode是否需要checkpoint。直接带回namenode是否检查结果。
（2）Secondary NameNode请求执行checkpoint。
（3）namenode滚动正在写的edits日志
（4）将滚动前的编辑日志和镜像文件拷贝到Secondary NameNode
（5）Secondary NameNode加载编辑日志和镜像文件到内存，并合并。
（6）生成新的镜像文件fsimage.chkpoint
（7） 拷贝fsimage.chkpoint到namenode
（8）namenode将fsimage.chkpoint重新命名成fsimage
总结
以上是关于HDFS的学习笔记，介绍了Hadoop框架，详细描述了HDFS架构，其中block的划分以及 NameNode和SecondaryNameNode功能剖析需要重点掌握，下半部分关于HDFS的笔记中会补充HDFS的读写流程、datanode工作机制以及数据存储和hdfs的小文件治理等一些关于HDFS的进阶知识。
