企业官网建设流程全解析

Flink SQL 优化的第一性原理

在讲 10 个技巧前，先建立一句话心智模型：Flink SQL 慢，99% 不是 SQL 写得差，而是"状态太大、数据倾斜、外部 IO 阻塞、资源配置错"这四件事之一。下面所有技巧都是冲着这四件事去的。

我们约定一个典型场景贯穿全文：一个"用户行为日志 → 实时聚合 → 写入 OLAP"的 ETL 作业，峰值 20 万 events/s。

一、并行度与 Slot 共享组：别让资源错配

技巧 1：按算子瓶颈设置非均匀并行度

新手常把全局并行度设一个数（如 8），但 source、聚合、sink 的瓶颈完全不同。Flink SQL 可以通过SET+ 算子 hint 细粒度控制：

-- 给 source 高并行度抢数据, 给 sink 低并行度省连接数 CREATE TABLE source_kafka (...) WITH (...); -- 通过 table.optimizer 或 pipeline 配置, 关键参数: SET 'parallelism.default' = '8'; -- 对重聚合算子单独提升 (需 lookup hint 或改写为 CTE + 单独作业)

更实用的做法：观察到反压在哪个算子（Web UI 的反压面板），只给那个算子加并行度，而不是全局加倍（全局加倍会浪费 source/sink 的连接资源）。

技巧 2：用 Slot 共享组隔离重算子

默认所有算子共享 slot，一个重算子可能拖垮同 slot 的轻算子。用slot-sharing-group把重聚合和轻 filter 隔开：

-- DataStream API 侧示例 (SQL 可通过 compiled plan 调整) env.addSource(...).slotSharingGroup("heavy") .keyBy(...).aggregate(...).slotSharingGroup("heavy");

经验值：20 万 events/s 的聚合作业，并行度 16~32、每个 TM 4 slot 是常见甜点区。

二、数据倾斜：流式作业的头号杀手

技巧 3：热点 key 打散（加盐局部聚合 + 去盐全局聚合）

倾斜是 Flink 最常见的反压源。比如user_id里有个大 V 占了 30% 流量，直接GROUP BY user_id会被它压垮。

-- 两阶段: 先加盐局部聚合, 再去盐全局聚合 -- 阶段一: 加随机前缀打散 INSERT INTO agg_local SELECT concat(user_id, '_', cast(rand()*8 as int)) AS salted_key, count(*) AS cnt FROM source_kafka GROUP BY concat(user_id, '_', cast(rand()*8 as int)); -- 阶段二: 去掉盐, 合并 INSERT INTO agg_global SELECT split_index(salted_key, '_', 0) AS user_id, sum(cnt) AS cnt FROM agg_local GROUP BY split_index(salted_key, '_', 0);

配合下面的**技巧 10（Local-Global 聚合）**可自动完成两阶段，无需手写。

技巧 4：用 MiniBatch 聚合削峰

开 MiniBatch 后，Flink 不逐条触发聚合，而是攒一小批（如 1s）一起算，大幅减少 state 访问次数：

SET 'table.exec.mini-batch.enabled' = 'true'; SET 'table.exec.mini-batch.allow-latency' = '1 s'; SET 'table.exec.mini-batch.size' = '5000';

实测：相同负载下 MiniBatch 让聚合算子的 state 访问次数降60%~80%，CPU 占用明显下降。

三、状态管理：别让 Checkpoint 拖死你

技巧 5：状态 TTL 定期清理，避免无限膨胀

很多作业状态只关心"最近 7 天"，但忘了设 TTL，状态越积越大，Checkpoint 越来越慢直到超时。

-- 给聚合/去重状态设 7 天 TTL SET 'table.exec.state.ttl' = '7 d'; -- 或在 DDL 里针对某状态 CREATE TABLE dedup_out (...) WITH ( 'state.ttl' = '7d' );

务必设 TTL，否则三个月后你会在凌晨被 Checkpoint 超时告警叫醒。

技巧 6：RocksDB + 增量 Checkpoint + 本地磁盘调优

状态大的作业（GB 级以上），Heap 后端会 OOM，必须用 RocksDB，并开增量 checkpoint：

SET 'state.backend' = 'rocksdb'; SET 'state.backend.rocksdb.checkpoint.transfer.thread.num' = '4'; SET 'state.checkpoints.incremental' = 'true'; SET 'state.backend.rocksdb.memory.managed' = 'true'; -- 交给 Flink 管理 memtable 内存

增量 checkpoint 让每次只存变化的数据块，Checkpoint 时间从分钟级降到秒级。再配合把 RocksDB 的dbStoragePath指向本地 SSD（不是 HDFS），随机写性能直接起飞。（这块我们在第四周 ClickHouse、第五周 StarRocks 也有类似"本地盘优先"的经验。）

四、开窗与乱序：正确性优先

技巧 7：开窗 + allowedLateness 的正确姿势

窗口聚合最怕迟到数据导致结果反复跳变。用allowedLateness+ 侧输出兜底（详见第九周 Flink 窗口那篇）：

SELECT window_start, window_end, province, count(*) AS pv FROM TABLE(TUMBLE(TABLE source_kafka, DESCRIPTOR(ts), INTERVAL '10' MINUTE)) GROUP BY window_start, window_end, province; -- 迟到数据通过 watermark + allowed_lateness 控制; -- 极端迟到走 side output, 不污染主结果

重点是：watermark 不要设太紧（否则丢数据），也不要太松（否则延迟高）。一般取"业务可接受的乱序边界 + 网络抖动余量"。

技巧 8：去重与 Top-N 用内置优化

SQL 里的ROW_NUMBER() OVER (PARTITION BY ... ORDER BY ...)做 Top-N 时，Flink 有专门的AppendOnlyTopN/UpdatableTopN优化，会自动只保留 top 元素进状态。别手写成ORDER BY + LIMIT子查询，后者不会触发优化：

-- ✅ 触发 TopN 优化 SELECT * FROM ( SELECT *, ROW_NUMBER() OVER (PARTITION BY province ORDER BY score DESC) AS rn FROM source_kafka ) WHERE rn <= 10;

五、外部 IO：别让 join 和维表拖垮吞吐

技巧 9：维度表 join 用 Lookup Join + 缓存，异步 IO 替代同步

维表 join（比如关联用户画像）如果每次去查 MySQL/Redis，同步调用会让算子吞吐暴跌。正确做法：

-- 1) 声明带缓存的 Redis 维表 CREATE TABLE dim_user ( user_id STRING, age INT, city STRING ) WITH ( 'connector' = 'redis', 'lookup.cache.max-rows' = '100000', 'lookup.cache.ttl' = '1 h' ); -- 2) 用异步 lookup (redis connector 支持 async) SELECT o.user_id, d.city, count(*) AS cnt FROM source_kafka AS o LEFT JOIN dim_user FOR SYSTEM_TIME AS OF o.proctime AS d ON o.user_id = d.user_id GROUP BY o.user_id, d.city;

如果连接器不支持异步，用Async IO自定义（第九周 MCP、第六周 Flink CDC 都强调过异步解耦的价值）。缓存命中率高的维表，加 LRU 缓存后吞吐可提升5~10 倍。

技巧 10：Local-Global 两阶段聚合（自动版技巧 3）

不想手写加盐？开这个开关，Flink 自动在 map 端做局部聚合再 shuffle：

SET 'table.optimizer.agg-phase-strategy' = 'TWO_PHASE'; -- 默认就是, 但确保没被关 SET 'table.exec.local-agg.enabled' = 'true';

它会自动把GROUP BY拆成"本地预聚合 + 全局合并"，天然缓解倾斜，是性价比最高的一个开关。

六、资源配置：算给你的作业"吃"对内存

6.1 Managed Memory 给 RocksDB 留足

SET 'taskmanager.memory.managed.size' = '2048m'; -- 给 RocksDB 状态用 SET 'taskmanager.memory.network.fraction' = '0.15'; -- 网络缓冲别太抠

RocksDB 的 memtable 和 block cache 都吃 managed memory，给少了会频繁落盘（写放大）。

6.2 背压排查 SOP

作业慢了先别改 SQL，按这个顺序查：

1. Web UI 反压面板 -> 找到反压算子 2. 若是 Source: 检查 kafka 分区数 >= 并行度 3. 若是 聚合: 上 MiniBatch + 两阶段聚合 + 查倾斜 key 4. 若是 Sink: 检查目标库写入瓶颈 (批量/并行度/索引) 5. 若是 状态算子: 查 TTL + RocksDB 磁盘 IO

七、优化前后实测对比

同一个 20 万 events/s 的聚合作业，逐项开启上述技巧的累积效果：

延迟降76%、吞吐提升110%、Checkpoint 从"随时超时"变稳定 5~6s。这就是系统化优化的威力。

八、总结

Flink SQL 优化不是玄学，而是一张清晰的 checklist：并行度对齐瓶颈算子 → 打散倾斜 → 状态设 TTL 并用 RocksDB 增量 → 开窗控制乱序边界 → 维表走缓存/异步 → 开 MiniBatch 和两阶段聚合 → 资源给够 managed memory。把这 10 个技巧落成作业的默认模板，新作业一上手就不会踩坑。

下一篇预告

《推理即服务架构全景：vLLM 之外 5 种大模型部署方案深度对比》——把前面所有推理部署单点（vLLM/MLA/TensorRT-LLM/Triton/llama.cpp）串成一张完整的"推理即服务"选型地图与决策树。[49_推理即服务架构全景_vLLM之外5种大模型部署方案深度对比.md]

系列导航：

• Flink 工业 IoT 异常检测-从边缘采样到云端告警的数据闭环

• 向量数据库选型实战：Milvus vs Chroma vs Qdrant 谁更适合 RAG

• 向量数据库 + RAG 让 IoT 诊断拥有“记忆“