Hadoop之HDFS架构演进之路

 

 Doug Cutting，从这个人的发量看起来就是很厉害的人，Hadoop之父，同时也是Lucene、Nutch 、Hadoop等项目的发起人，我们在介绍Hadoop之前知道有这样一个人就可以了。 

Hadoop的产生背景

首先，我们要知道，一门新技术的产生或者新生事物的出现必然是因为在该领域出现了难以突破的瓶颈和障碍，因为有需要，所以新生的技术和领域会不断催生出来，独领风骚，因此我们需要不断学习去追赶时代潮流，落后就要淘汰。

21世纪是大数据爆发时代，随着信息数量以爆炸式增长，传统的数据库和计算引擎已经跟不上数据增长的速度以及业务对海量数据处理效率的要求，“数据”的价值逐步得到体现和重视，“数据资产”毫无疑问将是数字经济下越来越重要的一项资产，也将是全球经济竞争的重要领域。数字经济时代的数据主要有四个特点

• Volume：数据体量大， 数据量已经从TB（1024GB=1TB）级别跃升到PB（1024TB=1PB）、EB（1024PB=1EB）乃至ZB(1024EB=1ZB)级别，随着“物联网”的到来，传感器的大范围使用，数据增长空间更加巨大
• Variety：数据的多样性，随着互联网时代的崛起，数据来源有了更多的形式，丰富的数据应用场景产生了各种结构化数据、半结构化数据已经非结构数据
• Velocity：数据处理效率，海量的技术意味着对数据处理计算能力提出更高的要求，人们对数据响应速度要求越来越高，趋向实时或准实时响应
• Value：数据价值，海量的数据本身价值很低，如何从海量的数据里面提取出有价值的信息成为数据应用的大方向，通过各种指标的提取使得数据具现化，典型的应用如 用户画像、音乐推荐系统、电商推荐系统等

 

最早提出“大数据”时代到来的是全球知名咨询公司麦肯锡，麦肯锡称：“数据，已经渗透到当今每一个行业和业务职能领域，成为重要的生产因素。人们对于海量数据的挖掘和运用，预示着新一波生产率增长和消费者盈余浪潮的到来。“大数据”在 物理学、生物学、环境生态学等领域以及军事、金融、通讯等行业存在已有时日，却因为近年来互联网和信息行业的发展而引起人们关注，推动了大数据技术的变革，Hadoop因此产生并得到发展，让我们一起了解Hadoop的架构演变吧。

 

Hadoop是什么

The Apache™ Hadoop® project develops open-source software for reliable, scalable, distributed computing

The Apache Hadoop software library is a framework that allows for the distributed processing of large data sets across clusters of computers using simple programming models. It is designed to scale up from single servers to thousands of machines, each offering local computation and storage. Rather than rely on hardware to deliver high-availability, the library itself is designed to detect and handle failures at the application layer, so delivering a highly-available service on top of a cluster of computers, each of which may be prone to failures.

Hadoop是Apache开源的分布式软件开发框架，提供可靠的、可扩展的分布式计算能力。主要是通过分而治之，移动数据不如移动计算的核心思想，支持通过大量服务器组成集群，将数据存储在多个服务器上，每一台服务器都可以提供计算能力，从而大大提升数据计算能力，解决海量数据存储以及计算的难题，将计算任务分配到每台服务器上进行计算结果，最后统一汇总到管理节点得到最终的结果。

 

Hadoop的架构组成

Hadoop的诞生源于Google三篇论文，也就是我们经常说的“三辆马车”，2006年Hadoop出了第一个发行版本，Hadoop到目前为止发展已经有10余年，版本经过了无数次的更新迭代，目前业内大家把Hadoop大的版本分为Hadoop1，hadoop2，Hadoop3三个版本。

 

 

“三辆马车”分别是GFS、MapReduce、BigTable，和Hadoop生态的对应关系如下：

Google三篇论文	Hadoop生态
GFS分布式文件系统	HDFS
MapReduce计算模型	MapReduce
BigTable	Hbase

HDFS主要是用来解决海量数据存储的问题，MapReduce是用来解决海量数据计算的问题，而Hbase则是底层基于HDFS的列式存储数据库，适用于结构化存储，用来解决海量数据映射及查询的问题，当然Hadoop生态不仅仅于此，Hadoop生态是一个庞大的生态圈，简短的篇幅难以涵盖。

 

本文我们主要介绍HDFS的体系架构：

Hadoop分布式文件系统(HDFS)被设计成适合运行在通用硬件(commodity hardware)上的分布式文件系统。它和现有的分布式文件系统有很多共同点。但同时，它和其他的分布式文件系统的区别也是很明显的。HDFS是一个高度容错性的系统，适合部署在廉价的机器上，降低生产成本。HDFS能提供高吞吐量的数据访问，非常适合大规模数据集上的应用。

 

HDFS架构演进之路

 

HDFS架构演进

 

HDFS 1.0架构

一般来说，架构我们分两种，一种就是主从架构，另一种是对等架构。在大数据生态中，常用的对等架构有Zookeeper、Kafka，而HDFS是主从式（master/slave）结构，由NameNode和DataNode以及SecondaryNamenode组成，如下图所示：

 

Namenode：属于集群中的中心服务器，管理节点，主要负责管理文件系统的命名空间(namespace)以及客户端对文件的访问，比如打开、关闭、重命名文件或目录，同时管理集群元数据的存储，记录文件中数据块（block）的映射关系。

Datanode：顾名思义Datanode主要负责存储用户数据，处理来自文件系统客户端的请求，保持与namenode的通信，执行namenode的调度指令。

SeconddaryNameNode：主要是合并NameNode的edit logs到fsimage文件。

 

HDFS 1.0分布式文件系统由一个Namenode和多个Datanode共同组成，大家可以思考一下这样会出现什么问题呢？

没错，相信大家都能想到，HDFS 1.0会出现SPOF（single point of failure）单点故障的问题以及内存受限的问题，在实际生产中我们是无法接受这样问题的出现，一旦NameNode出现了故障或者宕机，会导致数据丢失。这个问题在HDFS 2.0得到了圆满的解决。

 

HDFS 2.0架构

 

 

HDFS 2.0采用HA（高可用）的方案，相对于HDFS 1.0来说，Namenode会区分两种状态，active和standby，正常工作的时候时候由active Namenode对外提供服务，standby Namenode则会从journalnode同步元数据，保证和active保持元数据一致，当active Namenode出现故障或者宕机的时候，standby会自动切换为新的active Namenode对外提供服务，并且HA对外提供了统一的访问名称，对于用户来说，不管访问的Namenode是active状态还是standby状态都是无感知的。

 

此外HDFS 2.0通过federation（联邦）机制解决了内存受限的问题，思考一个问题，一个集群的内存是有限，当内存不足的时候我们要怎么处理呢，很多同学会说加内存，加机器，当然方向是对的，可是一个集群之间的通信需要成本，管理节点能力也是有限的。因此HDFS 2.0采用了建仓库的办法，也就是federation机制，一般适用于1000+规模的集群，小公司基本是用不上。

 

HDFS 3.0架构

HDFS 3.0在架构上相对于HDFS 2.0没什么大的调整，HDFS 2.0只支持至多两个Namenode，而HDFS 3.0在2.0的基础上增加了多个Namenode的支持，提高集群可用性。主要聚焦提升底层数据存储优化，降低数据开销的成本，采用纠错码技术提高集群的容错性。

 

 

总结

通过对Hadoop架构的介绍以及演进，我们对Hadoop有了大致的认知，知道Hadoop的架构组成及用途，了解Hadoop架构演进每个阶段主要解决了什么问题，希望对大家有所帮助

注：本文主要是讲述Hadoop之HDFS的架构演进，不涉及具体代码