我想知道是否有人可以解释分布式缓存在Hadoop中的工作原理。我正在多次运行一个作业，每次运行后我都注意到每个节点上的本地分布式缓存文件夹的大小都在增加。
多个作业是否有办法在分布式缓存中重用相同的文件？或者分布式缓存仅在任何单个作业的生命周期内有效吗？
我感到困惑的原因是Hadoop文档提到“DistributedCache跟踪缓存文件的修改时间戳”，所以这让我相信如果时间戳没有改变，那么它不需要重新缓存或重新将文件复制到节点。
我使用以下方法将文件成功添加到分布式缓存中：
DistributedCache.addFileToClassPath(hdfsPath, conf);
答案 0 :(得分：2)
DistributedCache使用引用计数来管理缓存。 org.apache.hadoop.filecache.TrackerDistributedCacheManager.CleanupThread负责清理引用计数为0的CacheDirs。它将每分钟检查一次（默认时间为1分钟，您可以通过“mapreduce.tasktracker.distributedcache.checkperiod”设置它。）
当Job完成或失败时，JobTracker会向TaskTrackers发送org.apache.hadoop.mapred.KillJobAction。然后，如果TaskTracker收到KillJobAction，它会将操作放到tasksToCleanup。在TaskTracker中，有一个名为taskCleanupThread的后台线程，它接受来自tasksToCleanup的操作并进行清理工作。对于KillJobAction，它将调用purgeJob来清理Job。在此方法中，它将减少此作业使用的引用计数（rjob.distCacheMgr.release();）。
以上分析基于hadoop-core-2.0.0-mr1-cdh4.2.1-sources.jar。我还检查了hadoop-core-0.20.2-cdh3u1-sources.jar，发现这两个版本之间有一点点差异。例如，org.apache.hadoop.filecache.TrackerDistributedCacheManager.CleanupThread中没有0.20.2-cdh3u1。初始化作业时，TrackerDistributedCacheManager将检查是否有足够的空间来放置此作业的新缓存文件。如果没有，它将删除具有0引用计数的缓存。
如果您使用的是cdh4.2.1，则可以增加“mapreduce.tasktracker.distributedcache.checkperiod”以使清理工作延迟。然后，增加了多个作业使用相同分布式缓存的概率。
如果您使用的是cdh3u1，则可以增加缓存大小的限制（“local.cache.size”，默认值为10G）和缓存的最大目录（“mapreduce.tasktracker.cache.local.numberdirectories”，默认值是10000）。这也可以应用于cdh4.2.1。
答案 1 :(得分：0)
如果仔细观察this book says，是否存在分布式缓存中可存储内容的限制。默认情况下，它是10GB（可配置）。同时在群集中运行多个不同的作业。此外，Hadoop类型保证文件在单个作业的缓存中保持可用，因为它由tasktracker为访问缓存中的文件的不同任务完成的引用计数维护。在您的情况下，对于后续作业，文件可能不在那里，因为它们已被标记为删除。
如果您在任何地方不同意，请纠正我。我很乐意进一步讨论这个问题。
答案 2 :(得分：0)
您应该可以通过DistributedCache API而不是“-libjars”
来完成此操作