我已经开始学习 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 处理整个文件?相反,所有 JobClient 之间的键/值如何协调?再次,我试图保证我的可疑日志结构仍然会产生正确的结果。