【发布时间】：2012-09-26 21:02:11
【问题描述】：
在为我当前的一个项目构建基础架构时，我遇到了替换现有 HDFS 文件的问题。更准确地说，我想做以下事情：
我们有几台机器（日志服务器）不断生成日志。我们有一台专用机器（log-preprocessor）负责从log-servers接收日志块（每个块的长度约为30分钟，大小为500-800 mb） strong>，对它们进行预处理并上传到我们 Hadoop 集群的 HDFS。
预处理分三步完成：
- 对于每个 logserver：过滤（并行）接收到的日志块（输出文件约为 60-80mb）
- 合并（合并排序）步骤 1 中的所有输出文件并进行一些小过滤（此外，将 30 分钟的文件合并为 1 小时的文件）
- 使用外部数据库中的当前映射，处理步骤#2 中的文件以获得最终日志文件，并将此文件放入 HDFS。
最终日志文件将用作在 HADOOP 集群上运行的几个 periodoc HADOOP 应用程序的输入。在 HDFS 中，日志文件的存储方式如下：
hdfs:/spool/.../logs/YYYY-MM-DD.HH.MM.log
问题描述：
第 3 步中使用的 映射 会随着时间而变化，我们需要通过重新计算第 3 步并用新的 HDFS 文件替换旧的 HDFS 文件来反映这些变化。至少在过去 12 小时内以某种周期性（例如每 10-15 分钟）执行此更新。请注意，如果 mapping 发生了变化，在同一个输入文件上应用 step3 的结果可能会有很大不同（它不仅仅是先前结果的超集/子集）。所以我们需要覆盖 HDFS 中的现有文件。
但是，我们不能只执行 hadoop fs -rm 然后 hadoop fs -copyToLocal 因为如果某些 HADOOP 应用程序正在使用临时删除的文件应用程序可能会失败。我使用的解决方案 - 在旧文件附近放置一个新文件，这些文件具有相同的名称但不同的后缀表示文件的版本。现在布局如下：
hdfs:/spool/.../logs/2012-09-26.09.00.log.v1
hdfs:/spool/.../logs/2012-09-26.09.00.log.v2
hdfs:/spool/.../logs/2012-09-26.09.00.log.v3
hdfs:/spool/.../logs/2012-09-26.10.00.log.v1
hdfs:/spool/.../logs/2012-09-26.10.00.log.v2
任何 Hadoop 应用程序在启动（设置）期间都会选择具有最新版本的文件并使用它们。因此，即使正在进行一些更新，应用程序也不会遇到任何问题，因为没有删除输入文件。
问题：
你知道一些更简单的方法来解决这个问题，它不使用这种复杂/丑陋的文件版本控制吗？
-
某些应用程序可能开始使用当前正在上传但尚未上传的 HDFS 文件（应用程序在 HDFS 中看到此文件但不知道它是否一致）。如果是 gzip 文件，这可能会导致映射器失败。你能建议我如何处理这个问题吗？我知道对于本地文件系统，我可以执行以下操作：
cp infile /finaldir/outfile.tmp && mv /finaldir/output.tmp /finaldir/output
这是可行的，因为 mv 是一个原子操作，但我不确定 HDFS 是否属于这种情况。如果 HDFS 在传统的本地文件系统中具有像 mv 这样的 atomic 操作，您能否建议？
提前致谢！
【问题讨论】：
标签： hadoop atomic hdfs infrastructure