Apache Hadoop HDFS

`

一.Apache Hadoop 简介

Hadoop的起源要从Google三篇论文说起

[① gfs ② MapReduce ③ Bigtable]

, 当时hadoop的开发者Dout Cutting 正在Lucene的子项目Nortch项目中需要对大量网页数据进行检索提取处理，并提取有用的数据，在看到此三篇论文后相继开发出了HDFS，MapReduce，在加上后续的HBASE，三篇论文的技术实现为大数据场景的应用为复杂业务的解决提供了更多的可能性。之后Hadoop的产品慢慢壮大，也渐渐形成了体系。大数据也因有了技术的支持，在全世界开始活跃起来。

gfs => HDFS

MapReduce => mapreduce

Bigtable => HBASE

狭义上：

Hadoop指的是Apache的hadoop产品，包括HDFS，Yarn与MapReduce三部分。

主要发行版：

Apache Hadoop            Apache 开源项目(主要有0.x版本，1.x版本，2.x版本，3.x版本)
Cloudera Hadoop          CDH系列
Hortonworks				 针对虚拟机，docker有支持，而且文档非常全面，现已和Cloudera合并

广义上：

Hadoop指代的是Hadoop生态圈。

二.Apache Hadoop HDFS

HDFS

:Hadoop生态圈的分布式文件系统，为大数据平台提供基础的高容错文件存储。

作为一种文件系统，与传统的PC机的本地文件系统(Windows的NDFS，Linux的ext4等)相比，分布式文件系统，具有更好的容错性(

副本体系

), 另外，由于是分散式存储，扩展性更强，同时由于副本都是分散式存储，数据的安全性也有大大提高。

那么问题来了。

Part One

HDFS能够解决大数据的那些问题？

主要解决的是海量数据的存储。

Part Two

虽然分散式存储，冗余备份(多副本)，为海量数据的存储提供了比较好的解决方案，但是对于文件的读写，那该从哪里读，往哪里写呢？

在回复这个问题前，有必要了解HDFS各部分组件的主要职责。HDFS的核心组件主要包括

NameNode

,

DataNodoe

和

SecondaryNameNode

。其中

NameNode

主要负责存储元数据(包括文件名，文件的目录结构，文件属性，文件快大小，每块所在的位置等)。

DataNode

才是真正负责存储数据的。如果把

DataNode

比作禁书的话，那么

NameNode

就好比禁书目录，无论是添加新的章节(上传文件)，还是修改部分推敲不太成熟的部分(写文件)，都需要进行登记。而

SecondaryNameNode

则好比老总(

NameNode

)的秘书一般，负责资料等的整理(负责元数据同步工作)。

因此，对于文件的读写过程中是不需要关注往哪里写，或者哪里读，你只需要提供相应的信息, 在

NameNode

处登记后，由

NameNode

检索即可。由

DataNode

进行存储和平行复制形成副本。

Part Three

HDFS的设计思想是什么？

分而治之，将大文件，大批量文件，分布式的存放在大量服务器上。以便于采取分而治之的方式对海量数据进行运算分析。

总结：

分而治之

(切分，分散存储)，

冗余备份

(高可靠)

Part Four

HDFS架构

NameNode

:HDFS集群的主节点，主要

负责维护目录树和元数据

(块存储信息，

DataNode

列表等)，内存+磁盘，向DataNode发布命令，负责均衡，保持副本数等

DataNode

:

真正存储数据的地方

，将块存储在本地硬盘，

检测块数据是否是正确

的，同时

会通过心跳机制汇报节点信息

。

Secondary NameNode

: 辅助

NameNode

的工作，下载

NameNode

的元数据和镜像信息，合并并返回

NameNode

中部分元数据信息。但是尽管如此，

SecondaryNameNode

也不能代替

NameNode

，但是可以说

SecondaryNameNode

中保存了

NameNode

中部分元数据信息。

副本机制：

一个副本所在机器宕机了，会生成一个副本，万一之前的副本恢复了，会删掉一个副本

.

Part Five

HDFS有哪些特性？

①

2.x默认块的大小128m

,通过在

hdfs-site.xml配置:dfs.blocksize

② namenode负责维护目录树和块信息(元数据)。

目录树

: 目录层级管理

[hadoop@mycat03 ~]$ hdfs dfs -ls /
Found 4 items
-rw-r--r--   3 hadoop hadoop          0 2019-03-06 19:29 /git.docx
drwxr-xr-x   - hadoop hadoop          0 2019-03-06 09:45 /mktest
drwx------   - hadoop hadoop          0 2019-03-05 20:14 /tmp
drwxr-xr-x   - hadoop hadoop          0 2019-03-05 20:53 /user

块信息: blk id信息,存储的

DataNode(DN)

列表

③ hdfs适合一次写入,多次读取,不允许修改,允许追加。

Part Six

HDFS有哪些优点？那些缺点？

HDFS优点：

可构建在廉价的服务器上，提供了容错机制和回复机制

高容错性

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

检测和快速应对硬件故障

:

在集群的环境中，硬件故障是常见的问题。因为有上千台服务器连接在一起，这样会导致高故障率。因此故障检测和自动恢复是hdfs文件系统的一个设计目标。

流式数据访问

:

Hdfs的数据处理规模比较大，应用一次需要访问大量的数据，同时这些应用一般都是批量处理，而不是用户交互式处理。应用程序能以流的形式访问数据集。主要的是数据的吞吐量，而不是访问速度。

简化的一致性模型

:

大部分hdfs操作文件时，需要一次写入，多次读取。在hdfs中，一个文件一旦经过创建、写入、关闭后，一般就不需要修改了。这样简单的一致性模型，有利于提高吞吐量。

HDFS缺点：

低延迟数据访问，比如毫秒级，低延迟与高吞吐率

小文件存储

占用NameNode大量内存 150B*1000w=15E,即1.5G,寻道时间超过读取时间

并发写入，文件随即修改(一个文件只能有一个写者，仅支持append)

Part Seven

为什么HDFS上不适合存储大量小文件？

小文件过多，会过多占用namenode的内存，并浪费block

:

① 文件的元数据（包括文件被分成了哪些blocks，每个block存储在哪些服务器的哪个block块上），都是存储在namenode上的。
HDFS的每个文件、目录、数据块占用150B，因此300M内存情况下，只能存储不超过300M/150=2M个文件/目录/数据块的元数据。

② dataNode会向NameNode发送两种类型的报告：增量报告和全量报告。
增量报告是当dataNode接收到block或者删除block时，会向nameNode报告。
全量报告是周期性的，NN处理100万的block报告需要1s左右，这1s左右NN会被锁住，其它的请求会被阻塞。

文件过小，寻道时间大于数据读写时间，这不符合HDFS的设计

:

HDFS为了使数据的传输速度和硬盘的传输速度接近，则设计将寻道时间（Seek）相对最小化，将block的大小设置的比较大，这样读写数据块的时间将远大于寻道时间，接近于硬盘的传输速度。

Part Eight

如何搭建这样的HDFS分布式文件系统呢？

在Apache Hadoop官网，提供了

单节点

，

伪分布式

，

完全分布式

，

高可用(HA)集群

和

联邦集群

几种方案，将

NameNode

，

SecondaryNameNode

和

DataNode

分别部署到不同节点即可。(配置hadoop-env.sh配置环境变量和JVM参数等 => 外置配置，hdfs-site.xml,core-sizte.xml配置

NameNode

和

SecondaryNameNode

等)。

完全分布式方案是最初的企业应用解决方案，但是存在单点故障和NameNode压力(只有一个NameNode节点多台DataNode节点)，所以便有了HA方案，通过配置多个NameNode，解决单点故障，一旦集群中有一个NameNode宕机了，就可以从余下的NameNode中选取新的NameNode作为主节点，一般来说，此方案，任何时候只有一台NameNode在工作，此方案NameNode的压力没有得到改善，于是又推出了联邦机制。

active namenode: 活跃的，接受客户端请求，处理DataNode

standby namenode: 不活跃的(热备)

所谓联邦机制，即多个NameNode节点可以同时工作，任务分散给多个NameNode执行，但是此方案，存在单点故障，没有课切换的备机。

Part Nine

如何使用Java API操作HDFS呢？

maven依赖:  groupId:org.apache.hadoop   artifactId:hadoop-common
groupId:org.apache.hadoop   artifactId:hadoop-hdfs
groupId:org.apache.hadoop   artifactId:hadoop-hdfs-nfs

具体的程序操作会在后面单独章节列出来。

Part Ten

这里的副本是不是类似于Redis中的副本(主从)呢？

和Redis不同，HDFS这种副本备份不能够完全意义上称之为一主多从，毕竟Redis的主从可是主节点和从节点的数据要求一致的，而对于HDFS而言，所谓的一主只是一个

NameNode

节点加多个

DataNode

从节点。两者存储的数据完全不同，因此并不能称之为完全意义上的主从。