标签：文件 存储 架构 HDFS 数据 数组 分布式文件系统 haddoob 节点

一、apache

Apache基金会 是专门为支持开源软件项目而办的一个非盈利性组织

二、分布式文件系统

1、FS File System

文件系统时极域硬盘之上的文件管理的工具

我们用户操作文件系统可以和硬盘进行解耦

2、DFS Distributed File System

分布式文件系统

将我们的数据存放在多台电脑上存储

分布式文件系统有很多,HDFS(Hadoop Distributed FileSyetem)是Hadoop自带的分布式文件系统

HDFS是mapreduce计算的基础

三、文件切分的思想（引出分而治之的思想 第一个核心思想）

a. 文件存放在一个磁盘上效率肯定是最低的

读取效率低

如果文件特别大会超出单机的存储范围

b. 字节数组

文件在磁盘真实存储文件的抽象概念

数组可以进行拆分和组装,源文件不会收到影响

c. 切分数据

对字节数组进行切分

d. 拼接数据

按照数组的偏移量将数据连接到一起，将字节数组连接到一起

e. 偏移量

当前数据在数组中的相对位置,可以理解为下标

数组都有对应的索引,可以快速定位数据

f. 数据存储的原理:

不管文件的大小,所有的文件都是由字节数组构成

如果我们要切分文件,就是将一个字节数组分成多份

我们将切分后的数据拼接到一起,数据还可以继续使用

我们需要根据数据的偏移量将他们重新拼接到一起

四、Block拆分标准

数据块Block

a. 是磁盘进行数据 读/写的最小单位,数据被切分后的一个整体被称之为块 ​ b. 在Hadoop 1默认大小为64M,在Hadoop 2及其之后默认大小为128M块，这么大是为了最小化寻址开销 ​ c. 同一个文件中,每个数据块的大小要一致除了最后一个节点外 ​ 不同文件中,块的大小可以不一致 ​ 文件大小不同可以设置不同的块的数量 ​ HDFS中小于一个块的大小的文件不会占据整个块的空间 ​ d. 真实情况下,会根据文件大小和集群节点的数量综合考虑块的大小 ​ e. 数据块的个数=Ceil(文件大小/每个块的大小)

拆分的数据块需要等大

a. 数据计算的时候简化问题的复杂度(否则进行分布式算法设计的时候会因为数据量不一很难设计) ​ b. 数据拉取的时候时间相对一致 ​ c. 通过偏移量就知道这个块的位置 ​ d. 相同文件分成的数据块大小应该相等

注意事项

a. 只要有任意一个块丢失,整个数据文件被损坏 ​ b. HDFS中一旦文件被存储,数据不允许被修改 ​ 修改会影响偏移量

修改会导致数据倾斜（单节点数据量过多）

修改数据会导致蝴蝶效应 ​ c. 但是可以被追加(一般不推荐) ​ 追加设置需要手动打开 ​ d. 一般HDFS存储的都是历史数据.所以将来Map Reduce都用来进行离线数据的处理 ​ f. 块的大小一旦文件上传之后就不允许被修改 128M-512M

五、Block数据安全

a. 只要有任意一个块丢失,整个数据文件被损坏 ​ b. 肯定要对存储数据做备份 ​ c. HDFS是直接对原始数据进行备份的,这样能保证恢复效率和读取效率 ​ d. 备份的数据肯定不能存放在一个节点上,使用数据的时候可以就近获取数据 ​ f. 备份的数量要小于等于节点的数量 ​ g. 每个数据块默认会有三个副本,相同副本是不会存放在同一个节点上 ​ h. 副本的数量可以变更 ​ 可能近期数据被分析的可能性很大,副本数可以多设置几个 ​ 后期数据很少被分析,可以减少副本数

六、Block的管理效率

需要专门给节点进行分工

• 存储 DataNode 实际存储数据的节点

• 记录 NameNode

• 日志 Secondary NameNode

标签：文件,存储,架构,HDFS,数据,数组,分布式文件系统,haddoob,节点
来源： https://www.cnblogs.com/Nana7mi/p/16614024.html

本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享；
2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关；
3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关；
4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除；
5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。