3. Flink核心基础

在实时湖仓工程中，Flink承担着“流式计算引擎”的核心角色，而Iceberg则提供表格式的湖存储能力。要真正把两者组合成稳定可用的实时湖仓，必须先理解Flink自身的运行架构、编程接口、时间语义以及状态与检查点机制。本节围绕这五个关键点展开，为后续的Iceberg写入、增量读取与流批一体打下基础。

一、Flink运行时架构：从JobManager到TaskManager

Flink采用分布式主从架构。客户端提交作业后，由JobManager负责作业调度、检查点协调与故障恢复；TaskManager负责实际的任务执行，并通过Task Slot管理资源。一个Flink集群可以运行多个作业，每个作业被拆分为若干算子链，最终以并行子任务的形式分布在TaskManager上执行。

在实时湖仓场景中，数据通常从Kafka等消息队列进入，经过DataStream或SQL算子转换后写入Iceberg。此时并行度、Slot数量与Iceberg写入文件大小会相互影响：并行度过高会产生大量小文件，并行度过低则吞吐不足。因此架构理解不仅是概念问题，更直接影响湖仓写入质量。

二、DataStream API与Table API & SQL：两条编程路径

Flink提供两套主要编程接口。DataStream API面向底层流处理，适合需要精细控制事件顺序、定时器、状态和自定义算子的场景；Table API & SQL则提供声明式关系语义，适合表达过滤、聚合、连接和窗口等逻辑，并且天然支持流批统一。

在实时湖仓工程中，常见做法是：用SQL完成大部分ETL逻辑，用DataStream处理复杂事件或自定义状态逻辑，两者可以通过toChangelogStream、fromChangelogStream等方式互相转换。这样既保留SQL的开发效率，又保留DataStream的灵活性。

// DataStream 读取 Kafka 并写入 Iceberg 的典型骨架
DataStream<RowData> stream = env.fromSource(
    KafkaSource.<RowData>builder()
        .setBootstrapServers("kafka:9092")
        .setTopics("ods_orders")
        .setGroupId("flink-iceberg-demo")
        .build(),
    WatermarkStrategy.<RowData>forBoundedOutOfOrderness(Duration.ofSeconds(5))
        .withTimestampAssigner((event, ts) -> event.getLong(0)),
    "kafka-source"
);

// 通过 Table API 做聚合，再写回 Iceberg
Table result = tableEnv.sqlQuery(
    "SELECT window_start, window_end, shop_id, SUM(amount) AS gmv " +
    "FROM TABLE(TUMBLE(TABLE orders, DESCRIPTOR(event_time), INTERVAL '1' MINUTE)) " +
    "GROUP BY window_start, window_end, shop_id"
);

三、时间语义：事件时间、处理时间与水位线

时间语义决定了窗口、聚合和连接如何理解“时间”。Flink支持三种时间：事件时间（Event Time）、处理时间（Processing Time）和摄入时间（Ingestion Time）。实时湖仓中，事件时间最常用，因为它能正确处理乱序和延迟数据，保证结果可重放。

事件时间依赖水位线（Watermark）推进。水位线表示“时间小于该值的事件已经到齐”，窗口在水位线越过窗口结束时间后触发计算。水位线延迟设置过小会导致迟到数据被丢弃，设置过大则增加结果延迟。在Iceberg写入场景中，水位线还影响快照提交频率和文件可见性。

四、状态管理与检查点机制：Exactly-Once的基石

Flink的状态分为算子状态和键控状态。键控状态按key分区，常见类型包括ValueState、ListState、MapState和ReducingState。状态让Flink能够跨事件记住信息，例如累计GMV、去重集合或会话窗口。

检查点（Checkpoint）是Flink实现容错的核心机制。JobManager周期性触发检查点，算子将状态快照写入状态后端（如HashMapStateBackend或EmbeddedRocksDBStateBackend），并配合精确一次或至少一次语义。当作业失败时，Flink从最近一次完成的检查点恢复，重新处理检查点之后的数据。

ExecutionCheckpointingOptions.CHECKPOINTING_INTERVAL: 60s
ExecutionCheckpointingOptions.CHECKPOINTING_TIMEOUT: 10min
ExecutionCheckpointingOptions.MAX_CONCURRENT_CHECKPOINTS: 1
ExecutionCheckpointingOptions.CHECKPOINTING_MODE: EXACTLY_ONCE
state.backend: rocksdb
state.backend.incremental: true

在写入Iceberg时，检查点与Iceberg提交紧密相关。Flink的Iceberg Sink通常在两阶段提交协议下工作：检查点期间预提交数据文件，检查点完成后再提交Iceberg快照。这样能保证端到端Exactly-Once，避免重复写入或数据丢失。

五、常见误区与复盘

• 误区一：并行度越高越好。并行度过高会导致Iceberg小文件激增，建议结合分区和文件大小目标调整。
• 误区二：忽略水位线延迟。水位线设置过小会丢弃迟到数据，导致湖仓结果不完整。
• 误区三：检查点与Iceberg提交脱节。若未启用两阶段提交，可能出现重复数据或快照不一致。
• 误区四：状态无限增长。键控状态未设置TTL会导致RocksDB膨胀，最终拖垮作业。