原子hadoop fs移动

Question

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

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

预处理分3个步骤完成:

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

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

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

问题描述:

步骤3中使用的映射随时间而变化,我们需要通过重新计算step3并用新的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应用程序在启动(设置)时都会选择具有最新版本的文件并使用它们.因此,即使正在进行某些更新,应用程序也不会遇到任何问题,因为没有删除任何输入文件.

问题:

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,它也是重命名的默认行为.