我已经开始学习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
我想为每个键累加第三列。我有一个由几个节点组成的集群在运行这个作业，所以我遇到了几个问题：
1.文件分发
假设hadoop的HDFS在64Mb块中工作（默认情况下），并且每个文件都分布在集群中，我能确定正确的密钥会与正确的数字匹配吗？也就是说，如果包含密钥的块在一个节点中，而包含同一密钥的数据的块（同一日志的不同部分）在不同的机器上，那么M/R框架如何匹配这两者（如果有的话）？
2.区块分配
对于所描述的文本日志，如何确定每个块的截止点？它是在一行结束之后，还是正好在64Mb（二进制）？这有关系吗？这与我的#1有关，我担心的是在整个集群中，正确的值与正确的键匹配。
3.文件结构
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
...
然而，日志是巨大的，将它们转换为上述格式将非常昂贵（时间）。我应该担心吗？
4.工作分配
作业的分配是否使得只有一个JobClient处理整个文件？相反，所有JobClients之间的键/值是如何协调的？再次，我试图保证我的阴暗的日志结构仍然能产生正确的结果。
假设hadoop的HDFS在64Mb块中工作（默认情况下），并且每个文件都分布在集群中，我能确定正确的密钥会与正确的数字匹配吗？也就是说，如果包含密钥的块在一个节点中，而包含同一密钥的数据的块（同一日志的不同部分）在不同的机器上，那么M/R框架如何匹配这两者（如果有的话）？
键和值的映射方式取决于InputFormat类。Hadoop有几个InputFormat类，还可以定义自定义InputFormat类。
如果使用FileInputFormat，则映射器的键是文件偏移集，值是输入文件中的行。在大多数情况下，文件偏移被忽略，并且作为输入文件中的一行的值由映射器处理。因此，默认情况下，日志文件中的每一行都将是映射程序的值。
可能会出现这样的情况，即OP中日志文件中的相关数据可能会被拆分到多个块中，每个块将由不同的映射器处理，Hadoop无法将它们关联起来。一种方法是让单个映射器使用FileInputFormat#isSplitable方法来处理整个文件。如果文件大小太大，这不是一种有效的方法。
对于所描述的文本日志，如何确定每个块的截止点？它是在一行结束之后，还是正好在64Mb（二进制）？这有关系吗？这与我的#1有关，我担心的是在整个集群中，正确的值与正确的键匹配。
HDFS中的每个块默认为64MB大小，除非文件大小小于64MB或默认块大小已被修改，否则不考虑记录边界。输入中的行的某些部分可以在一个块中，其余部分可以在另一块中。Hadoop了解记录的边界，所以即使一条记录（行）被分割成块，它仍然只能由一个映射器处理。为此，可能需要从下一个块进行一些数据传输。
作业的分配是否使得只有一个JobClient处理整个文件？相反，所有JobClients之间的键/值是如何协调的？再次，我试图保证我的阴暗的日志结构仍然能产生正确的结果。
不太清楚查询是什么。我建议你看一些教程，然后再回来查询。