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 有优势

1. 大规模并行（MPP）

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

2. 资源弹性

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

3. 复用生态 Connector

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

4. 统一引擎

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

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

2.1 准备：Java 11+

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

java -version

下载并解压 Flink 二进制包：

tar -xzf flink-*.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 万行）：

CREATE TABLE Orders (
    order_number BIGINT,
    price        DECIMAL(32,2),
    buyer        ROW<first_name STRING, last_name STRING>,
    order_time   TIMESTAMP(3)
) WITH (
  'connector' = 'datagen',
  'number-of-rows' = '100000'
);

执行聚合 + 排序 + TopN：

SELECT buyer, SUM(price) AS total_cost
FROM Orders
GROUP BY  buyer
ORDER BY  total_cost LIMIT 3;

执行后去 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 管理

1. Catalog

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

2. 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 服务的体验拆成三块去优化：

1. 查询冷启动

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

2. 尾延迟稳定性

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

3. 运维友好

• 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，建议持续关注这些票据的进展，很多性能、可用性、冷启动体验的改进都会在这里推进。