一、流批一体概述
大家好，我是老张。做大数据运维这些年，从 Hadoop 1.x 一路摸爬滚打过来，踩过的坑比写过的代码还多。今天咱们聊聊流批一体——这个听起来高大上、实际上也确实是趋势的概念。
说白了，流批一体就是让一套系统既能处理实时流数据，又能处理离线批量数据。你想想看，以前我们做实时用 Storm、Flink，做离线用 Hive、Spark，两套系统两套代码，运维起来简直要命。我有个项目，凌晨三点被叫起来修实时链路，修完发现离线任务也挂了，因为两套集群共享了同一个 HDFS 目录……嗯，从那以后我就开始认真研究流批一体了。
1.1 流批一体到底是什么？
流批一体，核心就一句话：同一份数据，同一套代码，同一个引擎。不管是秒级延迟的实时流，还是 T+1 的离线批，都用同一套技术栈来处理。
我个人习惯把它拆成三个层面来看：
- 存储层：流数据和批数据共用同一份存储，比如 Kafka 或 HDFS，避免数据冗余和一致性难题。
- 计算层：同一个计算引擎（比如 Flink、Spark Structured Streaming）同时支持流和批两种模式，API 统一。
- 运维层：监控、告警、重试、资源调度，一套体系搞定，不用两套班子来回切换。
核心观点：流批一体不是技术噱头，而是运维效率的刚需。我见过太多团队因为两套系统不一致，导致数据对不上、凌晨加班、互相甩锅。流批一体至少能让你少接一半的告警电话。
1.2 技术演进：从 Lambda 到 Kappa
流批一体不是凭空冒出来的。它的演进路径，说白了就是大数据架构的「减负史」。
1.2.1 Lambda 架构
Lambda 架构是 2011 年由 Nathan Marz 提出的。它的思路很简单：批处理层保证准确性，流处理层保证低延迟。两套代码，两套链路，最后在服务层合并结果。
我在项目中遇到过这样的场景：实时链路用 Flink 算 PV/UV，离线链路用 Hive 跑 T+1 报表。结果每天对账都要吵一架——实时说 100 万，离线说 95 万，谁都不认。最后发现是实时窗口边界和离线分区边界差了 5 分钟。这种问题在 Lambda 架构下几乎无解。
| 维度 | 批处理层 | 流处理层 |
|---|---|---|
| 延迟 | 小时级/天级 | 秒级/分钟级 |
| 准确性 | 高（全量重算） | 中（可能丢数据） |
| 代码维护 | 两套代码 | 两套代码 |
| 运维复杂度 | 高 | 高 |
避坑指南：我曾经在 Lambda 架构下踩过一个坑——实时层和批处理层用了不同的序列化方式，导致合并结果时字段顺序错乱。从那以后，我要求团队必须统一数据格式，哪怕多花两天改造时间。
1.2.2 Kappa 架构
Kappa 架构是 Jay Kreps 在 2014 年提出的。它的核心思想是：只用一套流处理引擎，通过重放历史数据来模拟批处理。说白了，批处理就是「把流处理的时间窗口拉长到无限大」。
我个人觉得 Kappa 架构更优雅，但也不是银弹。它要求你的流处理引擎必须支持 exactly-once 语义和状态一致性，否则重放历史数据时数据会乱套。
| 对比项 | Lambda 架构 | Kappa 架构 |
|---|---|---|
| 代码量 | 两套代码 | 一套代码 |
| 运维成本 | 高（两套链路） | 低（一套链路） |
| 数据一致性 | 难保证 | 容易保证 |
| 历史重算 | 批处理层直接重算 | 重放 Kafka 数据 |
| 适用场景 | 对延迟和准确性都有极致要求 | 能接受秒级延迟的场景 |
我的建议：如果你的业务对延迟要求不高（比如分钟级），直接上 Kappa 架构。如果必须秒级且数据量极大，Lambda 架构仍然有它的价值。但无论如何，尽量统一引擎，别搞两套。
1.3 流批一体的核心架构图
下面这张图是我自己画的，展示了流批一体在数据流转中的核心位置。你可以看到，无论是实时流还是离线批，最终都汇聚到同一套计算引擎和存储层。
1.4 适用场景分析
流批一体不是万能的。我见过有人硬要把所有场景都往流批一体上套，结果搞得不伦不类。下面说说我个人的判断标准。
1.4.1 适合流批一体的场景
- 实时数仓：既需要秒级 OLAP 查询，又需要 T+1 的离线报表。用一套 Flink SQL 搞定，省心。
- 用户行为分析：实时看用户点击，离线做用户画像。数据源一样，逻辑一样，只是窗口大小不同。
- 监控告警与历史回溯：实时告警 + 离线趋势分析。我有个项目就是用 Flink 同时跑实时和回溯任务，运维量直接减半。
1.4.2 不适合流批一体的场景
- 对延迟要求极其苛刻（毫秒级）：比如高频交易。流批一体的引擎再快也有状态管理开销，不如专用流引擎。
- 批处理数据量极大且计算逻辑复杂：比如全量 T+1 的机器学习特征工程。这时候用 Spark 批处理反而更稳。
- 团队技术栈严重割裂：如果团队一半人只会 Hive，一半人只会 Flink，强行统一只会让两边都痛苦。先做技术培训，再谈架构升级。
总结一下：流批一体解决的是「运维效率」和「数据一致性」的问题，不是「性能极致」的问题。选不选它，先问自己三个问题：
- 我现在的两套系统，运维成本是不是已经失控了？
- 实时和离线数据对不上的问题，是不是每天都在发生？
- 团队有没有能力统一技术栈？
如果三个答案都是「是」，那流批一体就是你的解药。如果有一个「否」，先解决那个问题再动手。
好了，第一章就聊到这儿。流批一体的概念和架构先有个印象，后面我们会深入每个环节的运维细节。记住一句话：架构是骨架，运维是血肉。再好的架构，没有靠谱的运维也是白搭。