srdfg

dfgdf

• 数据集大小>一台计算机存储能力时,

  • 要对它分区并存储到若干台单独的计算机上

• 管理网络中跨多台计算机存储的文件系统

  • 称分布式文件系统

• 该系统架构于网络之上,势必会引入网络编程复杂性,

  • 分布式文件系统比普通磁盘文件系统更复杂。

• 使文件系统能够容忍节点故障且不丢失任何数据,就是一个极大挑战

 

• Hadoop自带HDFS的分布式文件系统,

  • Hadoop Distributed Filesystem

• 在非正式文档或旧文档以及配置文件中,有时也称DFS

• HDFS是 Hadoop的旗舰级文件系统,也是本章重点

• 实际Hadoop是一个综合性的文件系统抽象,

  • 因此接下来我们将了解将Hadoop与其他存储系统集成的途径,

  • 例如本地文件系统和 Amazon S3系统。

<font color=red>意思就是Hadoop也可以和其他存储系统集成</font>

3.1 HDFS的设计

• HDFS以流式数据访问模式存储超大文件,运行于商用硬件集群

• 超大文件“超大文件”在这里指有几百M、百G甚至百T大小

  • 目前有存储PB级数据的Hadoop集群

在这里插入图片描述

 

• 流式数据访问

• HDFS的构建思路:一次写入、多次读取最高效

  • 数据集通常由数据源生成或从数据源复制,接着长时间在此数据集上分析

  • 每次分析都将涉及该数据集大部分数据甚至全部

    • 因此读取整个数据集的时间延退比读取第一条记录的时间延迟更重要

 

• 商用硬件

• Hadoop不需运行在昂贵且高可靠的硬件

• 它是设计运行在商用硬件(普通硬件的集群上对庞大的集群来说,节点故障几率非常高

• HDFS遇到上述故障时,能继续运行且不让用户察觉到明显的中断

• 那些不适合在HDFS上运行的应用也值得研究

  • 目前HDFS对某些应用领域并不适合,以后可能会有所改进

 

• 要求低时延迟数据访问的应用,

  • 几十毫秒范围,不适合在HDFS上运行

• HDFS是为高数据吞吐量应用优化的,这可能会以提高时间延迟为代价。

• 目前,对于低延退的访问,Hbase(参见第20章)是更好的选择

 

• 大量的小文件

• namenode将文件系统的元数据存储在内存,

  • 因此该文件系统所能存储的文件总数受限于namenode的内存容量

• 毎个文件、目录和数据块的存储信息约150字节

• 如果有一百万个文件,且每个文件占一个数据块,至少要300MB内存

• 上百万个文件可行,但数十亿个文件就超出当前硬件能力

<font color=red>文件系统的元数据是在内存里的！</font>

 

• 多用户写入

• 任意修改文件HDFS中的文件写入只支持单个写入者,且写操作总“只添加”方式在文件末尾写数据。

• 它不支持多个写入者的操作,也不支持在文件的任意位置修改

• 可能以后会支持这些操作,但它们相对比较低效

在这里插入图片描述

3.2HDFS的概念

3.2.1数据块

• 磁盘都有默认的数据块大小

  • 磁盘数据读/写的最小单位

• 构建于单个磁盘之上的文件系统通过磁盘块来管理该文件系统中的块,该文件系统块大小可以是磁盘块的整数倍

• 文件系统块几千字节,磁盘块一般512字节

• 这些信息(文件系统块大小)对需要读/写文件的用户来说透明

• 系统仍然提供一些工具(如df和fsck)来维护文件系统

  • 由它们对文件系统中的块进行操作

<font color=red>一个扇区</font>

 

• HDFS也有块,但是大得多,默认128MB。

• 与单一磁盘上的文件系统相似,HDFS上的文件也被划分为块大小的多个分块( chunk),作为独立的存储单元。

• 但与面向单一磁盘的文件系统不同的是,HDFS中小于一个块大小

的文件不会占据整个块的空间(当一个1MB的文件存储在一个128MB的

块中时,文件只使用1MB的磁盘空间,而不是128MB)。

• 本书中提到的“块”特指HDFS中的块。