目标
我的任务是在导入文件中找到重复的条目，并在稍后阶段将这些导入文件的重复条目与全局数据库进行比较。文件中的数据是个人信息，如姓名、电子邮件、地址等。这些数据并不总是完整的，而且常常拼写错误。
这些文件将由外部用户通过web表单上传。用户需要在流程完成时得到通知，并且他/她必须能够下载结果。
另外，为了解决这个任务，我需要评估apachebeam是否适合这个任务。
可能的解决方案
我考虑了以下问题：导入文件被上传到s3，管道要么以pub-sub事件（kafka队列）的形式获取文件位置，要么监视s3（如果可能）以获取传入文件。
然后通过一个ptransform读取文件，并将每一行推入一个pcollection。作为一个附带的输出，我会更新一个搜索索引（在redis或类似的系统中）。下一个转换将访问搜索索引，并尝试查找匹配项。最终结果（唯一值、重复值）将写入到s3的输出文件中，并为下一次导入清除索引。
问题
这种方法有意义吗？它是beam的惯用方法吗？
光束适合这种加工吗？
以上有什么改进建议吗？
我需要跟踪文件名/id，以便在最后通知用户。如何在管道中移动这些元数据。我是否需要为元数据和负载创建一个“信封”对象，并在我的pcollection中使用这个对象？
传入的文件是无边界的，但文件内容本身是有边界的。有没有一种方法可以用惯用的方式找出文件处理的结尾？
1条答案
按热度按时间mzsu5hc01#
这种方法有意义吗？它是beam的惯用方法吗？
这是一个主观问题。一般来说，我会说不，这不是apachebeam的惯用用法。apachebeam是一个定义etl管道的框架。beam编程模型没有用于消除重复数据的意见或内置功能。重复数据消除是通过实现（您编写的业务逻辑代码）或数据存储的功能（唯一约束，在sql或键/值存储中选择distinct）实现的。
光束适合这种加工吗？
是的，光束是合适的。
以上有什么改进建议吗？
我不建议在管道中间编写搜索索引。通过这样做，然后尝试在下面的转换中读回数据，您已经有效地在dag中创建了一个循环。管道可能会受到竞争条件的影响。有两个独立的管道就不那么复杂了—一个用于写入搜索索引（重复数据消除），另一个用于写回s3。
我需要跟踪文件名/id，以便在最后通知用户。如何在管道中移动这些元数据。我是否需要为元数据和负载创建一个“信封”对象，并在我的pcollection中使用这个对象？
是的，这是一种方法。我相信您可以通过readablefile类获得文件元数据。
传入的文件是无边界的，但文件内容本身是有边界的。有没有一种方法可以用惯用的方式找出文件处理的结尾？
我不确定，但我不认为这是可能的管道执行流模式。