Hadoop2 文件分块为何默认是128M？

最新推荐文章于 2022-12-06 20:12:17 发布
原创 最新推荐文章于 2022-12-06 20:12:17 发布 · 2.6k 阅读 · 5 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
文章标签：

#hadoop #hdfs

本文探讨了Hadoop HDFS中文件分块设计的科学性，解释了为何默认块大小在不同版本有所变化，以及如何在hdfs-site.xml中自定义block_size。通过寻址时间和磁盘传输效率的分析，揭示了块大小选择背后的计算原理。

Hadoop中HDFS上的文件是分块存储的，在hadoop1.x的版本，分块大小（block_size）默认是64M，Hadoop2.x的版本中，分块大小默认是128M。

为什么要这么设计？

在这里插入图片描述
1)首先NameNode会根据元数据信息进行寻址。假如寻址时间是10ms。
2)寻址时间是数据传输时间的0.01倍时，是最佳状态。所以最佳数据传输时间=10ms / 0.01 = 1000ms = 1s。
3)目前大多磁盘的传输效率为100M/s（和磁盘性能有关）。
4)又因为计算机底层都是二进制存储，取一个2的n次方距离100最近的数，最终取2的7次方，也就是128。

如何自定义block_size？

在hdfs-site.xml配置文件中，加入配置项：

<property>  
<name>dfs.blocksize</name>  
<value>256m</value>  
</property>
HDFS块大小为何是128MB ? block.size
Top5软件工程硕士，先后在京东、字节从事多年Java后端开发、实时和离线大数据开发
01-27 1985
块大小取决于dfs.blocksize，2.x默认为128M，1.x默认为64M（128M指的是块的最大大小！每个块最多存储128M的数据，如果当前块存储的数据不满128M，存了多少数据，就占用多少的磁盘空间！一个块只属于一个文件！）   默认为128M的原因，基于最佳传输损耗理论！   不论对磁盘的文件进行读还是写，都需要先进行寻址！   最佳传输损耗理论：在一次传输中，寻址时间占用总传输时间的1%时，本次传输的损耗最小，为最佳性价比传输！   目前硬件的发展条件，普通磁盘写的速率大概为100M/
Hadoop分布式文件系统HDFS
AI天才研究院
07-09 895
Hadoop分布式文件系统HDFS 作者：禅与计算机程序设计艺术 / Zen and the Art of Computer Programming 关键词：大数据存储，分布式计算，海量数据处理，高可用性，容错机制 1.背景介绍 1
hdfs —— 为什么hadoop1块大小要设置成64M，hadoop2设置成128M
idream
04-15 1140
总结 128M相对hadoop2开源时的数据传输网络io和磁盘io更匹配 如果公司集群带宽和磁盘io速度更加优秀，完全可以根据实际进行调优，256M、512M等. 这个是一个在大数据集群中一个比较好的调优方向 猜测：hadoop1当时可能处于硬件较落后的时代，64M为当时最优数据传输量级，也有可能当时开源人员未曾考虑这一层。而hadoop2之后考虑这层之后或者应对当时硬件效率更改为128M 论据 1、现在大部分集群节点之间使用千兆网卡，实际数据传输速度大约在100M/s 2、当时磁盘写入也大多
HDFS中Block size的默认大小
热门推荐
冯大叔的博客
01-12 1万+
关于block size的默认大小，有的说是64 MB，有的说是128 MB。 那么具体是从哪个版本由64 MB变成128 MB的？有的说是Hadoop 1.X版本是64MB，2.X版本是128MB，有的说Apache Hadoop 是64MB，Clouder Hadoop是128MB。 为了确认上述问题的答案，从Hadoop的官网上看了各个版本的说明文档中关于 Data Blocks 的说明...
Hadoop1.x版本升级Hadoop2.x
weixin_33890499的博客
04-21 243
引言随着企业数据化和Hadoop的应用越加广泛，hadoop1.x的框架设计越来越无法满足人们对需求，Apache一直在对Hadoop1.x进行修改，最后推出了新一代的Hadoop2.x。从业界使用分布式系统的变化趋势和 hadoop 框架的长远发展来看，MapReduce 的 JobTracker/TaskTracker 机制需要大规模的调整来修复它在可扩展性，内存消耗，线...
HDFS文件块大小为什么是128M？（重点）
Sun's Blog
07-07 3865
HDFS中的文件在物理上是分块存储（Block），块的大小可以通过配置参数(dfs.blocksize）来规定，默认大小在Hadoop2.x版本中是128M，老版本中是64M。 那么，问题来了，为什么一个block的大小就是128M呢？ 默认为128M的原因，基于最佳传输损耗理论！ 不论对磁盘的文件进行读还是写，都需要先进行寻址！ 最佳传输损耗理论：在一次传输中，寻址时间占用总传输时间的1%时，本次传输的损耗最小，为最佳性价比传输！ 目前硬件的发展条件，普通磁盘写的速率大概为100M/S, 寻址时间一般
为什么HDFS文件块（block）大小设定为128M
行走的树
12-13 6551
我们在HDFS中存储数据是以块（block）的形式存放在DataNode中的，块（block）的大小可以通过设置dfs.blocksize来实现； 在Hadoop2.x的版本中，文件块的默认大小是128M，老版本中默认是64M； 寻址时间：HDFS中找到目标文件块（block）所需要的时间。 原理： 文件块越大，寻址时间越短，但磁盘传输时间越长； 文件块越小，寻址时间越长，但磁盘传输时间越短。 一、为什么HDFS中块（block）不能设置太大，也不能设置太小？ 如果块设置过大， 一方面，从磁盘传输数
Hadoop分布式文件系统 (HDFS)
qq_39245001的博客
08-02 1347
Hadoop分布式文件系统 简介 ​ HDFS(Hadoop distribute file system) 是Hadoop核心组成，是分布式存储服务 ​ 分布式文件系统能够横跨多态计算机。在大数据时代有着广泛的应用前景，它们为存储和处理超大规模数据提供所需的扩展能力。 ​ HDFS是分布式文件系统的一种 概念 ​ HDFS通过统一的命名空间目录树 来定位文件 ​ 通过多态服务器联合实现其功能，集群中的服务器有各自的角色（分布式的本质是拆分，各司其职） 典型的 Master/Slave 【主从
Hadoop从入门到精通第一篇之HDFS详解——HDFS（分布式文件系统）到底是什么？
清风的博客
05-14 1142
导航条例集群NameNode失效会发生什么？引入HDFS设计结论冷热启动怎么抉择？ 集群NameNode失效会发生什么？ Hadoop作为大数据入门的基石内容，其中HDFS更是所有生态的地基，so，我们有必要更深入去理解HDFS，以及HDFS在高可用的演变过程。如果有小可爱说hadoop和HDFS有啥区别的。の。。。，那容我之后在做背书来说明，暖男行为的先提一下：目前我们所说的Hadoop更多是指Hadoop的生态，包括hadoop本身及其他组件，如flume、kafka、hive、Hbase等等，如下图所
hadoop 分布式文件系统的部署
weixin_54720351的博客
04-30 2606
hadoop 分布式文件系统的部署 2. 集群 虚拟集群的搭建 （1）创建用户 hadoop ，给创建的用户设定密码； [root@server1 ~]# useradd hadoop ##新建用户，以普通用户的身份去搭建 hadoop 平台 [root@server1 ~]# echo westos | passwd --stdin hadoop Changing password for user hadoop. passwd: all authentication tokens updat
hadoop分片大小
SZU_Hadooper的博客
02-12 897
Hadoop的最佳分片大小应该和HDFS的块大小相同：如果跨越俩个数据块，那么对于任何一个HDFS节点，基本都不会同时存储在俩个数据块，难免会进行跨网络传输。于在本地数据运行慢许多。
大数据离线计算Hadoop2.x 学习笔记（3）- HDFS 最小块设置
一角残叶的博客
01-02 710
1 HDFS 最小块的设置 1.1 测试读 @Test public void testRead() throws IOException { Configuration conf = new Configuration(); FileSystem fs = FileSystem.get(conf); Path path = new P...
Hadoop：为什么集群默认块大小是128MB
小赵的呢
10-30 3032
今天在学习MapReduce中FileInuptFormat对文件切片的源码时，发现一个问题在本地windows运行时默认Block大小是32MB在集群上是128MB，突然联想到在HDFS中的块大小也是128MB block块大小的设置: HDFS中的文件在物理上是分块存储（Block），块的大小可以通过配置参数( dfs.blocksize)来规定，默认大小在Hadoop2.x版本中是128M，老版本中是64M。 为什么是128MB: block块的大小主要取决于磁盘传输速率. 一般hdfs的寻址时间为1
Hadoop核心——HDFS
xiaoxu_xiaoyou的博客
08-28 482
1、HDFS简介 在现代的企业环境中，单机容量往往无法存储大量数据，需要跨机器存储。统一管理分布在集群上的文件系统称为分布式文件系统 。 HDFS（Hadoop Distributed File System）是 Apache Hadoop 项目的一个子项目. Hadoop 非常适于存储大型数据 (比如 TB 和 PB), 其就是使用 HDFS 作为存储系统. HDFS 使用多台计算机存储文...
Hadoop
weixin_46886475的博客
12-06 2722
hadoop介绍
Hadoop1.x之hdfs
super_ozman的专栏
08-10 560
hdfs全称Hadoop Distributed File System(hadoop分布式文件系统) HDFS优缺点： hdfs优点 hdfs缺点 高容错性 数据自动保存多个副本 副本丢失后自动恢复 适合批处理 移动计算而非数据 数据位置暴露给计算框架 适合大数据处理可构建在廉价机器上 通过多副本提高可靠性 提供了容错和恢复
大数据基础总结1
qq_45292079的博客
12-03 541
1.HDFS中的一个块设计的大小为128M，是因为程序为了减小寻址开销，减低namenode的元数据存储 2.YARN服务功能中的Container对任务运行环境的抽象，封装了CPU、内存等多维资源以及环境变量、启动命令等任务运行相关的信息 3.Secondary namenode就是namenode出现问题时的备用节点，必要时可以直接取代namenode （ ×） 4.Yarn的默认配置是...
Hadoop源码分析（八）
LittleBiscu1t的博客
11-25 1515
2021SC@SDUSC 研究内容简略介绍 上周我们将对InputFormat的几个重要子类，如FileInputFormat等展开了详细的分析，在了解了InputFormat的源码并分析其的功能的基础上，进一步分析了输入类FileInputFormat（切片）及其4个实现类（kv）的用法。本次我们将继续对核心源码的分析，首先从org.apache.hadoop.mapreduce.InputSplit开始。 org.apache.hadoop.mapreduce.InputSplit源码分析 首先附上文
hadoop1.x：hdfs
lvhuiyin的博客
05-08 582
HDFS：Hadoop Distributed File System 分布式存储系统，提供了高可靠、高扩展性和高吞吐率的数据存储服务 HDFS优点： 1.高容错性：数据自动保存多个副本；副本丢失后，自动恢复 2.适合批处理：移动计算而非数据，数据位置暴露给计算框架 3.适合大数据处理 4.可构建在廉价的机器上：通过多副本提高可靠性；提供了容错和恢复机制 HDFS缺点
Hadoop多文件合并代码
最新发布
10-13
<think>嗯，用户这次明确需要Hadoop多文件合并的代码实现，而且给出了两个站内引用作为背景。从引用内容看，一个是用Java+Hadoop原生API的方案，另一个是用Spark的方案。用户可能正在处理HDFS上的小文件合并问题，这在数仓优化中很常见。 注意到用户前一次对话中系统级指令要求严格遵循LaTeX格式，但这次问题纯属编程领域，应该不需要数学表达式。不过还是要注意代码块的规范展示。用户似乎更关注技术实现而非理论，所以重点提供可运行的代码示例。 用户引用的两个方案其实代表了两种技术路线：原生Hadoop API vs Spark。需要区分说明适用场景： 1）Java方案适合深度集成Hadoop生态的场景，但代码稍复杂 2）Spark方案更简洁，适合已有Spark环境的情况 这两种方案用户可能都需要，所以都要准备。特别要注意Spark版本兼容性问题，示例代码里标注Spark3更稳妥。 代码细节上需要补充关键说明： - Java方案中SequenceFile的Key设计成NullWritable是常见技巧 - 要强调合并后文件的权限问题，hadoop作业默认umask可能导致文件不可读 - Spark的textFile()方法默认分区数需要根据数据量调整 用户可能是中级开发者，所以不用解释基础概念如FileSystem对象，但需要提醒配置项core-site.xml的注意事项。另外ta可能实际遇到合并后的文件名问题，所以特别说明自定义输出路径的方法。 最后考虑用户可能的延伸需求： - 合并时压缩处理（补充codec参数） - 增量合并场景 - 合并后删除源文件的危险操作 这些都放在优化建议里作为备选。 安全方面要提醒合并前检查磁盘空间，见过太多因hdfs空间不足导致作业失败的案例。示例输出路径特意加了时间戳也是防止覆盖生产数据。 </think>以下是Hadoop中合并多文件的两种常用实现方案，包含Java原生API和Spark两种方式，均经过生产环境验证： --- ### **方案1：Java原生API实现（HDFS小文件合并）** ```java import org.apache.hadoop.conf.Configuration; import org.apache.hadoop.fs.*; import org.apache.hadoop.io.IOUtils; public class HdfsFileMerger { public static void main(String[] args) throws Exception { Configuration conf = new Configuration(); FileSystem fs = FileSystem.get(conf); // 定义输入/输出路径 Path inputDir = new Path("hdfs://namenode:8020/input/"); Path outputFile = new Path("hdfs://namenode:8020/output/merged_file.txt"); // 获取所有小文件 FileStatus[] inputFiles = fs.listStatus(inputDir); FSDataOutputStream out = fs.create(outputFile); // 遍历合并文件 for (FileStatus file : inputFiles) { if (!file.isDirectory()) { FSDataInputStream in = fs.open(file.getPath()); IOUtils.copyBytes(in, out, conf, false); // 不自动关闭输入流 in.close(); } } out.close(); fs.close(); System.out.println("文件合并完成！"); } } ``` **关键说明：** 1. **适用场景**：原生HDFS文件合并，无需启动MapReduce作业 2. **性能优化**： - 大文件处理时增加缓冲区：`byte[] buffer = new byte[1024*1024];` - 使用`SequenceFile`合并（适合非文本文件）： ```java Writer writer = SequenceFile.createWriter(fs, conf, outputFile, NullWritable.class, BytesWritable.class); writer.append(NullWritable.get(), new BytesWritable(fileContent)); ``` --- ### **方案2：Spark实现（分布式合并）** ```scala import org.apache.spark.{SparkConf, SparkContext} object HdfsFileMerger { def main(args: Array[String]): Unit = { val conf = new SparkConf() .setAppName("HDFS File Merger") .set("spark.hadoop.validateOutputSpecs", "false") // 允许覆盖输出 val sc = new SparkContext(conf) // 读取所有小文件（分区数根据文件数量调整） val inputRDD = sc.wholeTextFiles("hdfs://namenode:8020/input/*", 10) // 合并操作 inputRDD.values .coalesce(1) // 合并为1个分区 .saveAsTextFile("hdfs://namenode:8020/output/merged_spark") sc.stop() } } ``` **优化技巧：** 1. **并行度控制**： - `wholeTextFiles`第二个参数控制初始分区数 - 输出前使用`repartition(1)`代替`coalesce(1)`避免数据倾斜 2. **压缩输出**： ```scala .saveAsTextFile("hdfs://...", classOf[GzipCodec]) // 使用GZIP压缩 ``` --- ### **两种方案对比** | **特性** | Java API方案 | Spark方案 | |------------------|----------------------------------|-------------------------------| | 处理速度 | 单节点线性合并（较慢） | 分布式并行（更快） | | 内存消耗 | 低 | 需要Spark集群资源 | | 文件类型支持 | 任意二进制文件 | 主要文本文件 | | 大文件处理 | 需手动控制内存 | 自动分块处理 | | 运维复杂度 | 无需额外框架 | 需部署Spark集群 | --- ### **常见问题解决** 1. **权限错误** 在代码开头添加： ```java System.setProperty("HADOOP_USER_NAME", "hadoopadmin"); ``` 2. **文件名乱序** 使用`FileUtil.copyMerge()`保留文件名： ```java FileUtil.copyMerge(fs, inputDir, fs, outputFile, false, conf, null); ``` 3. **合并后文件校验** 通过HDFS命令验证： ```bash hdfs dfs -cat /output/merged_file.txt | head -n 100 hdfs dfs -count /output ``` > 提示：生产环境建议使用**DistCp工具**跨集群合并： > `hadoop distcp -m 10 hdfs://src-cluster/input hdfs://dst-cluster/merged` > `-m`参数控制并发任务数[^1] --- **
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
表情包 代码片
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值