Google Dataflow / Apache Beam Python - 来自PCollection的Side-Input会导致性能下降

Question

我们使用Python SDK在google dataflow中运行日志文件解析作业。 数据分布在几百个日常日志中，我们通过云存储中的文件模式读取这些日志。 所有文件的数据量约为5-8 GB（gz文件），总共为500-8,000万行。

loglines = p | ReadFromText('gs://logfile-location/logs*-20180101')

此外，我们有一个简单的（小）映射csv，它将logfile条目映射到人类可读的文本。 有大约400行，5 kb大小。

例如，带有[param = testing2]的日志文件条目应映射到最终输出中的“客户请求的14天免费产品试用”。

我们在一个简单的beam.Map和sideinput中执行此操作，如下所示：

customerActions = loglines | beam.Map(map_logentries,mappingTable)

其中map_logentries是映射函数，mappingTable是映射表。

但是，这只有在我们通过open（）/ read（）读取本机python中的映射表时才有效。 如果我们通过ReadFromText（）利用光束管道做同样的事情，并将生成的PCollection作为侧输入传递给Map，如下所示：

mappingTable = p | ReadFromText('gs://side-inputs/category-mapping.csv')    
customerActions = loglines | beam.Map(map_logentries,beam.pvalue.AsIter(mappingTable))

性能完全降低到每秒约2-3项。

现在，我的问题：

1. 为什么性能会如此糟糕地破坏，将PCollection作为侧输入传递会出现什么问题呢？
2. 如果可能不建议使用PCollections作为侧输入，那么应该如何构建诸如需要可以/不应该硬编码到映射函数中的映射的管道？

对我们来说，映射确实经常发生变化，我需要找到让“普通”用户提供它的方法。 我们的想法是在云存储中提供映射csv，并通过ReadFromText（）将其简单地合并到管道中。 在本地阅读它涉及向工人提供映射，因此只有技术团队才能做到这一点。

我知道侧输入存在缓存问题，但肯定这不适用于5kb输入。

上面的所有代码都是伪代码来解释问题。 任何想法和想法都将受到高度赞赏！

Answer 1

对于更有效的侧输入（小到中等大小），您可以使用beam.pvalue.AsList(mappingTable)因为AsList导致Beam实现数据，因此您确定将获得该pcollection的内存列表。

旨在用于side-argument规范---与使用AsSingleton和AsIter的地方相同，但强制将此PCollection的实现作为列表。

来源： https ： //beam.apache.org/documentation/sdks/pydoc/2.2.0/apache_beam.pvalue.html?highlight=aslist#apache_beam.pvalue.AsList

Answer 2

1. 代码看起来很好。 但是，由于mappingTable是一个映射，不会beam.pvalue.AsDict更适合您的用例吗？

2. 您的mappingTable足够小，因此侧输入是一个很好的用例。 鉴于mappingTable也是静态的，你可以从GCS加载start_bundle您的功能DoFn 。 有关更多详细信息，请参阅此帖子的答案。 如果mappingTable变得非常大，您还可以考虑将map_logentries和mappingTable转换为键值对的PCollection ，并使用CoGroupByKey将它们连接起来。