《hadoop权威指南》笔记二: hdfs读写过程剖析

2024-08-29 10:32

本文主要是介绍《hadoop权威指南》笔记二: hdfs读写过程剖析,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!

基于《hadoop权威指南》第四版。
温故知新

一、hdfs简介

Hadoop分布式文件系统(HDFS)被设计成适合运行在通用硬件(commodity hardware)上的分布式文件系统。

hdfs的设计如下:

https://hadoop.apache.org/docs/current/hadoop-project-dist/hadoop-hdfs/HdfsDesign.html

image.png

ps: hdfs只是hadoop文件系统实现的一种,其他还有:

image.png

二、hdfs读写分析

剖析hdfs的读写过程,是hdfs数据写入读取性能优化的基础。

1、读取过程

image.png

客户端角度

对客户端来说,读取hdfs上的文件就是创建一个fs下的FileSystem对象,并open文件。

hdfs角度

对hdfs而言,详细过程如下:

1、FileSystem对象就是DistributedFileSystem的一个实例。

2、DistributedFileSystem通过rpc调用namenode来获取文件初始块的位置。会根据集群网络拓扑图返回最近的datanode节点(假如客户端本身就是datanode时会直接本地读取数据)

(当客户端并发过多时hdfs是如何解决压力?)

3、DistributedFileSystem类返回一个FSDataInputStream对象(封装了DFSInputStream,可以流式地读取数据),管理datanode和namenode的I/O

4\5、反复调用read方法,当这个块读完的时候会读取下一个块的最佳datanode。(整队客户端是透明的)

6、读取完成调用close方法,结束读取。

异常情况

正常情况下的读取如上所述,但当客户端与datanode通信异常的时候,就复杂的多:

1、会尝试从这块最相邻的datanode读取数据。

2、同时客户端也会记住这个故障datanode,以保证后面不会反复读取该节点的块。

3、客户端同时会校验数据是否完整,不完整的话从其他节点重新读取,同时将损坏情况上报给namenode

重点:

每个客户端可以直接在datanode上检索数据,且namenode只需告知客户端最佳的datanode。所以数据是不会经过namenode的中转。

目前hadoop并不适合跨IDC部署

2、写入过程

image.png

写入过程相对复杂一些,这里详细记录一下:

客户端角度

与读取过程类似,创建一个fs下的FileSystem对象,create新建一个文件,然后write。

hdfs角度

1、与读取时类似,都要先生成DistributedFileSystem

2、client通过rpc调用namenode的create方法,在命名空间新增一个文件(此时hdfs中还没有实际的数据块)。 namenode会执行检查,保证文件是不存在的以及客户端是有权限创建目录,否则就会抛出IOException异常。

3、步骤2成功后DistributedFileSystem会返回一个FSDataOutputSream对象,此时可以写入数据。

4、FSDataOutputSream会将数据拆分成一个个的数据包,并写入内部的队列。另外一个对象DataStreamer会挑选出合适存储数据副本的一组datanode写入数据。在多副本情况下,第一个datanode收到数据后,它会把数据传送到下一个datanode,依次异步复制。

5、FSDataOutputSream内部也维护了一个确认队列,来等待datanode收到确认回执,然后才会从确认队列删除数据。

6、客户端写完数据后,会调用FSDataOutputSream的close方法,将所有数据写入到datanode的管线。

7、DistributedFileSystem告知namenode客户端已经写完数据,等待确认。namenode知道每个文件的存储节点情况,当成功写入最小的副本数量(dfs.namenode.replication.min配置,默认为1)时,namenode会返回写入成功。

异常情况

当任何datanode在数据写入期间发生故障,则执行以下操作(客户端无感知):

1、关闭写入管线,将队列里面的数据包添加回数据队列的最前端,以保证下游datanode不会漏数据。

2、为存储在另外一个正常datanode的当前数据块指定一个新的标识,并将该标识传递给namenode以保障故障datanode在恢复后可以删除存储的部分数据块。

3、管线中删除故障datanode,剩余正常的datanode构成临时新的管线。而namenode发现副本数据不足时,会再创建一个新的副本。

4、后续数据会继续正常处理。

副本选择

namenode如何选择在哪个datanode存储副本? 一般需要权衡:

  • 可靠性
  • 写入带宽
  • 读取带宽

同机架服务器之间的读取带宽是非常高的,跨数据中心虽然可以增加数据冗余和可靠性,但带宽消耗极大。

hadoop默认的策略下,同一份数据不同副本尽可能避免落到一个机架上面,这样达到冗余与性能的权衡。

三、数据一致性问题

hdfs并不严格满足POSIX

hdfs为了性能,牺牲了一些POSIX的要求。新建一个文件时,它能在文件系统中立即可见,如:

Path p = new Path("p");
Fs.create(p);
assertThat(fs.exists(p),is(true));

但是写入的内容并不能保证立即可见,即使数据流已经刷新并存储

OutputStream out = fs.create(p);
out.write("content".getBytes("UTF-8"));
out.flush();
assertThat(fs.getFileStatus(p).getLen(),is(0L));

当数据写入超过一个块之后,第一块数据对新的reader是可见的,但当前写入的块对其他reader不可见。

hflush()与hsync()

FSDataOutputStream提供了hflush()方法,强行将所有的缓存刷新到datanode中,当hflush()返回成功,则所有新的reader可见。

FSDataOutputStream out = fs.create(p);
out.write("content".getBytes("UTF-8"));
out.hflush();
assertThat(fs.getFileStatus(p).getLen(),is(((long)"content".length())));

但是hflush不保证datanode已经将数据写入到磁盘(数据仅在内存中),为了确保数据写入到磁盘中,我们还可以使用hsync()替代(类似POSIX的fsync())。

当然 hflush()与hsync() 都是会带来更大开销,需要我们不断测试度量不同频率下调用时的性能,来选择一个最终合适的调用频率。

注意:Hadoop 1.x中hflush()被称为sync、hsync()不存在!

四、其他问题

1、put与copyFromLocal的区别

http://stackoverflow.com/questions/7811284/difference-between-hadoop-fs-put-and-hadoop-fs-copyfromlocal

在Hadoop 2.7.2版本测试发现确实无区别,但是3.X新版本有修改,增加了一个线程池并发拷贝的功能

https://github.com/apache/hadoop/blob/7a3188d054481b9bd563e337901e93476303ce7f/hadoop-common-project/hadoop-common/src/main/java/org/apache/hadoop/fs/shell/CopyCommands.java

2、Ozone

Hadoop 社区推出了新的分布式存储系统-Ozone。Ozone能够轻松管理小文件和大文件,是一个分布式Key-value 对象存储系统。值得关注!

这篇关于《hadoop权威指南》笔记二: hdfs读写过程剖析的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!



http://www.chinasem.cn/article/1117603

相关文章

浅析Spring Security认证过程

类图 为了方便理解Spring Security认证流程,特意画了如下的类图,包含相关的核心认证类 概述 核心验证器 AuthenticationManager 该对象提供了认证方法的入口,接收一个Authentiaton对象作为参数; public interface AuthenticationManager {Authentication authenticate(Authenti

Hadoop企业开发案例调优场景

需求 (1)需求:从1G数据中,统计每个单词出现次数。服务器3台,每台配置4G内存,4核CPU,4线程。 (2)需求分析: 1G / 128m = 8个MapTask;1个ReduceTask;1个mrAppMaster 平均每个节点运行10个 / 3台 ≈ 3个任务(4    3    3) HDFS参数调优 (1)修改:hadoop-env.sh export HDFS_NAMENOD

HDFS—存储优化(纠删码)

纠删码原理 HDFS 默认情况下,一个文件有3个副本,这样提高了数据的可靠性,但也带来了2倍的冗余开销。 Hadoop3.x 引入了纠删码,采用计算的方式,可以节省约50%左右的存储空间。 此种方式节约了空间,但是会增加 cpu 的计算。 纠删码策略是给具体一个路径设置。所有往此路径下存储的文件,都会执行此策略。 默认只开启对 RS-6-3-1024k

HDFS—集群扩容及缩容

白名单:表示在白名单的主机IP地址可以,用来存储数据。 配置白名单步骤如下: 1)在NameNode节点的/opt/module/hadoop-3.1.4/etc/hadoop目录下分别创建whitelist 和blacklist文件 (1)创建白名单 [lytfly@hadoop102 hadoop]$ vim whitelist 在whitelist中添加如下主机名称,假如集群正常工作的节

Hadoop集群数据均衡之磁盘间数据均衡

生产环境,由于硬盘空间不足,往往需要增加一块硬盘。刚加载的硬盘没有数据时,可以执行磁盘数据均衡命令。(Hadoop3.x新特性) plan后面带的节点的名字必须是已经存在的,并且是需要均衡的节点。 如果节点不存在,会报如下错误: 如果节点只有一个硬盘的话,不会创建均衡计划: (1)生成均衡计划 hdfs diskbalancer -plan hadoop102 (2)执行均衡计划 hd

hadoop开启回收站配置

开启回收站功能,可以将删除的文件在不超时的情况下,恢复原数据,起到防止误删除、备份等作用。 开启回收站功能参数说明 (1)默认值fs.trash.interval = 0,0表示禁用回收站;其他值表示设置文件的存活时间。 (2)默认值fs.trash.checkpoint.interval = 0,检查回收站的间隔时间。如果该值为0,则该值设置和fs.trash.interval的参数值相等。

Hadoop数据压缩使用介绍

一、压缩原则 (1)运算密集型的Job,少用压缩 (2)IO密集型的Job,多用压缩 二、压缩算法比较 三、压缩位置选择 四、压缩参数配置 1)为了支持多种压缩/解压缩算法,Hadoop引入了编码/解码器 2)要在Hadoop中启用压缩,可以配置如下参数

作业提交过程之HDFSMapReduce

作业提交全过程详解 (1)作业提交 第1步:Client调用job.waitForCompletion方法,向整个集群提交MapReduce作业。 第2步:Client向RM申请一个作业id。 第3步:RM给Client返回该job资源的提交路径和作业id。 第4步:Client提交jar包、切片信息和配置文件到指定的资源提交路径。 第5步:Client提交完资源后,向RM申请运行MrAp

10. 文件的读写

10.1 文本文件 操作文件三大类: ofstream:写操作ifstream:读操作fstream:读写操作 打开方式解释ios::in为了读文件而打开文件ios::out为了写文件而打开文件,如果当前文件存在则清空当前文件在写入ios::app追加方式写文件ios::trunc如果文件存在先删除,在创建ios::ate打开文件之后令读写位置移至文件尾端ios::binary二进制方式

Retrieval-based-Voice-Conversion-WebUI模型构建指南

一、模型介绍 Retrieval-based-Voice-Conversion-WebUI(简称 RVC)模型是一个基于 VITS(Variational Inference with adversarial learning for end-to-end Text-to-Speech)的简单易用的语音转换框架。 具有以下特点 简单易用:RVC 模型通过简单易用的网页界面,使得用户无需深入了