摘自以下正文——
(http://developer.yahoo.com/hadoop/tutorial/module2.html),它提到顺序可读的大文件不适合本地缓存。但我不明白本地是什么意思...
我认为有两个假设:一是Client缓存来自HDFS的数据,二是datanode将hdfs数据缓存在其本地文件系统或内存中,以便客户端快速访问。有谁可以解释更多吗?多谢。
但是,虽然 HDFS 具有很强的可扩展性,但其高性能设计也限制了它
特定类别的应用程序;它不像 NFS 那样通用。有一个大
使用 HDFS 做出的额外决策和权衡的数量。尤其:
假设使用 HDFS 的应用程序执行长顺序流读取
文件。 HDFS经过优化,提供流式读取性能;这是以牺牲
随机查找文件中任意位置的时间。
数据会被写入HDFS一次,然后被多次读取;文件更新
关闭后不再受支持。 (Hadoop 的扩展将提供
支持将新数据附加到文件末尾;它计划被纳入
Hadoop 0.19 但尚未可用。)
由于文件的大小以及读取的顺序性,系统不会
不提供机制数据本地缓存。缓存的开销已经足够大了
该数据应该简单地从 HDFS 源重新读取。
假设单个机器经常发生故障,无论是永久性的还是
间歇性地。集群必须能够承受多个系统的完全故障
机器,可能有很多机器同时发生(例如,如果一个机架同时发生故障)。
虽然性能可能会与丢失的机器数量成比例地下降,但系统作为一个
整体不应变得过于缓慢,也不应丢失信息。数据复制
策略来解决这个问题。
任何真正的 Mapreduce 作业可能都会处理来自 HDFS 的 GB(10/100/1000 秒)数据。
因此,任何一个映射器实例很可能会按顺序处理大量数据(典型的块大小为 64/128/256 MB,具体取决于您的配置)(它将从头开始读取整个文件/块)结束。
在同一台机器上运行的另一个映射器实例也不太可能在不久的将来随时再次处理该数据块,更重要的是,多个映射器实例也将在任何一个 TaskTracker 中与该映射器一起处理数据(希望有一个相当一部分是数据的实际物理位置的“本地”,即数据块的副本也存在于映射器实例运行的同一台机器上)。
考虑到所有这些,缓存从 HDFS 读取的数据可能不会给您带来太多好处 - 在查询另一个块并最终在缓存中替换它之前,您很可能不会对该数据进行缓存命中。
本文内容由网友自发贡献,版权归原作者所有,本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容,请联系:hwhale#tublm.com(使用前将#替换为@)