HDFS的设计理念是源于非常朴素的思想:
当数据集大小超过单台计算机的存储能力时,就有必要将其进行分区,并且存储到若干台单独的计算机上,而管理网络中跨多台计算机存储的文件系统称为分布式文件系统(distribute filesystem).
hadoop 具有一个抽象的文件系统的概念,HDFS只是其中的一个实现。
hadoop文件系统接口由Java 抽象类 org.apache.hadoop.fs.FileSystem类定义,该类同时还继承了org.apache.hadoop.conf并且实现了JAVA 的java.io.Closeable接口。
HDFS特点以及短板:
特点:
- 适合存储超大文件:存储在HDFS 的文件大多在GB甚至是TB 级别。
- 运行于廉价的硬件之上:HDFS 在设计的时候,就已经认为在汲取规模足够大的时候,节点故障并不是小概率事件,而可以认为是一种常态,例如,一个节点故障的概率如果是千分之一,那么当集群规模是1000台的时候,正常情况每天都会有节点故障。当节点发生故障是,能够继续运行并且不让用户察觉到明显的终端,所以,HDFS并不需要运行在高可靠且昂贵的服务器上,普通的PC server即可。
- 流式数据访问:HDFS认为,一次写入,多次读取是最搞笑的访问模式。HDFS 的数据集作为Hadoop的分析对象,在数据集生成以后,会长时间在吃数据集上 进行各种分析。每次分析都将涉及该数据集的大部分数据甚至全部数据,因此,读取整个数据集的时间延迟比读取第一条记录的时间延迟更重要~。
短板:
- 实时数据访问弱:如果应用要求数据访问的时间在秒或者毫秒级别,那么,HDFS是做不到的,由于HDFS针对高书记吞吐做了优化,因而牺牲了读取数据的速度,队友相应时间是秒或者是毫秒的数据藩王,可以考虑使用HBase.
- 大量的小文件:当hadoop启动的时候,NameNode会将所有元数据读到内存,以此构建目录树。一般来讲,一个HDFS上的 文件、目录和数据块的存储信息,大约在150字节左右,那么,可以推算出,如果NameNode的内存为16GB的话,大概只能存放480万个文件,对于一个超大规模的集群,这个数字很快就能达到。
- 多用户写入,任意修改文件:HDFS中的文件只能有一个写入者,并且写数据操作总是在文件末。它不支持多个写入者,也不支持在数据写入之后,在文件的任意位置进行修改。事实上,如果不讲hdfs-site.xml中的dfs.support.append设置为true,HDFS也不支持对文件进行追加操作。
![](https://i-blog.csdnimg.cn/blog_migrate/4a8ebd618b4858f3317f04a08b812ecd.png)
HDFS-架构:
- 块:
使用块的好处就:
(1)可以保存比存储节点单一磁盘大的文件。
(2)简化存储子系统:实现了元数据和数据的分块管理与存储。
(3)容错性高:将dfs.relication 设置为2,即配置每个HDFS的块在hadoop中保存的份数,值越高,冗余性越好,默认为3.
- NameNode和SecondaryNameNode :
SecondaryNameNode,也被称之为第二名字节点,是用于定期合并命名空间镜像和命名空间镜像的编辑日志的辅助守护进程。每个HDFS集群都有一个SecondaryNameNode,在生产环境下,一般SecondaryNameNode也会单独运行在一台服务器上。
- DataNode
DataNode会不断地向NameNode报告。初始化时,每个DateNode将当前存储的块告知NameNode,在集群正常工作时,DateNode任然会不断的更新NameNode,为止提供本地修改的相关信息,同时接受来自NameNode的指令,创建,移动或者删除本地磁盘上的数据。
- HDFS客户端