hadoop - 原子 hadoop fs 移动

Question

在为我当前的一个项目构建基础架构时，我遇到了替换现有 HDFS 文件的问题。更准确地说，我想执行以下操作:

我们有几台机器(日志服务器)不断生成日志。我们有一台专用机器(日志预处理器)负责从日志服务器 ，对它们进行预处理并上传到我们的 Hadoop 集群的 HDFS。

预处理分为 3 个步骤:

1. 对于每个logserver:过滤(并行)收到的日志 block (输出文件大约60-80mb)
2. 合并(合并排序)第 1 步的所有输出文件并进行一些小的过滤(此外，30 分钟的文件合并为 1 小时的文件)
3. 使用来自外部数据库的当前映射，处理步骤#2 中的文件以获得最终日志文件，并将此文件放入 HDFS。

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

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

问题描述:

第 3 步中使用的映射会随着时间的推移发生变化，我们需要通过重新计算第 3 步并将旧的 HDFS 文件替换为新文件来反射(reflect)这些变化。此更新至少在过去 12 小时内以某种周期性(例如每 10-15 分钟)执行一次。请注意，如果 ma​​pping 已更改，则对同一输入文件应用 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 应用程序在启动(设置)期间都会选择具有最新版本的文件并使用它们。因此，即使正在进行某些更新，应用程序也不会遇到任何问题，因为没有输入文件被删除。

问题:

1. 您是否知道不使用这种复杂/丑陋的文件版本控制的更简单的方法来解决这个问题？

2. 某些应用程序可能会开始使用当前正在上传但尚未上传的 HDFS 文件(应用程序会在 HDFS 中看到此文件，但不知道它是否一致)。如果是 gzip 文件，这可能会导致映射器失败。你能告诉我如何处理这个问题吗？我知道对于本地文件系统我可以做类似的事情:

   cp infile/finaldir/outfile.tmp && mv/finaldir/output.tmp/finaldir/output

这是可行的，因为 mv 是一个原子操作，但我不确定 HDFS 是否属于这种情况。如果 HDFS 在传统的本地文件系统中有像 mv 这样的原子操作，您能指点一下吗？

提前致谢!

Answer 1

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

HDFS，直到 1.x，缺少原子重命名(它们是 脏 更新 IIRC)——但该操作通常被认为是“类似原子的”，并且从未给您遇到的特定场景带来问题在这里记住。您可以依赖它而不必担心部分状态，因为源文件已经创建并关闭。

HDFS 2.x 及更高版本支持正确的原子重命名(通过新的 API 调用)，它取代了早期版本的脏重命名。如果您使用 FileContext，这也是重命名的默认行为。 API。