面试官把我问懵了....

news/2024/5/20 3:39:53 标签: hadoop, hdfs, big data

感谢兄弟们的关注与支持,如果觉得有帮助的话,还请来个点赞、收藏、转发三操作

该文章已更新到语雀中,后台回复“语雀”可获取公众号:进击吧大数据整个职业生涯持续更新的所有资料

在前面介绍了Hadoop三部曲搞起~,简单理解了HDFS底层是如何完成读写功能的,在存储层面,HDFS采用了块抽象的方式简化了存储系统设计,即一个文件会被切分成多个块进行存储,在Hadoop 1.x中块的大小是64MB;在Hadoop 2.x中块的大小是128MB,当然在实际生产环境中,也有设置为256MB。

那么这里大家思考一下,Hadoop为什么要设计块大小为64、128或者256呢?为什么不能是100、200、300呢?为什么在Hadoop 1.X设置的块大小是64MB?为什么在Hadoop2.X就调整为128MB呢?

当然这个问题在面试中也会经常被问到。本文将来为大家详细介绍一下其中的设计思想,通过本文你将可以了解到:
1、系统磁盘块原理
2、磁盘读写流程
3、通过实际生活中的借款例子来诠释HDFS块设计思想
如有错误的地方,欢迎大佬指出~

首先大家应该要先清晰的知道,HDFS支持的文件语义是属于一次写入多次读取的,文件被切分成块在不同的机器上存储。

假设我们有一个500MB的文件存储到HDFS上,那么Hadoop就会将文件进行切块存储,我们按照128MB来计算大概会生成4个块。如下图可见,最后一个Block实际大小不足128MB,但仍会占用一个块。这里需要和操作系统中的磁盘块区分开来,下文会简单介绍下磁盘块的知识点(这块属于操作系统层面的东西,不想看的同学直接往下翻就行);

图片

什么是磁盘块?

我们先来简单复习了解下系统层面的知识,因为这和下面讲解HDFS的块设计是有关系的。我们就拿日常的硬盘举例
图片比如常使用的移动硬盘是由多个盘片叠加组成的(可以想象成以前我们玩的的光碟),盘片上面有一层特殊的磁性材质是由刚性材料制成,这也是硬盘名称的由来,和硬盘相对应的还有一种叫做软盘,可想而知,软盘是由一种软性材料组成的。硬盘的一个主轴上通常能安装好几个盘片,盘片是有正反两面的(也称为盘面),每一面都有这种磁性物质,而且 都能存储二进制信息,所以每个盘片需要两个磁头来读写数据。
图片图片

磁头采用了非接触式头,与盘片之间的间隙只有0.1~0.3um,这样可以获得很好的数据传输率。而且磁头靠近主轴(转轴)接触的表面,即线速度最小的地方,是一个特殊的区域,它不存放任何数据,又被称为启停区或者是着陆区(Landing Zone),启停区外就是数据区。在最外圈,离主轴最远的地放是“0”磁道,硬盘数据的存放就是从最外圈开始的
图片

硬盘内部结构中还有一个电动机来带动盘片旋转,副电动机会带动一组磁头到相对应的盘片上并确定是读取正面还是反面,当磁盘旋转的时候,磁头要是保持在一个位置上,则每个磁头都会在磁盘表面上划出一个圆形轨迹,这些圆形轨迹就叫做磁道(Track)
图片磁道会被等分为多个弧段,这些弧段就是扇区(Sector),等分的目的就是在读取和写入数据的时候,磁盘会以扇区为单位进行读取和写入这样可以提高运行速度。数据硬盘的第一个扇区又叫做引导扇区。每个扇区就是一个个磁盘块,存储固定数量用户可访问的数据,原来的扇区设计都是512Byte(即0.5KB)的容量,但目前大多数硬盘驱动器使用4KB扇区来存储大量的数据减少数据的拆解。
图片

图片上图展示了关于磁道、扇面、扇区、扇区组之间的关系:A代表的是磁道;B代表的是扇面;C代表的是扇区;D代表的是簇(扇区组)。

磁盘读写流程

磁盘写

当我们写入文件到磁盘的时候,内部是按照柱面、磁头、扇区的方式进行的,即先是在第一磁道的第一个磁头下的所有扇区下存储,然后是同一个柱面的下一个磁头,直到把所有的内容写入到磁盘中。

磁盘读

当我们需要从磁盘中读取数据的时候,系统会把数据逻辑地址传给磁盘,磁盘内部的控制电路会按照寻址逻辑将逻辑地址翻译成物理地址,即要先确定读取的数据在哪个磁道上的哪个扇区(物理地址由柱面号、磁头号、扇区号三部分组成),当拿到物理地址后,需要将磁头放到这个扇区上方,为了能够到达这个扇区,那么磁头需要移动,这个过程就是我们常说的寻道,这个过程所花费的时间又叫做寻道时间,寻道时间越短,IO操作越快;同时磁盘会将目标扇区进行旋转,到达磁头下,这个过程花费得时间又叫做旋转时间,该时间延迟取决于磁盘转速;最后才开始读取数据,然后将数据存放到系统缓冲区中,这个传输过程所花费的时间是传输数据,该部分的时间和前面两个时间相比可以几乎忽略不计。因此在磁盘上读取数据所花费的总时间=寻道时间+旋转时间+实际传输时间,但真正决定一个硬盘读写速度的是它的平均存取时间(也就是平均寻道时间和平均旋转延迟之和)。
图片如上图所示,一次完整的磁盘读请求会经过cache层,Mapping层、通用层、I/O调用层和块设备驱动层,最后是物理设备层。

HDFS设计思想-“借钱事件”

那么我们继续回到今天的主题上,磁盘读写跟HDFS 块的大小又有什么关系呢?我们来举一个现实生活中真实的例子:相信大家都借出去过钱吧,假如你手里有10w块钱可以借出去,那么这里有几种借钱选择:
● 第一种情况:借给100个人,每个人1000块
● 第二种情况:借给10个人,每个人1w块
● 第三种情况:借给2个人,每个人5w块
● 第四种情况:借给1个人,10w全借出去

如果是你的话,第1,2种情况是不是肯定不会选择,想想看,你会时刻惦记着10个人以上还债情况吗?你有那么多精力吗?同样的道理,如果HDFS的块大小越大,那么即使大文件那么切分的块个数也不会太多,在NameNode中存储也是能够cover住的,如果设置的块太小,那么就会生成大量的块,恐怕很快会消耗完NameNode的内存,这个和小文件危害问题其实是一样的,而且也会加大NN恢复加载元数据的时间。假设你设置的块大小为1MB,有一个1G的文件要存储,那么就会切分1024个块存储到DataNode上,这里还有一个问题就是1024个块有可能会分布到很多的DataNode上,在数据读写和副本复制的时候,无非增加了网络IO资源,这些也是要考虑进去的。
图片

那既然块大小不能太小,如果设置块大小非常大呢?那么就和前面介绍的磁盘原理挂钩了,如果设置的块大小非常大,虽然切分的块个数是少了,对NameNode保存元数据信息也不会有太大压力,但是并行度就低了(想想MR模型),效率就会下降了,你说是不是呢?
图片那么既然块大小不能太大,也不能太小,那为什么在Hadoop2.x之后把块大小调整为128MB呢?这个其实是跟早期的Hadoop设计有关系的,在学习Hadoop的时候,我们知道该系统是参考了Google的GFS论文,在GFS设计中就是使用的64MB作为默认的块大小(感兴趣的朋友可以再回过头来看看该论文中的Chunk Size部分),这里列出文中提到的几点原因:

  1. Lower the loading of master(减少NameNode负载). The master server of GFS only provides metadata of the chunk instead of chunk content. Therefore, less requests will be sent to master server if the chunk is relative large.

  2. Reduce network overhead(降低网络IO), it encourage applications to finish many operations on a single chunk and persistent network connection. Applications also get their data in fewer request.

  3. Reduce metadata size stored in the master(减少NameNode元数据存储). There is only one master server in GFS’s design. All metadata of chunks are stored in the memory of master server in order to reduce the latency and increase the throughput. Large chunks means less metadata, and less metadata means less load time of the metadata.
    图片
    介绍到这里,可能会有朋友说既然这样的话,那为什么不是设置成256MB呢?其实这个块的大小设置并不是固定的,128MB是属于比较通用的配置,也是做过基准测试的,具体还要根据你的实际情况来抉择,如果说你们的数据量非常大,而且机器配置也很高,那么可能设置256MB或者512MB性能会更好;如果数据量很少,那么128MB的块大小可能更适合。如果要调整块大小,可以修改hdfs-site.xml文件中的dfs.block.size属性

图片

进击吧大数据

从事大数据行业多年,涉及范围包括不局限于基础支撑、计算引擎、数据整合、数据应用等多方向,参与过大型企业数仓体系建设、对数据建模、数据治理、业务增长有一定的理解;曾收获过多家一线大厂offer,目前带领团队建设企业实时数仓;欢迎大佬们一起加入交流成长


http://www.niftyadmin.cn/n/1035066.html

相关文章

(全网首篇)数仓专题-及时性保障方案

在数仓的建设之路中,其中必不可少的一个依赖组件就是调度系统。目前市面上也有很多优秀产品,如以DAG为核心的工作流系统:Azkaban、Oozie、Airflow、DolphinScheduler;以Quartz为代表的定时系统包括Elastic-Job、Xxl-Job、Saturn、…

获取信息集(ZFI002)维护内容 - GS01/GS02/GS03

T-CODE: GS01/GS02/GS03 程序中获取信息集:ZFI002,并将获取的值存入RANGE变量中 表:setleaf range变量:lra_blart *&---------------------------------------------------------------------* *& Report ZTEST *&…

聊聊我对数仓建设的一些思考

该文章已更新到语雀中,后台回复“语雀”可获取进击吧大数据整个职业生涯持续更新的所有资料 目前大部分行业中的数仓建设大多是采用Kimball指导思想进行的,在初期发展阶段为了快速支撑业务,而且希望能让领导感受到数仓存在的价值从而带来更大…

生产订单(prod order)状态直接从表(AUFK/JEST/TJ02T/TJ02)获取

1、根据生产订单从AUFK获取 对象号 (OBJNR) 2、根据AUFK-OBJNR JEST-OBJNR 获取 对象状态 (JEST-STAT) 3、根据JEST-STAT在TJ02T中获取对应语言的 对象状态描述 4、根据JEST-STAT在TJ02中获取 对象状态 的是否显示状态

BAPI_SALESORDER_CHANGE参数EXTENSIONIN - 更新销售订单增强字段值

BAPI_SALESORDER_CHANGE(BAPI1)和SD_SALESDOCUMENT_CHANGE (BAPI2)扩展方法相同。BAPI1 内部调用BAPI2 标准表和结构扩展:(网上很多解释,不赘述) 根据客制化字段的位置需要扩展不同的表或结构: 更新抬头:…

十分钟带你走进Hive世界(每走一步都是为了离你更近些)

该文章已更新到语雀中,后台回复“语雀”可获取进击吧大数据整个职业生涯持续更新的所有资料 该文基于Hive专题-从SQL聊Hive底层执行原理进一步的深入学习Hive,相信大多数童鞋对于Hive底层的执行流程只是局限于理论层面。那么本篇将带大家花半个小时左右的时间在自己…

一文理解主数据和参考数据

如果你准备要开展推动数据治理或者是数据质量的项目,那么你就有可能会听说到几个词:主数据和参考数据。一开始听到主数据这一词听起来就很高大上,而且非专业人士肯定不理解(即便是从事数据行业的朋友也很难参透)。这一…

CJ20N - 项目定义屏幕增强(SMOD: CNEX0006)

实现如下效果: 增强实施: SMOD: CNEX0006 Step1: 扩展PROJ内嵌结构CI_PROJ Step2、CMOD实施ZPS00001 Step3、创建屏幕600,设置为“子屏幕” Step4、实施增强出口EXIT_SAPLCJWB_002 定义全局变量 TABLES: proj. "将屏幕更新字段&…