总之，如何我们后面再看到 Exactly-once XXX，一定要警惕引擎想要透露出什么信息。
端到端的数据一致性
端到端一致性（End-To-Ene Consistency），即将数据的输出也作为流计算引擎的一致性设计的一部分，正确的结果贯穿着这整个流计算应用的始终：从输入、处理过程、输出，每一个环节都需要保证其自身的数据一致性，同时在整个流计算流程中，作为整体实现了端到端的一致性。
在这个统一的理论框架下，批处理过程的一致性也可以纳入本文讨论的范畴中来。但无论是纯粹的流计算，还是上面统一的数据处理模型，我们都可以将流（批）数据处理的过程抽象为「读取数据-处理数据-输出数据」这样的三个部分，可用下面的无向图来表达，其中点代表数据加工逻辑，边表示数据流向，数据处理过程中的中间状态（State）一般需要做持久化存储。
进一步分析，每一次存储或者批量事务存储 O(t) 时，引擎到底做了什么？前面我们定义了 O(t) = Sink(t) + State(t) -> O(t) = Sink(t) + OperatorState(t) + SourceState(t) ，对于引擎来说，当出现 FailOver 时，都会通过 SourceState(t) 回拨数据源偏移量进行部分重算，即消息读取语义是 At-Least-Once 的，
后者对流计算流域的影响堪比20世纪初 GFS，BigTable 以及MapReduce 三篇论文对大数据的影响，后面 Google 又在 MillWheel 之上继续发展，开源了 Apache Bean 这个系统级的流批一体数据解决方案，因为 MillWheel 是更纯粹的「流计算」，所以我们重点来分析 MillWheel。
引擎中的每个节点都维护了以记录 ID 为主键的布隆过滤器，计算前都会通过此过滤器进行判断，若提示不存在则进行数据处理，如果存在，则需要二次校验。当然，MillWheel 在实际使用布隆过滤器，是做了若干改造的，这里就不具体展开了。
算子状态 OperatorState(t) ：计算中算子的 Changelog，也会写入单独的 Kafaka 队列中，该队列对用户透明；
输出结果 Sink(t) ：即用户配置的实际的输出队列，用于存放计算结果。
这里提到的 Spark Streaming 指的是原始的基于「Micro-batch，微批」的 Spark 流处理引擎，后面 Spark 又提出了Structured Streaming，使用 Continuous Processing mode 来替代「微批」解决延迟的问题，
微批类比 epoch。不同之处在于：1、Spark Streaming 在计算过程中的每一个 RDD 生成阶段都会有延迟，而 Flink 在计算过程中可以进行实时处理；2、Spark Streaming 只有一个「epoch」，而 Flink 可以有多个 「epoch」并行存在。基于上述两点原因，Flink 的数据处理的端到端延迟要小得多，但这两种引擎幂等输出能实现一致性的本质是相似的。
然而在实际使用过程中，许多人对可观测性的关注，主要集中在系统上线之后。这当然是没有问题的，但实际上，从一个系统开发开始，一直到线上运行，都是可以从可观测的角度来对系统的质量进行评估和衡量，我们可以称之为对质量的观测。
线上运行：此时需要重点关注系统的稳定性以及业务的稳定性，因此各种线上的性能指标、业务指标、应用日志、Trace等各种数据都是非常重要的
