gydtep

本篇文章从流计算的本质出发，重点分析流计算领域中数据处理的一致性问题，同时对一致性问题进行简单的形式化定义，提供一个一窥当下流计算引擎发展脉络的视角，让大家对流计算引擎的认识更为深入，为可能的流计算技术选型提供一些参考。

gydtep

例子2，后接不同的名词：Exactly-once State Consistency 和 Exactly-once Process Consistency。前者是 Flink 在官网中对其一致性的叙述，后者是 Kafka Streaming 的一致性保证，前者的语义约束弱于后者。

gydtep

总之，如何我们后面再看到 Exactly-once XXX，一定要警惕引擎想要透露出什么信息。

端到端的数据一致性

gydtep

进一步分析，每一次存储或者批量事务存储 O(t) 时，引擎到底做了什么？前面我们定义了 O(t) = Sink(t) + State(t) -> O(t) = Sink(t) + OperatorState(t) + SourceState(t) ，对于引擎来说，当出现 FailOver 时，都会通过 SourceState(t) 回拨数据源偏移量进行部分重算，

gydtep

在流计算过程中，定期（epoch）以事务（2PC）的方式进行批量存储结果（分布式一致性快照 + 写外部存储）。需要注意的是，由于 Flink 会以 epoch 为周期输出结果，因此基于此构建的流处理系统会存在一定的端到端延迟。

gydtep

同传统的批处理系统类似，流处理中也是以 RDD 构建出整个的数据血缘，当发生 FailOver 时，则重新计算整个 RDD 就可以了。如果 Spark Streaming 存在非确定性的计算，则不能实现端到端一致，

gydtep

有「心灵手巧」型的 Apache Flink，巧妙地结合了分布式一致性快照和两阶段事务实现一致性；也有「重剑无锋」型的 Apache Kafka Streams，直接将流处理过程事务化，屏蔽复杂的底层逻辑，编程模型和理解成本都更简单

gydtep

当然，引擎虽然这么多，但其背后是有若干条主线贯穿的，希望我们能拨开迷雾，不被营销的噱头所影响，能洞察到一些更为本质的东西。本文论述的端到端一致的流数据处理实现，重点聚焦在「计算和状态」管理，但实际上，还有很多因素需要我们去考虑，如时间窗口的推导、延迟数据的处理策略、底层计算节点的通信容错等，这些问题多多少少也会影响数据的一致性，考虑到文中篇幅，这里就不一一展开了，感兴趣的同学可以选择一个主题做深入研究。

gydtep

众所周知，在云原生开发模式下，可观测性是非常重要的一部分，它通过日志、指标、Trace等数据，让我们可以深入了解系统的运行状态和健康程度。在 CNCF Landscape大图中，可观测性也占据了相当大的一块位置。

gydtep

然而在实际使用过程中，许多人对可观测性的关注，主要集中在系统上线之后。这当然是没有问题的，但实际上，从一个系统开发开始，一直到线上运行，都是可以从可观测的角度来对系统的质量进行评估和衡量，我们可以称之为对质量的观测。