来自以下几段文字——
(http://developer.yahoo.com/hadoop/tutorial/module2.html)，提到顺序可读的大文件不适合本地缓存。但我不明白本地是什么意思...
我认为有两个假设:一个是客户端缓存来自 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 读取的数据可能不会给您带来太多好处 - 在查询另一个块并最终将其替换到缓存中之前，您很可能不会对该数据进行缓存命中。
关于hadoop - 在本文的上下文中， "local caching of data"是什么意思？，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/10099816/