我有一个 Flink 项目,它接收一个事件流,并执行一些逻辑来添加这个事件的标志,然后它会保存flag
一段eventID
时间以供其他系统重用或查询。
在这种情况下,数据量不会太多,而且需要有良好的可靠性,当然最好在使用前及时更新。
传统上,我们可以使用外部数据库来保存此类数据。但是在了解了 state 之后,我发现它似乎很有用,并且有很好的 backends 机制,并且可以查询。
所以我提出问题是为了更多地倾听你的论点和证据。
我有一个 Flink 项目,它接收一个事件流,并执行一些逻辑来添加这个事件的标志,然后它会保存flag
一段eventID
时间以供其他系统重用或查询。
在这种情况下,数据量不会太多,而且需要有良好的可靠性,当然最好在使用前及时更新。
传统上,我们可以使用外部数据库来保存此类数据。但是在了解了 state 之后,我发现它似乎很有用,并且有很好的 backends 机制,并且可以查询。
所以我提出问题是为了更多地倾听你的论点和证据。
我将我的最后两条评论移至此处作为答案,因为我意识到我实际上是在这样做。
好吧,那可能是 Uber 的主题演讲。但最重要的是,有些公司正在使用极大的状态来保存您需要有效执行计算的数据。
例如,我编写了一个程序,它接收具有唯一 ID 和值字段(int)的消息。然后我有一个有状态的函数,它由接收到的消息的 ID 键入,并且我收到的针对该 ID 的每条消息都将添加到一个有状态的值对象中,从而更新该 ID 的总数。如果需要,您可以创建一个有状态的列表对象来保存您收到的所有消息。另一种方法是使用专为快速读/写而设计的“新时代”数据库,如 Cassandra,来存储它。但是由于 I/O,这种方法有其自身的局限性(长话短说,Flink 和 Cassandra 可以快速处理大量数据,但网络带宽却不能)。
因此,将所有这些数据保持在 flink 中的状态可以很好地完成和使用,并且有很多好处。
我必须警告的一件事是,我不知道 Flink 的状态是否具有与 Cassandra 或 Kafka 相同的故障保护。而他们跨节点复制他们的数据,这样如果一个节点出现故障,那么其他节点可以处理所有事情并在重新启动时重新填充另一个节点。Flink 的状态可以存储在远程后端,如 s3 存储桶或 hdfs(参见:https ://ci.apache.org/projects/flink/flink-docs-release-1.4/ops/state/state_backends.html ),但是我不知道是否有复制状态。因此,如果状态全部存储在一个出现故障的节点上,如果它永远消失或备份在另一个节点上。这是需要更多研究的事情,因为这应该是您选择的重大决定。
希望至少能给你一些信息和一个关于要问什么问题的简要想法。