gydtep

正确认识流计算系统一致性的内在含义和其能力范畴，对我们构建正确且健壮的流计算任务至关重要。下面我会介绍几组概念，以便于大家更好地理解流计算系统的一致性。

gydtep

R(E(t), O(t)) = O'(t+1)，且 O'(t+1) = O(t+1)

我们在这里将引擎状态作为一种特殊输出的考虑有两点。其一，引擎的状态一般也是输出到外部存储如 RocksDB/HDFS，这和计算下游的输出别无二致。其二，通过屏蔽引擎内部的容错机制实现，简化端到端一致性问题的抽象过程，便于更好地理解问题本身。

gydtep

如果在提交这一批数据的提交过程中又发生了异常，譬如只有部分节点的结果输出了，其他节点发生了故障结果丢失，则可以通过回到上个批次提交的状态，重算此批次数据，重算过程中，由于仅存在确定性计算，所以无论是引擎内还是引擎外，是可以通过幂等来保证数据的的一致性的。

gydtep

目前流计算引擎的种类非常多，不是所有的引擎都可以实现端到端一致的流处理，在具备此能力的引擎中，从技术成本、引擎架构、能力范围考虑，会有不同的取舍和实现，如 Flink 中使用了轻量级的「分布式一致性快照」用于状态管理，Kafka Streams 为何没有使用呢？实现了幂等输出就一定能实现端到端一致么？本章节会一一解答上述问题。

gydtep

举例：Kafka Streams 的输出后端需要是 Kafka，以配合在事务提交过程中，屏蔽部分已输出至下游（被 Kafka Broker 持久化），但还不满足事务隔离性的消息（read_committed 级别），从流计算输出的角度来看，这些消息已被成功处理同时输出至下游，但从端到端的一致性来看，

gydtep

不同之处在于：1、Spark Streaming 在计算过程中的每一个 RDD 生成阶段都会有延迟，而 Flink 在计算过程中可以进行实时处理；2、Spark Streaming 只有一个「epoch」，而 Flink 可以有多个 「epoch」并行存在。基于上述两点原因，Flink 的数据处理的端到端延迟要小得多，但这两种引擎幂等输出能实现一致性的本质是相似的。

gydtep

基于上述的讨论，我们可以大体总结出质量观测的几个痛点：

海量的异构数据：在系统开发、测试、验证、上线等各个阶段产生了大量的日志、时序、Trace 等数据，这些数据产生的位置、数据格式、以及存储的位置，都有可能是不一样的。如何从这些数据中快速精准地挖掘出潜在的质量问题比较困难。

gydtep

扩展困难：随着数据规模的增长，软件的扩展能力、性能、稳定能力等方面都会有很大的挑战。
数据孤岛：不同的数据处于不同的系统中，协同困难。例如想要将 ES 中的日志和 Prometheus 中的指标进行一个 Join 查询就无法实现，除非做额外的二次开发。

gydtep

通知管理能力弱：许多告警管理系统只是简单地将告警消息发送出去，存在着通知渠道不完善、通知内容不符合用户需求、无法支持值班需求等等问题。

gydtep

告警的智能管理，除了基于规则的降噪，还会加入更多的算法支持，根据告警内容自动进行聚类，减少告警通知风暴