批处理系统中的输入是确定的，计算过程中可以通过计算的原子性来保证数据的一致性（如 Spark 中的 RDD 血缘）。
除了数据输入带来的挑战，流计算输出的数据会被实时消费，类似这样不同于批处理的应用场景，也给数据的一致性带来的诸多挑战，如出现 FO 后，是撤回之前发出的数据，还是是同下游进行协商实现一致性，都是需要考虑的。
恰好一次≠恰好一致
今天大多数流计算引擎用「Exactly-Once」去暗示用户：既然输入的数据不是静态集合而是会连续变化的，那对每一条消息「恰好处理」了一次，输出的数据肯定是一致的。上述逻辑的推导过程是没问题的，但并不严谨，因为 Exactly-Once 作为一个形容词，后面所连接的动词或者宾语被故意抹去了，不同的表达含义也会大相径庭。
Exactly-once State Consistency 只是表达了：流计算要求对状态的更新只提交一次到持久后端存储，但这里的状态一般不包括「输出到下游结果」，而仅指引擎内部的状态，譬如各个算子的状态、实时流的消费偏移等，流计算引擎内部状态变更的保证，并不能等价于从输入到输出的一致性，端到端一致性需要你自己关心。
在存在不确定性计算的流计算中，不确定性计算的（中间）结果可视为流计算引擎状态的一部分。从整体上看，任何一个时间点的引擎状态等于之前所有事件计算结果（中间结果和输出结果）的累计。
State(t) = OperatorState(t) + SourceState(t)
则定义流计算引擎的计算过程为，存在计算计算逻辑 F 使得：
F(E(t), Sink(t), State(t)) = Sink(t+1) + State(t)
。因此，我们将条件退化为可以通过事务的方式进行批量存储，这是因为事务的 ACID 特性能保证结果能以原子提交的方式作用于下游算子或者是外部的消息系统/数据库，在保证了结果（状态）一致性的前提下，能达到较高的吞吐率。
但由于「Strong Production」会对计算进行去重，因此即便进行了多次重算，但有且仅有一次重算的结果被输出给下游（下游算子或结果接受端），从整体上来看数据是满足一致性的，这也被称之为「Effective Determinism」。
Kafka Streams 是 Apache Kafka 0.10.0版本中包含的一个Java库，严格来讲并不算一个完整的流处理引擎，利用这个库，用户可以基于 Kafka 构建有状态的实时数据处理应用，更进一步地，Kafka Streams 需要数据输入源和输出均为 Kafka 消息队列。
Spark Streaming 只能保证引擎内部的处理逻辑是一致的，但是对于结果输出，则并没有做特别的抽象，因此如果我们希望实现端到端的一致性语义，则需要对自行维护和判断一些信息。
