hadoop--HDFS基础（适合初学者）
文章目录
-
-
- 1 HDFS分布式文件系统基础
-
- 1.1 文件系统
- 1.2 分布式文件系统
- 1.3 HDFS简介
- 1.4 HDFS起源发展
- 1.5 HDFS设计目标
- 1.6 HDFS应用场景
- 1.7 HDFS重要特性
- 2 HDFS shell操作
-
- 2.1 HDFS shell命令行解释说明
- 2.2 HDFS shell命令行常用操作
-
- 创建文件夹
- 查看指定目录下内容
- 上传文件到HDFS指定目录下
- 查看HDFS文件内容
- 拷贝HDFS文件
- 追加数据到HDFS文件中
- HDFS数据移动操作
- 命令官方指导文档
- 3 HDFS工作流程与机制
-
- 3.1 HDFS集群角色与职责
- 3.2 HDFS写数据流程（上传文件）
- 3.3 HDFS读数据流程（下载文件）
-
1 HDFS分布式文件系统基础
1.1 文件系统
概述：
- 文件系统是一种存储和组织数据的方法，实现了数据的存储、分级组织、访问和获取等操作，使得用户对文件访问和查找变得容易；
- 文件系统使用树形目录的抽象逻辑概念代替了硬盘等物理设备使用数据块的概念，用户不必关心数据底层存在硬盘哪里，只需要记住这个文件的所属目录和文件名即可；
- 文件系统通常使用硬盘和光盘这样的存储设备，并维护文件在设备中的物理位置；
传统常见的文件系统：
所谓传统常见的文件系统更多指的的单机的文件系统，也就是底层不会横跨多台机器实现。比如windows操作系统上的文件系统、Linux上的文件系统、FTP文件系统等等。这些文件系统的共同特征包括：
- 带有抽象的目录树结构，树都是从/根目录开始往下蔓延；
- 树中节点分为两类：目录和文件；
- 从根目录开始，节点路径具有唯一性。
数据：指存储的内容本身，比如文件、视频、图片等，这些数据底层最终是存储在磁盘等存储介质上的，一般用户无需关心，只需要基于目录树进行增删改查即可，实际针对数据的操作由文件系统完成。
元数据（metadata）又称之为解释性数据，记录数据的数据；文件系统元数据一般指文件大小、最后修改时间、底层存储位置、属性、所属用户、权限等信息。
海量数据带来的问题：
-
成本高：传统存储硬件通用性差，设备投资加上后期维护、升级扩容的成本非常高。
-
如何支撑高效率的计算分析：传统存储方式意味着数据：存储是存储，计算是计算，当需要处理数据的时候把数据移动过来。程序和数据存储是属于不同的技术厂商实现，无法有机统一整合在一起。
-
性能低：单节点I/O性能瓶颈无法逾越，难以支撑海量数据的高并发高吞吐场景。
-
可扩展性差：无法实现快速部署和弹性扩展，动态扩容、缩容成本高，技术实现难度大。
1.2 分布式文件系统
**核心属性：**分布式存储、元数据记录、分块存储、副本机制。
问：数据量大，单机存储遇到瓶颈。
解：单机纵向扩展：磁盘不够加磁盘，有上限瓶颈限制。多机横向扩展：机器不够加机器，理论上无限扩展。
问：文件分布在不同机器上不利于寻找。
解：元数据记录下文件及其存储位置信息，快速定位文件位置。
问：文件过大导致单机存不下、上传下载效率低。
解：文件分块存储在不同机器，针对块并行操作提高效率。
问：硬件故障难以避免，数据易丢失。
解：不同机器设置备份，冗余存储，保障数据安全。
1.3 HDFS简介
-
HDFS（Hadoop Distributed File System ），意为：Hadoop分布式文件系统。是Apache Hadoop核心组件之一，作为大数据生态圈最底层的分布式存储服务而存在。也可以说大数据首先要解
-
决的问题就是海量数据的存储问题。
-
HDFS主要是解决大数据如何存储问题的。分布式意味着是HDFS是横跨在多台计算机上的存储系统。
-
HDFS是一种能够在普通硬件上运行的分布式文件系统，它是高度容错的，适应于具有大数据集的应用程序，它非常适于存储大型数据 (比如 TB 和 PB)。
-
HDFS使用多台计算机存储文件, 并且提供统一的访问接口, 像是访问一个普通文件系统一样使用分布式文件系统。
1.4 HDFS起源发展
Doug Cutting领导Nutch项目研发，Nutch的设计目标是构建一个大型的全网搜索引擎，包括网页抓取、索引、查询等功能。随着爬虫抓取网页数量的增加，遇到了严重的可扩展性问题——如何解决数十亿网页的存储和索引问题。2003年的时候, Google 发表的论文为该问题提供了可行的解决方案。《分布式文件系统（GFS），可用于处理海量网页的存储》Nutch的开发人员完成了相应的开源实现HDFS，并从Nutch中剥离和MapReduce成为独立项目HADOOP。
1.5 HDFS设计目标
- 硬件故障（Hardware Failure）是常态， HDFS可能有成百上千的服务器组成，每一个组件都有可能出现故障。因此故障检测和自动快速恢复是HDFS的核心架构目标。
- HDFS上的应用主要是以流式读取数据（Streaming Data Access）。HDFS被设计成用于批处理，而不是用户交互式的。相较于数据访问的反应时间，更注重数据访问的高吞吐量。
- 典型的HDFS文件大小是GB到TB的级别。所以，HDFS被调整成支持大文件（Large Data Sets）。它应该提供很高的聚合数据带宽，一个集群中支持数百个节点，一个集群中还应该支持千万级别的文件。
- 大部分HDFS应用对文件要求的是write-one-read-many访问模型。一个文件一旦创建、写入、关闭之后就不需要修改了。这一假设简化了数据一致性问题，使高吞吐量的数据访问成为可能。
- 移动计算的代价比之移动数据的代价低。一个应用请求的计算，离它操作的数据越近就越高效。将计算移动到数据附近，比之将数据移动到应用所在显然更好。
- HDFS被设计为可从一个平台轻松移植到另一个平台。这有助于将HDFS广泛用作大量应用程序的首选平台。
1.6 HDFS应用场景
适合：大文件、数据流式访问、一次写入多次读取、低成本部署，廉价PC、高容错。
不适合：小文件、数据交互式访问、频繁任意修改、低延迟处理。
1.7 HDFS重要特性
主从架构、分块存储、副本机制、元数据记录、抽象统一的目录树结构（namespace）
主从架构：
- HDFS集群是标准的master/slave主从架构集群。
- 一般一个HDFS集群是有一个Namenode和一定数目的Datanode组成。
- Namenode是HDFS主节点，Datanode是HDFS从节点，两种角色各司其职，共同协调完成分布式的文件存储服务。
- 官方架构图中是一主五从模式，其中五个从角色位于两个机架（Rack）的不同服务器上。
分块存储：
- HDFS中的文件在物理上是分块存储（block）的，默认大小是128M（134217728），不足128M则本身就是一块。
- 块的大小可以通过配置参数来规定，参数位于hdfs-default.xml中：dfs.blocksize。
副本机制：
- 文件的所有block都会有副本。副本系数可以在文件创建的时候指定，也可以在之后通过命令改变。
- 副本数由参数dfs.replication控制，默认值是3，也就是会额外再复制2份，连同本身总共3份副本。
元数据记录：
在HDFS中，Namenode管理的元数据具有两种类型：
- 文件自身属性信息：文件名称、权限，修改时间，文件大小，复制因子，数据块大小。
- 文件块位置映射信息：记录文件块和DataNode之间的映射信息，即哪个块位于哪个节点上。
抽象统一的目录树结构（namespace）：
- HDFS支持传统的层次型文件组织结构。用户可以创建目录，然后将文件保存在这些目录里。文件系统名字空间的层次结构和大多数现有的文件系统类似：用户可以创建、删除、移动或重命名文件。
- Namenode负责维护文件系统的namespace名称空间，任何对文件系统名称空间或属性的修改都将被Namenode记录下来。
- HDFS会给客户端提供一个统一的抽象目录树，客户端通过路径来访问文件，形如：hdfs://namenode:port/dir-a/dir-b/dir-c/file.data
数据块存储
- 文件的各个block的具体存储管理由DataNode节点承担。
- 每一个block都可以在多个DataNode上存储。
2 HDFS shell操作
2.1 HDFS shell命令行解释说明
概述：
- 命令行界面（英语：command-line interface，缩写：CLI），是指用户通过键盘输入指令，计算机接收到指令后，予以执行一种人际交互方式。
- Hadoop提供了文件系统的shell命令行客户端: hadoop fs [generic options]
文件系统协议：
- HDFS Shell CLI支持操作多种文件系统，包括本地文件系统（file:///）、分布式文件系统（hdfs://nn:8020）等
- 具体操作的是什么文件系统取决于命令中文件路径URL中的前缀协议。
- 如果没有指定前缀，则将会读取环境变量中的fs.defaultFS属性，以该属性值作为默认文件系统。
hadoop fs -ls file:/// #操作本地文件系统
hadoop fs -ls hdfs://node1:8020/ #操作HDFS分布式文件系统
hadoop fs -ls / #直接根目录，没有指定协议 将加载读取fs.defaultFS值
区别：
- hadoop dfs 只能操作HDFS文件系统（包括与Local FS间的操作），不过已经弃用（Deprecated）；
- hdfs dfs 只能操作HDFS文件系统相关（包括与Local FS间的操作）,常用；
- hadoop fs 可操作任意文件系统，不仅仅是hdfs文件系统，使用范围更广；
目前版本来看，官方最终推荐使用的是hadoop fs。当然hdfs dfs在市面上的使用也比较多。
HDFS文件系统的操作命令很多和Linux类似，因此学习成本相对较低。可以通过hadoop fs -help命令来查看每个命令的详细用法。
2.2 HDFS shell命令行常用操作
创建文件夹
hadoop fs -mkdir [-p] ...
- path 为待创建的目录
- -p选项的行为与Unix mkdir -p非常相似，它会沿着路径创建父目录，简单来说就是支持多级创建文件夹。
示例： hadoop fs -mkdir /a
查看指定目录下内容
hadoop fs -ls [-h] [-R] [ ...]
- path 指定目录路径
- -h 人性化显示文件size
- -R 递归查看指定目录及其子目录
上传文件到HDFS指定目录下
hadoop fs -put [-f] [-p] ...
- -f 覆盖已存在的目标文件
- -p 保留访问和修改时间，所有权和权限。
- localsrc 本地文件系统（客户端所在机器）
- dst 目标文件系统（HDFS）
查看HDFS文件内容
hadoop fs -cat ...
- 读取指定文件全部内容，显示在标准输出控制台。
- 注意：对于大文件内容读取，慎重
下载HDFS文件
hadoop fs -get [-f] [-p] ...
- 下载文件到本地文件系统指定目录，localdst必须是目录
- -f 覆盖目标文件（已存在下）
- -p 保留访问和修改时间，所有权和权限。
拷贝HDFS文件
hadoop fs -cp [-f] ...
- -f 覆盖已存在的目标文件
追加数据到HDFS文件中
hadoop fs -appendToFile ...
- 将所有给定本地文件的内容追加到给定dst文件。
- dst如果文件不存在，将创建该文件。
- 如果为-，则输入为从标准输入中读取
HDFS数据移动操作
hadoop fs -mv ...
- 移动文件到指定文件夹下
- 可以使用该命令移动数据，重命名文件的名称
命令官方指导文档
https://hadoop.apache.org/docs/r3.3.0/hadoop-project-dist/hadoop-common/FileSystemShell.html
3 HDFS工作流程与机制
3.1 HDFS集群角色与职责
官方架构图：
主角色namenode：
- NameNode是Hadoop分布式文件系统的核心，架构中的主角色。
- NameNode维护和管理文件系统元数据，包括名称空间目录树结构、文件和块的位置信息、访问权限等信息。
- 基于此，NameNode成为了访问HDFS的唯一入口。
- NameNode内部通过内存和磁盘文件两种方式管理元数据。
- 其中磁盘上的元数据文件包括Fsimage内存元数据镜像文件和edits log（Journal）编辑日志。
职责：
- NameNode仅存储HDFS的元数据：文件系统中所有文件的目录树，并跟踪整个集群中的文件，不存储实际数据。
- NameNode知道HDFS中任何给定文件的块列表及其位置。使用此信息NameNode知道如何从块中构建文件。
- NameNode不持久化存储每个文件中各个块所在的datanode的位置信息，这些信息会在系统启动时DataNode重建。
- NameNode是Hadoop集群中的单点故障。
- NameNode所在机器通常会配置有大量内存（RAM）。
从角色datanode：
- DataNode是Hadoop HDFS中的从角色，负责具体的数据块存储。
- DataNode的数量决定了HDFS集群的整体数据存储能力。通过和NameNode配合维护着数据块。
职责：
- DataNode负责最终数据块block的存储。是集群的从角色，也称为Slave。
- DataNode启动时，会将自己注册到NameNode并汇报自己负责持有的块列表。
- 当某个DataNode关闭时，不会影响数据的可用性。 NameNode将安排由其他DataNode管理的块进行副本复制。
- DataNode所在机器通常配置有大量的硬盘空间，因为实际数据存储在DataNode中。
主角色辅助角色： secondarynamenode
- Secondary NameNode充当NameNode的辅助节点，但不能替代NameNode。
- 主要是帮助主角色进行元数据文件的合并动作。可以通俗的理解为主角色的“秘书”。
3.2 HDFS写数据流程（上传文件）
核心概念：
- Pipeline管道
- Pipeline，中文翻译为管道。这是HDFS在上传文件写数据过程中采用的一种数据传输方式。
- 客户端将数据块写入第一个数据节点，第一个数据节点保存数据之后再将块复制到第二个数据节点，后者保存后将其复制到第三个数据节点。
为什么datanode之间采用pipeline线性传输，而不是一次给三个datanode拓扑式传输呢？
- 因为数据以管道的方式，顺序的沿着一个方向传输，这样能够充分利用每个机器的带宽，避免网络瓶颈和高延迟时的连接，最小化推送所有数据的延时。
- 在线性推送模式下，每台机器所有的出口宽带都用于以最快的速度传输数据，而不是在多个接受者之间分配宽带。
- ACK应答响应
- ACK (Acknowledge character）即是确认字符，在数据通信中，接收方发给发送方的一种传输类控制字符。表示发来的数据已确认接收无误。
- 在HDFS pipeline管道传输数据的过程中，传输的反方向会进行ACK校验，确保数据传输安全。
- 默认3副本存储策略
- 默认副本存储策略是由BlockPlacementPolicyDefault指定。
- 第一块副本：优先客户端本地，否则随机
- 第二块副本：不同于第一块副本的不同机架。
- 第三块副本：第二块副本相同机架不同机器。
完整流程图：
- HDFS客户端创建对象实例DistributedFileSystem， 该对象中封装了与HDFS文件系统操作的相关方法。
- 调用DistributedFileSystem对象的create()方法，通过RPC请求NameNode创建文件。NameNode执行各种检查判断：目标文件是否存在、父目录是否存在、客户端是否具有创建该文件的权限。检查通过，NameNode就会为本次请求记下一条记录，返回FSDataOutputStream输出流对象给客户端用于写数据。
- 客户端通过FSDataOutputStream输出流开始写入数据。
- 客户端写入数据时，将数据分成一个个数据包（packet 默认64k）, 内部组件DataStreamer请求NameNode挑选出适合存储数据副本的一组DataNode地址，默认是3副本存储。DataStreamer将数据包流式传输到pipeline的第一个DataNode,该DataNode存储数据包并将它发送到pipeline的第二个DataNode。同样，第二个DataNode存储数据包并且发送给第三个（也是最后一个）DataNode。
- 传输的反方向上，会通过ACK机制校验数据包传输是否成功；
- 客户端完成数据写入后，在FSDataOutputStream输出流上调用close()方法关闭。
- DistributedFileSystem联系NameNode告知其文件写入完成，等待NameNode确认。因为namenode已经知道文件由哪些块组成（DataStream请求分配数据块），因此仅需等待最小复制块即可成功返回。最小复制是由参数dfs.namenode.replication.min指定，默认是1.
3.3 HDFS读数据流程（下载文件）
- HDFS客户端创建对象实例DistributedFileSystem， 调用该对象的**open()**方法来打开希望读取的文件。
- DistributedFileSystem使用RPC调用namenode来确定文件中前几个块的块位置（分批次读取）信息。对于每个块，namenode返回具有该块所有副本的datanode位置地址列表，并且该地址列表是排序好的，与客户端的网络拓扑距离近的排序靠前。
- DistributedFileSystem将FSDataInputStream输入流返回到客户端以供其读取数据。
- 客户端在FSDataInputStream输入流上调用read()方法。然后，已存储DataNode地址的InputStream连接到文件中第一个块的最近的DataNode。数据从DataNode流回客户端，结果客户端可以在流上重复调用read（）。
- 当该块结束时，FSDataInputStream将关闭与DataNode的连接，然后寻找下一个block块的最佳datanode位置。这些操作对用户来说是透明的。所以用户感觉起来它一直在读取一个连续的流。客户端从流中读取数据时，也会根据需要询问NameNode来检索下一批数据块的DataNode位置信息。
- 一旦客户端完成读取，就对FSDataInputStream调用close()方法。