让大家对流计算引擎的认识更为深入，为可能的流计算技术选型提供一些参考。文章主要分为三个部分：第一部分，会介绍流计算系统和一致性难题的本质；
正确认识流计算系统一致性的内在含义和其能力范畴，对我们构建正确且健壮的流计算任务至关重要。下面我会介绍几组概念，以便于大家更好地理解流计算系统的一致性。
进一步分析，每一次存储或者批量事务存储 O(t) 时，引擎到底做了什么？前面我们定义了 O(t) = Sink(t) + State(t) -> O(t) = Sink(t) + OperatorState(t) + SourceState(t) ，对于引擎来说
Kafka Streams 需要数据输入源和输出均为 Kafka 消息队列。
Kafka Streams 中的「结果」也以事务的方式批量持久化，但和 Flink 不同的是，这些结果是被写入不同的消息队列中：
即，任意的数据的处理都是「流（Stream）」 和「表（Table）」间的互相转换，其中流用来表征运动中的数据，表用来表征静止的数据：
上述逻辑的推导过程是没问题的，但并不严谨，因为 Exactly-Once 作为一个形容词，后面所连接的动词或者宾语被故意抹去了，不同的表达含义也会大相径庭。
流计算中的确定性指的是，给定相同的一组数据，重复运行多次或者打乱数据进入引擎的顺序，计算完成后将会输出相同的结果，否则就是非确定性计算。
在整个质量观测的生命周期中，除了各种各样的数据，我们也会涉及到各种各样的系统，例如 GitLab、sonarqube、Allure、JMeter、Jenkins、Travis CI、Argo CD 等等。
数据统一接入和管理
基于上述几个痛点，我们的解决方案是将这些异构的数据进行统一的存储和管理，如下图所示：
下面是另一个指标，可能随着系统的进化，新版本发布之后，该指标的值会发生一个陡增。此时如果是固定阈值告警的话，会将陡增之后的所有数据都认为是异常点，导致告警频繁触发。此时需要人为介入去调整阈值。
