HDFS:Hadoop Distributed File System,Hadoop分布式文件系统,主要用来解决海量数据的存储问题。
备份冗余存储 dfs.replication = 3
为各类分布式运算框架(如:MapReduce,spark,hive.....)提供数据存储服务。
数据切块、副本存放、元数据
- 首先,它是个文件系统。用于存储文件,通过统一的命名空间——目录树来定位文件。
- 其次,它是分布式的。由很多服务器联合起来实现其功能,集群中的服务器有各自的角色。
文件的各个block的存储管理由datanode结点承担。
datanode是HDFS集群从结点,每一个block都可以在多个datanode上存储多个副本,副本数量也可以通过参数设置(dfs.replication)
5.HDFS是设计成适应一次写入,多次读出的场景,且不支持文件的修改。
注:适合用来做数据分析,并不适合用来做网盘应用,因为不便修改,延迟大,网络开销大,成本太高
如上图所示,HDFS也是按照Master和Slave的结构。分为NameNode(NN)、SecondaryNameNode、DataNode(DN)这几个角色。
NameNode:名称节点。
- 是HDFS的主节点、管理员。
- 是接收客户端(命令行、Java API程序 )的请求:创建目录、上传数据、下载数据、删除数据等等。
- 管理和维护HDFS的日志和元信息
DataName:数据节点。 负责存储client发来的数据库block;执行数据块的读写操作。
SecondaryNameNode:是NameNode的冷备份;合并fsimage和fsedits然后再发给namenode
fsimage:元数据镜像文件(文件系统的目录树)
edits:元数据的操作日志(针对文件系统做的修改操作记录)
namenode内存中存储的是=fsimage+edits。
SecondaryNameNode负责定时默认1小时,从namenode上,获取fsimage和edits来进行合并,然后在发送给namenode,减少namenode的工作量。
1.低延时数据访问。在yoghurt交互性的应用上,应用需要在ms或者几个s的时间内得到响应。由于HDFS为高吞吐率做了设计,也因此牺牲了快速响应。对于低延时的应用,可以考虑HBase或者Cassandra。
2.大量的小文件。标准的HDFS数据块的大小是128M(2.x),存储小文件并不会浪费实际的存储空间,但是无疑会增加在NameNode上的元数据。大量的小文件会影响整个集群的性能。
Btrfs为小文件做了优化-inline file,对于小文件有很好的空间优化和访问时间优化。
3.多用户写入、修改文件。HDFS的文件只能有一个写入者,而且写操作只能在文件结尾以追加的方式进行。它并不支持多个写入者,也不支持在文件写入后,对文件的任意位置的修改。
但是在大数据领域,分析的是已经存在的数据。这些数据一旦产生就不会修改。因此,HDFS的这些特性和设计的局限也就容易理解了。HDFS为大数据领域的数据分析,提供了非常重要而且十分基础的文件存储功能。
1.冗余备份:每个文件存储成一系列数据块(Block)。为了容错,文件的所有数据块都会有副本(副本数量即复制因子,dfs.replication)。
2.副本存放:采用机架感知(Rak-aware)的策略来改进数据的可靠性、高可用和网络带宽的利用率。
3.心跳检测:NameNode周期性地从集群种的每一个DataNode接收心跳包和块报告,收到心跳包说明该DataNode工作正常。
4.安全模式:系统启动时,NameNode会进入安全模式。此时不允许出现数据块的写操作。
5.数据完整性检测:HDFS客户端软件实现了对HDFS文件内容的校验(CheckSum)和检查(dfs.bytes-per-checksum)。
如果NameNode失效,那么客户端或者MapReduce作用均无法读写查看文件。
1.启动一个拥有文件系统元数据的新NameNode(这个一般不采用,因为复制元数据非常消耗时间)。
2.配置一对活动-备用(Active-Standby)NameNode,活动NameNode失效时,备用NameNode立即接管,用户不会有明显中断的感觉。
原文:https://www.cnblogs.com/shine-rainbow/p/11335989.html