---

流式计算回顾

在上一篇文章中我们后面介绍了一部分关于在纯粹的计算场景下的架构：流式架构。

当任务不涉及大量引用数据或次要效应时，流计算（Stream Computing）展现出了卓越的可扩展性优势。现实世界中的许多应用场景并非如此简单，它们往往包含复杂的数据依赖和交互作用。

---

流式服务结合分布式特性

流式计算最广泛的应用领域之一是实时统计分析，比如计算过去五分钟内的数据汇总。之所以能高效利用流计算，是因为它们可以直接从原始输入数据中提取所需信息，并且生成的统计结果具有在分布式系统中极为宝贵的单调递增属性，这显著提升了系统的处理效率和一致性。

更深层次数据关联或复杂运算的应用而言，单纯依赖流计算可能难以满足需求。

在这种情况下，通常需要结合分布式数据管理系统中的策略，如数据分区（partitioning）和复制（replication），来增强系统的处理能力和数据可用性。

---

流式计算组成部分

• 工作任务（work task）：客户端的计算需求时，我们将任务细分为微小的作业单元，随后智能地分配这些作业至各个计算节点上进行处理。
• 运维节点（operate node）：每台服务器配备一个或多个专门的管理角色，以维持高效运作。
• 工作节点（work node）：在计算节点层面，实际的计算任务被高效执行，并通过优化的通信路径将成果即时传递给后续计算节点或中转站，确保流程无缝衔接。
• 数据传输：作为节点间的桥梁，不仅促进信息在计算节点间的流畅传递，还充当初级数据的接入点。当消费者消费速率低于生产者时，该系统自动实施缓冲策略，保证数据流的连续与稳定。一般常用的是 Kafka等其他的MQ的消息服务。
• 管理节点（manage node）：整个集群的神经中枢，它不仅协调各部分状态，还负责信息的综合调度与全局状态的同步，确保集群运行的一致性和最高效率，常用的是 Zookeeper等。

---

监控数据处理进度

在流式计算领域中，单一数据记录往往需历经多种处理步骤（例如：更新各类计数器、执行统计分析等），这一过程可抽象为一个定向无环图（Directed Acyclic Graph, DAG），该图从数据源的起点延伸至所有计算任务圆满结束的终点。

此外，单个数据记录的处理操作可能跨越多个节点，而非限定于单一节点完成。形象地比喻，这如同设立了一个由100名工人组成的网络，每位工人能够接收来自多个上游的任务，进行加工后，再传递给多个下游环节。

这种分布式处理模式极大地增加了追踪每项任务是否顺利完成的复杂度，而有效管理和监控这一流程正是流式计算面临的挑战之一。

接下来，探讨如何在DAG框架内监控每个数据记录的处理进展。

流式分析案例

初始化时，每条记录在其诞生源头被赋予一个唯一的消息ID，此ID如同一张伴随数据流转的“身份证”，在每次处理生成新数据并传递时均被携带着，确保数据来源的可追溯性。

注意，一条数据可能源自多个路径（例如经过联接操作后）。利用这个ID，系统能够有效跟踪关联到该记录的所有计算任务的完成状态，从而实现精细化的进度管理。

流转数据的衍生存储

当一个处理阶段完成对输入数据的处理并产生输出数据，准备将其传至下游时，系统会向一个特殊组件（确认器Ackor）发送确认（ack）或失败（fail）信号，并附带输入数据及输出数据的唯一标识符。

在一切运作无碍的情况下，每个标识符都会因数据的生成及其后续处理完成而被确认器接收两次。尽管数据量庞大且单一记录可能导致众多衍生数据，为每条数据单独计数并不现实。

确认器采取高效策略

为每个原始记录分配一个初始值为0的64位数值，并非传统计数，而是利用异或运算（XOR）。每当接收到一个标识符的反馈，便执行value XOR id的操作。

凭借异或运算的性质，若所有相关标识符均被恰当地成对接收，最终该记录对应的value将重置为0，标志着与该记录相关的所有处理步骤圆满结束，这种方法巧妙规避了直接计数的资源消耗，适用于大规模数据处理场景。

确认器异常应对策略

基于利用ACK机制，通过对接收到的所有消息ID执行XOR操作，来监控单条记录是否已完成处理。接下来将分析遇到异常情况时，系统的应对策略。

工作节点故障的处理（精确一次处理）

一个典型问题场景是运算节点的故障，导致ACK机制无法接收到某些数据ID的确认信息。为解决这一难题，系统采取了超时处理机制：即若在预设时间内未收到某条数据的第二次ID回执，该数据记录将被标记为处理失败，并触发源端（例如Kafka）的重传流程。

这意味着无法确保“恰好一次”（exactly-once）的语义保证，在实际操作中，部分数据可能在重传前已被部分处理，导致数据的前半部分被重复处理。这是纯流式计算的一个固有特性，它在一定程度上界定了流计算技术的应用边界和挑战所在。

确认器故障的处理（恰好一次处理）

数据源同样设置了超时机制。一旦确认器崩溃，无法向数据源反馈消息确认，那么该消息（或记录）也将被重新发送，这同样引入了无法确保“精确一次处理”语义的问题。

至于数据源本身发生故障的情况，其后果较为严峻，因此，诸如Kafka之类的系统，通过实施复制策略来强化服务的高可用性，并倾向于采用无状态的消费者设计，确保即使在故障后快速重启并恢复运作，也是应对这一挑战的关键策略。

流处理到微批处理

流式计算在实现“恰好一次”处理语义上存在局限，而这正是众多应用场景的硬性需求。为应对这一挑战，一些框架摒弃了纯粹的流处理模式，转而采纳微批处理方式。

微批处理是什么

微批处理虽同样涉及数据聚合后再进行批量作业，但其特点是聚合窗口极短，通常以秒为单位，因此得名“微批”。这种处理模式在保持近似实时处理能力的同时，旨在克服纯粹流计算在保证“恰好一次”处理上的不足。

微批处理的精确一次

微批处理的优势在于能够实现“精确一次”的处理语义，尤其对于状态管理的精确更新至关重要，这部分内容我将在次日详细阐述。

缺点是增加了处理延迟，尽管对于那些对延迟不太敏感，能够接受秒级延迟的应用而言，微批处理仍然是一个可行且合理的选项。

Spark Streaming天生基于微批处理设计理念，实质上是将Spark的批处理能力微缩化实现。这意味着Spark Streaming天然适合追求微批处理效率与功能整合的应用场景。

微批处理的状态管理机制

缺乏精确一次性（exactly-once semantics）保障的情况下，数据可能会被重复处理，导致对计数器的多重更新，进而产生不准确的结果。

微批处理(micro-batch)模式来精细管理这一挑战，通过为每个批次分配一个事务ID来标记处理顺序，并严格确保状态(state)的更新遵循这些ID的顺序执行。这一机制不仅记录了状态的当前值，还保留了前一版本的状态值，形成了一种状态变迁的“快照”。

当系统识别到某个微批需要重处理时，利用保存的前一状态快照进行恢复，随后再应用更新。它能够确保即使在重处理的情境下，每个微批对状态的修改也只会被执行一次，从而维护了数据处理结果的准确性和一致性。

总体系列总结

在之前的整个系列文章中分析和介绍了分布式系统设计的关键决策，这些原则同样适用于流式计算架构等众多系统。聚焦于分布式数据系统，我以Zookeeper和Kafka为例进行阐述，二者作为流计算框架的核心组件，凸显其重要性。

• 流计算，该领域对低延迟有严格要求，因此在传统分布式系统挑战之上，还需应对更细粒度处理的难题。流计算框架，纯粹的流处理虽实时性高，但无法确保exactly-once语义下的数据准确性；

• 微批处理，解决这一问题，却牺牲了一定的低延迟特性。为拓宽应用场景，多数现代流计算框架已集成或原生支持微批处理模式，力求在保证数据精准度与维持低延迟间找到最佳平衡点。