查找与mapPartitions与类型的字典

火花的性能比较，是能够更好地partitionBy后使用lookup从性能的角度来看，对像：查找与mapPartitions与类型的字典

sc.parallelize(range(4000000))         \ 
    .mapPartitions(lambda l: [ dict([ (i,i) for i in l ]) ]) \ 
    .map(lambda d: d.get(33, None))       \ 
    .collect()

我的目的是模拟与快速查找分布式哈希映射。

来源

2015-08-25 FallingSkies

我在这里看不到分布式HashMap。您正在创建字典的RDD，然后尝试从字典中获取33元素... – eliasah

eliasah正确，我试图模拟一个，而不是构建一个。 – FallingSkies

RDD已经发布，并有它自己的哈希函数，所以你想模拟什么？当然，你想做什么不清楚，没有冒犯。 – eliasah

是否使用partitionBy然后lookup或为每个分区创建一个存储所有发生元素的HashMap强烈依赖于您的数据。取决于关键基数和数据分布，前者或后者的解决方案可能是有利的。

但是，在一般情况下，我会避免经常使用lookup，因为它是分区大小的线性操作。当您在分区数据上调用lookup时，它将完全遍历相应的分区以查找具有匹配键的所有元素。对于这种操作，具有更好查找复杂性的数据结构可能是有益的。

如果你真的想要实现一个分布式哈希映射，那么我想你应该划分你的数据，调用不同的数据，然后在哈希映射中插入剩余的数据以加快查询速度。

来源

2015-08-25 15:10:23

我的目标是通过快速查找来模拟分布式散列表。我编辑了我的问题来反映这一点。 – FallingSkies

@FailingSkies，我认为它强烈依赖于你的数据，例如密钥和数据分配的基数。此外，您必须正确指定语义。在你的解决方案中，如果某个分区包含具有相同密钥的元素，则不会获得与“lookup”相同的结果。如果你真的想实现一个分布式哈希映射，那么我想你应该划分你的数据，调用不同的数据，然后将其余数据插入哈希映射中以加快查询速度。 'lookup'的问题在于它是贯穿整个分区的线性操作。 –

谢谢，这是我正在寻找的答案，“查找是贯穿整个分区的线性操作”。请制定正确的答案，以便我可以给你学分。 – FallingSkies

查找与mapPartitions与类型的字典

回答

相关问题