原子hadoop fs移动

在为我当前的一个项目构建基础设施时，我遇到了替换现有HDFS文件的问题。更准确地说，我想做以下几点：

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

我们有一些机器（日志服务器）在不断生成日志。我们有一台专用机器（日志预处理器），负责从日志服务器接收日志块（每个块长约30分钟，大小约500-800 mb），对其进行预处理并上传到Hadoop集群的HDFS

预处理分3步完成：

对于每个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分钟）执行此更新。请注意，如果映射已更改，则在同一输入文件上应用步骤3的结果可能会显著不同（它将不仅仅是以前结果的超集/子集）。因此，我们需要覆盖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 infle/finaldir/outfile.tmp和mv/finaldir/output.tmp/finaldir/output

这是有效的，因为mv是一个原子操作，但是我不确定HDFS的情况是否如此。如果HDFS在传统的本地文件系统中有像mv这样的原子操作，请您提供建议

---

提前谢谢

IMO，文件重命名方法绝对适合使用

高达1.x的HDFS缺少原子重命名（它们是脏更新IIRC）-但该操作通常被认为是“原子式”的，并且从来没有给您想到的特定场景带来问题。由于源文件已经创建并关闭，因此您可以依赖于此，而不必担心部分状态

HDFS 2.x以后的版本支持正确的原子重命名（通过一个新的API调用），该重命名已经取代了早期版本的脏重命名。如果使用API，这也是重命名的默认行为