尽管许多公司都在努力启用他们的实时数据，但越来越多的公司实际上正在运行生产、流式工作负载。当我与客户一起运行他们的工作负载时，我意识到通过正确的准备可以避免某些问题。

我提倡尽可能使用流媒体。在 Flink 上开始使用流媒体变得越来越容易——您可以使用 FlinkSQL 或像Ververica这样的 SaaS 平台。即使开始很简单，事情也会变得复杂。

当事件时间处理面对现实

事件时间处理是一个引人入胜的概念——在事件中嵌入时间可以实现查看数据的新方法。事件何时加载到系统并不重要——您总是可以将它与正确的时间窗口相关联。机器停机一个小时？没问题！只需重新启动它并推送事件 - 结果最终将是正确的。

好的，这就是理论。如果你从技术角度来看——这并不简单。您应该非常了解水印及其对工作的影响。所以另一方面，你真的不能永远等待。好吧，理论上你仍然会求助于后期数据处理。这并不像听起来那么容易。

例如，默认时间窗口触发器将为每个延迟事件触发窗口。想象一下，有一个每秒处理数百万个事件的管道，其中一个生产者被卡住了一个小时。您的系统将充斥着通常计算起来非常昂贵的延迟数据。

您可以通过实现自定义窗口触发器来解决这个问题——尽管这需要编写一些自定义代码。因此，您不再编写纯 SQL 作业。

另一个可能被忽略的常见延迟数据问题是窗口状态缺少 TTL。如果您允许延迟 3 天，则在该时间段内创建的所有时间窗口的状态将被保留。之所以如此，是因为处理延迟数据的默认策略是合并窗口（并且需要此工作状态）。

在处理时间时，您还应该注意空闲分区、无序间隔的后果——我们通常认为这是理所当然的事情。空闲分区实际上与后期数据处理密切相关。在这种情况下，只有一个明智的策略——撞水印。这再次可能导致数据延迟，以防事件应该在那里，但它们只是卡在上游生产者端的某个地方。