Hadoop的前世今生

什么是大数据

各行各业都会产生大量的数据，比如社交网站的意见观点，电商平台人们浏览网页停留的时间，交通运输每天产生的数据等等。这些数据大多不是结构化的，一般来说都是半结构化或者非结构化的

在以前，我们的处理能力达不到，所以很多数据要么没有存起来，要么没有利用起来。而现在数据越来越集中在云端的服务器上，并且计算能力已经今非昔比了，我们完全有能力对大数据进行存储和分析。

所以所谓的大数据指的就是，原有的计算能力无法处理的大批量的数据，而大数据技术研究的是如何快速有效的处理这些结构化、半结构化数据的技术。

处理大数据的架构

下图是传统的集中式架构

image.png

它的主要问题在于扩展性不强而且数据库将成为很大的瓶颈。

所以谷歌提出了

• MapReduce算法

• BigTable

• GFS

合称“三剑客”。

那么相对于传统的架构，有什么样的变化呢？

• 首先它可以使用大量的x86服务器，而不是使用性能强健的大型机来完成计算，也就是Scale-out的

• 另外它使用软件方案来保证硬件故障容错

  我们知道x86服务器的稳定性不如小型机，存在一定的故障的可能，但是小型机实在太贵了。我们完全可以让x86服务器组成集群，然后使用上层软件来保障整体的硬件故障容错。

• 简化并行分布式计算，不需要再控制节点的同步和数据的交换。

image.png

Hadoop模仿Google的实现方式，最终演变成一系列的开源项目。

总结一下：

大数据既是一个概念又是一门技术，它是以Hadoop和Spark为代表的大数据基础框架，可以实现数据分析、挖掘、预测。

Hadoop

上面说到Hadoop是一种分布式计算解决方案，含有若干组件，其中最著名的当属

• HDFS分布式文件系统：存储海量数据

  存储技术是大数据的基础，因为对于大量的数据，我们希望能找的一种比较廉价的方式来保存我们的数据，那么分布式文件系统当属首选。

• MapReduce编程模型：

  并行处理框架，实现任务分解和调度

所以Hadoop的优势在于：

• 高扩展性，也就是可以通过增加节点来活动性能提升，比如说性能不够了，就怼新的服务器上去。

• 低成本，可以基于便宜的x86服务器

• 成熟的生态圈，里面有大量的工具集可以使用

下面分别介绍一下HDFS和MapReduce

image.png

HDFS

在【大话存储II】学习笔记（15章），文件级集群系统中我们介绍了分布式集群的基本概念。

分布式文件系统可以等价于非共享存储集群文件系统，也就是说同一个文件系统下的文件是存放在不同的节点里面，而且Sharing-nothing

那么分布式文件系统应该解决

• 统一的命名空间，也就是对外显现同一个文件目录。

  这样用户不用管数据是如何存放的，分布式文件系统已经帮它解决存放的问题了，用户用起来就像使用本地文件一样简单。

• 缓存一致，因为数据都缓存在各自的节点，不存在不缓存不一致的情况。

• 分布式锁，也就是多个连接并发访问的时候，如何控制文件的数据会出现不一致的情况。

若要理解HDFS，我们需要知道如下的基本概念。

基本概念

分布式设计

HDFS这样的架构，非常类似于【大话存储II】学习笔记（15章），块级集群存储系统中的XIV，当然XIV是提供块存储的，不过XIV也利用了文件系统的思想，对每个块像一个文件一样。

HDFS的基本存储和操作单位是数据块， 默认大小64MB，一般设置为128M。为什么要这么设计呢？因为一个文件会比较大，为了分布式存放，可以分成若干小块。那么最好就切成相同大小，比如说64MB。

image.png

而且为了保证数据块不丢失，对每个数据块会保存3副本，分布在两个机架的三个节点中。 其中两份在同一个机架，一份在另一个机架。

比如下图中两个A数据块放在机架1，另一份副本放到了机架2 。

image.png

角色

在【大话存储II】学习笔记（15章），文件级集群系统我们介绍过，分布式文件系统有对称和非对称的两种。

对称集群中所有节点的地位相同，互相维护通信链接进行数据同步，也正因为如此，不适合扩展。

而HDFS采用的是非对称集群，所以有Master和Slave两种角色。

Master就是HDFS中的NameNode，它的作用是 存放元数据，管理文件系统的命名空间。也就是一个注册中心，其他的Slave都要到它这边注册。

Master和Slave组成集群以后，可以自服务，也可以对外提供服务。

它会记录两种信息：

• 文件与数据块的映射关系

• 数据块与服务器的对应关系，也就是每个块存放的节点的信息

Slave则是DataNode，它的主要作用就是存放数据块，是具体的执行者。

当块存储信息改变了以后，DataNode会向NameNode主动更新信息

image.png

另外，在这种主从架构里面，NameNode的地位很超然，非常的重要，一旦他挂了则整个系统就宕了。

所以从HDFS 2x就可以为NameNode配置HA了。

如下图所示，出现了一个Secondary NameNode。

image.png

二级NameNode定期同步元数据镜像文件和修改日志，当NameNode发生故障时，备胎转正。

image.png

HDFS的读与写

写

下面我们来看一下写流程。

image.png

• 客户端向NameNode发出请求，表示自己要发送文件了，然后NameNode会返回现在空余存储的信息

• 然后客户端将文件分块，

• 接着，客户端将数据块1以及相应的元数据信息发给DataNode1

• 然后开启流水线复制，将数据同步给另外的节点

• 写完了以后，DataNode才返回更新信息，最后NameNode向客户端返回成功。

image.png
image.png

读文件

下图展示了HDFS的读流程

image.png

• 首先客户端向NameNode发起读请求，将路径+文件名发过去

• NameNode返回元数据，告诉客户端可以从哪些地方取

• 然后由客户端自己向DataNode读取数据

image.png

HDFS的特点

了解了HDFS的架构以及读写流程以后，我们可以总结一下HDFS的特点。

本质上HDFS就是一个分布式文件系统，它

• 通过三副本机制进行冗余，类似于的分布式的RAID10

• 它的写比较的复杂，需要复制2份，还要同步各种信息，而且修改也比较麻烦，只能删除以后再写。所以比较适合于一次写入，多次读取的场景，现在的OLAP就比较契合

• 因为每次写或者读都需要向NameNode发起请求，所以NameNode是整个系统的瓶颈，所以如果是小文件的话，NameNode压力非常大。

也就是说HDFS适合于批量读，这样吞吐量高，因为可以并发读嘛。

但是不支持多用户写相同的文件，因为没有加锁。

也就是不适合交互应用以及那些实时性要求高的地方。

image.png