带闪烁的大时间窗口的流联接
我需要根据一个键连接两个事件源。事件之间的间隔最长可达1年（即具有id1的event1可能在今天到达，而来自第二个事件源的具有id1的相应event2可能在一年后到达）。假设我只想输出连接的事件输出。
我正在探索在RocksDB后端使用Flink的选项（我遇到了表API，它们似乎适合我的用例）。我找不到做这种长窗口连接的引用体系结构。我希望系统一天能处理大约2亿个事件。
关于处理这种长窗口连接的任何建议
相关：我也在探索使用Lambda和DynamoDB作为状态来进行流连接（相关问题）。我将使用管理的AWS服务，如果这个信息是相关的。
共有1个答案
这个用例的明显挑战是一年的大连接窗口大小和高摄取率，这可能导致巨大的状态大小。
这里的主要问题是这是否是1：1连接，即来自流a的记录是否与来自流B的记录完全（或最多）连接一次。这很重要，因为如果您有1：1连接，您可以在一个记录与另一个记录连接后立即将其从状态中删除，并且您不需要将其保留一整年。因此，您的状态仅存储尚未加入的记录。假设大多数记录都是快速加入的，那么您的状态可能会保持在合理的小状态。
如果您有一个1：1连接，那么Flink的表API（和SQL）的时间窗口连接和DataStream API的间隔连接就不是您想要的。它们被实现为M：N联接，因为每个记录都可能与另一个输入的多个记录联接。因此，它们保留了整个窗口间隔的所有记录，即在您的用例中保留了一年的记录。如果您有一个1：1的联接，您应该自己将联接实现为KeyedCoProcessFunction。
如果每个记录可以在一年内加入多次，那么就没有办法缓冲这些记录。在这种情况下，可以使用Flink的表API（和SQL）的时间窗口联接和DataStream API的间隔联接。
-
我正在运行一个简单的示例来测试基于EventTime的Windows。我能够生成带有处理时间的输出，但当我使用EventTime时，没有输出。请帮助我明白我做错了什么。
-
作业并行性（4,8,16):[自动生成源]-->[Map1]-->[滚动窗口(10s)]-->[Map2]-->[接收器] Flink窗口性能eps 4p、8p、16p 作业以上的性能最高达到了每秒50k+-左右，不管我如何将集群缩放成4-16的并行度。 闪烁性能无窗口4p、8p 我已经删除了窗口的逻辑，以消除瓶颈性能的应用程序逻辑，但似乎窗口仍然导致我的整个流性能下降，即使该窗口只是一个通过函数
-
有人能帮我理解一下在flink中的窗口（会话）是什么时候和如何发生的吗？或者样品是如何加工的？ 例如：假设定义的时间窗口是30秒，如果一个事件在t时间到达，另一个事件在t+30，那么这两个事件都将被处理，但是在t+31到达的事件将被忽略。 如果我说的不对，请纠正。 上面的问题是：如果一个事件在t时间到达，而另一个事件在t+3时间到达，是否还会等待整个30秒来汇总并最终确定结果？ DTO： ====
-
我是Flink的新手，需要方法的帮助。我有时间颗粒度为5分钟的事件流。我想通过调用rest API来获取事件的元数据，其中包含过去1小时数据点的历史事件，即过去12点（5分钟时间颗粒度）。 e、 g事件的时间戳为10:00、10:05、10:10、10:15等，因此如果我想获取时间戳为11:00的事件元数据，我将调用send发送所有时间戳为10:00、10:05、10:10、10:15的事件。。1
-
我正在阅读Flink示例CountWithTimestamp，下面是该示例的代码片段： 我的问题是，如果我删除onTimer中的if语句（收集未触摸的stmt），而代之以processElement开头的另一个if语句
-
我有一个flink任务，它使用带事件时间和水印的键控翻滚窗口来聚合数据。 我的问题是，flink是否保持着他已经关闭的窗口的状态？否则，我没有其他解释为什么属于以前从未打开过的窗口的事件会打开一个窗口而不会立即删除它。 假设我们的窗口是1小时，禁止自动关闭是10分钟 让我们举个例子: event1=（"2022-01-01T08:25:00Z"）= event2=（"2022-01-01T09:2