4. 批流一体架构设计：统一数据源层、计算层与存储层
批流一体架构的核心在于消除传统 Lambda 架构中批与流两条独立管线的维护成本，通过统一的数据源接入、统一的计算引擎与统一的存储视图，实现“一套代码、一份数据、一次运维”。本章从三层架构出发，分别阐述每一层的设计目标、关键组件与实现策略。
4.1 统一数据源层设计
数据源层负责将异构、多速率的数据源以标准化的方式接入批流一体平台。设计要点包括：
- 多协议适配：支持 Kafka、Pulsar、RocketMQ 等消息队列作为实时流源，同时支持 HDFS、S3、OSS 等文件系统作为批量源。
- Schema 统一管理：使用 Avro / Protobuf 作为序列化格式，配合 Schema Registry 实现字段级兼容性校验。
- 偏移量（Offset）持久化：将流式消费的偏移量写入外部状态存储（如 ZooKeeper / Redis），确保批任务重跑时能精确回溯。
- 水位线（Watermark）注入：在数据源层为乱序事件注入统一水位线，使下游计算层能正确处理事件时间语义。
设计原则：数据源层只做“接入与标准化”，不做业务清洗。所有数据以原始格式进入统一缓冲区，由计算层按需处理。
4.2 统一计算层设计
计算层是批流一体的核心战场，需要同时支持流式微批处理与大规模离线批处理。设计策略如下：
| 维度 | 流处理模式 | 批处理模式 | 统一方案 |
|---|---|---|---|
| 执行引擎 | Flink Streaming | Flink Batch / Spark Batch | Flink 统一 Runtime |
| 时间语义 | 事件时间 + Watermark | 处理时间 / 事件时间 | 事件时间优先，Watermark 对齐 |
| 状态管理 | RocksDB / Heap StateBackend | 外部存储（HBase / Redis） | 统一 State API + 可插拔 Backend |
| 容错机制 | Checkpoint + Savepoint | Task 重试 + 数据重跑 | 统一 Checkpoint 协议 |
| 资源调度 | YARN / K8s 动态扩缩 | YARN / K8s 固定资源 | 弹性资源池 + 优先级队列 |
实战建议：优先选择 Flink 作为统一计算引擎，利用其
StreamExecutionEnvironment 与 BatchTableEnvironment 的底层共享，将批作业视为“有界流”执行，大幅降低学习与运维成本。
4.3 统一存储层设计
存储层需要同时满足流式数据的低延迟写入与批式数据的高吞吐查询。设计采用“分层存储 + 统一视图”架构：
- 实时层（Realtime Layer）：使用 Apache HBase / Cassandra / Redis 等 NoSQL 存储，支持毫秒级点查与增量更新。
- 近线层（Nearline Layer）：基于 Apache Kafka / Pulsar 的 Topic 持久化，保留 7~30 天原始事件，供回溯与重跑。
- 离线层（Offline Layer）：使用 HDFS / S3 / OSS 作为冷存储，数据以 Parquet / ORC 列式格式存放，支持大规模 OLAP 查询。
- 统一元数据：通过 Hive Metastore / Apache Iceberg / Delta Lake 提供表级 Schema 与分区信息，使批流任务能透明读写同一张表。
4.4 三层协同的关键设计
三层之间并非孤立，需要通过以下机制实现端到端一致性：
- 统一事务边界：使用两阶段提交（2PC）或 Kafka 事务，确保数据从源层到存储层的 Exactly-Once 语义。
- 数据生命周期管理：通过 TTL 策略自动将数据从实时层迁移到近线层，再沉降到离线层，降低存储成本。
- 统一监控与告警：对三层分别采集延迟、吞吐、存储水位等指标，聚合到 Grafana 看板，实现一体化运维。
常见陷阱：不要试图在存储层做“全量实时”，这会导致存储成本爆炸。正确的做法是：热数据（最近 1 小时）放实时层，温数据（1 小时~7 天）放近线层，冷数据（7 天以上）放离线层，查询时由统一元数据层自动路由。
4.5 架构总览
下图展示了批流一体三层架构的完整数据流与组件关系：
关键收益：通过三层统一设计，开发人员只需关注业务逻辑（计算层），无需关心数据来源与存储格式；运维人员只需管理一套元数据与一套监控体系，整体运维成本降低 40%~60%。