在Beam文档中，建议与withProcessingTime一起使用withLogAppendTime。为什么会这样呢？
答案 0 :(得分：2)
正如cricket_007所说，这取决于您的用例。
Beam中的关键概念之一是事件时间处理。也就是说，您可以根据服务（光束管道）何时接收数据来定义数据处理逻辑，而可以根据事件实际发生的时间（例如，用户实际点击广告的时间）来定义数据处理逻辑。当您的数据流可能包含延迟事件或无序事件时，这在流传输情况下很有帮助。 Beam使您可以处理这些情况。
例如如果您的管道具有执行“在2018年10月23日下午1点至下午2点之间发生的汇总事件” 之类的步骤，那么，如果实际发生在1.30pm的事件迟到（例如在3.30pm ）由于某些网络延迟或其他原因？在基于处理时间的方法中，可能会在下一个窗口（例如“下午2时至下午3时”）中说明此延迟事件。但是，您的业务逻辑很有可能希望重新计算“下午1点到下午2点”的原始聚合，而不是在另一个聚合中使用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/
答案 1 :(得分：0)
偏好事件时间处理的几个原因：
您以后可以重做处理-例如，修复错误，进行更改或测试另一种方法。能够在实时流和历史流上使用完全相同的代码使事情变得更容易。
一致的确定性行为-如果通过相同的代码运行相同的数据，则将获得相同的结果。处理时间不是这种情况。同样，这使某些事情（例如测试）变得更容易。