1. 批流一体数据处理平台需求分析与架构总览

在构建任何数据处理平台之前，最重要的一步不是选服务，而是把“要解决什么问题”说清楚。批处理与流处理在传统架构中往往被拆成两套系统：一套负责 T+1 的离线报表，一套负责秒级告警与实时看板。两套系统各自维护代码、各自维护口径，最终导致同一指标在两个地方算出不同结果。批流一体的核心诉求，就是用一套计算逻辑、一套元数据、一套运维体系，同时承载历史全量数据与实时增量数据。

批处理与流处理的本质差异

批处理面向有界数据集，数据先落地再计算，典型特征是吞吐高、延迟以分钟到小时计、可重跑、结果确定。流处理面向无界数据流，数据到达即计算，典型特征是延迟低、需要处理乱序与迟到数据、状态需要持久化、结果随窗口推进不断更新。二者真正的难点不在“快慢”，而在于时间语义与状态管理：批处理天然按分区顺序读取，流处理必须显式定义事件时间、水位线和窗口触发条件。

统一诉求可以归纳为三点：其一，逻辑统一，同一份业务口径只实现一次；其二，存储统一，历史与实时共享同一份数据底座，避免双写不一致；其三，运维统一，监控、权限、血缘、调度使用同一套体系。理解这三点，才能理解后面所有服务选型的取舍依据。

典型业务场景与功能边界

批流一体平台并非适用于所有场景。它最适合三类业务：实时风控与告警（需要秒级判断，同时要用历史数据回溯规则）、实时数仓与看板（同一指标既要实时又要历史对比）、特征工程与推荐（离线训练特征与在线推理特征必须一致）。反之，纯离线月度结算、一次性数据迁移这类没有实时诉求的任务，用批处理即可，不必强行上流。

功能边界需要明确写进需求文档，避免后期扯皮。平台应负责：数据接入、清洗转换、窗口聚合、状态管理、结果写入、任务调度、血缘追踪、质量校验。平台不负责：业务规则的具体定义、上游系统的数据生产、下游应用的展示逻辑。边界清晰，才能让平台团队与业务团队各司其职。

非功能指标与选型原则

非功能指标决定了架构的“硬度”。延迟方面，实时链路端到端应控制在秒级到十秒级，离线链路允许小时级；吞吐方面，按峰值每秒十万条消息设计，预留 2 倍余量；一致性方面，实时结果允许最终一致，但离线结果必须精确一次；可用性方面，核心链路目标 99.9%，故障恢复时间小于 5 分钟。这些数字不是拍脑袋，而是根据业务容忍度反推出来的。

AWS 服务选型遵循四条原则：托管优先，减少自建运维成本；存储计算分离，S3 做底座，计算按需伸缩；开放格式优先，Iceberg、Parquet 避免厂商锁定；按需与预留结合，流处理用按需应对波峰，批处理用 Spot 降低成本。下面给出一个可直接参考的选型对照表。

从需求到架构的落地路径

实际推进时，建议按“先通后优”的顺序：第一步，用 Kinesis 接入一条实时流，写入 S3 原始层，验证链路连通；第二步，用 Glue 对同一份 S3 数据做批量清洗，确认批流读取同一份数据；第三步，引入 Iceberg 表格式，让流式写入与批量读取共享同一张表；第四步，接入调度与监控，形成闭环。每一步都有可观察的验证点：数据是否到达、分区是否正确、指标是否一致、告警是否触发。

需要特别注意的是，批流一体不是“把批处理改成流处理”，而是让两种处理共享同一份逻辑与同一份存储。架构总览的价值在于，让团队在动手写第一行代码之前，就对数据从哪来、经过什么、到哪去、由谁负责、如何验证有一张清晰的全局图。这张图越清晰，后续的选型与实现就越不容易返工。