- 体系结构
(★★)hdfs的优点与缺点
HDFS 具有以下优点:
(1) 高容错性
- 数据自动保存多个副本。它通过增加副本的形式,提高容错性。
- 某一个副本丢失以后,它可以自动恢复,这是由 HDFS 内部机制实现的,我们不必关心。
(2) 适合批处理 - 它是通过移动计算而不是移动数据。
- 它会把数据位置暴露给计算框架。
(3) 适合大数据处理 - 数据规模:能够处理数据规模达到 GB、TB、甚至PB级别的数据。
- 文件规模:能够处理百万规模以上的文件数量,数量相当之大。
- 节点规模:能够处理10K节点的规模。
(4) 流式数据访问 - 一次写入,多次读取,不能修改,只能追加。
- 它能保证数据的一致性。
(5) 可构建在廉价机器上 - 它通过多副本机制,提高可靠性。
- 它提供了容错和恢复机制。比如某一个副本丢失,可以通过其它副本来恢复。
2、 HDFS 缺点:
(1) 不适合低延时数据访问; - 比如毫秒级的来存储数据,这是不行的,它做不到。
- 它适合高吞吐率的场景,就是在某一时间内写入大量的数据。但是它在低延时的情况 下是不行的,比如毫秒级以内读取数据,这样它是很难做到的。
(2) 无法高效的对大量小文件进行存储 - 存储大量小文件的话,它会占用 NameNode大量的内存来存储文件、目录和块信息。这样是不可取的,因为NameNode的内存总是有限的。
- 小文件存储的寻道时间会超过读取时间,它违反了HDFS的设计目标。 改进策略
(3) 并发写入、文件随机修改 - 一个文件只能有一个写,不允许多个线程同时写。
- 仅支持数据 append(追加),不支持文件的随机修改。
(★★)HDFS的体系结构
Client:切分文件;访问或通过命令行管理HDFS;与NameNode交互,获取文件位置信息;与DataNode交互,读取和写入数据。
NameNode:Master节点,只有一个,管理HDFS的名称空间和数据块映射信息;配置副本策略;处理客户端请求。
DataNode:Slave节点,存储实际的数据;执行数据块的读写;汇报存储信息给NameNode。
Secondary NameNode:辅助NameNode,分担其工作量;定期合并fsimage和fsedits,推送给NameNode;紧急情况下,可辅助恢复NameNode,但Secondary NameNode并非NameNode的热备。
(★)相比于 HDFS1.0, HDFS 2.0 最主要的改进在哪几方面?
NameNode支持HA
命名空间支持分区(Federation)联邦
支持目录快照
https://blog.csdn.net/qw311113qin/article/details/81707258
- 工作原理
(★★★)hdfs底层存储设计
对于大数据来说,数据量是巨大的,多样性的,而且后期是要进行本地计算的,这样的话数据的存储要求是可靠的来保证数据的不丢失,HDFS就实现了这样的一个功能
HDFS存储数据的可靠性主要表现在其的副本机制,默认是3个,而且有其自己的一套存储策略。一个分布式的集群包含有很多的机架,每个机架又包含很多节点,机架内的节点之间的传输效率高于跨机架的节点之间的传输效率,并且机架之间机器的网络通讯通常要收到上层交换机的间网络带宽的限制。所以为了数据的安全和高效,Hadoop默认的存储策略是:
1、第一个副本存储在client所在的node中。(如果client不在集群中,则随机存储一个node)
2、第二个副本存储在与第一个副本不同机架的其他任意机架的任意node中。
3、第三个副本存储在与第一个副本同一个机架但是不同的node中。
4、如果还有其他副本设置,则随机选择存储。
这样的存储策略可以保证如果第一个节点失效时,能够优先在本机架找到另一个副本,另外如果整个机架发生了故障,能够保证在其他的机架中同样能够找到副本。这样既保证了数据的可靠,又兼容了高效。
(★★★)HDFS 的文件上传与下载底层工作原理(或 HDFS 部分源码分析):FileSystem 的create()和 open()方法源码分析?
https://www.cnblogs.com/qq503665965/p/6696675.html
https://www.cnblogs.com/qq503665965/p/6740992.html
(★★★)HDFS 的 namenode 与 secondarynamenode 的工作原理(重点是日志拉取和合并过程)?
在NameNode端的工作流程如下:
1.Namenode始终在内存中保存metedata,用于处理“读请求” 到有“写请求”到来时,namenode会首先写editlog到磁盘,即向edits文件中写日志,成功返回后,才会修改内存,并且向客户端返回.
2.Hadoop会维护一个fsimage文件,也就是namenode中metedata的镜像,但是fsimage不会随时与namenode内存中的metedata保持一致,而是每隔一段时间通过合并edits文件来更新内容。
secondary namenode的工作流程: 1.secondary通知namenode切换edits文件
2.secondary从namenode获得fsimage和edits(通过http)
3.secondary将fsimage载入内存,然后开始合并edits
4.secondary将新的fsimage发回给namenode
5.namenode用新的fsimage替换旧的fsimage