流批一体
Flink 的终极目标是一套 API、一套引擎、统一处理有界和无界数据：
有界流（批）→ DataSet API（已废弃）
→ Table API / SQL（统一）
无界流（流）→ DataStream API
→ Table API / SQL（统一）
现代 Flink：
// 同一套 Table API，自动选择批或流
Table table = tableEnv.sqlQuery("""
SELECT userId, COUNT(*) FROM events
GROUP BY userId
""");
// 有界数据源 → 批模式
// 无界数据源 → 流模式
同一个 SQL 在无界源上执行时会持续产出更新（changelog 流），聚合状态默认不设上限，生产环境要配 table.exec.state.ttl，否则状态同样会无限增长。
实时数仓
传统数据仓库：
业务 DB → 每日 ETL → Hive → 报表（T+1）
实时数仓：
业务事件 → Kafka → Flink → ClickHouse/Apache Doris
↓ 实时
实时报表/实时 BI（秒级）
实时数仓的关键组件：
| 层 | 技术 | 延迟 |
|---|---|---|
| 数据采集 | Kafka/CDC | 毫秒 |
| 实时计算 | Flink | 秒级 |
| 实时存储 | ClickHouse/Doris/StarRocks | 毫秒 |
| 实时查询 | SQL/API | 毫秒 |
SQL 化趋势
流处理的 SQL 化降低使用门槛：
-- Flink SQL：实时活跃用户统计
SELECT
window_start,
window_end,
COUNT(DISTINCT userId) as uv
FROM TABLE(TUMBLE(TABLE events, DESCRIPTOR(event_time), INTERVAL '1' MINUTE))
GROUP BY window_start, window_end;
优势：
- 数据分析师无需写 Java
- 与离线 SQL 一致，统一语义
- 可视化工具对接（Metabase、Superset）
局限：
- 自定义逻辑仍需 DataStream API
- 复杂 CEP 无法 SQL 表达
- 性能调优需要理解底层
Serverless 流处理
云计算平台的 Serverless 流处理：
| 平台 | 服务 | 模式 |
|---|---|---|
| AWS | Amazon Managed Service for Apache Flink（原 Kinesis Data Analytics）/ EMR Serverless | 托管 Flink |
| GCP | Dataflow | Apache Beam |
| Azure | Stream Analytics | 托管 SQL |
| 阿里云 | Realtime Compute for Apache Flink | 托管 Flink |
各家命名和产品边界变化很快，选型时以云厂商当期文档为准；上表只说明「托管 Flink + 按量计费」这条路线在主流云上都存在。
Serverless 的优势：
- 按量付费，无闲置成本
- 自动扩缩容
- 免运维
局限：
- 自定义受限（如无法安装自定义插件）
- 延迟可能高于自建集群
- 成本在高频场景下可能更高
AI × 流处理
实时机器学习推理与流处理的融合：
用户行为事件流
↓
Flink 窗口聚合 → 实时特征（近5分钟点击数、用户偏好向量）
↓
在线模型推理（TensorFlow Serving / TorchServe）
↓
实时推荐/风控决策
实时特征工程：
// 近 5 分钟用户活跃度，每 1 分钟滑动一次
stream.keyBy(Event::userId)
.window(SlidingEventTimeWindows.of(Duration.ofMinutes(5), Duration.ofMinutes(1)))
.aggregate(new ActivityFeature())
.addSink(new RecommendationSink());
RecommendationSink 内部通过 AsyncSinkBase（flink-connector-base 提供的 Sink V2 异步基类）或 RichAsyncFunction 批量调用推理服务。不要把 modelApi.predict() 直接放进 map：同步 HTTP 调用会阻塞算子线程，一条慢请求就拖垮整个链路的吞吐；而且 modelApi 作为算子字段必须可序列化，通常要在 open() 里创建客户端。
事件驱动架构的演进
第一代：单体应用（同步调用）
→ 延迟低，耦合高
第二代：消息队列（异步解耦）
→ Kafka + Consumer Group
第三代：流处理引擎（实时计算）
→ Kafka Streams / Flink
第四代：事件驱动微服务 + 流计算
→ eventd v3 模式：业务事件 + 实时分析
第五代：实时数仓 + AI 推理
→ 流处理 + 机器学习 + SQL 数仓
Java 生态的位置
Java 在流处理生态中的位置：
| 层面 | Java 工具 | 竞争 |
|---|---|---|
| 引擎 | Flink / Kafka Streams | Spark Streaming（Scala）、Storm（陈旧） |
| 框架 | Spring Cloud Stream | Akka Streams（Scala） |
| 查询 | Flink SQL | Presto/Trino |
| 存储 | 无 | 专用 OLAP 数据库 |
Java 的优势：
- 企业级生态成熟（Spring、Hibernate、监控工具）
- Kafka/Flink 的核心开发语言
- 人才储备大
给读者的建议
- 先从 Kafka Streams 入门：轻量、低耦合、无需新基础设施
- 需要 Watermark、乱序处理、CEP 或跨系统 Sink 时转入 Flink：这些是 Streams 的边界，也是 Flink 的核心优势
- 混合架构是终点：而不是二选一
- 关注 SQL 化趋势：Table API/SQL 会让流处理更普及
- 实时特征工程是 AI 的入口：流处理 + 机器学习是未来方向
小结
| 趋势 | 现状 | 未来 |
|---|---|---|
| 流批一体 | Flink Table API 初步统一 | 完全统一语义 |
| 实时数仓 | 技术就绪，落地中 | 主流替代 T+1 |
| SQL 化 | 简单查询可用 | 复杂场景也能覆盖 |
| Serverless | 云平台提供 | 成本进一步优化 |
| AI 融合 | 特征工程为主 | 端到端实时推理 |
下一节 15.3 全书总结与学习路径回顾 。
继续阅读
探索更多技术文章
浏览归档，发现更多关于系统设计、工具链和工程实践的内容。