为什么HDFS一次写入并多次读取？

Question

我是Hadoop的新学习者.

在阅读Apache HDFS时,我了解到HDFS是一次写入文件系统.其他一些发行版(Cloudera)提供了追加功能.了解这一设计决策背后的理性将是一件好事.在我看来,这种设计在Hadoop上创造了许多限制,使其适用于有限的一组问题(类似于日志分析的问题).

专家评论将帮助我更好地理解HDFS.

Answer 1

HDFS 对其文件和应用程序遵循一次写入、多次读取的方法。它假设 HDFS 中的文件一旦写入就不会被修改，尽管它可以访问“n”次（尽管未来版本的 Hadoop 也可能支持此功能）！目前，在 HDFS 中，任何时候都严格有一个写入器。这种假设支持高吞吐量数据访问，也简化了数据一致性问题。网络爬虫或 MapReduce 应用程序最适合 HDFS。

由于 HDFS 的工作原理是“一次写入，多次读取”，因此流式数据访问功能在 HDFS 中极为重要。因为 HDFS 设计更多是为了批处理而不是用户交互使用。重点是数据访问的高吞吐量而不是数据访问的低延迟。HDFS 关注的不是存储数据，而是如何以尽可能快的速度检索数据，尤其是在分析日志时。在 HDFS 中，读取完整数据比从数据中获取单个记录所花费的时间更重要。为了实现流数据访问，HDFS 忽略了一些 POSIX 要求。

http://www.edureka.co/blog/introduction-to-apache-hadoop-hdfs/

Answer 2

HDFS的设计有三个主要原因,

• HDFS的设计是通过盲目复制谷歌GFS的设计,该设计仅用于支持批量计算

• 除了批量计算之外,HDFS最初并不是用于任何事情

• 设计一个真正的分布式文件系统,可以支持高性能批处理操作以及实时文件修改是困难的,并且超出了HDFS原始实现者的预算和经验水平.

Hadoop无法构建为完全读/写文件系统.MapR FS证明了这一点.但是实现这样的事情远远超出了原始Hadoop项目的范围和功能,并且HDFS原始设计中的架构决策基本上排除了改变这种限制.关键因素是NameNode的存在,因为HDFS要求所有元数据操作(如文件创建,删除或文件长度扩展)通过NameNode进行往返.MapR FS通过完全消除NameNode并在整个集群中分发元数据来避免这种情况.

随着时间的推移,没有一个真正的可变文件系统变得越来越烦人,因为像Spark和Flink这样的Hadoop相关系统的工作负载越来越多地转向运营,接近实时或实时的操作.对这个问题的回应包括

• MapR FS.如上所述...... MapR实现了HDFS的全功能高性能重新实现,包括POSIX功能以及noSQL表和流API.该系统已在一些最大的大数据系统中运行多年.

• 库杜.Cloudera基本上放弃了在HDFS之上实现可行的突变,并宣布Kudu没有时间表可用于普遍可用性.Kudu实现了类似表格的结构,而不是完全通用的可变文件.

• Apache Nifi和商业版HDF.Hortonworks也在很大程度上放弃了HDFS,并宣布了他们的战略,即将应用程序分批(由HDFS支持)和流媒体(由HDF支持)孤岛.

• Isilon的.EMC将HDFS线路协议作为其Isilon产品线的一部分实施.这使得Hadoop集群可以拥有两个存储孤岛,一个用于基于HDFS的大规模,高性能,经济高效的批处理,另一个用于通过Isilon进行中等规模的可变文件访问.

• 其他.为解决HDFS的一次写入性质,有许多基本上已经不复存在的努力.这些包括KFS(Kosmix文件系统)等.这些都没有被大量采用.

Answer 3

尽管这种设计决策确实施加了限制，但 HDFS 的构建考虑了高效的流数据访问。引用Hadoop - 权威指南：

HDFS 的构建理念是：最有效的数据处理模式是一次写入、多次读取的模式。数据集通常是从源生成或复制的，然后随着时间的推移对该数据集执行各种分析。每次分析都将涉及数据集的很大一部分（如果不是全部），因此读取整个数据集的时间比读取第一个记录的延迟更重要。