3、主流技术选型：Flink、Spark Streaming、Kafka Streams、Paimon/Iceberg 的选型对比
做日志场景的流批一体架构，选型是第一步，也是最头疼的一步。市面上能叫得上名字的引擎不少，但真正适合日志场景的，其实就那么几个。我这些年踩过的坑，多半都跟选型有关——选对了，后面顺风顺水；选错了，改起来成本极高。
今天咱们就掰开揉碎，聊聊 Flink、Spark Streaming、Kafka Streams 这三个计算引擎，以及 Paimon、Iceberg 这两个存储层。我不会跟你讲大而全的理论，而是结合日志场景的实际痛点，说说我个人的判断和取舍。
3.1 计算引擎三巨头：谁更适合日志处理？
先看计算层。Flink、Spark Streaming、Kafka Streams，这三个我都深度用过。说实话，没有的好坏，只有场景的匹配度。
| 维度 | Flink | Spark Streaming | Kafka Streams |
|---|---|---|---|
| 延迟 | 毫秒级（纯流） | 秒级（微批） | 毫秒级（纯流） |
| 状态管理 | 强（RocksDB + 定时快照） | 弱（依赖外部存储） | 中（内置状态存储） |
| Exactly-Once | 端到端支持 | 端到端支持 | 仅 Kafka 内部 |
| 批流一体 | 原生支持 | 通过 Structured Streaming | 不支持 |
| 运维复杂度 | 高（需独立集群） | 高（需 YARN/K8s） | 低（嵌入应用） |
| 日志场景适配度 | ★★★★★ | ★★★☆☆ | ★★☆☆☆ |
3.1.1 Flink：日志场景的「六边形战士」
我个人习惯把 Flink 作为日志场景的首选。为什么？因为它把流和批统一了。你想想看，日志数据白天是实时流，晚上要做历史回溯，Flink 一套代码搞定，不用维护两套作业。
我在项目中遇到过这样一个场景：某电商平台的用户行为日志，白天需要秒级延迟做实时风控，晚上又要跑全量数据做用户画像。用 Flink 的 DataStream API 写一套逻辑，白天跑流模式，晚上切批模式，代码复用率超过 90%。
3.1.2 Spark Streaming：批处理的「老大哥」
Spark Streaming 本质上是微批处理，把流切成一个个小批次。这在日志场景下有个天然问题：延迟。哪怕你把批次间隔设到 500 毫秒，实际端到端延迟也在秒级。对于实时告警、风控这类场景，这个延迟不可接受。
但 Spark Streaming 也有它的优势。如果你的日志处理逻辑里包含大量复杂的批处理操作——比如多维聚合、复杂 Join、机器学习模型训练——那 Spark 的生态优势就体现出来了。我记得有个项目，日志清洗用 Flink，清洗完的数据落到 Hive 里，再用 Spark 做离线分析，两套引擎各司其职。
3.1.3 Kafka Streams：轻量级但「能力有限」
Kafka Streams 是个很有意思的引擎。它不需要独立集群，直接嵌入你的 Java 应用里，运维成本极低。如果你的日志处理逻辑比较简单——比如字段提取、格式转换、简单的过滤和聚合——Kafka Streams 完全够用。
但它的短板也很明显：不支持批处理，状态管理能力弱，Exactly-Once 语义只保证 Kafka 内部。一旦你的日志场景需要做历史数据回溯、复杂状态计算、或者跨数据源 Join，Kafka Streams 就力不从心了。
我个人的建议是：Kafka Streams 适合做日志链路中的「轻量级预处理」环节，比如在日志进入主处理流程之前，先做一次字段裁剪和格式标准化。但别指望它承载核心的流批一体逻辑。
3.2 存储层选型：Paimon vs Iceberg
计算引擎选完了，接下来是存储层。日志场景对存储的要求很明确：支持流式写入、支持批量读取、支持时间旅行（Time Travel）、成本可控。目前最主流的两个选择是 Paimon 和 Iceberg。
| 维度 | Apache Paimon | Apache Iceberg |
|---|---|---|
| 流式写入 | 原生支持（Changelog 机制） | 需额外配置（通过 Flink CDC） |
| 实时性 | 秒级可见 | 分钟级可见 |
| 批流一体 | 强（Flink + Paimon 原生集成） | 中（需额外工具链） |
| 数据湖兼容性 | 一般（生态较新） | 强（Spark、Trino、Hive 等） |
| 日志场景适配度 | ★★★★★ | ★★★☆☆ |
3.2.1 Paimon：为流批一体而生
Paimon 的前身是 Flink 的 Table Store，后来捐给了 Apache。它的核心设计理念就是「流批一体」。Paimon 的 Changelog 机制可以实时捕获数据的插入、更新、删除操作，下游的 Flink 作业可以像消费 Kafka 一样消费 Paimon 表的变化。
我在日志场景中用过 Paimon 做「实时数仓」的 ODS 层。日志数据通过 Flink 写入 Paimon，秒级可见。下游的实时报表、实时告警直接读 Paimon 的增量数据，离线分析读 Paimon 的快照数据，一套存储搞定所有场景。
3.2.2 Iceberg：成熟但「流式能力偏弱」
Iceberg 是数据湖领域的「老牌劲旅」，生态非常成熟。Spark、Trino、Flink、Hive 都能直接读写。如果你的团队已经有一套基于 Spark 的数据湖体系，Iceberg 是自然的选择。
但 Iceberg 在流式写入方面偏弱。它本质上还是面向批处理设计的，虽然 Flink 可以通过 CDC 方式写入 Iceberg，但延迟在分钟级，而且不支持真正的 Changelog 流。对于日志场景的秒级实时需求，Iceberg 有点力不从心。
我记得有个项目，客户坚持用 Iceberg，结果实时报表的延迟从预期的 5 秒变成了 5 分钟。后来我们做了个折中方案：日志先写入 Kafka，Flink 消费 Kafka 做实时处理，同时每隔 5 分钟批量写入 Iceberg 做离线存储。虽然也能跑，但架构复杂了不少。
3.3 选型决策矩阵：一张图说清楚
说了这么多，你可能有点晕。没关系，我画了一张选型决策图，帮你快速定位。
3.4 我的最终建议
说了这么多，最后给个总结性的建议吧。
- 计算引擎： 首选 Flink。如果你的日志处理逻辑极其简单（只有过滤和映射），且不想维护集群，可以考虑 Kafka Streams。Spark Streaming 只在你已经有 Spark 生态且对延迟不敏感时使用。
- 存储层： 首选 Paimon。如果你的团队已经深度绑定 Spark 生态，且对实时性要求不高（分钟级），Iceberg 也是合理的选择。
- 组合推荐： Flink + Paimon 是目前日志场景下最成熟的流批一体方案。我最近三个项目都是这个组合，效果都不错。