这是因为事务的 ACID 特性能保证结果能以原子提交的方式作用于下游算子或者是外部的消息系统/数据库，在保证了结果（状态）一致性的前提下，能达到较高的吞吐率。
引擎可以直接将存储后的结果发出去。回头再看端到端一致性数据处理语义的充分必要条件，显然 MillWheel 是符合「实时存储每一条中间和最终计算结果」这个条件的。
需要高可用、高吞吐的存储后端用于状态存储。因此，我们将条件退化为可以通过事务的方式进行批量存储，
当在 t ~ t + 1 时刻发生故障，恢复函数 R 可以屏蔽此次故障产生的副作用，让使用方认为没有故障发生，可以得到正确的 O(t+1)，显然，解决的思路是：将 E(t) 和 O(t) 作为输入，
由于 O(t) = Sink(t) + State(t) ，引擎内部很好实现幂等状态更新，若引擎下游系统也实现了数据幂等，当在 t ~ t + n 间内出现 FailOver 时，引擎可以通过重新计算 t ~ t + n 之间的所有值，直接输出给下游使用。
输出的结果 Sink(t)，e.g. Kafka 事务消息，但是在结果的存储方式上各有所不同，下面我们来看一看目前业界主流的几个流计算引擎的设计考量。
这里会有很多技术上的挑战，这里稍微举几个例子。
譬如，需要有稳定且高吞吐的存储后端用于结果存储，Google 内部的 BigTable 发挥了其作用。
举例：Kafka Streams 的输出后端需要是 Kafka，以配合在事务提交过程中，屏蔽部分已输出至下游（被 Kafka Broker 持久化），但还不满足事务隔离性的消息（read_committed 级别），
2、Spark Streaming 只有一个「epoch」，而 Flink 可以有多个 「epoch」并行存在。基于上述两点原因，Flink 的数据处理的端到端延迟要小得多，但这两种引擎幂等输出能实现一致性的本质是相似的。
然而在实际使用过程中，许多人对可观测性的关注，主要集中在系统上线之后。这当然是没有问题的，但实际上，从一个系统开发开始，
