Apache Hadoop、HDFS介绍

Hadoop介绍

用Java语言实现开源
允许用户使用简单的编程模型实现对海量数据发分布式计算处理
Hadoop核心组件：

1. HDFS ：存储
2. YARN：资源调度
3. MapReduce：计算

广义Hadoop是指大数据生态圈

HAdoop特点：扩容能力、成本低、效率高、可靠性（多份复制）

Hadoop集群

Hadoop包括两个集群：HDFS集群、YARN集群

• 逻辑上分离：两集群相互之间没有依赖关系，互不影响
• 物理上在一起：往往部署在同一台物理服务器上
• ＭapReduce是计算框架、代码层面的组件，没有集群之说

启停操作：

• 手动逐个进程启停：
• shell脚本一键启停
  HDFS集群：start-dfs.sh stop-dfs.sh
  YARN集群：start-yarn.sh stop-yarn.sh
  hadoop集群： start-all.sh stop-all.sh

启动完毕后可以使用jps命令查看进程是否启动成功
Hadoop启动日志路径 /expert/server/hadoop-3.3.0/logs/

• HDFS本质是一个文件系统
• 有目录树结构，和Linux类似

HDFS分布式文件系统基础

文件系统与分布式文件系统

文件系统是一种存储组织数据的方法，实现了数据的存储、分级组织，访问获取等，使得用户对文件访问和查找变得容易

传统文件系统多指单机文件系统，比如Windows文件系统、Linux文件系统、FTP文件系统等，特点是：

• 带有抽象的目录树结构，树都是从/根目录开始调度
• 树中节点分为：目录和文件
• 从根目录开始，节点路径具有唯一性

数据：底层是存储在磁盘上的，用户只需基于目录树进行增删改查即可，实际针对数据的操作由文件系统完成
元数据：记录数据的数据
文件系统元数据，一般指文件大小、最后修改时间、底层存储位置、属性，所属用户、权限等信息

大数据时代下，单机遇到问题：成本大，计算效率低、性能低

分布式存储系统核心属性：分布式存储、元数据记录、分块存储、副本机制
1，分布式存储
问题：存储遇到瓶颈
单机纵向扩展：磁盘不够家磁盘，有上限瓶颈限制
多机横向扩展：机器不够加机器，理论上无限扩展 —多机分布式
2，元数据记录
文件分布在不同机器上不利于查找 — 元数据记录，快速定位文件位置
3，文件分块存储
问题：文件过大导致单机存不下，上传下载效率低
解决：将文件分块，存储在不同机器上，针对块并行操作提高效率
4，副本机制
问题：硬件故障，数据容易丢失
解决：不同机器设置备份，冗余存储、保证数据安全

总结：分布式存储系统核心属性：

1. 分布式存储：无限支持海量数据存储
2. 元数据记录：快速定位文件位置便于查找
3. 文件分块存储：块并行操作提高效率
4. 设置副本备份：冗余存储，保证数据安全

HDFS简介

HDFS：HAdoop分布式文件系统

作为大数据生态圈最底层，主要用于解决大数据存储问题，HDFS使用多台计算机存储文件，并且提供统一的访问接口

HDFS的核心架构目标：故障检测和自动快速恢复
HDFS对文件要求write-one-read-many。一个文件一旦创建、写入、关闭之后就不需要修改了
HDFS适合场景：大文件、一次写入多次访问，低成本部署、高容错数据流式访问
HDFS不适合场景：小文件、数据交互式访问、频繁任意修改、低延迟处理

图中rack指机架
特点：

1. 主从架构：1个Namenode 5个Datenodes
   Namenode是HDFS主节点，Datanode是HDFS从节点，两种角色各司其职，共同协调完成分布式的文件存储服务

2. 数据都是小方块–分块存储
   HDFS中的文件在物理上是分块存储（block）的，默认大小是128M（134217728），不足128M则本身就是一块，即只有文件超过1278时才会被分块

3. 块与块之间replication–副本备份
   副本数由参数dfs.replication控制，默认值是3，也就是会额外再复制2份，连同本身总共3份副本。

4. Namenode中记录Metadata元数据
   在HDFS中，Namenode管理的元数据具有两种类型：
   1.文件自身属性信息
   文件名称、权限，修改时间，文件大小，复制因子，数据块大小。
   2.文件块位置映射信息
   记录文件块和DataNode之间的映射信息，即哪个块位于哪个节点上。

5. 抽象统一的目录树结构
   HDFS会给客户端提供一个统一的抽象目录树，客户端通过路径来访问文件

HDFS shell命令行

命令行CLI：指用户通过键盘输入指令，计算机接收到指令后予以执行的一种人机交互方式
Hadoop中shell命令行：hadoop fs [generic options]

在node1中输入:

hadoop fs -ls file:/// 
#查看的本地文件系统hadoop fs -ls hdfs://node1:8020/
#查看hdfs根目录下hdoop fs -ls /
#输出的是hdfS的目录，是因为设置的默认是hdfscat /export/server/hadoop-3.3.0/etc/hadoop/core-size.html
#查看，可以看到默认的是hdfs

hdfs中shell命令和Linux很相似

hadoop fs -mkdir [-p] … 创建文件夹，-p是如果父目录不存在主动创建
hadoop fs -ls [-h] [-R] [ …] 查看指定目录下内容
hadoop fs -put [-f] [-p] … 上传文件到指定目录
-f 覆盖目标文件（已存在下）
-p 保留访问和修改时间，所有权和权限。
localsrc 本地文件系统（客户端所在机器）
dst 目标文件系统（HDFS）

hadoop fs -put file:///root/2.txt hdfs://node1:8020/ithei
#将本地root目录下2.txt文件上传到hefs上node1端口号8020的ithei文件下
#上面的省略写法：
hadoop fs -put 2.txt /

hadoop fs -cat … 查看hdfs文件内容

hadoop fs -cat /ithei/2.txt

hadoop fs -get [-f] [-p] … 下载hdfs上文件到本地

hadoop fs -get /ithei/2.txt ./666.txt
#将hdfs上ithei文件夹下2.txt文件下载到本地/根目录下，并改名为了666.txt

hadoop fs -cp [-f] … 拷贝hdfs文件

Hadoop fs -put 1.txt  #1.txt上传到hads
hadoop fs -cat /1.txt  

hadoop fs -appendToFile … 将所有给定本地文件的内容追加到给定dst文件.追加合并

echo 1 > 1.txt  #将内容1写入1.txt
echo 2 > 2.txt
echo 3 > 3.txthadoop fs -put 1.txt /  #先将1.txt上传
hadoop fs -cat /1.txt  #查看hdfs上/目录下1.txt内容，输出1
hadoop fs -appendToFile 2.txt 3.txt /1.txt   #将2.txt与3.txt追加到1.txt中
hadoop fs -cat /1.txt  #再次查看，输出1，2，3

官方指导文档

HDFS工作流程与机制

HDFS集群角色与职责

主角色：namenode

• NameNode是Hadoop分布式文件系统的核心，架构中的主角色。
• NameNode维护和管理文件系统元数据，包括名称空间目录树结构、文件和块的位置信息、访问权限等信息。
• 基于此，NameNode成为了访问HDFS的唯一入口。
• NameNode内部通过内存和磁盘文件两种方式管理元数据。（内存速度快，但是断电数据丢失，所以也放在磁盘文件上）
• namenode仅存储HDFS的元数据，并不存储数据块
• namenode知道任何给定文件的块列表和位置。用户想要查找某文件都必须通过namenode
• namenode并不持久存储每个文件中各个块所在的datenode信息，关机后只记录有哪些文件，文件中有哪些块并不知道，这些信息在系统启动中由小弟汇报过来
• namenode需要大内存，因为元数据存储需要大内存
• namenode是Hadoop集群中的单点故障（单点故障：某一个局部出问题会导致整体出问题。上课老师与同学中，老师便是一个单点故障）

从角色：datanode

• DataNode是Hadoop HDFS中的从角色，负责具体的数据块存储
• 并和NameNode配合维护着数据块，要删就删，要增就增
• datenode负责最终块block的存储，也称为slave，从角色
• 启动时，会将自己注册到nameode并汇报自己所有的块列表
• 当某个datenode关闭时，不会影响数据，因为是默认3副本，冗余存储
• datenode在部署时需要大量硬盘空间，即大磁盘，因为实际数据在datenode中

主角色辅助角色： secondarynamenode

• 充当NameNode的辅助节点，但不能替代NameNode
• 主要是帮助主角色进行元数据文件的合并动作。可以理解为主角色的“秘书”

HDFS写数据流程（上传文件）

Pipeline管道
这是HDFS在上传文件写数据过程中采用的一种数据传输方式

• 客户端将数据块写入第一个数据节点，第一个数据节点保存数据之后再将块复制到第二个数据节点，后者保存后将其复制到第三个数据节点。
• 为什么datanode之间采用pipeline线性传输，而不是一次给三个datanode拓扑式传输呢？
  因为数据以管道的方式，顺序的沿着一个方向传输，这样能够充分利用每个机器的带宽，避免网络瓶颈和高延迟时的连接，最小化推送所有数据的延时。
  
  ACK应答响应
• ACK (Acknowledge character）即是确认字符，在数据通信中，接收方发给发送方的一种传输类控制字符。表示发来的数据已确认接收无误。
• 在HDFS pipeline管道传输数据的过程中，传输的反方向会进行ACK校验，确保数据传输安全

默认3副本存储策略

1. 第一块副本：优先客户端本地，否则就近随机
2. 第二块副本：不同于第一块副本的不同机架。机架类似机柜
3. 第三块副本：第二块副本相同机架不同机器。
   

上传文件流程：

1. HDFS客户端创建对象实例DistributedFileSystem， 该对象中封装了与HDFS文件系统操作的相关方法。
2. 调用DistributedFileSystem对象的create()方法，通过RPC请求NameNode创建文件。
   NameNode执行各种检查判断：目标文件是否存在、父目录是否存在、客户端是否具有创建该文件的权限。
   检查通过， NameNode就会为本次请求记下一条记录，返回FSDataOutputStream输出流对象给客户端用于写数据。
3. 客户端通过FSDataOutputStream输出流开始写入数据。
4. 客户端写入数据时，将数据分成一个个数据包（packet 默认64k）, 内部组件DataStreamer请求NameNode挑选出适合存储数据副本的一组DataNode地址，默认是3副本存储
5. 传输的反方向上，会通过ACK机制校验数据包传输是否成功；
6. 客户端完成数据写入后，最后在FSDataOutputStream输出流上调用close()方法关闭。
7. DistributedFileSystem联系NameNode告知其文件写入完成，等待NameNode确认。
   因为namenode已经知道文件由哪些块组成（DataStream请求分配数据块），因此仅需等待最小复制块即可成功返回。
   最小复制是由参数dfs.namenode.replication.min指定，默认是1.只要有一个副本成功就认为是上传成功。

HDFS读数据流程（下载文件）

读数据流程：

1. HDFS客户端创建对象实例DistributedFileSystem， 调用该对象的open()方法来打开希望读取的文件。

2. DistributedFileSystem使用RPC调用namenode来确定文件中前几个块的块位置（分批次读取）信息。

3. DistributedFileSystem将FSDataInputStream输入流返回到客户端以供其读取数据。

4. 客户端在FSDataInputStream输入流上调用read()方法。然后，已存储DataNode地址的InputStream连接到文件中第一个块的最近的DataNode。数据从DataNode流回客户端，结果客户端可以在流上重复调用read（）。

5. 当该块结束时，FSDataInputStream将关闭与DataNode的连接，然后寻找下一个block块的最佳datanode位置。这些操作对用户来说是透明的。所以用户感觉起来它一直在读取一个连续的流
   客户端从流中读取数据时，也会根据需要询问NameNode来检索下一批数据块的DataNode位置信息。

6. 一旦客户端完成读取，就对FSDataInputStream调用close()方法。