背景 计算机硬件性能在过去十年间的发展普遍遵循摩尔定律，通用计算机的CPU主频早已超过3GHz，内存也进入了普及DDR4的时代。然而传统硬盘虽然在存储容量上增长迅速，但是在读写性能上并无明显提升，同时SSD硬盘价格高昂，不能在短时间内完全替代传统硬盘。传统磁盘的I/O读写速度成为了计算机系统性能提高的瓶颈，制约了计算机整体性能的发展。 硬盘性能的制约因素是什么？如何根据磁盘I/O特性来进行系统设计？针对这些问题，本文将介绍硬盘的物理结构和性能指标，以及操作系统针对磁盘性能所做的优化，最后讨论下基于磁盘I/O
在理解inode之前，先了解下磁盘扇区，磁盘的最小单位，我们都知道，磁盘一个扇区是512个字节。磁盘读写是都是按照块来操作的，一个块一般是4K，也就是连续的8个扇区，以块为单位读写是为了提高性能。
Linux系统下文件数据储存在"块"中，文件的元信息，例如文件的创建者、文件的创建日期、文件的大小等。这种储存文件元信息的区域就叫做inode，中文译名为"索引节点"。
Linux系统下文件数据储存在"块"中，文件的元信息，例如文件的创建者、文件的创建日期、文件的大小等。这种储存文件元信息的区域就叫做inode，中文译名为"索引节点"。inode也占用硬盘空间，硬盘格式化的时候，操作系统自动将硬盘分成两个区域。一个是数据区，存放文件数据；另一个是inode区（inode table），存放inode所包含的信息。
今天线上出现了一个inode耗尽的问题，最后通过清理磁盘上的小文件来解决问题。大概分享下inode的相关知识。
随着互联网、云计算及大数据等信息技术的发展，越来越多的应用依赖于对海量数据的存储和处理，如智能监控、电子商务、地理信息等，这些应用都需要对海量图片的存储和检索。由于图片大多是小文件(80%大小在数MB以内)，以GFS、HDFS为代表的适用于流式访问大文件的分布式存储系统，若直接用来存储图片，由于元数据膨胀，在扩展性和性能方面均存在严重问题。
日常工作中需要对日志文件进行分析，当日志文件过大时，Linux中使用vim、cat、vim、grep、awk等这些工具对大文件日志进行分析将会成为梦魇，具体表现在：
本文隶属于专栏《1000个问题搞定大数据技术体系》，该专栏为笔者原创，引用请注明来源，不足和错误之处请在评论区帮忙指出，谢谢！
Linux系统中，磁盘上的文件和目录被组成一棵目录树，每个节点都是目录或文件.就如如下图所示: 上面我们讲的[pwd]指令,就是显示所在当先目录树的哪一个位置.
上一遍记录了当时集群资源死锁的问题，后来想了想其实小文件较多也会让集群变慢，小文件较多在执行作业时rpc时间就会增加，从而拖垮了job的执行速度。
JuiceFS 是一款面向云原生设计的高性能共享文件系统，在 Apache 2.0 开源协议下发布。提供完备的 POSIX 兼容性，可将几乎所有对象存储接入本地作为海量本地磁盘使用，亦可同时在跨平台、跨地区的不同主机上挂载读写。
swap是位于磁盘上的特殊文件（或分区），属于“虚拟内存”的一部分。通俗点就是内存的备胎，内存充足的情况下，基本上没swap什么事（和设置有关）；内存不够用时系统便将内存中的部分数据腾挪到swap中，为正在运行的程序腾出内存。
linux中： 文件的合并： 创建两个文件a, b :touch a b cat a > b 是把a的内容写到b中，b中的内容会被覆盖 cat a >> b 是把a的内容追加到b文件的末尾，b的内容不会被覆盖 cat a b > c 是把两个文件重新组合成一个新的文件
如果一个文件大小为10K，则1亿个文件大小仅为1TB(但要消耗掉NameNode 20GB内存)
在存储容量有限的嵌入式设备上，一般对于系统分区在使用过程中没有数据写入需求，同时希望可以节省存储空间——只读压缩文件系统应运而生。另外，只读压缩文件系统也可用于归档文件。相比tar，zip等压缩软件，只读压缩文件系统的性能和灵活性都更好。Linux早期的只读文件系统有CramFS和SquashFS，以及参考了上述两个文件系统设计的用户态只读压缩文件系统CromFS。另外，最近两年在Android平台上实现商用的EROFS也值得关注。EROFS针对手机使用场景，对读放大和内存占用过多从设计理念上带来了一些新的优化。
把一个大文件转换成二进制内容，然后按照一个固定的大小对二进制内容进行切割，得到多个小文件，然后循环上传所有的小文件。在js中，文件File对象是Blob对象的子类，可以使用 slice() 方法完成对文件的切割；
例如将一个BLM.txt文件分成前缀为 BLM_ 的1000个小文件，后缀为系数形式，且后缀为4位数字形式
4、设置 join 或aggregate洗牌（shuffle）数据时使用的分区数
理解inode，要从文件储存说起。 文件储存在硬盘上，硬盘的最小存储单位叫做"扇区"（即：Sector）。每个扇区储存512字节（相当于0.5KB）。 操作系统读取硬盘的时候，不会一个个扇区地读取，这样效率太低，而是一次性连续读取多个扇区，即一次性读取一个"块"（block）。这种由多个扇区组成的"块"，是文件存取的最小单位。"块"的大小，最常见的是4KB，即连续八个 sector组成一个 block。 文件数据都储存在"块"中，那么很显然，我们还必须找到一个地方储存文件的元信息，比如文件的创建者、文件的创建日期、文件的大小等等。这种储存文件元信息的区域就叫做inode，中文译名为"索引节点"。 block中存储的就是文件的实际数据，比如说，照片，视频，音频等等，但是有一点需要注意！就是inode当中不包含文件名！一个文件的文件名，存储在上级目录的block中！ 其实inode和block之间的关系就像是一本书一样，inode是一本书的目录，一本书会有很多内容，一个知识点或者一个故事会占很多页，一个block就相当于书中的一页内容。
腾讯云对象存储COS提供了多种工具支持将本地数据上传到COS，如COSBrowser、COSCMD、COS Migration、COSFS等等，本文探讨Linux环境下，如何将机器上挂载的文件存储CFS的数据快速迁移到COS。
在 Vue.js 开发中，将项目部署到生产环境通常需要进行打包。打包是将项目中的源代码、依赖库和配置文件等资源整合到一个或多个文件中，并进行最小化处理，以减小文件大小、提高加载性能和保护源代码的安全性。本文将详细介绍如何使用 Vue CLI 打包 Vue3 项目。
检测系统瓶颈 性能调优 创建一项基线，用来评估系统的首次运行性能（即集群默认配置） 分析Hadoop计数器，修改，调整配置，并重新执行任务，与基线进行比较 重复执行第2步，直到最高效率 识别资源瓶颈 内存瓶颈 当发现节点频繁出现虚拟内存交换时表示出现了内存瓶颈 CPU瓶颈 通常情况下，处理器负载超过90%，在多处理器系统上整体负载超过50% 判断是否是单个特定线程独占了CPU IO瓶颈 磁盘持续活动率超过85%（也有可能是由CPU或内存导致） 网络带宽瓶颈 在输出结果或shuffle阶段从map拉取数据时
文件管理在操作系统中负责文件的存储、检索、共享和保护。管理空闲空间是其中的一项重要任务，以确保文件系统的高效和灵活性。常见的空闲空间管理方法有空闲区表法、空闲链表法、位示图法和成组链表法。
线上出了问题，我需要去查找log来定位问题，但是由于线上数据量庞大，这些log文件每过一个小时就会自动回滚一次，尽管如此，有的log文件依然达到了五六g以上的大小。
继续分布式系统的设计图解，下半部分是基础设施，此篇是分布式文件系统。这里面典型就是 GFS，对应开源的版本就是 HDFS。
HDFS（Hadoop Distributed File System）是Hadoop分布式计算中的数据存储系统，是基于流数据模式访问和处理超大文件的需求而开发的。下面我们首先介绍HDFS中的一些基础概念，然后介绍HDFS中读写操作的过程，最后分析了HDFS的优缺点。
逻辑卷管理LVM是一个多才多艺的硬盘系统工具。无论在Linux或者其他类似的系统，都是非常的好用。传统分区使用固定大小分区，重新调整大小十分麻烦。但是，LVM可以创建和管理“逻辑”卷，而不是直接使用物理硬盘。可以让管理员弹性的管理逻辑卷的扩大缩小，操作简单，而不损坏已存储的数据。可以随意将新的硬盘添加到LVM，以直接扩展已经存在的逻辑卷。LVM并不需要重启就可以让内核知道分区的存在。
之前听 CSDN 头牌博主 @沉默王二 说过一句话，我觉得十分在理：处在互联网时代，是一种幸福，因为各式各样的信息非常容易触达，如果掌握了信息筛选的能力，就真的是“运筹帷幄之中，决胜千里之外”。就像现在各行业都内卷不断，我们要从中破圈，只有想办法提升自己的竞争力！例如备战面试，广泛无脑地刷题只会消耗完你最后一丝精力，而多刷别人总结复盘记录下来的面经，有利于我们为下一次的“跨越”做好准备！
初次接触分布式文件系统，有很多迷惑。通过参考网络文章，这里进行对比一下Hadoop 分布式文件系统（HDFS）与 传统文件系统之间的关系：
文件服务器(file servers)是一种器件，它的功能就是向服务器提供文件。 它加强了存储器的功能，简化了网络数据的管理。 它一则改善了系统的性能，提高了数据的可用性，二则减少了管理的复杂程度，降低了运营费用。
事情是这样发生的- ，还是和数据泵有关的一个问题，但这次不是说数据泵的问题。应用方通过数据泵导入数据时发生空间不足的问题 “No space left on device”，询问是否空间不足导致，错误如下所示：
原文地址： MapReduce Input Split（输入分/切片）详解 结论： 经过以上的分析，在设置map个数的时候，可以简单的总结为以下几点： （1）如果想增加map个数，则设置mapred.map.tasks 为一个较大的值。 （2）如果想减小map个数，则设置mapred.min.split.size 为一个较大的值。 （3）如果输入中有很多小文件，依然想减少map个数，则需要将小文件merger为大文件，然后使用准则2。 看了很多博客，感觉没有一个说的很清楚，所以我来整理一下。
『我们测试文件上传时需要上传指定大小的文件，Windows 如何创建指定大小的文件，有比较便捷的操作方法吗 ？』
文件存储在硬盘上，硬盘的最小存储单位叫做"扇区"（sector）。每个"扇区"的大小为512字节（byte）， ，操作系统读取硬盘的时候，不会一个个扇区的读取，这样效率太慢。他是一次性读取多个扇区，即一次性读取一个"Block块"。一个Block有8个连续的扇区（sector）组成。 数据都存在Block块里面，但是我们怎么知道一个数据存放在哪些Block块里面呢？这个时候就必须需要一个索引，引导我们去找到哪些存放在BLOCK块里面的额数据。这存放索引的地方我们称为索引节点（Inode），索引节点里面包括了：文件的类型，属主，属组，权限，和时间戳一些信息，但是不包括文件名， 1.1.2 inode包含的内容
原文链接：https://mp.weixin.qq.com/s/m4NPnZaKJMXKrTwtZoOQeQ
本文档将向您展示Apache Hudi如何克服可怕的小文件问题。Hudi的一个关键设计决策是避免在一开始就创建小文件，并始终编写大小适当的文件。在Hudi中有两种管理小文件的方法，下面将介绍每种方法的优点和优缺点。
小文件是指文件大小明显小于 HDFS 上块（block）大小（默认64MB，在Hadoop2.x中默认为128MB）的文件。如果存储小文件，必定会有大量这样的小文件，否则你也不会使用 Hadoop，这样的文件给 Hadoop 的扩展性和性能带来严重问题。当一个文件的大小小于 HDFS 的块大小（默认64MB）就认定为小文件，否则就是大文件。为了检测输入文件的大小，可以浏览Hadoop DFS 主页 ，并点击 Browse filesystem（浏览文件系统）。
搜索引擎每天接收大量用户搜索请求，把这些用户输入的搜索关键词记录，再离线统计分析，得到热门TopN搜索关键词。
相信参过Linux 系统运维面试的人都知道，考官必问的一道题就是怎么使用lvm来新建一个文件系统。如果你答不上来，哈哈，那么不客气， 你的面试几乎就结束了
概述：虚拟化是一个广义术语，通常是指计算元件在虚拟的基础上而不是真实的基础上运行，是一个为了简化管理，优化资源的解决方案.服务器虚拟化则是一项用以整合基于x86服务器，来提高资源利用效率和性能的技术.本文从企业业务系统和管理角度出发，着重分析研究了X86技术架构下，虚拟网卡与SR-IOV、NUMA、虚拟磁盘格式相应的特点，并探索了不同应用场景下的资源划分和性能优化方案，希望能够通过多应用系统下的实践和最优配置，来提高X86服务器的性能和资源利用效率.
Apache Hudi是一个流行的开源的数据湖框架，Hudi提供的一个非常重要的特性是自动管理文件大小，而不用用户干预。大量的小文件将会导致很差的查询分析性能，因为查询引擎执行查询时需要进行太多次文件的打开/读取/关闭。在流式场景中不断摄取数据，如果不进行处理，会产生很多小文件。
传统的机器学习模型，数据集比较小，模型的算法也比较简单，使用单机存储，或者本地硬盘就足够了，像 JuiceFS 这样的分布式存储并不是必需品。
图 13总结：通过测试，在本次实验中我们得出的以下几点结论：1. 小文件(最好是大于 0.5M，如果文件太小，在进行 tar 打包并压缩或者 zip 压缩时，其占用的磁盘空间会比源文件大很多)在进行 tar 打包并压缩或者 zip 压缩时，其占用磁盘的大小不变；中等文件(100M 左右的 pdf 格式文件) ，在进行 tar 打包并压缩或者zip 压缩时时，大约节省 20%-30%的空间；对于大文件(500M 左右的视频文件)基本上没有节省多少磁盘空间。2. 在 Radhat5.5 中对于 tar 打包并压缩测试和 zip 压缩测试中，tar 和 zip 对文件的压缩是一样的，对磁盘的节省程度是一样的。3. 本次测试中由于选择文件的特殊性，不能够完全模仿在真实情况下的操作，所以得出的结论会有一定程度的误差。由于 cuizong007 的水平有限，难免有错误的地方，还请多多包涵。欢迎各位技术好友进行技术方面的交流。cuizong007 的邮箱是：cuizong007sina.com图 5图 67.对文件 2 进行查看(如图 7 和图 8)：图 7图 88. 对文件 3 进行 tar 和 zip 压缩(如图 9 和图 10)：图 9图 109. 对文件 2 进行查看(如图 11 和图 12)：图 11图 1210.在将所有的文件进行 tar 和 zip 压缩完后，查看压缩完后的情况(如图 13)：在 linux 下人们不免会遇到要压缩一些文件，但是究竟要那种方式压缩，所得到的结果最能够节省磁盘的空间，而且有不容易出现错误呢？本次实验结果只做技术讨论，相互的学习。实验环境：在 xp 系统下安装在虚拟机上的 redhat5.5 的系统。本次实验结果将主要测试最常用的、最简单的(即没有添加太复杂的命令选项)tar 和 zip命令。1. 我们选择了三个不同大小的文件(文件名分别为：1、2 和 3；文件 1 和文件 2 都是 pdf文档；文件 3 为视频文件)如图 1 所示：图 12. 我们首先使用命令 tar 将第一个小文件(即 1)进行压缩。 (使用命令： tar zcvf 1.tar.gz 1)如图 2 所示：图 23.再使用命令 zip 压缩第一个小文件(即 1)进行压缩。 (使用命令： zip 1.zip 1)如图 3所示：图 34.使用命令查看 tar 和 zip 压缩同一文件 1 的大小(使用命令：
伙伴们，开始本文之前给大家说个事情：由于最近坚持更新公众号文章，向大家推送学习内容，居然收到了微信客服的致电和来信，给开通了留言功能。有点小小的意外和开森！以后发布的文章大家就可以随时留言，希望大家多多留言提出宝贵意见哦！！！
后续业务开发过程中，每个子业务（kudu、es、clickhouse等等）都会创建SparkSession对象，以及初始化开发环境，因此将环境初始化操作封装成工具类，方便后续使用
前言 前面几篇简单介绍了什么是大数据和Hadoop，也说了怎么搭建最简单的伪分布式和全分布式的hadoop集群。接下来这篇我详细的分享一下HDFS。 HDFS前言： 设计思想：（分而治之）将大文件、大批量文件，分布式存放在大量服务器上，以便于采取分而治之的方式对海量数据进行运算分析。 在大数据系统中作用：为各类分布式运算框架（如：mapreduce，spark，tez，……）提供数据存储服务。 分布式文件系统： 问题引发：海量数据超过了单台物理计算机的存储能力 解
现代社会信息数据爆炸式增长，工业界业务需求纷繁复杂。数据存储的数据量，建表数量也都不断增长。openGauss通用的普通表，每个数据表对应一个逻辑逻辑上的大文件（最大32T），该逻辑文件又按照固定的大小划分多个实际文件存在对应的数据库目录下面。所以，每张数据表随着数据量的增多，底层的数据存储所需文件数量会逐渐增多。同时，openGauss对外提供hashbucket表、大分区表等特性，每张数据表会被拆分为若干个子表，底层所需文件数量更是成倍增长。由此，这种存储管理模式存在以下问题：
这是我们经常能听到很多大佬说的一句话，那为什么说 Linux 中都是文件呢？这句话究竟代表着什么具体的含义呢？在操作系统中，文件系统又扮演着一个什么样的角色？作为一个普通的开发者，我们究竟对文件系统要有怎么样的认识？今天我们就来看看这个大哥 —— 文件系统
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
实时音视频
即时通信 IM
对象存储
