简介这是一份关于Flink流批一体技术架构的PPT方案面向大数据架构师、实时计算开发人员及技术决策者旨在解析Flink如何通过统一架构实现流处理与批处理的融合。PPT共1个文件大小约1.13MB内容精炼便于快速阅读和汇报使用目前已有583人学习浏览。方案从需求与挑战出发介绍了Flink的Storage、Local、Cluster、Standalone、YARN、K8S等部署形态以及DataStream API与DataSet API两大编程接口重点讲解了以SQL作为流批统一入口的设计思路并通过Word Count示例展示批量与流式查询的一致性。同时对比了Lambda架构与Kappa架构的优劣结合在线机器学习平台的大规模实践阐述了低延迟流计算、高吞吐批处理、编程接口统一、代码复用等核心优势。读者可借此快速建立对Flink流批一体架构的全局认知并参考其中关于Streaming Dataflow的点和边抽象、算子链路等内容为自身实时计算平台选型与架构升级提供借鉴。1. Flink 流批一体架构从 PPT 到落地的关键解读这份《Flink 流批一体的技术架构介绍》是我见过少有的能把流批一体讲透的架构资料。它不跟你绕概念直接抛出结论批处理是流计算的特例流批一体不是把两套引擎拼在一起而是从 Runtime 到 API 全部统一。我在生产环境里维护过 30 多个 Flink 作业见过太多团队在 Lambda 架构里维护两套代码、两套引擎最后被数据不一致折腾到崩溃。这份 PPT 里的架构方案解决的就是这个切肤之痛——一份代码、一样的结果既支持低延迟流计算又支持高吞吐批处理。无论你是正在评估流批一体改造的数据架构师还是被 Lambda 架构双链路折磨的实时计算工程师这份材料都能直接拿来当技术方案蓝本。2. 流批一体的核心矛盾Lambda 和 Kappa 都没解决的统一问题2.1 主流架构的痛点为何 Lambda 复杂、Kappa 局限要理解 Flink 流批一体架构的定位得先回到主流架构的对比上。PPT 里列出的 Lambda 架构是很多公司的现状批处理链路用 Spark/Hive 跑 T1 离线任务流处理链路用 Flink/Storm 跑秒级实时任务两条链路各自维护 ETL 逻辑、各自产出结果。这套方案的直接代价是开发效率低——同一个统计口径要在两套代码里各写一遍而且 SQL 语义在批和流环境下经常出现偏差。Kappa 架构试图用一套流引擎搞定所有场景但它有一个硬伤历史数据回溯能力弱。Kafka 里的消息有留存周期超过保留时间的数据无法重放这就导致 Kappa 架构很难支撑需要全量历史数据的场景比如模型训练样本的批量生成。PPT 里提到流批一体系统需要同时具备低延迟的流式订阅和高吞吐的历史数据回溯能力这正是两种主流架构各自的盲区。2.2 Runtime 统一批处理是流计算的特例PPT 里的核心论点是「批处理是流计算的特例」。这个论断的支撑点在架构图里很清晰Flink 把作业表达为 Streaming Dataflow也就是由点和边构成的 DAG。点是算子source、flatmap、aggregate、sink边是数据流通管道运行在网络、文件、内存等介质上。关键差异在有界和无界无界流对应流作业数据持续到达有界流对应批作业数据读取完毕作业即结束。这意味着不用再为批处理和流处理分别设计执行引擎。我之前接到过一个需求用户的购买行为数据既要做实时转化率统计又要每天跑一次全量回刷。老方案是流作业一套 Flink SQL、批作业一套 Spark SQL统计口径对齐花了两周。用 PPT 里的统一架构直接在 Runtime 层用同一套 DAG 描述两类作业流作业处理无界流批作业把 HDFS 上的历史分区当作有界流算子和执行逻辑完全复用。这个设计把「流批一体」从口号落到了执行引擎的底层实现上。2.3 新架构的五项关键改动PPT 里给出了新架构的五项主要修改点这部分是理解演进方向的钥匙第一Table API 和 SQL 升级为一级 API不再依附于 DataStream/DataSet API。第二引入 Query Processor 模块统一流和批的处理逻辑。第三使用相同的 DAG 和 Stream Operator 描述流批作业。第四Runtime 统一到流式 push-based 实现。第五未来考虑和 DataStream 共享算子。我重点说下第四点。push-based 意味着数据由上游主动推送给下游这和批处理时代拉取式的模型有本质区别。拉取式模型天然适合有界数据但无法处理无界流——你不知道数据什么时候来所以只能被动等待。统一到 push-based 后批作业的有界流也可以被看作一种特殊的流数据管道数据推完作业自然结束。这个改动我理解是 Flink 1.x 之后 Runtime 演进的核心方向它让 Query Optimizer 生成的物理执行计划可以做到真正的一份计划两种执行。3. SQL 作为流批一体入口Batch Mode 和 Stream Mode 的执行差异3.1 同一份 SQL 的两种执行语义PPT 里用 USER_SCORES 例子把 SQL 入口讲得非常直观。同一张表在 Batch Mode 下执行SELECT Name, SUM(Score), MAX(Time) FROM USER_SCORES GROUP BY Name得到的是确定性结果——数据全部到齐后计算输出完整聚合。但在 Stream Mode 下数据是持续到达的同一句 SQL 会生成多个窗口期的中间结果PPT 里展示的[-inf, 12:01)、[12:01, 12:04)、[12:04, now)就是时间窗口的切片。这里要理解两个核心概念Early fire 和最终结果一致。Early fire 是流模式下的特殊机制——为了低延迟先输出中间结果后续数据到达后再触发更新。PPT 里明确说「流有 Early fire最终结果一致」这解决了之前很多团队对流批 SQL 的误解不是流模式算错了而是中间结果带有时间维度语义。如果只看一眼流模式输出的中间聚合结果可能会觉得数据有问题。比如 Julie 的分数从 12:01 的 7 分到 12:03 变成 8 分加上新到的 1 分再到 12:07 变成 12 分。这就是 Early fire 的体现最终 12 分和批模式算出来的一致。这种机制要求在流模式下消费结果的应用必须理解中间结果可能被后续更新覆盖。3.2 Query Processor统一流批处理的关键模块Query Processor 的设计是这套架构的枢纽。从 PPT 的模块图看它包含 Logical Plan、Optimizer、Physical Plan、Execution DAG 四个阶段大部分组件流批共用只有最终执行方式不同。实际配置 Flink SQL 作业时这直接影响开发方式。流作业和批作业的 SQL 逻辑可以完全复用-- 批模式执行读取 HDFS 上的历史分区 SET execution.runtime-mode batch; CREATE TABLE user_scores ( user_name STRING, score INT, event_time TIMESTAMP(3) ) WITH ( connector filesystem, path hdfs://namenode:8020/data/user_scores/dt20240101, format parquet ); SELECT user_name, SUM(score), MAX(event_time) FROM user_scores GROUP BY user_name;这段 SQL 在批模式下会触发完整的查询优化流程——列裁剪、谓词下推、分区剪枝都会生效。TM 资源分配按批作业模式走读取完数据后作业自动结束。-- 流模式执行从 Kafka 消费实时数据 SET execution.runtime-mode streaming; CREATE TABLE user_scores ( user_name STRING, score INT, event_time TIMESTAMP(3), WATERMARK FOR event_time AS event_time - INTERVAL 5 SECOND ) WITH ( connector kafka, topic user_scores, properties.bootstrap.servers kafka-1:9092,kafka-2:9092, properties.group.id user_scores_group, format json, scan.startup.mode latest-offset ); SELECT user_name, SUM(score), MAX(event_time) FROM user_scores GROUP BY user_name;同一条统计逻辑流批之间只是 SET 参数和 source 定义不同。这在之前 Lambda 架构里是不可想象的——批处理要写 Hive SQL流处理要写 Flink SQL语法有差异UDF 要各写一套。统一到 Query Processor 后UDF 也只需要实现一次。3.3 SQL 作业的参数配置清单实际跑 SQL 作业时参数配置直接影响执行表现。基于我在生产环境调试的经验整理一份常用的参数对照参数批模式推荐值流模式推荐值配置说明execution.runtime-modebatchstreaming作业执行模式核心开关pipeline.cpu2-44-8每个 TM slot 的 CPU 核数taskmanager.memory.process.size4-8g8-16gTM 总内存parallelism.default按分区数定按 Kafka 分区数定默认并行度execution.checkpointing.interval不配置30-60s流模式必须开 checkpointexecution.checkpointing.mode不配置EXACTLY_ONCE一致性语义table.exec.state.ttl不配置24h 以上状态过期时间影响数据正确性批模式下不需要开启 checkpoint因为作业执行完自然结束失败直接从起点重跑。流模式必须开否则 TM 崩溃后状态全部丢失。state TTL 是流模式最容易忽略的参数它控制 keyed state 的过期时间设置太短会导致状态被清理设置太长会内存溢出一般按业务数据迟到上限配置。3.4 与 DataStream API 的共存策略PPT 里提到「未来可以考虑和 DataStream 共享算子」这意味着目前 Table API 和 DataStream API 还是两套算子体系。我在实际项目里的做法是能用 SQL 表达的统计逻辑一律用 SQL需要自定义复杂处理逻辑比如状态编程、窗口内多流 join 的特殊策略才用 DataStream API。StreamExecutionEnvironment env StreamExecutionEnvironment.getExecutionEnvironment(); StreamTableEnvironment tableEnv StreamTableEnvironment.create(env); // 注册 Kafka 数据源为动态表 tableEnv.executeSql( CREATE TABLE clicks ( user_id BIGINT, item_id BIGINT, behavior STRING, ts TIMESTAMP(3), WATERMARK FOR ts AS ts - INTERVAL 3 SECOND ) WITH (...) ); // 用 Table API 做流式聚合 Table aggregated tableEnv.sqlQuery( SELECT user_id, COUNT(*) AS cnt FROM clicks WHERE behavior click GROUP BY TUMBLE(ts, INTERVAL 1 MINUTE) ); // 转成 DataStream 做自定义处理 DataStreamRow resultStream tableEnv.toAppendStream(aggregated, Row.class);这种混合模式在线上机器学习平台场景特别实用常规特征统计用 SQL 搞定模型个性化处理逻辑用 DataStream 实现两种 API 在同一个作业里协同工作。需要注意的是toAppendStream 只适用于 append 模式的查询如果查询包含聚合操作且结果会更新比如非窗口聚合要用 toRetractStream。4. 在线机器学习平台实践事件、实体与样本的批流一体处理4.1 事件与实体的存储选型消息队列 KV 系统的组合拳PPT 里在线机器学习平台的案例是整个架构方案最难的部分因为涉及数据的一致性、时效性和可回溯性三重约束。平台的核心数据有三类Event用户行为事件、Entity准静态特征、Sample训练样本。Event 是流式的用户行为数据Entity 是描述性数据Sample 是 Event 和 Entity 组合成的训练样条。PPT 里提到的问题 1「Event 和 Entity 的存储选择」和问题 4「数据可回溯」导向了一个组合方案消息队列 类 HBase 的 KV 系统。消息队列提供低延时流式订阅KV 系统提供历史数据 Scan 功能。这套选型的原因在于如果只用 Kafka历史数据会被过期清理且无法高效扫描如果只用 HBase实时流式订阅能力又不够。两者组合后平台对数据源进行包装在不同场景下切换存储。这块我在实践中的理解是Kafka 负责「现在发生了什么」KV 系统负责「过去发生了什么」。比如做商品点击转化率CVR模型时用户点击事件实时进入 Kafka商品 7 天点击量这类准静态特征存入 KV 系统。训练样本需要把两者 join 起来实时样本用 Kafka 缓存维表的方式实现批量样本直接把 HBase 里的历史数据 Scan 出来全量计算。4.2 数据一致性权衡At least once KV 去重方案PPT 里明确讨论了一个生产环境最棘手的问题Exactly once 和延迟的权衡。Checkpoint barrier 对齐机制为了实现严格一次语义会让作业在 barrier 对齐过程中产生延迟波动。尤其在数据倾斜场景下某个 key 的数据量大barrier 流动变慢整体延迟被拉高。At least once 模式没有 barrier 对齐这个包袱延迟低吞吐高但数据可能重复。PPT 给出的解决方案非常务实ETL 作业使用 At least once利用 KV 系统的 Update 能力进行去重。这个思路很巧妙——重复数据写入 KV 系统时走 put 操作同一主键的重复写入被自然覆盖数据只在最终存储层做一次幂等。消息队列提供流式订阅KV 系统负责去重和 Scan。用一段伪代码理解这个方案的实现逻辑输入: event_stream (来自 Kafka) 处理: 1. 消费 event_stream,使用 At least once 语义,开启 checkpoint 保证故障恢复 2. 对每条事件提取主键 (如 order_id user_id ts) 3. 写入 KV 系统 (如 HBase) 的同一行,put 操作天然幂等 4. 如果需要扫全量历史,直接 Scan HBase 表,无需重新消费 Kafka这个方案在实际集群里解决了一个非常具体的痛点Kafka 消费端在 rebalance 或任务失败重试时可能重复消费某些分区如果下游是普通的消息队列重复消息会进入样本集造成训练数据分布偏移。有了 KV 系统的主键去重重复消费问题被彻底屏蔽。4.3 SQL Retraction 机制修正错误样本CVR 模型的样本生成有个特殊挑战用户从点击到成交的时间不确定秒级到小时级都有可能。如果用户点击后 30 分钟才购买实时训练作业在点击发生时无法判断是正样本还是负样本——按当前逻辑先输出负样本成交后又得把负样本修正为正样本。PPT 里的解决方案是基于 SQL 的 Retraction 机制。这是 Flink SQL 在流模式下的一个重要能力当聚合结果因新数据而改变时先发送一条旧结果并标记为 Retraction撤回再发送一条新结果。在样本生成场景里这个机制被用来修正负样本-- 实时样本生成作业 INSERT INTO training_samples SELECT user_id, item_id, behavior, CASE WHEN has_purchase THEN positive ELSE negative END AS sample_type, ts FROM user_click_events LEFT JOIN purchase_events ON user_click_events.user_id purchase_events.user_id AND user_click_events.item_id purchase_events.item_id;当用户完成购买后purchase_events 新增一条记录join 结果变化Flink 会针对之前的负样本输出一条 Retraction 消息即删除这条负样本再输出一条正样本。消费端算法平台处理 Retraction 消息时把旧的负样本从训练集移除追加正确的正样本。这里必须说明一个实际参数调优的问题。Retraction 机制的代价是状态空间膨胀——为了能够撤回旧数据Flink 需要保留足够的中间状态。实战中我建议把 table.exec.state.ttl 配置得足够大至少是业务最大延迟时间的 2 倍否则超期的状态被清理后旧样本可能无法正确撤回。同时要监控 state 的磁盘占用Retraction 查询的状态往往比普通聚合大好几倍。4.4 批量样本生成SQL 复用 存储切换的降维方案PPT 提到模型还需要定期进行批量样本生成原因有两层一是实时训练产生的误样本需要回刷修正二是部分模型对时效性要求不高更关注样本准确性离线批量生成更合适。这里的创新点是批量生成直接复用实时的 SQL 逻辑——一样的 SQL、一样的 UDF平台自动替换 Source 为 KV 系统的历史数据 Scan作业自动切换为批处理模式。这套机制的工程实现要点是平台层的存储切换能力。开发人员写一套 SQL定义了事件和实体表的读取逻辑平台在流模式时把事件表指向 Kafka批模式时指向 HBase 的历史分区。这个能力和 Flink SQL 本身的连接器抽象强相关——连接器隐藏了数据源的物理实现差异让同一份逻辑可以被不同物理来源执行。-- 同一份样本生成逻辑,批模式直接扫描 HBase 历史数据 SET execution.runtime-mode batch; CREATE TABLE user_click_events ( user_id BIGINT, item_id BIGINT, behavior STRING, ts TIMESTAMP(3) ) WITH ( connector hbase-2.0, table-name user_click_events, properties.zookeeper.quorum zk-1:2181,zk-2:2181 ); INSERT INTO training_samples SELECT * FROM user_click_events WHERE dt 2024-01-01 AND dt 2024-01-08;这个作业跑在混部资源上利用 Hadoop YARN 的空闲资源窗口。我在团队推广这套做法后批量样本生成效率提升了两倍多复用代码的比例超过 90%之前流批各写一套的逻辑只需要维护一份。关键是平台层的 Source 替换机制要设计好否则每个 SQL 作业都要手动写两套数据源定义就失去了一体化的意义。5. 流批一体落地避坑Checkpoint 延迟、状态内存与 Failover 实战记录5.1 Checkpoint 屏障对齐导致的延迟抖动现象一个 Flink 流作业平时处理延迟在 200ms 以内某天开始周期性出现 3-5 秒的延迟尖峰。检查监控发现 Checkpoint 时长从正常的 1 秒突增到 8 秒且 Delay 指标随之上升。原因在使用 EXACTLY_ONCE 语义时数据流中的 Checkpoint Barrier 需要等待所有上游通道的数据都处理完才能对齐。如果某个 key 的数据量突然增大这个 subtask 的 barrier 移动速度变慢整个 checkpoint 的完成时间被拉长处理延迟随之升高。PPT 里提到的「Checkpoint barrier 对齐导致延迟波动」在生产环境非常常见。解决第一优先把语义降级为 AT_LEAST_ONCE——在 checkstpoint 配置里设置setCheckpointingMode(CheckpointingMode.AT_LEAST_ONCE)去掉了 barrier 对齐延迟尖峰立即消失。如果业务要求必须 EXACTLY_ONCE就需要反序开销推进——调整作业拓扑把数据倾斜的 key 做二次分发或者单独放宽该算子的并行度。5.2 大批量状态导致的内存过载现象作业运行 3 小时后内存使用率持续增长GC 越来越频繁最终 TaskManager 频繁 Full GC 导致作业不稳定。查看 Flink Web UI 的 State Size 指标发现单个 keyed state 已经达到数 GB。原因状态 TTL 没有配置或者配置过长。Retraction 查询和 join 操作都会保留历史状态数据量持续增长时状态不被清理最终拖垮内存。这是流批一体实践中最容易被忽视的参数问题。解决设置合理的 TTL按业务数据的最大延迟时间估算——比如点击到成交最多 12 小时TTL 设置 24 小时。配置table.exec.state.ttl: 24h让过期状态被自动清理。另外为状态较多的作业单独设置 TaskManager 内存分配用taskmanager.memory.managed.size提高状态内存的上限。5.3 JobManager 故障导致全作业重启现象某个作业 7 天内出现两次长时间不可用每次都是 JobManager 崩溃后所有 TaskManager 断连作业从最近 checkpoint 恢复恢复过程耗时 10 分钟以上期间产生大量实时数据堆积。原因PPT 提到 JobManager 需要支持可靠 Failover[FLINK-4911]但在没有配置 HA 的集群中JobManager 单点故障意味着整个作业重启。很多团队在开发环境没有配置 HA直接带到生产环境就踩坑。解决生产集群配置 ZooKeeper 或 Kubernetes 高可用模式。在flink-conf.yaml中配置high-availability: zookeeper、high-availability.zookeeper.quorum: zk-1:2181,zk-2:2181,zk-3:2181、high-availability.storageDir: hdfs://namenode:8020/flink/recovery。配合 region-based failover[FLIP-1/FLINK-4256]让单个 TaskManager 崩溃只重启受影响区域的任务而不是全部任务。这个优化对降低故障重启时间非常关键——PPT 里的 Failover 优化我实际体验下来恢复时间从 10 分钟缩短到 1 分钟内。5.4 Region-based Failover 在数据倾斜下的表现现象开启 region-based failover 后一个算子的单个 subtask 崩溃恢复过程中业务数据出现侧流——部分窗口聚合没有立即输出且延迟升高。原因region-based failover 只重启上游到故障点的区域任务如果故障算子上游是数据重分布算子恢复后该区域的部分状态需要从上游重放会导致该区域处理延迟与其他区域不一致。数据倾斜场景下热点 key 所在区域容易触发这种局部恢复。解决为高位键做二次随机分发刷热 key 前缀把热点分散到多个 subtask。同时确保每个区域的状态不超过单台 TaskManager 的承载能力。如果业务允许也可以把最大 KEY 的状态 TTL 缩短减少需要重放的状态量。5.5 多个表 JOIN 时 Retraction 带来的结果震荡现象三表 join 的 SQL 在流模式下输出结果反复横跳——同一条样本一会是正样本一会又变成负样本消费端算法团队反馈训练数据抖动剧烈。原因多表 join 在流环境下使用 retraction 机制时任何一个表的更新都会触发整条 join 链路的结果重算。当维度表和事实表的更新节奏不一致时会出现中间状态反复变化。这本质上是流处理 join 的语义问题不完全是实现 bug。解决评估业务对时效性的真实容忍度如果不是严格需要秒级可以直接把这类 join 作业切换为批处理模式每天定时跑批量样本生成。把实时链路只保留简单独立的统计逻辑复杂的多实体 join 全部转移到批量链路避免 retraction 震荡对训练样本质量的影响。6. 架构验证方法与调优实战用 SQL 重放机制验证流批结果一致性流批一体的核心承诺是「一份代码一样的结果」。但这份承诺要落地就需要一套验证方法。我的做法是利用 Flink 的 State Processor API 和批模式重放机制对流批结果做系统性比对。具体验证流程是这样的先用批模式跑一遍 HBase 里的历史数据产出全量统计结果作为基准。然后启动流模式作业消费 Kafka 中同时间段的数据等到所有数据全部消费完毕在scan.startup.mode设置为earliest-offset的情况下等待窗口期过后取出最终的聚合快照和基准结果做 diff。// 读取批量结果 DatasetRow batchResult spark.read() .parquet(hdfs://namenode:8020/tmp/batch_result) .select(user_id, sum_score, max_ts); // 读取流模式最终状态快照 Configuration conf new Configuration(); conf.setString(execution.runtime-mode, batch); StreamExecutionEnvironment env StreamExecutionEnvironment.getExecutionEnvironment(conf); Savepoint savepoint Savepoint.load(env, hdfs://namenode:8020/flink/savepoints/savepoint-20240101, new RocksDBStateBackend(hdfs://namenode:8020/flink/rocksdb));实际验证时我建议注意三件事。第一时间窗口要对齐——流模式输出的窗口结果和批模式的时间切分不一定完全一致需要确保比较口径相同否则 diff 出来的差异全是假阳性。第二验证样本要覆盖边界场景——凌晨流量低谷、双十一流量高峰、业务字段新增等极端情况都要单独检查。第三验证逻辑本身要纳入 CICD 流程——每次修改 SQL 或新增业务逻辑后自动触发一次重放比对避免人为遗忘。还有一个实践中的小技巧流批作业共享的 SQL 逻辑建议用单独的模块管理通过 CI 在提交时做语法校验和运行模式双测。我之前遇到过一次事故——在流 SQL 里加了某个批模式的窗口函数语法结果流作业提交后直接报错线上链路中断了半小时。从那以后我每次改 SQL 都强制跑一遍批流双模验证同一份 SQL 先在本地用批模式读历史数据再切流模式消费测试 topic两边输出一致才允许上线。这已经成了团队的标准动作希望对你也有参考价值。验证框验就写到这里具体到你的业务场景欢迎在实践中给我反馈。希望帮到你。本文还有配套的精品资源点击获取