我们正在尝试重新设计当前的数据管道，并思考Streaming是否可以替代数据移动。 RDBMS事件涉及对现有数据以及历史数据的INSERT，UPDATE和DELETE。所有这些事件都可以有密钥来唯一地识别它们。正确性和完整性很重要，在处理这些事件和延迟时可能会在某种程度上牺牲。即我们需要根据某些键处理微批处理中的事件，并且我们需要不再有该键的延迟事件（近似，启发式等等）。此外，此事件未订购。即key1，key2数据可以一起到达。在某些时候，key1的所有记录都将到达，而在其他时刻key2的所有数据都将到达。问题是如何以有意义的方式处理键控数据。再次完整性很重要。我们可以以增量累积结果，但在我们获得给定密钥的完整数据之前它将没有用。
我能想到的一种方法是使用no-sql store来存储使用主键作为行键的事件，并在no-sql存储上执行幂等更新。但我认为它还必须保持关键数据的状态改变并使其可供下游用户使用，以便他们知道哪些数据发生了变化。他们现在可以从no-sql商店读取这些数据。但现在问题是no-sql store是volatile，因此下游可能会处理不一致的数据。
另一种方法是不依赖于no-sql而是以某种方式从流中处理数据。我正在阅读流处理的一些概念，如固定滑动窗口，会话窗口，水印。但我看不出其中任何一个是否可以解决手头的问题。可能是我需要基于数据（键）和非对齐窗口 来自出版商的一些信号表明每批事件的完成情况？
答案 0 :(得分：0)
我把这个项目放在一边，但我在谷歌数据流，火花流和apache光束上经历了相当多的文档。 Storm和Apex在这一点似乎太复杂了。
像watermarks和triggers这样的概念看起来很有希望在窗口完成时以及何时开始处理时告诉您。我可以继续累积事件，直到我收到每个流的水印事件，告诉我开始处理。您可能需要更改这些事件的数据源或发布者才能发送此“事件完成”事件。这可能只是拼图的第一部分。获得事件的自定义窗口后，您可能需要在开始处理或更新/删除数据存储区中的条目之前完成这些事件并从数据存储区（hbase，cassandra）中提取其他数据;此外，如果您有更多的下游用户，那么您必须向下游传达在该自定义窗口或上游处理中完成的更改，因为您已经拥有该事件，因此可能不难为任何下游访问。您可能只需要对这些事件采用某种标准来识别多个消费者，即客户ID，交易ID，时间段等下行消息。