大数据-Hadoop-HDFS(一)：数据存储模块(Hadoop Distributed File System,分布式文件系统)【适合一次写入，多次读出的场景】【可以追加数据，但不可修改已有数据】

本文主要是介绍大数据-Hadoop-HDFS(一)：数据存储模块(Hadoop Distributed File System,分布式文件系统)【适合一次写入，多次读出的场景】【可以追加数据，但不可修改已有数据】，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

一、HDFS概述

1、HDFS产出背景及定义

• 随着数据量越来越大，在一个操作系统存不下所有的数据，那么就分配到更多的操作系统管理的磁盘中，但是不方便管理和维护，迫切需要一种系统来管理多台机器上的文件，这就是分布式文件管理系统。HDFS只是分布式文件管理系统中的一种。
• HDFS（Hadoop Distributed File System），它是一个文件系统，用于存储文件，通过目录树来定位文件；其次，它是分布式的，由很多服务器联合起来实现其功能，集群中的服务器有各自的角色。
• HDFS的使用场景：适合一次写入，多次读出的场景，且不支持文件的修改。适合用来做数据分析，并不适合用来做网盘应用。

2、HDFS优点

• 高容错性

  1. 数据自动保存多个副本。它通过增加副本的形式，提高容错性。
     
  2. 某一个副本丢失以后，它可以自动恢复。
     

• 适合处理大数据

  1. 数据规模：能够处理数据规模达到GB、TB、甚至PB级别的数据；
  2. 文件规模：能够处理百万规模以上的文件数量，数量相当之大。

• 可构建在廉价机器上，通过多副本机制，提高可靠性。

3、HDFS缺点

• 不适合低延时数据访问：HDFS不适合低延时数据访问，比如毫秒级的存储数据，是做不到的。

• 无法高效的对大量小文件进行存储。

  • 存储大量小文件的话，它会占用NameNode大量的内存来存储文件目录和块信息。这样是不可取的，因为NameNode的内存总是有限的；
  • 小文件存储的寻址时间会超过读取时间，它违反了HDFS的设计目标。
  • 根本原因： HDFS存储了大量的小文件，会降低NameNode的服务能力！NameNode负责文件元数据(属性，块的映射)的管理，NameNode在运行时，必须将当前集群中存储所有文件的元数据全部加载到内存！NameNode需要大量内存！
  • 举例： 当前运行NN的机器，有64G内存，除去系统开销，分配给NameNode50G内存！
    1. 文件a (1k), 存储到HDFS上，需要将a文件的元数据保存到NameNode，加载到内存。a文件的元数据包括： 文件名 创建时间 所属主 所属组 权限 修改时间+ 块的映射(1块)，假设这些元数据大小为150B，则最多存储$\frac{50G}{150B}$个文件a的元数据信息，能存储的文件a的总大小为： $\frac{50G}{150B}\times 1k$
    2. 文件b (128M), 存储到HDFS上，需要将b文件的元数据保存到NameNode，加载到内存。b文件的元数据包括： 文件名 创建时间 所属主 所属组 权限 修改时间+块的映射(1块)，假设这些元数据大小为150B，则最多存储$\frac{50G}{150B}$个文件b的元数据信息，能存储的文件b的总大小为：$\frac{50G}{150B}\times 128M$

• 不支持并发写入、文件随机修改

  • HDFS不支持对文件的随机写，即仅支持数据append（追加），不支持文件的随机修改！原因： 文件在HDFS上存储时，以block为基本单位存储！
    1. 没有提供对文件的在线寻址(打开)功能；
    2. 文件以块形式存储，修改了一个块中的内容，就会影响当前块之后所有的块，效率低；
  • 同一个文件在同一时刻只能由一个客户端写入！

4、HDFS组成架构

• NameNode（nn）：就是Master，它是一个主管、管理者。
  1. 管理HDFS的名称空间；
  2. 配置副本策略；
  3. 管理数据块（Block）映射信息；
  4. 处理客户端读写请求。
• DataNode：就是Slave。NameNode下达命令，DataNode执行实际的操作。
  1. 存储实际的数据块；
  2. 执行数据块的读/写操作。
• Client：就是客户端。
  1. 文件切分。文件上传HDFS的时候，Client将文件切分成一个一个的Block，然后进行上传；
  2. 与NameNode交互，获取文件的位置信息；
  3. 与DataNode交互，读取或者写入数据；
  4. Client提供一些命令来管理HDFS，比如NameNode格式化；
  5. Client可以通过一些命令来访问HDFS，比如对HDFS增删查改操作；
• Secondary NameNode：并非NameNode的热备。当NameNode挂掉的时候，它并不能马上替换NameNode并提供服务。
  1. 辅助NameNode，分担其工作量，比如定期合并Fsimage和Edits，并推送给NameNode ；
  2. 在紧急情况下，可辅助恢复NameNode。

5、HDFS文件块(block)大小

HDFS中的文件在物理上是分块存储（Block），块的大小可以通过配置参数( dfs.blocksize)来规定，默认大小在Hadoop2.x版本中是128M，老版本中是64M。

• 默认块大小为128M，128M指的是块的最大大小！每个块最多存储128M的数据，如果当前块存储的数据不满128M，存了多少数据，就占用多少的磁盘空间！
• HDFS的文件块(block)的大小设置主要取决于磁盘传输速率。
• 一个文件块(block)不管大小，只属于一个文件！
  

5.1 文件块(block)大小的计算

• 默认为128M的原因，基于最佳传输损耗理论！
• 最佳传输损耗理论：在一次传输中，寻址时间占用总传输时间的1%时，本次传输的损耗最小，为最佳性价比传输！
• 不论对磁盘的文件进行读还是写，都需要先进行寻址！
• 目前硬件的发展条件，普通磁盘写的速率大概为100M/S, 寻址时间一般为10ms，传输时间 = $\frac{10ms}{1\%}=1s$
• 所以一个block的大小理论上设置为 $100M/s\times 1s=100M$最合适
• 另一方面，块在传输时，每64K还需要校验一次，因此块大小，必须为2的n次方，最接近100M的就是128M！
• 如果公司使用的是固态硬盘，写的速度是300M/S，将块大小调整到 256M
• 如果公司使用的是固态硬盘，写的速度是500M/S，将块大小调整到 512M

5.2 文件块(block)大小要合适

• 文件块(block)大小不能太大
  • 如果块设置的太大，从磁盘传输数据的时间会明显大于定位这个块开始位置所需的时间。导致程序在处理这块数据时，会非常慢。
  • 在上传文件时，一旦发生故障，会造成资源的浪费。
  • 在一些分块读取的场景，不够灵活，会带来额外的网络消耗，比如：当前有文件A(大小为1G)，
    1. 如果文件块(block)大小为128M，则文件A存在8块block中。如果只需要读取A文件0-128M部分的内容，需要读取取第一块block，即需要读取128M的内容即可。
    2. 如果文件块(block)大小为1G， 则文件A存在1块block中。只需要读取A文件0-128M部分的内容，需要读取取第一块block，则需要读取1G的内容。
• 文件块(block)大小不能太小
  • HDFS的块比磁盘的块大，其目的是为了最小化寻址开销；
  • 块设置太小，会增加寻址时间，程序一直在找块的开始位置；比如：文件A(大小为128M)
    1. 如果block的大小为1M，则需要生成128个block，同时在NameNode中要生成128个映射信息与之对应；
    2. 如果block的大小为128M，则需要生成1个block，同时在NameNode中要生成1个映射信息与之对应；
  • 块太小，同样大小的文件，会占用过多的NameNode的元数据空间
  • 块太小，在进行读写操作时，会消耗额外的寻址时间

二、HFDS的Shell操作

1、基本语法

bin/hadoop fs 具体命令   

bin/hdfs dfs 具体命令

dfs是fs的实现类。

2、命令大全

[wyr@hadoop102 hadoop-2.7.2]$ bin/hadoop fs[-appendToFile <localsrc> ... <dst>][-cat [-ignoreCrc] <src> ...][-checksum <src> ...][-chgrp [-R] GROUP PATH...][-chmod [-R] <MODE[,MODE]... | OCTALMODE> PATH...][-chown [-R] [OWNER][:[GROUP]] PATH...][-copyFromLocal [-f] [-p] <localsrc> ... <dst>][-copyToLocal [-p] [-ignoreCrc] [-crc] <src> ... <localdst>][-count [-q] <path> ...][-cp [-f] [-p] <src> ... <dst>][-createSnapshot <snapshotDir> [<snapshotName>]][-deleteSnapshot <snapshotDir> <snapshotName>][-df [-h] [<path> ...]][-du [-s] [-h] <path> ...][-expunge][-get [-p] [-ignoreCrc] [-crc] <src> ... <localdst>][-getfacl [-R] <path>][-getmerge [-nl] <src> <localdst>][-help [cmd ...]][-ls [-d] [-h] [-R] [<path> ...]][-mkdir [-p] <path> ...][-moveFromLocal <localsrc> ... <dst>][-moveToLocal <src> <localdst>][-mv <src> ... <dst>][-put [-f] [-p] <localsrc> ... <dst>][-renameSnapshot <snapshotDir> <oldName> <newName>][-rm [-f] [-r|-R] [-skipTrash] <src> ...][-rmdir [--ignore-fail-on-non-empty] <dir> ...][-setfacl [-R] [{-b|-k} {-m|-x <acl_spec>} <path>]|[--set <acl_spec> <path>]][-setrep [-R] [-w] <rep> <path> ...][-stat [format] <path> ...][-tail [-f] <file>][-test -[defsz] <path>][-text [-ignoreCrc] <src> ...][-touchz <path> ...][-usage [cmd ...]]

3、常用命令实操

• 启动Hadoop集群（方便后续的测试）

  [wyr@hadoop102 hadoop-2.7.2]$ sbin/start-dfs.sh
  [wyr@hadoop103 hadoop-2.7.2]$ sbin/start-yarn.sh
  

• -help：输出这个命令参数

  [wyr@hadoop102 hadoop-2.7.2]$ hadoop fs -help rm
  

• -ls: 显示目录信息

  [wyr@hadoop102 hadoop-2.7.2]$ hadoop fs -ls /
  

• -mkdir：在HDFS上创建目录

  [wyr@hadoop102 hadoop-2.7.2]$ hadoop fs -mkdir -p /sanguo/shuguo
  

• -moveFromLocal：从本地剪切粘贴到HDFS

  [wyr@hadoop102 hadoop-2.7.2]$ touch kongming.txt
  [wyr@hadoop102 hadoop-2.7.2]$ hadoop fs  -moveFromLocal  ./kongming.txt  /sanguo/shuguo
  

• -appendToFile：追加一个文件到已经存在的文件末尾

  [wyr@hadoop102 hadoop-2.7.2]$ touch liubei.txt
  [wyr@hadoop102 hadoop-2.7.2]$ vi liubei.txt
  输入
  san gu mao lu
  [wyr@hadoop102 hadoop-2.7.2]$ hadoop fs -appendToFile liubei.txt /sanguo/shuguo/kongming.txt
  

• -cat：显示文件内容

  [wyr@hadoop102 hadoop-2.7.2]$ hadoop fs -cat /sanguo/shuguo/kongming.txt
  

• -chgrp 、-chmod、-chown：Linux文件系统中的用法一样，修改文件所属权限

  [wyr@hadoop102 hadoop-2.7.2]$ hadoop

这篇关于大数据-Hadoop-HDFS(一)：数据存储模块(Hadoop Distributed File System,分布式文件系统)【适合一次写入，多次读出的场景】【可以追加数据，但不可修改已有数据】的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！

---