我一直在学习hadoop，目前我正在尝试处理结构不太合理的日志文件 - 因为我通常用于M / R键的值通常位于顶部档案（一次）。所以基本上我的映射函数将该值作为键，然后扫描文件的其余部分以聚合需要减少的值。所以[假]日志可能如下所示：
## log.1
SOME-KEY
2012-01-01 10:00:01 100
2012-01-02 08:48:56 250
2012-01-03 11:01:56 212
.... many more rows
## log.2
A-DIFFERENT-KEY
2012-01-01 10:05:01 111
2012-01-02 16:46:20 241
2012-01-03 11:01:56 287
.... many more rows
## log.3
SOME-KEY
2012-02-01 09:54:01 16
2012-02-02 05:53:56 333
2012-02-03 16:53:40 208
.... many more rows
我想为每个键累积第3列。我有一个由几个节点组成的集群来运行这个工作，所以我被几个问题所困扰：
鉴于hadoop的HDFS在64Mb块中工作（默认情况下），并且每个文件都在群集上分布，我能确定正确的密钥与正确的数字匹配吗？也就是说，如果包含密钥的块位于一个节点中，并且包含该相同密钥（同一日志的不同部分）的数据的块位于不同的机器上 - 则M / R框架如何匹配这两个（如果在所有）？
对于所描述的文本日志，如何确定每个块的截止点？是在一行结束后，还是完全在64Mb（二进制）？它甚至重要吗？这与我的＃1有关，我担心的是正确的值与整个集群上的正确密钥相匹配。
M / R处理的最佳文件结构（如果有）是什么？如果一个典型的日志看起来像这样，我可能会更加担心：
A-DIFFERENT-KEY 2012-01-01 10:05:01 111
SOME-KEY 2012-01-02 16:46:20 241
SOME-KEY 2012-01-03 11:01:56 287
A-DIFFERENT-KEY 2012-02-01 09:54:01 16
A-DIFFERENT-KEY 2012-02-02 05:53:56 333
A-DIFFERENT-KEY 2012-02-03 16:53:40 208
...
但是，日志很大，将它们转换为上述格式会非常昂贵（时间）。我应该担心吗？
分配的作业是否只有一个JobClient处理整个文件？相反，如何在所有JobClient之间协调键/值？再一次，我试图保证我的阴暗日志结构仍能产生正确的结果。
答案 0 :(得分：1)
鉴于hadoop的HDFS在64Mb块中工作（默认情况下），并且每个文件都在群集上分布，我能确定正确的密钥与正确的数字匹配吗？也就是说，如果包含密钥的块位于一个节点中，并且包含该相同密钥（同一日志的不同部分）的数据的块位于不同的机器上 - 则M / R框架如何匹配这两个（如果在所有）？
键和值的映射方式取决于InputFormat类。 Hadoop有几个InputFormat类，也可以定义自定义的InputFormat类。
如果使用FileInputFormat，则映射器的键是文件偏移量，值是输入文件中的行。在大多数情况下，忽略文件偏移量，并且映射器处理输入文件中的一行。因此，默认情况下，日志文件中的每一行都是映射器的值。
可能存在如OP中的日志文件中的相关数据可能跨块分割的情况，每个块将由不同的映射器处理，并且Hadoop不能将它们相关联。一种方法是让单个映射器使用FileInputFormat＃isSplitable方法处理整个文件。如果文件太大，这不是一种有效的方法。
对于所描述的文本日志，如何确定每个块的截止点？是在一行结束后，还是完全在64Mb（二进制）？它甚至重要吗？这与我的＃1有关，我担心的是正确的值与整个集群上的正确密钥相匹配。
默认情况下，HDFS中的每个块都是64MB大小，除非文件大小小于64MB或者修改了默认块大小，否则不考虑记录边界。输入中的某些部分可以在一个块中，其余部分在另一个块中。 Hadoop理解记录边界，因此即使记录（行）跨块分割，它仍将仅由单个映射器处理。为此，可能需要从下一个块进行一些数据传输。
分配的作业是否只有一个JobClient处理整个文件？相反，如何在所有JobClient之间协调键/值？再一次，我试图保证我的阴暗日志结构仍能产生正确的结果。
不完全清楚查询是什么。建议通过一些教程并回过头来查询。