我们计划使用apache flink和一个巨大的物联网设置。客户将向我们发送一些结构化的传感器数据（如传感器id、传感器类型、传感器值、时间戳）。我们无法控制每个客户何时发送这些数据，很可能是实时发送的，但我们无法保证。我们将所有事件存储在rabbitmq/kafka中。更新：我们可以假设每个传感器的事件是按顺序排列的。
在开始实施可能的流媒体管道之前，我们对以下挑战的解决方案感兴趣：
多窗口聚合
我们将所有原始传感器数据存储到cassandra中。此外，我们希望在多个时间窗口（例如15瑞典克朗、1分钟、15分钟、1小时、1天）上按传感器id聚合传感器数据。使用flink流媒体高效地实现所需输出的推荐方法是什么？
非常晚的数据
如前所述，我们无法控制 when 数据已发送。例如，客户可能遇到网络故障，因此数据可能会延迟到达。建议的处理方法是什么？如果我们只能通过传感器id来保证良好的水印（因为每个客户都有自己的时间/问题/失败），我们如何使用水印？我们可以添加一些允许的迟到时间（比如6-12小时左右），这是否可以用内存窗口存储中的flinks管理？在允许迟到之后会发生什么？我们是否应该将真正最新的数据存储到另一个kafka主题中，并连续进行批处理？最后，一些客户将收集到的传感器数据上传到csv文件中。本指南是否也适用于批处理方法？
未来数据
由于传感器配置错误（因为我们无法控制），当某个客户向我们发送的数据距离我们很远时，流会发生什么情况？
我们对你的建议很好奇。谢谢。
1条答案
按热度按时间6yjfywim1#
这是相当多的问题。我试着一一回答：
多窗口聚合
您可以构造级联窗口操作符的数据流，并在每个窗口之后分叉（以发出或进一步处理）结果。
非常晚的数据
问题似乎在于，有些数据可能“非常”晚到达，而不是按每个键的顺序到达。目前不可能使用每密钥水印。因此，所有事件的“逻辑时钟”都是相同的。flink允许的延迟定义了状态等待延迟到达数据的时间。如果数据延迟到达（在水印之后），但在允许的延迟内，则相应的状态仍然可用，并计算更新。如果事件太晚（晚于允许的延迟时间），则状态被丢弃，事件也被丢弃。允许的高迟到率意味着需要保持更多的状态。然而，这个问题原则上可以通过扩展来解决。对Kafka主题的后期数据处理也可以用flink来完成。此外，使用流处理器可以更好地连续处理周期性文件。批处理解决方案需要处理跨数据文件（外部化状态处理）、作业调度、错误处理。。。
未来数据
使用flink的水印机制，操作员总是转发其最高的水印（时间不能倒转），但将其水印计算为从所有输入通道接收的最小水印。所以除非你有未来所有频道的数据，否则你应该没事。未来的数据将被视为状态，并在时间到达“未来”时进行计算。这意味着，您不会丢失数据，但您可能需要等待相当长的一段时间，直到它被处理。
根据您的描述，我会考虑将聚合实现为键控流上的有状态flatmap操作符。假设每个传感器的数据按顺序到达，您可以在平面图（或平面图链，每个时间间隔一个）中进行必要的聚合。
这里的一个挑战是，在看到晚于聚合间隔的事件之前，您不知道何时关闭聚合。在具有全局有效水印的流中，即使没有接收到特定密钥的事件，时间也可以提前（并且窗口可以关闭）。
另一个问题是在传感器被移除的情况下移除状态。这不会被自动检测到。也许一个特殊的标记记录可以用来触发国家清理。