HDFS 优点
硬件故障预防
一个 HDFS
实例有可能包含数百台或数千台服务器,每一个台机器都存储文件系统数据的一部分,这种情况下硬件故障是常态。而 HDFS
可检测故障并从中快速自动恢复。
流数据访问
HDFS
设计用于批处理而不是用户的交互式使用,其重点是数据访问的高吞吐量而并不追求数据访问的低延迟。
处理大数据集
HDFS
的核心目标就是为处理具有大数据量的应用,在其上运行的应用的文件大小一般都为 TB
级别。HDFS
可提供高聚合数据带宽并且要扩展到集群中的数百个节点上,并对于单个应用可支持上千万个文件。
简单一致模型
HDFS
应用程序是一个"一次写入多次读取"的文件访问模型。这种模型可以简化数据的一致性问题并且能够实现高吞吐数据访问。一旦写入不能修改只能增加(append
)
移动计算替代移动数据
Moving Computation is Cheaper than Moving Data
当一个计算程序与数据同在一个物理节点上时,运算最高效,特别是当数据量特别大时,移动计算远优于移动数据集。移动计算可以最大限度地减少网络拥塞并提高系统的整体吞吐量。HDFS
设计的是将计算迁移到更靠近数据所在的位置,而不是将数据移动到运行应用程序的位置。HDFS 为应用程序提供了接口,使其自身更靠近数据。
跨异构硬件和软件平台的可移植性
HDFS 的设计便于从一个平台移植到另一个平台。 这有助于广泛采用 HDFS 作为大量应用程序的首选大数据处理平台。
缺点
不适合低时间延迟的访问
如果要处理一些用户要求时间比较短的低延迟应用请求,则HDFS不适合。HDFS是为了处理大型数据集分析任务的,主要是达到高的数据吞吐量而设计的,这就可能要求以高延迟作为代价。
无法高效存储小文件
因为nameNode
把文件系统的元数据放置在内存中,所以文件系统所能容纳的文件数目是由NameNode的内存大小来决定的,一般来说,每一个文件、文件夹和Block
需要占据150
字节左右的空间,所以,如果你有100
万个文件,每一个占据一个Block
,你就至少需要300MB的内存,当前来说,数百万的文件还是可行的,当扩展到数十亿时,对于当前的硬件水平来说就无法实现了。还有一个问题就是,因为Map task
的数量是由splits来决定的,所以用MR
处理大量小文件时,就会产生过多的Maptask
,线程管理开销将会增加作业时间。举个例子,处理10000M
的文件,若每个split
为1M
,那么就会有10000
个maptasks
,会有很大的线程开销;若每个split
为100M
,则100
个Maptasks
,每个maptask
将会有更多的事情做,而线程的管理开销也将会减小很多。
不支持多用户写入及任意修改文件
一个文件只有一个写线程,不能多个线程同时读写,而且写操作只能在文件末尾完成,仅支持文件的追加(append),不支持修改。