这些消息已被成功处理同时输出至下游，但从端到端的一致性来看，它们依然属于不一致的数据。又如，使用 Flink 处理 CDC（Change Data Capture） 的场景，
类似 Kafka Broker 中的消息无法撤回，MySQL 提交的事务也无法回滚，因此输出数据中也需要有类似的字段实现隔离（isolation）语义，以屏蔽这种不一致的数据。
流 -> 流：没有聚合操作的数据处理过程；
流 -> 表：存在聚合操作的数据处理过程；
表 -> 流：触发输出表数据变化的情况；
表 -> 表：不存在这样的数据处理逻辑。
在这个统一的理论框架下，批处理过程的一致性也可以纳入本文讨论的范畴中来。但无论是纯粹的流计算，还是上面统一的数据处理模型，我们都可以将流（批）数据处理的过程抽象为
流 -> 流：没有聚合操作的数据处理过程；
流 -> 表：存在聚合操作的数据处理过程；
表 -> 流：触发输出表数据变化的情况；
表 -> 表：不存在这样的数据处理逻辑。
然而在实际使用过程中，许多人对可观测性的关注，主要集中在系统上线之后。这当然是没有问题的，但实际上，从一个系统开发开始，一直到线上运行，都是可以从可观测的角度来对系统的质量进行评估和衡量，我们可以称之为对质量的观测。
依赖规则，缺乏智能：质量监控比较依赖于人的经验，很大程度上受限于人为设定的规则和阈值，无法做到数据自适应，因此无法发挥出真正的数据价值。
监控规则泛化能力弱：不同的业务、甚至同一业务的不同版本，指标的规律性、阈值都有可能是不同的。因此我们需要为不同的业务、不同的版本去做监控规则的适配。
多渠道：支持短信、语音、邮件、钉钉、企业微信、飞书、Slack等多种通知渠道，同时还支持通过自定义 Webhook 进行扩展。同一个告警，支持同时通过多个渠道
关于对未来的展望：
目前质量观测，数据的统一采集和管理，分析、可视化、监控等能力已经都相对完善
从监控角度来说，智能巡检已经可以比较好的自适应数据，另外就是进行智能根因分析，自动发现问题的根源，加快问题溯源，减轻排障困难
