Day28-34｜7.3.2 数据流体系结构风格：让数据经过可组合的处理链

对应教材：《系统架构设计师教程（第2版）》第7章“系统架构设计基础知识”——7.3.2 数据流体系结构风格。

学习定位：数据流体系结构风格把系统看作一组对数据进行处理的构件，以及连接这些构件的数据通道。它特别适合批量数据处理、编译器、日志分析、媒体转换、ETL 和流式计算等场景。本节需要掌握数据流风格的基本思想、批处理与管道—过滤器的区别、过滤器和管道的特点、优缺点、适用场景，以及如何在案例分析中讨论吞吐量、延迟、顺序、容错和数据一致性。

一、数据流风格的基本思想

数据流体系结构风格的核心是：输入数据按照一定方向流经若干处理步骤，每个处理步骤完成相对独立的转换、分析或输出。系统的主要行为由数据的流动和变换决定，而不是由一组复杂的对象之间频繁互相调用决定。

从抽象结构看，它包含三个要素：

1. 数据源：产生原始数据的文件、设备、网络、数据库、消息通道或用户输入。
2. 处理构件：读取数据、过滤数据、转换格式、聚合统计、分析判断或生成结果的单元。
3. 数据通道：在处理构件之间传递数据的连接件，可以是内存缓冲区、文件、管道、队列、网络连接或分布式流平台。

数据流风格通常强调处理步骤的独立性和可组合性。一个处理构件最好只关注自身的输入、转换规则和输出，不直接了解整个处理链的其他步骤。这样可以替换某个步骤、重新排列处理顺序、复用处理构件，或者根据负载对某个步骤单独扩展。

但是，数据流风格并不意味着所有系统都要把业务拆成一条直线。真实数据处理可能存在分支、合并、反馈、窗口、状态和外部副作用。架构师需要判断数据处理是否确实是系统的主导协作方式，并为非线性部分补充状态管理、顺序控制和错误处理机制。

二、批处理风格

批处理风格将输入数据收集成一批，系统按预先定义的步骤依次处理整批数据，最后生成输出。每个处理步骤通常读取上一步的完整结果，处理完后再把结果交给下一步。

典型流程是：

原始文件 → 数据清洗 → 格式转换 → 业务计算 → 汇总统计 → 报表文件。

批处理常用于日终结算、工资计算、账单生成、历史数据归档、数据仓库装载和大批量文件转换。它的优点是处理过程清晰、容易重跑、便于形成阶段性结果；缺点是端到端延迟较高，步骤之间可能需要大量中间存储，某一步失败可能阻塞后续步骤。

批处理设计要关注批次边界、重复执行、断点续跑、数据快照、失败重试和结果校验。不能简单地认为“定时任务就是批处理架构”；如果任务之间存在复杂业务交互、实时响应和大量共享状态，单纯采用批处理可能造成延迟和一致性问题。

三、管道—过滤器风格

管道—过滤器风格由一组过滤器和连接过滤器的管道组成。过滤器从输入端读取数据，对数据执行一种相对独立的转换，然后将结果写入输出端；管道负责传递数据，不应承担复杂业务处理。

可以把它理解为一条可组合的生产线：

输入 → 解析过滤器 → 清洗过滤器 → 转换过滤器 → 规则过滤器 → 聚合过滤器 → 输出。

过滤器具有以下典型特点：

• 处理逻辑相对独立，输入和输出契约清晰。
• 尽量避免直接共享内部状态。
• 可以被替换、复用、并行或重新组合。
• 只通过输入和输出与相邻过滤器协作。
• 需要明确处理失败时是停止、跳过、重试还是输出错误数据。

管道可以是同步调用、内存队列、文件、消息队列或网络连接。管道的实现方式会显著影响延迟、吞吐、可靠性和可观测性，因此不能把“过滤器”与某一种中间件绑定。

四、数据流风格的主要变体

4.1 顺序管道

所有数据按照固定顺序经过每个过滤器，结构简单、容易理解，适合处理步骤稳定、数据量可控的流程。缺点是某个慢步骤会拖慢整个链路，难以充分利用并行能力。

4.2 分支与合并

输入被分发到多个处理分支，分支结果再合并。适合并行执行独立分析或按数据类型路由，但要解决分支失败、结果顺序、重复合并和部分结果处理问题。

4.3 流式处理

数据以连续记录或事件的形式流动，处理可以边到边算，而不必等待完整批次。适合实时监控、日志分析、风控和 IoT 数据处理。需要考虑窗口、时间语义、迟到数据、状态保存、检查点和故障恢复。

4.4 反馈流

处理结果会影响后续输入或处理参数，形成反馈回路。反馈能支持迭代优化和控制系统，但会增加状态、稳定性和终止条件方面的复杂度，不再是简单的无状态流水线。

五、数据流风格的优点

5.1 可组合和可复用

过滤器的输入输出契约清晰时，同一个清洗、解析、脱敏或格式转换组件可以复用于多个流程。增加一个处理步骤通常不需要修改所有其他步骤。

5.2 有利于并行处理

当不同过滤器或同一过滤器的不同数据分片彼此独立时，可以并行执行，提高吞吐量。架构师可以根据瓶颈对特定阶段增加实例，而不必扩展整个链路。

5.3 便于局部验证

每个过滤器可以使用固定输入样本测试输出结果，容易建立单元测试和契约测试。处理链可以用小规模数据进行端到端验证，再逐步扩大数据量。

5.4 适合渐进式处理大数据

通过流式读取、分块处理和背压机制，可以避免一次性将所有数据加载到内存。对于海量日志和文件，数据流结构便于控制资源消耗。

5.5 处理过程具有可解释性

一条清晰的处理链能让维护人员看到数据经历了哪些转换，适合需要审计、追踪和可重复计算的场景。

六、数据流风格的缺点与边界

6.1 不适合复杂交互事务

如果业务需要多个对象频繁双向协作、共享事务状态或即时查询，强行拆成过滤器会导致大量上下文传递和复杂的回写机制。数据流适合“数据经过处理”，不一定适合“多个角色围绕状态协商”。

6.2 全局状态管理困难

过滤器越强调独立，越难处理需要跨步骤共享的状态。若将状态放入公共存储，又可能引入并发、锁和隐性耦合。应明确状态所有者、访问方式和一致性策略。

6.3 错误处理容易被低估

数据流中的错误可能发生在读取、解析、转换、输出和通道传输各个阶段。必须决定坏数据是否隔离、失败批次是否重跑、重跑是否会重复副作用，以及如何向下游说明部分失败。

6.4 延迟与吞吐存在权衡

批量聚合有利于吞吐，却增加等待时间；细粒度流式处理降低延迟，却增加调度、状态和网络开销。不能笼统地说数据流风格既高吞吐又低延迟，应结合窗口和资源模型验证。

6.5 可观测性和追踪更复杂

数据经过多个异步步骤后，单条记录的处理路径可能难以还原。需要批次号、记录号、事件时间、处理版本、检查点和统一追踪标识，才能定位数据丢失、重复和延迟。

七、过滤器设计的关键原则

7.1 单一职责与适度粒度

一个过滤器应有清晰的主要职责，但不能拆得过细。过粗会导致替换和并行困难，过细会增加通道、序列化和运维成本。合理粒度取决于业务变化频率、性能瓶颈、复用价值和独立部署需求。

7.2 明确输入输出契约

契约应说明数据格式、字段语义、必填项、版本、错误表示、字符编码、时间和单位。只描述“输入一条记录，输出处理结果”远远不够；尤其要说明缺失、重复、乱序和非法数据如何处理。

7.3 尽量幂等和可重入

过滤器失败后常需要重试。若过滤器产生外部副作用，应使用业务唯一键、去重记录或事务外盒等机制，保证同一输入重复处理不会造成重复扣款、重复发放或重复写入。

7.4 控制背压和资源

下游处理速度低于上游时，需要背压、缓冲、限流或丢弃策略。无界队列会造成内存耗尽和延迟失控；无策略地丢弃数据又可能破坏业务。应定义队列容量、积压阈值、告警、降级和恢复动作。

7.5 保留可追踪信息

过滤器转换数据时不要随意丢弃批次号、来源、时间、版本和关联标识。对于需要审计的处理链，应保留原始数据、转换结果、规则版本和处理状态，支持回放与问题定位。

八、管道设计与可靠性

管道的可靠性取决于数据是否会丢失、重复、乱序和不可恢复。内存管道速度快但进程崩溃可能丢数据；文件管道可恢复但会带来存储和清理压力；消息管道支持持久化与重试，但需要处理消费确认、积压和死信。

设计时可以建立以下映射：

如果链路中任何一步具有不可逆副作用，就必须在副作用发生前后设计状态记录和恢复路径。对财务、库存和支付等业务，不能只依靠“消息至少投递一次”来证明正确性。

九、性能分析与容量估算

数据流系统的性能应分别分析每个阶段，而不是只看平均吞吐。设输入速率为每秒 10000 条，过滤器 A 每实例处理 4000 条，过滤器 B 每实例处理 2500 条，过滤器 C 每实例处理 6000 条，则在忽略其他开销时，B 是瓶颈，需要至少 4 个实例才能稳定承载目标流量，并且还要预留故障和峰值余量。

实际容量还受消息大小、序列化、网络、存储、窗口聚合、热点分区、重试比例和下游系统能力影响。扩容瓶颈阶段可能造成上游积压，因此需要同时观察输入速率、处理速率、队列长度、端到端延迟和失败率。

低延迟场景还要考虑队列等待时间和批量窗口；高吞吐场景则要评估批量大小、并行度和内存使用。性能结论必须来自与生产数据特征接近的压测，而不是只测试一条简单记录。

十、案例分析：日志分析与告警平台

某互联网平台需要接收应用日志、网关日志和安全审计日志，要求分钟级发现异常，能够按租户、服务和时间查询，并在规则触发后发送告警。日志来源格式不统一，部分来源会重复发送，峰值流量是平时的十倍。

可以采用数据流风格进行设计：采集过滤器接收日志并补充来源信息；解析过滤器将不同格式转换为统一事件；清洗过滤器处理非法字段、敏感信息和时间格式；去重过滤器依据来源与事件标识消除重复；路由过滤器按租户、服务和日志类型分发；窗口聚合过滤器计算错误率、访问量和异常模式；规则过滤器判断是否触发告警；索引输出和告警输出分别进入查询存储与通知通道。

复审重点包括：解析失败的日志是否进入错误隔离区；重复日志是否会重复告警；不同时间的日志如何处理迟到数据；峰值时是否有背压和分区扩展；规则版本是否可追踪；索引存储变慢时是否影响采集；告警通道失败后如何重试；敏感字段是否在进入下游前脱敏。

如果平台还要支持用户实时修改告警规则，就不能把规则完全硬编码在无状态过滤器中，需要引入规则版本、缓存刷新和一致性策略。若告警触发要扣费或改变账户状态，则应把副作用处理与日志流解耦，并使用幂等和审计机制。

十一、综合知识练习

练习1：单项选择

管道—过滤器风格中，过滤器最典型的职责是什么？

A. 管理整个系统的所有共享事务
B. 对输入数据执行相对独立的处理并产生输出
C. 负责所有模块的部署和监控
D. 直接修改所有业务数据库

答案：B。 过滤器是数据转换或处理单元，应该通过明确输入输出与其他过滤器协作，避免成为全局控制中心。

练习2：多项选择

数据流体系结构实现中通常需要重点考虑哪些问题？

A. 数据格式和处理契约
B. 数据重复、丢失和乱序
C. 背压、积压和容量瓶颈
D. 失败重试、死信和补偿
E. 只考虑正常路径的平均延迟

答案：A、B、C、D。 数据流系统的质量主要体现在异常、峰值和恢复条件下，不能只观察正常路径的平均值。

练习3：案例题

某企业将对账流程设计成五个串行过滤器。每个过滤器处理完成后直接把结果写入共享数据库，失败时由定时任务从头重跑；系统经常出现重复入账和中间结果覆盖。请分析问题并提出改进方案。

参考答案：

1. 过滤器通过共享数据库隐式协作，数据所有权和阶段结果边界不清，容易互相覆盖。
2. 从头重跑没有幂等设计，会重复产生入账等不可逆副作用。
3. 缺少批次号、记录号、阶段状态和版本，无法准确恢复和定位失败位置。
4. 共享数据库可能成为吞吐瓶颈，串行处理也没有利用可并行阶段。
5. 定时任务没有区分可重试错误、坏数据和系统性故障，缺少错误隔离和补偿。

改进时应为每个对账批次和明细记录建立唯一标识，定义各阶段输入输出契约和数据所有者；采用持久化管道或阶段结果存储，记录检查点、处理版本和状态；过滤器尽量实现幂等，入账操作使用业务唯一键、状态机和去重约束；失败时从最近检查点恢复，对坏数据进入隔离区，对临时故障进行有限重试并进入死信；评估阶段间的独立性，适当并行处理清洗和匹配；增加批次级对账、金额校验、积压监控和人工补偿流程。

十二、论文写作素材

论文论述数据流体系结构时，可以先写数据规模、处理步骤、延迟目标和可追溯要求，再说明如何划分过滤器、设计管道和确定批处理或流式处理方式。重点写一个风险：例如重复数据导致重复告警、下游变慢导致积压、某阶段失败导致整批重跑或迟到数据影响统计。随后写幂等、检查点、背压、死信、窗口、分区和监控等具体措施。

可直接使用的句式：

针对业务数据具有连续流入、处理步骤相对独立且需要水平扩展的特点，我采用管道—过滤器风格组织处理链。每个过滤器只负责一种主要转换，使用明确的数据契约和统一追踪标识；管道根据可靠性和延迟要求选择持久化队列或内存缓冲。对于重复、乱序、迟到和下游积压，我分别设计幂等、顺序控制、窗口处理和背压机制，并通过峰值压测、故障注入和重放测试验证吞吐、延迟与恢复能力。

还应主动写出边界：强事务和复杂双向交互部分不强行采用纯数据流，而是由领域服务或事务模块负责；数据流负责异步处理和结果传播。这样的论述能体现架构师对风格适用范围和组合方式的理解。

十三、今日复盘

本节主线是：

数据源 → 过滤器 → 管道 → 数据转换 → 并行与聚合 → 结果输出 → 失败恢复与追踪。

请回答以下问题：

1. 批处理与管道—过滤器在数据边界和处理方式上有什么区别？
2. 为什么过滤器通常要设计成幂等和可重入？
3. 数据流系统如何处理背压、重复、乱序和迟到数据？
4. 哪些业务不适合使用纯粹的数据流风格？

最后，选择一个日志、文件、订单事件或 IoT 数据处理场景，列出至少五个过滤器，写清每个过滤器的输入、输出、失败处理和可观测指标。再找出链路中最慢的阶段，估算所需并行实例数和积压阈值，这一步能把数据流风格从概念记忆转化为可用于案例分析的设计能力。