正如cricket\u007所说，这取决于您的用例。
beam的关键概念之一是事件时间处理。也就是说，您可以定义数据处理逻辑，而不是根据服务（beam管道）何时接收数据，而是根据事件实际发生的时间（例如，用户实际单击广告的时间）。当数据流可能包含延迟或无序事件时，这有助于流式处理。梁允许你处理这些案件。
e、 g.如果您的管道有一个类似于“2018年10月23日下午1点到下午2点之间发生的聚合事件”的步骤，那么如果实际发生在下午1点30分的事件由于网络延迟或其他原因而迟到（比如下午3点30分），会发生什么情况？在基于时间的处理方法中，这个延迟事件可能会在下一个窗口（例如“下午2点到3点”）中被考虑。但是，您的业务逻辑很有可能希望重新计算“1pm到2pm”的原始聚合，而不是在另一个聚合中使用late事件。处理这样的业务案例是事件时间处理的主要原因。
但是，您可能对在业务逻辑中处理该问题不感兴趣，例如，如果您不执行任何窗口/聚合（例如，基本etl），或者您根本没有最新的数据（例如，当您从现有文件中读取数据时），或者您的业务逻辑根本不关心它，或者事件很少，并且传递足够可靠，或者您可能在事件数据中没有可靠的时间戳。。。因此，您可以选择使用处理时间来代替。所有这些都取决于您的业务逻辑需要如何处理数据。
事件时间戳是在beam中的事件源附近分配的（通常在io中），因此在kafka的情况下，您可以选择事件时间戳的来源：https://beam.apache.org/releases/javadoc/2.8.0/org/apache/beam/sdk/io/kafka/timestamppolicy.html . 其他源可以使用其他方式为事件分配时间戳（例如，pubsubio可以读取消息属性中指定的时间戳）。
我建议您浏览一下这里的演示文稿，它们会更深入地探讨这个主题：https://beam.apache.org/documentation/resources/

选择事件时间处理的几个原因：
您可以稍后重新进行处理——例如，修复bug、进行更改或测试另一种方法。能够在实时流和历史流上使用完全相同的代码使事情变得更容易。
一致的、确定性的行为——如果您通过相同的代码运行相同的数据，您将得到相同的结果。处理时间并非如此。同样，这使得一些事情（比如测试）更容易。