• Hadoop3教程(二):HDFS的定义及概述


    (40)HDFS产生的背景和定义

    随着实际生产环境中的数据越来越大,在一台服务器上无法存储下所有的数据,那么就要把数据分散到多台服务器的磁盘里存放。但是像这样做跨服务器的数据管理和维护是很难的,所以就迫切需要一种方式,来协调管理多台机器上的文件,这就是分布式文件管理系统。

    HDFS就是最有名气的一种分布式文件管理系统,除此之外还有Google的GFS、淘宝自研的TFS等。

    HDFS(Hadoop Distributed File System),就是分布式文件管理系统的一种,它本质上是一个文件系统。

    它可以分布式的(在多台服务器节点上),以目录树的形式来存储和定位文件。

    跟windows的NTFS文件系统是一样的。

    HDFS的使用场景:适合一次写入,多次读出的场景。如果是需要频繁update的场景,其实是不适合HDFS。当然,只是不适合,不是不能用,完全可以用delete + 重新insert的方式,来实现update。

    (41)HDFS的优缺点

    HDFS的优点:

    1) 高容错性

    • 自动保存多个副本(多个节点保存多个副本)
    • 副本丢失后,可以自动恢复

    2) 适合处理大数据(只要资源够,处理上限很高)

    • 能够处理PB级别的数据;
    • 文件数量,百万级以上;

    3) 可以构建在廉价的机器上,通过多副本机制,提高可靠性。

    HDFS的缺点:

    1) 低延时数据访问不合适,毫秒级存储数据,那是不可能的;

    2)无法高效的存储大量的小文件:

    • 小文件会占用NameNode大量的内存来存储文件目录和块信息。每个文件都要在NameNode中创建一个保存元数据的地方(索引),这个大小是固定的,150byte,即使是小文件也是,所以大量小文件很容易就把NameNode占满。
    • 小文件过多的话,寻址时间会超过读取时间,违反HDFS的设计目标;

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

    • 一个文件只能有一个写,不允许多线程一起写;
    • 仅支持数据的追加,不支持随机修改;

    (42)HDFS组成架构

    HDFS里主要涉及4个组件:

    • NameNode
    • DataNode
    • Client
    • SecondaryNameNode

    1)NameNode(NN),是HDFS里的Master,管理者,主要作用:

    • 管理HDFS的名称空间
    • 配置副本策略
    • 管理数据块(block)的映射信息(可以理解成目录),默认情况下,一个文件块是128M,一条目录信息(一个文件块的元数据)是150Byte;
    • 处理客户端读写请求;

    2)DataNode,就是Slave。NameNode负责下命令,DataNode负责实际执行。

    • 存储实际的数据块;
    • 执行数据块的读写操作;

    3)Client,就是客户端

    • 文件切分。文件在上传HDFS的时候,Client将文件切分成一个一个的块。这个块的大小,是由NameNode规定的,默认情况下,NN规定一个文件块是128M,企业中通常使用128M或者256M。
    • 与NameNode交互,获取文件位置信息;
    • 与DataNode交互,读写数据;
    • 可以提供一些命令来管理HDFS,比如NN格式化;
    • 可以提供命令来访问HDFS,执行增删改查;

    4)Secondary NameNode,即2NN,并非是NameNode的热备份,当NameNode挂掉的时候,它并不能马上替换NameNode并提供服务。所以实际工作中,一般不会用2NN来做容灾,而是采用NameNode的高可用模式。

    • 辅助NameNode,分担其工作量,比如定期合并Fsimage和Edits,并推送给NameNode;
    • 在紧急情况下,可以辅助恢复NameNode,但并不完全一致,NN始终保留有2NN所不知道的信息(非实时同步);

    这里的紧急恢复,其实就是把2NN里保存的Fsimage和Edits复制到NameNode下,但毕竟有版本差。

    (43)HDFS文件块大小(面试重点)

    HDFS中的文件在物理上是分块(Block)储存的,块的大小可以通过参数dfs.blocksize来规定,可以在hdfs-default.xml中查看这个参数。

    Hadoop1.x中块的默认大小是64M,而2.x和3.x版本中是128M。

    这个blocksize代表着块的最大大小,如果数据只有1KB,那形成的块也只有1KB。

    有几个时间的概念需要介绍下:

    • 寻址时间:即查找到目标block的时间;

    • 传输时间:数据拷贝或者写入的时间。

    一般来讲,寻址时间为传输时间的1%时,整个过程是最佳状态。至于为什么,不知道,教程说是专家说的

    比如说,寻址时间为10ms,则传输时间为1s时,整个过程处于最佳状态。

    传输时间主要依赖于磁盘的传输速率,目前普通磁盘的传输速率普遍为100MB/s,固态的话,可能能达到200M~300M。

    所以这里有个讲究,磁盘的传输速率,对块大小的设置其实是有影响的,比如说这里,普通磁盘是100MB/s,为了实现1s左右的传输时间,blocksize一般设置为128M;如果是固态磁盘200M~300M,blocksize一般设置为256M。

    据教程里介绍,128M和256M是目前企业中的主流块大小,一般中小型企业用128M,大型企业会采用256M。

    那为什么块的大小,不能设置的太小,也不能设置的太大呢?

    在源数据大小一定的情况下

    • 如果HDFS的块设置的太小:

    会增加寻址时间,程序会花很长的时间在找块的开始位置上。

    • 如果块大小设置的太大:

    极端点,比如说所有数据都在一个块里,定位块的时间是降低了,但是针对这块数据的磁盘IO会明显变大,极大影响数据处理的速度。因为这样子失去了并行处理的优势,改成串行处理了。

    按我理解就是,以前可以多个进程读多个块,现在是只有一个块,只能一个进程,肯定很慢,hdfs的分块也失去了意义。

    总结:HDFS块的大小主要取决于磁盘的传输速率。所以说磁盘IO才是制约速度的那块短板。

    参考文献

    1. 【尚硅谷大数据Hadoop教程,hadoop3.x搭建到集群调优,百万播放】
  • 相关阅读:
    震惊,99.9% 的同学没有真正理解字符串的不可变性
    手把手教你玩转 Gitea|在 Windows 系统上安装 Gitea
    Linux教程01:最基本的10条命令
    SpringMVC处理Ajax请求及处理和响应json格式的数据
    剑指 Offer 48. 最长不含重复字符的子字符串
    写页面时别再把 Element Plus 整个搬进来啦!Vue3按需加载的坑我帮你踩平了
    Vue3 除了keep-alive,还有哪些页面缓存的实现方案
    分库分表之ShardingSphere
    如何在Go中编写注释
    【C++数据结构】B树概念及其实现(详解)
  • 原文地址:https://blog.csdn.net/wlh2220133699/article/details/133816453