标签：结构体 因此 验证 访问 了解 标准 副本 取数据 硬盘
hdfs文件系统主要设计为了存储大文件的文件系统；如果有个TB级别的文件，我们该怎么存储呢？分布式文件系统未出现的时候，一个文件只能存储在个服务器上，可想而知，单个服务器根本就存储不了这么大的文件；退而求其次，就算一个服务器可以存储这么大的文件，你如果想打开这个文件，效率会高吗
hdfs的出现就是为了解决上面的问题
hdfs为了满足大文件的存储和可读性，对数据进行切成多个小块进行存储，同时为了保证数据的可靠性，又对每个小块数据做复制，然后分别存储到多个节点中
hdfs2.7.3后，默认每个块的大小是128MB，在hdfs1.0的时候，默认每个块的大小是64MB
可以通过修改hdfs的配置文件自定义块大小
hdfs-site.xml文件中的dfs.blocksize
默认每个块的副本数是3，可以通过修改hdfs的配置文件自定义副本数
hdfs-site.xml的dfs.replication
hdfs是一个分布式的文件系统，采用主从（master/slave）的结构体系，一个hdfs集群由NameNode和多个datanode组成，其中namenode作为主节点，DataNode为从节点
Namenode简称NN
DataNode简称DN
NN的作用
a、存储元数据信息
b、元数据存储两份，一份在内存中，一份在硬盘中
c、保存文件、block、datanode的映射关系
DN的作用
a、存储block信息
b、block存储在硬盘中
c、维护block和文件的映射关系
数据存储在内存中是为了读取性能，保证效率，数据存储在硬盘中，为了持久化数据，保证数据不丢失
a、支持超大文件
支持超大文件，这里的超大文件几百MB，几百GB，甚至TB级别大小的文件，一般来说hadoop的文件系统会存储TB级别或者 PB级别的数据，所以在企业节点中，数据节点可能有上千个
b、检测和快速 应对 硬件故障
在集群中 环境中，硬件故障是常见的问题，因为 有上千台服务器，这样会导致高故障率，因此故障检测和自动 恢复 是hdfs文件系统 的一个设计目标
c、流式数据访问
Hdfs的数据处理规模比较大，应用一次要 访问大量的 数据，同时这些应用一般都是批量处理，而不是用户交互式 处理，应用程序能以流的形式访问数据集，主要是数据的吞吐量，而不是访问速度；适合做离线数据的处理
d、简化的一致性模型
大部分 hdfs操作文件时，需要一次 写入，多次读取，在 hdfs文件系统中，一个文件块一旦经过 创建，写入，关闭后就不允许 修改了，在hdfs2.7后 ，才允许对block进行追加修改，但是不能改变已有的数据，这样简单的一致性模型，保证数据操作的简单化
e、高容错性
数据自动保存多个 副本，副本丢失自动恢复
f、可构建在廉价的机器上
构建在廉价的机器上，可以启动通过扩展机器 个数里线性提高存储能力
a、低延迟数据访问
低延迟数据 ，如果用户进行交互的应用，比如京东，需要数据在毫秒后者秒级范围内得到响应，由于 hadoop对高吞吐 模型 做了优化，牺牲了获取数据的延迟，所以对于低延时的应用，不适合 用hadoop，而且hdfs的数据也不是结构化的数据
b、不适合大量小文件
Hdfs支持超大的文件，是通过数据分别在不同的数据节点，数据的元数据保存在namenode上，namenode的内存大小决定了hdfs可以保存的文件数量，虽然现在 内存已经很大，但是大量的 小文件还是会 影响namenode的节点性能，每个block会占用一片内存空间
c、不支持多次写入文件，修改文件
为了保证吞吐量，设计为这样
数据块（block）是hdfs存储文件的基本单位
在hdfs中，有一个特别重要的概念，数据块（block），前面介绍过，在hdfs存储的文件都是超大数据的文件，我们可以把这个超大规模的文件以一个标准切分成几块，分别存储到不同的磁盘上，这个标准就是block
a、为了存储大文件，一个服务器很难存储超大型的文件，拆分的话，文件块可以保存在不同的磁盘，在hdfs文件系统中，一个文件可以分成不同的block存储在不同的磁盘上
b、简化存储系统，这样就不需要管理文件，而是直接管理文件块就可以了
c、有利于数据的复制，在hdfs系统中，一个block块一般会复制三份（可以修改），比如复制一个1TB的数据和复制多个128MB的文件复制哪个更快？
对于一个文件而言，一个block id从0开始，按照固定的大小，顺序对文件进行划分和编号，划分好的每一块称一个block。Hdfs默认的block的大小是128MB，所以一个256MB的文件，共有256/128=2个块
不同于普通的文件系统（比如ext4或者ntfs），hdfs中，如果一个文件小于一个数据块的大小，并不用占用整个数据存储空间，而是仅仅会占用文件实际大小的空间
Namenode是维护hdfs中的元信息，包括文件和block之间的映射关系，block数量的信息，block和datanode之间的关系信息，数据格式参照入下
Filename replicas block-ids id2host
/test/log，3，{b1,b2},{b1:[host0,host1,host2]} ,{b2:[host3,host4,host5]}
Namenode中的元数据信息存储在内存/磁盘中，内存中为实时信息，磁盘中为数据的持久化存储使用使用
在磁盘中存储的信息主要下面两个
fsimage：元数据的镜像文件，存储namenode元数据信息
edit：操作日志文件（比如你上次，追加内容，这里只有写操作的日志，读操作不会记录）
下面重点讲一下这2个文件流程
上面的流程如果明白了，就会发现有2个问题
a、一般namenode会持续运行，不会被启动，那么edit文件会增长很大，这个时候就不好管理
b、如果edit文件增长到很大，那么每次namenode启动合并edit文件和fsimage就会很久，那namenode启动就会很慢
这个时候就有了SNN（second NameNode）
听名字，大家以为SNN是NN的热备份，其实SNN是NN的协助者，帮助进行元数据合并的
a、SNN会定时通过http的get方法从NN获取最新的edit和fsimage文件
b、然后NN会生成一个空的edit文件，该文件继续接受client的i写请求操作日志
c、SNN拿到最新的edit文件和fsimage文件，进行合并，生成最新的fsimage文件
d、SNN通过http的post方法把最新的fsimage文件发送到NN
e、这样就把上面那2个文件解决了
触发checkpoint的条件有3个
a、默认是3600s合并一次，可以通过修改fs.checkpoint.period自定义
b、根据edit.log文件的大小触发合并，默认是64MB会触发合并，可以通过修改fs.checkpoint.size自定义
在hadoop中，数据是存放在datanode上面的，是以block的形式存储的，datanode节点会不断的向namenode节点发送心跳报告，初始化，每个数据节点将当前存储的数据告知namenode节点，通过向namenode主动发送心跳保持联系，3s会发送一次
Datanode节点在工作的过程中，数据节点仍会不断的更新namenode节点与之对应的元数据信息，并接受来自namenode节点的指令，创建，移动或者删除本地磁盘上的数据块
如果10min都没有收到nd的心跳，则认为其已经挂了，并copy其上的block到其他dn
a、client向远程namenode发起读请求
b、NN会视情况返回文件的部分或者全部block列表，对于每个block，namenode都会返回该block的地址和副本的DN的地址
c、客户端会选取最接近的DN来读取block
d、读取完当前的block的数据后，关闭与当前的DN的连接，并为读取下一个block寻找最佳的DN
e、当读完列表的block后，且文件读取还没有结束，客户端会继续向NN获取下一批的block列表
f、读取完一个block都会进行checksum验证，如果读取的时候出现错误，client会通知NN，然后在从下一个拥有该block块的DN继续读取数据
2、写数据流程
a、client向namenode发起写请求
b、NN会检查路径是否存在、权限是否正确、文件是否存在
c、条件满足后，client开始写入文件，首先开发库会将文件拆分成多个packets，并在内部以数据队列的形式来管理这些packet，并向NN申请新的blocks，获取用来存储block和副本的DN的列表，
d、开始已经pipiline（管道）的形式将packet写入到第一个DN中，当第一个DN写入成功后，在将其传递给下一个DN，直到最后一个DN存储完成
e、然后开始上传下一个packet
a、现在NN上执行节点名字的删除
b、当NN上执行delete方式时，他这是标记操作涉及需要被删除的数据块，而不是主动联系这些数据块所在的DN节点
c、当保存这些数据库的DN节点向NN节点发送心跳时，在心跳应答里，NN会向DN发出指令，从而把数据删除
d、所以在执行delete方法后一段时间内，数据块才会被删除掉
标签：结构体 因此 验证 访问 了解 标准 副本 取数据 硬盘
原文地址：https://www.cnblogs.com/bainianminguo/p/11986605.html
