- 当数据集的大小超过一台计算机的存储能力时,就有必要对它进行分
区并存储到若干台单独的计算机上。 - 管理网络中跨多台计算机存储的文件系统称为分布式文件系统。
- 该系统架构于网络之上,势必会引入网络编程的复杂性,因此分布式文件系统比普通磁盘文件系统更为复杂。
- 例如,使文件系统能够容忍节点故障且不丢失任何数据,就是一个极大的挑战。
- Hadoop自带HDFS的分布式文件系统,
- Hadoop Distributed Filesystem
- 在非正式文档或旧文档以及配置文件中,有时也简称DFS
- HDFS是 Hadoop的旗舰级文件系统,也是本章重点,
- 但实际上Hadoop是一个综合性的文件系统抽象,
- 因此接下来我们将了解将Hadoop与其他存储系统集成的途径,
- 例如本地文件系统和 Amazon S3系统。
3.1 HDFS的设计
-
HDFS以流式数据访问模式存储超大文件,运行于商用硬件集群
-
超大文件“超大文件”在这里指有几百M、百G甚至百T大小的文件。
- 目前有存储PB级数据的Hadoop集群
- 流式数据访问
- HDFS的构建思路:一次写入、多次读取最高效
- 数据集通常由数据源生成或从数据源复制,接着长时间在此数据集上进行分析
- 每次分析都将涉及该数据集大部分数据甚至全部,
- 因此读取整个数据集的时间延退比读取第一条记录的时间延迟更重要。
- 商用硬件
- Hadoop不需运行在昂贵且高可靠的硬件
- 它是设计运行在商用硬件(普通硬件 的集群上的,因此至少对庞大的集群来说,节点故障几率非常高
- HDFS遇到上述故障时,能继续运行且不让用户察觉到明显的中断
- 那些不适合在HDFS上运行的应用也值得研究。
- 目前HDFS对某些应用领域并不适合,以后可能会有所改进。
- 要求低时延迟数据访问的应用,例如几十毫秒范围,不适合在HDFS上运行。
- HDFS是为高数据吞吐量应用优化的,这可能会以提高时间延迟为代价。
- 目前,对于低延退的访问,Hbase(参见第20章)是更好的选择。
- 大量的小文件
- namenode将文件系统的元数据存储在内存,
- 因此该文件系统所能存储的文件总数受限于namenode的内存容量
- 毎个文件、目录和数据块的存储信息约150字节
- 如果有一百万个文件,且每个文件占一个数据块,至少要300MB内存
- 上百万个文件可行,但数十亿个文件就超出当前硬件能力
- 多用户写入
- 任意修改文件HDFS中的文件写入只支持单个写入者,且写操作总“只添加”方式在文件末尾写数据。
- 它不支持多个写入者的操作,也不支持在文件的任意位置修改。
- 可能以后会支持这些操作,但它们相对比较低效。
3.2HDFS的概念
3.2.1数据块
