Question

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

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

预处理分3个步骤完成：

为每个 logserver ：过滤（并行）接收的日志块（输出文件大约为60-80mb）
合并（合并 - 排序）来自step1的所有输出文件并进行一些小的过滤（另外，30分钟的文件合并为1小时的文件）
使用外部数据库的当前映射，处理步骤＃2中的文件以获取最终日志文件并将此文件放入HDFS。

最终日志文件将用作在HADOOP集群上运行的多个periodoc HADOOP应用程序的输入。在HDFS中，日志文件存储如下：

hdfs:/spool/.../logs/YYYY-MM-DD.HH.MM.log

问题描述：

步骤3中使用的映射会随着时间的推移而发生变化，我们需要通过重新计算step3并用新的HDFS文件替换旧的HDFS文件来反映这些变化。此更新至少在过去12小时内以一定的周期（例如每10-15分钟）执行。请注意，如果映射已更改，则对同一输入文件应用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＆amp;＆amp; mv /finaldir/output.tmp / finaldir / output

这是有效的，因为 mv 是一个原子操作，但是我不确定这是否是HDFS的情况。如果HDFS在传统的本地文件系统中有像mv一样的原子操作，请问一下吗？

提前致谢！

Answer 1

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

HDFS，高达1.x，缺少原子重命名（它们脏更新IIRC） - 但操作通常被认为是“类似原子的”并且从未给出具体情况的问题记在这里。您可以依赖此而不必担心部分状态，因为源文件已经创建并关闭。

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

原子hadoop fs移动

问题描述：

问题：

1 个答案: