Flink OLAP Quickstart把 Flink 当成“秒级交互查询”的 OLAP 服务来用-程序员充电站

1. Flink OLAP 服务整体架构

Flink OLAP 服务由三部分组成：

Client（客户端）
- 任何能和 Flink SQL Gateway 交互的客户端都行：SQL Client、Flink JDBC Driver 等
Flink SQL Gateway
- 负责解析 SQL、元数据查找、统计信息分析、优化执行计划，然后把 JobGraph 提交到集群
Flink Session Cluster（Session 集群）
- OLAP 查询运行在 Session 集群上，主要目的是避免每次查询都启动集群的额外开销

你可以把它理解成：Client 提交 SQL → SQL Gateway 做“编译/优化/生成作业” → Session 集群执行。

为什么 Flink 做 OLAP 有优势

大规模并行（MPP）

Flink 天生是并行计算系统，Planner 可以调整并行度来适配不同数据规模的延迟目标

资源弹性

资源管理支持 min/max scaling，能随工作负载动态伸缩（尤其在 K8s 上更明显）

复用生态 Connector

直接复用 Flink 丰富的 Connector：读各种数据源、写各种下游

统一引擎

Streaming / Batch / OLAP 统一一套引擎与开发体验，团队成本更低

2. 本地快速跑通（Local Mode）

2.1 准备：Java 11+

先确认 Java 版本（Quickstart 里要求至少 Java 11）：

java-version

下载并解压 Flink 二进制包：

tar-xzfflink-*.tgz

2.2 启动本地集群

./bin/start-cluster.sh

启动后打开 Flink Web UI（本地默认）：

http://localhost:8081

你应该能看到集群已启动。

2.3 启动 SQL Client CLI（内嵌 Gateway）

./bin/sql-client.sh

2.4 跑一条 OLAP 风格聚合查询

先把结果模式设置成 table（示例里用 tableau）：

SET'sql-client.execution.result-mode'='tableau';

创建一个 datagen 表模拟 Orders（10 万行）：

CREATETABLEOrders(order_numberBIGINT,priceDECIMAL(32,2),buyerROW<first_name STRING,last_name STRING>,order_timeTIMESTAMP(3))WITH('connector'='datagen','number-of-rows'='100000');

执行聚合 + 排序 + TopN：

SELECTbuyer,SUM(price)AStotal_costFROMOrdersGROUPBYbuyerORDERBYtotal_costLIMIT3;

执行后去 Web UI（http://localhost:8081）里看 Job 详情，你能直观看到查询如何被拆成算子、如何并行执行。

3. 生产部署要点（Production Ready）

真正要把 Flink 用成“OLAP 服务”，关键点是：稳定、低冷启动、低端到端延迟（E2E）、更好的资源利用率。Quickstart 给了一个非常典型的生产形态：

Flink Session Cluster：长期在线，承载 OLAP 查询
Flink SQL Gateway：无状态服务，可水平扩展
Client：推荐 JDBC Driver（更适合生产连接管理）

3.1 Client：优先用 Flink JDBC Driver，并复用连接

生产提交查询推荐 Flink JDBC Driver，因为它提供底层连接管理能力。最关键的实践是：

尽量复用 JDBC 连接，避免频繁创建/关闭 Gateway session
这样可以显著降低 E2E 查询延迟（尤其是短查询、交互式场景）

3.2 集群：Session 模式 + Native Kubernetes

生产建议用 Native Kubernetes 的 session mode 部署 Session Cluster：

动态分配/回收 TaskManager
承载波峰波谷更友好

并且推荐配置：

slotmanager.number-of-slots.min

它的意义是：预留一部分“随时可用”的 slot 作为资源池，明显降低查询冷启动时间（Quickstart 里提到这和 FLIP-362 相关）。

3.3 SQL Gateway：无状态 + 服务发现 + 负载均衡

Gateway 推荐作为无状态微服务部署：

多实例注册到服务发现
客户端做负载均衡，把查询均匀打到各 Gateway 实例

这样做的收益是：提升可用性、避免单点、扩容简单。

3.4 数据源配置：Catalog 与 Connector 管理

Catalog

OLAP 场景建议配置 Catalog Store（Quickstart 提到 FileCatalogStore）
因为 OLAP 集群是长期运行服务，Catalog 信息变化不频繁，跨 session 复用可以减少冷启动成本

Connectors

Session Cluster 和 SQL Gateway 都依赖 connectors（分析 stats、读取数据源）
生产要把 connectors 的交付和版本治理当成“基础设施”，不要临时手动拷 jar

4. 推荐的生产配置与背后原因

下面是 Quickstart 提到的一组“很 OLAP 的配置”，我按模块解释一下它们为什么有用。

4.1 SQL & Table 选项

table.optimizer.join-reorder-enabled = true
- 开启 join reorder 可以让优化器选择更优 join 顺序，对复杂多表查询收益明显
pipeline.object-reuse = true
- 对象复用减少 GC 压力，提升吞吐和延迟稳定性
sql-gateway.session.plan-cache.enabled = true
- 计划缓存能减少重复查询的编译/优化成本，OLAP 场景非常实用

4.2 Runtime：OLAP 查询要用 BATCH 运行模式

execution.runtime-mode = BATCH
execution.batch-shuffle-mode = ALL_EXCHANGES_PIPELINED

原因（Quickstart 说得很关键）：

OLAP 查询的执行计划里可能同时出现 pipelined 与 blocking 边
Batch scheduler 可以按 stage 调度，避免某些场景的调度死锁风险
pipelined shuffle 能降低批查询延迟，让链路更“实时交互”

4.3 JDK 与 JVM：JDK17 + ZGC + code cache 调优

Quickstart 推荐：

JDK 版本：17
JVM 参数（额外）：
- -XX:PerMethodRecompilationCutoff=10000
- -XX:PerBytecodeRecompilationCutoff=10000
- -XX:ReservedCodeCacheSize=512M
- -XX:+UseZGC

背后逻辑：

JDK17 + ZGC 能显著降低停顿时间，OLAP 场景对“尾延迟”非常敏感
CodeCache 与 recompilation cutoff 调优更偏向稳定长时间运行的服务形态

4.4 调度/容错/重启策略：更像“查询服务”而不是“长跑作业”

jobmanager.execution.failover-strategy = full
restart-strategy.type = disable
jobstore.type = Memory
jobstore.max-capacity = 500

OLAP 查询通常是短作业或高频作业：

更希望失败时快速失败并由上层重试/兜底，而不是集群内部反复重启拖时间
jobstore 放内存更快，容量限制避免无限膨胀

4.5 网络与 Web：面向高并发查询的服务化调优

rest.server.numThreads = 32
- 提升 REST 并发处理能力（Gateway/集群交互更密集）
web.refresh-interval = 300000
- 降低 Web UI 刷新频率，避免 UI 本身成为额外负担
pekko.framesize = 104857600b
- 增大通信 frame，适配更复杂计划/更大消息

4.6 资源管理：TaskManager 与 JobManager 都要“够大”

Quickstart 的资源建议非常激进（典型 OLAP 配置思路）：

JM：2 副本（K8s）
JM CPU：16
JM memory：32g
TM CPU：16
TM slots：32
TM memory：65536m（64g）
managed memory：16384m（16g）
slotmanager.number-of-slots.min = taskManagerNumber * numberOfTaskSlots

核心思想：

OLAP 更倾向“单查询把计算尽量放在本地、减少网络/序列化”
TM 配大一些，能减少 shuffle、降低反序列化开销，整体更快更稳
JM 也要配大，因为它是计算与调度的单点

5. 一些落地经验：把“可用性”和“低冷启动”做扎实

你可以把 OLAP 服务的体验拆成三块去优化：

查询冷启动

预留 slot（slotmanager.number-of-slots.min）
复用 JDBC 连接
启用 plan cache
复用 catalog store

尾延迟稳定性

JDK17 + ZGC
object reuse
控制 Web UI 刷新与 REST 线程池
TM 资源不要太“碎片化”（大 TM 更利于局部计算）

运维友好

Gateway 无状态多副本
Session 集群独立出来（不跟别的 workload 混跑）
connector 与 catalog 的版本治理（避免“今天能查，明天 jar 不见了”）

6. Future Work：社区路线与相关 Tickets

Quickstart 提到 Flink OLAP 已在 Roadmap 中，相关工作追踪在：

https://issues.apache.org/jira/browse/FLINK-25318 https://issues.apache.org/jira/browse/FLINK-32898

如果你准备在生产上深用 Flink OLAP，建议持续关注这些票据的进展，很多性能、可用性、冷启动体验的改进都会在这里推进。

Flink OLAP Quickstart把 Flink 当成“秒级交互查询”的 OLAP 服务来用