管道使用案例 此管道从30个GCS目录中读取json文件，每天表示为一个目录，因此读取过去30天的数据（140亿行）。对该数据进行一些处理并作为json文件输出到GCS。
热键问题： 引入热键问题是因为我们的业务逻辑需要对最近几天的数据（约4亿行）进行大量处理，相对于过去29天的数据。因此，如果管道今天运行，它将读取过去一个月的数据，30天后的数据回到昨天需要最少的处理。虽然今天的数据需要大约100倍的处理。由于我们处理过去一个月的所有数据，包括今天的一步，因此在处理今天的数据时会生成热键
在最初启动时的管道中，我注意到在管道处理了超过29天的数据并开始处理今天的数据吞吐量急剧下降（每秒数量惊人的行数）后，吞吐量非常高（每秒百万行）。由于数据流为每个输入（30个目录）分配工作节点，因此需要处理最多的输入会因为未并行化到所有工作节点而停止。虽然大多数工作节点用于处理29天的数据。
尝试的解决方案：
GroupBy这一步骤执行得非常慢，以至于性能最差，而不是热键问题。Reshuffle.createRandomKey步骤以创建混洗以将高处理行与低处理混合（2018-05-03_04_50_16-6027709731981798472）重新执行此步骤的速度非常慢，以至于性能最差，而不是热键问题这里的一个常见建议是启用随机播放模式。我们过去曾试图这样做。虽然shuffle模式确实提高了GroupByKey步的性能，但是当输出写入GCS时，它显着降低了性能。