为什么“group by”比我的自定义CombineFn或asList（）慢得多？

Question

错误地，几个月前，我使用以下逻辑实际上实现了与PCollectionView的asList（）方法相同的功能：

1. 我为我的收藏中的每个元素分配了一个“000”的虚拟键
2. 然后我在这个虚拟键上做了一个groupBy，这样我就可以在一个数组列表中获得所有元素的列表

当我的集合中只有大约200个元素时，上述逻辑工作正常。当我在5000个元素上运行时，它运行了几个小时，直到我最终杀死它。然后，我创建了一个自定义“CombineFn”，其中我基本上将所有元素放入我自己的本地哈希表中。这有效，甚至在我的5000元素情况下，它在大约一分钟或更短的时间内运行。同样，我后来才知道我可以使用asList（）方法，并且在不到一分钟的时间内也可以运行。然而，令我担忧的是 - 以及我不理解的 - 是为什么这个小组需要花费很长时间才能运行（即使只有200个元素需要花费超过几秒钟）而且5000个它运行了几个小时而似乎没有完成任何东西。

我按代码查看了这个组，它似乎做了很多我不太明白的步骤......它是否与group by语句尝试在集群中运行的事实有某种关系？或者它可能与使用有效的编码器有关？还是我错过了别的什么？我问的原因是在某些情况下我被迫使用group by语句，因为数据集太大而无法放入任何一台计算机的RAM中。但是，我担心我不理解如何正确使用group by语句，因为它看起来很慢......

Answer 1

有一些因素可能导致性能下降。首先，如果您使用的是SerializableCoder，那么速度非常慢，AvroCoder可能会更适合您。其次，如果你在GBK之后迭代你的ParDo中的Iterable，如果你有足够的元素，你将超过缓存并最终多次获取相同的数据。如果您需要这样做，将数据显式放入容器中会有所帮助。 CombineFn和asList方法都可以为您完成此任务。