【问题标题】:Wikipedia pages co-edit graph extraction using Hadoop维基百科页面使用 Hadoop 共同编辑图形提取
【发布时间】:2013-02-01 15:54:25
【问题描述】:

我正在尝试使用 hadoop 构建维基百科共同编辑页面的图表。原始数据包含编辑列表,即每次编辑有一行告诉谁编辑了什么:

# revisionId pageId userId
1 1 10
2 1 11
3 2 10
4 3 10
5 4 11

我想提取一个图表,其中每个节点都是一个页面,如果至少有一个编辑器编辑了两个页面(同一个编辑器),那么两个页面之间就有一个链接。对于上面的示例,输出将是:

# edges: pageId1,pageId2
1,2
1,3
1,4
2,3

我远不是 Map/Reduce 方面的专家,但我认为这必须通过两个工作来完成:

  1. 第一个作业为每个用户提取已编辑页面的列表。

    # userId pageId1,pageId2,...
    10 1,2,3
    11 1,4
    
  2. 第二个作业采用上面的输出,并简单地生成每个用户编辑的所有页面对(因此这些页面已由同一用户编辑,因此将在图表中链接)。作为奖励,我们实际上可以计算每个页面有多少用户共同编辑,以获得每个边缘的权重。

    # pageId1,pageID2 weight
    1,2 1
    1,3 1
    1,4 1
    2,3 1
    

我使用 Hadoop 实现了这一点,它可以工作。问题是第二个工作的map阶段真的很慢(其实前30%还可以,但是之后就慢了很多)。我想出的原因是因为一些用户编辑了很多页面,映射器必须生成很多这些对作为输出。因此,Hadoop 必须溢出到磁盘,从而使整个事情变得非常缓慢。

因此我的问题如下:

  1. 对于那些在 Hadoop 方面比我有更多经验的人:我做错了吗?有没有更简单的方法来提取这张图?
  2. 磁盘溢出会是第二个作业的映射阶段很慢的原因吗?我怎样才能避免这种情况?

作为一个侧节点,它运行良好,只需少量编辑样本。只有 GB 的数据才会变慢。

【问题讨论】:

    标签: hadoop mapreduce wikipedia


    【解决方案1】:

    显然,这是一个被称为组合/互相关/共现的常见问题,有两种模式可以使用 Map/Reduce、Pairs 或 Stripes 来解决它:

    我在问题中提出的方法是配对方法,它通常会生成更多数据。条纹方法从组合器中受益更多,并且在我的情况下提供了更好的结果。

    【讨论】:

      猜你喜欢
      • 2016-10-11
      • 1970-01-01
      • 2016-08-04
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 2010-12-26
      • 1970-01-01
      相关资源
      最近更新 更多