Flink面试题及详细答案100道（81-100）- 部署、优化与生态

《前后端面试题》专栏集合了前后端各个知识模块的面试题，包括html，javascript，css，vue，react，java，Openlayers，leaflet，cesium，mapboxGL，threejs，nodejs，mangoDB，SQL，Linux… 。

前后端面试题-专栏总目录

一、本文面试题目录

81. Flink支持哪些部署模式（如Standalone、YARN、K8s等）？各自的部署步骤是什么？

Flink支持多种部署模式，适应不同的集群环境和业务需求，主要包括：

1. Standalone模式

特点：独立部署，不依赖外部资源管理器，适合测试和小规模生产环境。

部署步骤：

1. 下载并解压Flink安装包：

   wget https://archive.apache.flink.apache.org/downloads.html/flink-1.18.0-bin-scala_2.12.tgz
   tar -xzf flink-1.18.0-bin-scala_2.12.tgz
   cd flink-1.18.0
   

2. 配置集群节点（conf/workers）：

   node1
   node2
   node3
   

3. 配置主节点（conf/masters）：

   node1:8081
   

4. 启动集群：

   ./bin/start-cluster.sh
   

5. 验证部署：访问http://node1:8081查看Web UI。

2. YARN模式

特点：依赖Hadoop YARN资源管理器，适合已有Hadoop生态的环境。

部署步骤：

1. 确保Hadoop环境变量配置正确（HADOOP_HOME）。

2. 启动YARN Session（Session模式）：

   ./bin/yarn-session.sh -n 2 -s 2 -jm 1024 -tm 2048 -nm flink-session
   

   • -n：TaskManager数量；-s：每个TM的 slots；-jm：JobManager内存；-tm：每个TM内存。

3. 提交作业到YARN（Per-Job模式）：

   ./bin/flink run -m yarn-cluster -yn 2 -ys 2 ./examples/streaming/WordCount.jar
   

3. Kubernetes（K8s）模式

特点：容器化部署，适合云原生环境，支持自动扩缩容。

部署步骤：

1. 准备K8s集群和kubectl工具。

2. 部署Flink集群（使用官方Helm Chart）：

   helm repo add flink https://archive.apache.org/dist/flink/flink-helm-chart-1.18.0/
   helm install flink-cluster flink/flink
   

3. 提交作业到K8s：

   ./bin/flink run -t kubernetes-application \-Dkubernetes.cluster-id=flink-cluster \./examples/streaming/WordCount.jar
   

4. 其他模式

• Mesos模式：适用于Mesos资源管理器的集群。
• Cloud模式：如AWS EMR、Google Cloud Dataproc等托管服务。

82. 如何在YARN上部署Flink集群？Session模式和Per-Job模式有何区别？

在YARN上部署Flink主要有两种模式，适用于不同场景：

YARN部署通用前提

• 安装Hadoop（2.8+）并启动YARN集群。
• 配置HADOOP_HOME和YARN_CONF_DIR环境变量。

1. Session模式部署

原理：在YARN上启动一个长期运行的Flink集群（包含JobManager和TaskManager），多个作业共享该集群资源。

部署步骤：

# 启动YARN Session（指定资源参数）
./bin/yarn-session.sh \-n 3 \          # TaskManager数量-s 4 \          # 每个TaskManager的slots数量-jm 2048 \      # JobManager内存（MB）-tm 4096 \      # 每个TaskManager内存（MB）-nm flink-session \  # YARN应用名称-d              # 后台运行

提交作业到Session：

./bin/flink run -m yarn-session -c org.apache.flink.examples.streaming.WordCount ./examples/streaming/WordCount.jar

2. Per-Job模式部署

原理：每个作业单独启动一个Flink集群，作业完成后集群自动销毁，资源隔离性更好。

部署步骤：

# 直接提交作业，YARN会为其创建专属集群
./bin/flink run -t yarn-per-job \-c org.apache.flink.examples.streaming.WordCount \-Dtaskmanager.numberOfTaskSlots=4 \-Djobmanager.memory.process.size=2048m \-Dtaskmanager.memory.process.size=4096m \./examples/streaming/WordCount.jar

模式对比

特性	Session模式	Per-Job模式
资源隔离	弱（多作业共享资源）	强（每个作业独立资源）
启动开销	低（集群复用）	高（每个作业启动新集群）
适用场景	小作业、短作业、开发测试	大作业、长作业、生产环境
资源利用率	高（资源共享）	较低（资源独占）
故障影响	集群故障影响所有作业	单个作业故障不影响其他作业

83. Flink on K8s的核心组件有哪些？如何实现作业的自动扩缩容？

Flink on Kubernetes将Flink作业部署在容器化环境中，核心组件和扩缩容机制如下：

核心组件

1. JobManager Deployment：

   • 管理作业生命周期，包含JobMaster和ResourceManager。
   • 以K8s Deployment形式部署，确保高可用（默认1副本）。

2. TaskManager Deployment/StatefulSet：

   • 执行实际计算任务，按并行度动态创建。
   • 通常使用StatefulSet保证稳定的网络标识。

3. ConfigMap：

   • 存储Flink配置（flink-conf.yaml），如并行度、状态后端等。

4. Service：

   • 暴露JobManager的REST和UI端口（如8081），供外部访问。

5. JobManager High Availability：

   • 依赖K8s的Leader选举或外部存储（如ZooKeeper）实现HA。

自动扩缩容实现

Flink on K8s通过两种方式实现自动扩缩容：

1. 基于K8s HPA（Horizontal Pod Autoscaler）：

   • 根据指标（如CPU利用率、TaskManager负载）自动调整TaskManager数量。

   # hpa.yaml
   apiVersion: autoscaling/v2
   kind: HorizontalPodAutoscaler
   metadata:name: flink-taskmanager-hpa
   spec:scaleTargetRef:apiVersion: apps/v1kind: Deploymentname: flink-taskmanagerminReplicas: 2maxReplicas: 10metrics:- type: Resourceresource:name: cputarget:type: UtilizationaverageUtilization: 70  # CPU利用率超过70%时扩容
   

2. Flink Native Kubernetes Autoscaler（1.17+）：

   • 基于作业背压、Slot利用率等Flink内部指标动态调整资源。

   # 提交作业时启用自动扩缩容
   ./bin/flink run -t kubernetes-application \-Dkubernetes.operator.autoscaler.enabled=true \-Dkubernetes.operator.autoscaler.min-replicas=2 \-Dkubernetes.operator.autoscaler.max-replicas=10 \./examples/streaming/WordCount.jar
   

扩缩容注意事项

• 状态作业扩缩容需确保状态可重分区（Keyed State支持自动重分配）。
• 扩容可能导致短期性能波动（数据重分布）。
• 缩容前需确保Checkpoint完成，避免数据丢失。

84. 什么是Flink的“资源隔离”？不同部署模式下资源隔离的实现方式是什么？

资源隔离指Flink作业或任务之间相互独立使用计算资源（CPU、内存、网络等），避免相互干扰。不同部署模式的实现方式不同：

1. 内存隔离

• 原理：限制每个组件（JobManager/TaskManager）的内存使用，防止OOM影响其他进程。

• 实现方式：

  • Standalone模式：通过JVM参数（-Xmx、-Xms）限制进程内存，依赖操作系统的内存隔离。
  • YARN模式：YARN的Container机制为每个Flink组件分配独立内存，超出则被Kill。
  • K8s模式：通过Pod的resources.limits.memory配置内存上限，Kubelet负责 enforcement。

2. CPU隔离

• 原理：控制每个任务的CPU使用率，避免某一任务占用过多CPU资源。

• 实现方式：

  • Standalone模式：依赖操作系统的CPU调度（如Linux Cgroups），可通过taskmanager.cpu.cores限制。
  • YARN模式：YARN Container通过yarn.scheduler.minimum-allocation-vcores分配CPU核心。
  • K8s模式：通过Pod的resources.limits.cpu配置CPU上限，K8s调度器保证资源隔离。

3. 网络隔离

• 原理：限制任务的网络带宽，避免网络拥塞影响其他作业。

• 实现方式：

  • K8s模式：通过Network Policy或CNI插件（如Calico）限制Pod间网络流量。
  • YARN模式：部分YARN版本支持QoS机制限制Container网络带宽。

4. 资源隔离对比

部署模式	内存隔离	CPU隔离	网络隔离	隔离强度
Standalone	JVM参数 + OS进程隔离	弱（依赖OS调度）	无	低
YARN	Container内存限制	Container vCore分配	弱（部分支持）	中
K8s	Pod内存limits	Pod CPU limits	Network Policy	高

配置示例（K8s内存和CPU隔离）

# TaskManager Pod模板片段
spec:containers:- name: flink-taskmanagerimage: flink:1.18resources:requests:memory: "4Gi"cpu: "2"limits:memory: "8Gi"  # 内存上限cpu: "4"       # CPU上限

85. Flink作业的“反压（Backpressure）”会导致哪些问题？如何定位和解决反压？

反压指数据流处理速度不均衡，下游算子处理能力不足，导致数据在 upstream 算子堆积，形成压力传递。

反压导致的问题

1. 吞吐量下降：数据处理速度变慢，端到端延迟增加。
2. Checkpoint超时：数据堆积导致状态快照时间过长，Checkpoint失败。
3. 资源浪费：上游算子因等待下游而空闲，资源利用率降低。
4. 数据倾斜加剧：反压可能导致热点Key的处理延迟进一步恶化。

反压定位方法

1. Flink Web UI：

   • 查看“Backpressure”页面，算子颜色越红表示反压越严重。
   • 检查“Metrics”中的backpressure.time指标，值越高反压越明显。

2. Metrics监控：

   • bufferPool.available：可用缓冲区数量（持续为0说明反压）。
   • outputQueueLength：输出队列长度（持续增长表示下游处理慢）。

3. 日志分析：

   • 搜索TaskManager日志中的“Backpressure detected”关键字。
   • 检查是否有频繁的GC日志（可能因内存不足导致处理慢）。

反压解决策略

1. 优化下游算子性能：

   • 简化算子逻辑（如减少复杂计算、IO操作）。
   • 使用异步IO（AsyncFunction）处理外部系统交互。

2. 增加并行度：

   • 提高下游算子的并行度，分散处理压力：

     dataStream.keyBy(...).window(...).process(...).setParallelism(16);  // 增加并行度
     

3. 调整缓冲区大小：

   • 增大缓冲区（taskmanager.network.memory.buffer-size）缓解短期反压：

     # flink-conf.yaml
     taskmanager.network.memory.buffer-size: 64kb
     

4. 解决数据倾斜：

   • 对热点Key进行加盐拆分（见68题），均衡负载。

5. 资源扩容：

   • 增加TaskManager的CPU或内存资源，提升处理能力。

86. 如何优化Flink作业的吞吐量？有哪些关键参数可以调整？

优化Flink作业吞吐量需从资源配置、算子优化、状态管理等多方面入手，关键参数和方法如下：

1. 并行度优化

• 原则：并行度应匹配集群CPU核心数（通常为CPU核心数的1~2倍）。
• 参数：

  // 全局并行度
  env.setParallelism(16);// 算子单独设置并行度
  dataStream.keyBy(...).window(...).process(...).setParallelism(32);
  

2. 内存配置优化

• 调整TaskManager内存：

  # flink-conf.yaml
  taskmanager.memory.process.size: 16g  # 总内存
  taskmanager.memory.task.heap.size: 8g  # 任务堆内存（用于用户逻辑）
  taskmanager.memory.managed.size: 4g   # 托管内存（用于状态和排序）
  

3. 网络参数优化

• 增大网络缓冲区：

  taskmanager.network.memory.buffer-size: 64kb  # 单个缓冲区大小
  taskmanager.network.memory.max: 8g            # 网络内存上限
  

• 启用网络压缩：

  taskmanager.network.compress: true  # 压缩网络传输数据
  

4. 状态后端优化

• 使用RocksDB并启用增量Checkpoint：

  RocksDBStateBackend backend = new RocksDBStateBackend("hdfs:///flink/checkpoints");
  backend.enableIncrementalCheckpointing(true);
  env.setStateBackend(backend);
  

• 配置RocksDB优化：

  state.backend.rocksdb.block.cache-size: 2g  # 增大块缓存
  state.backend.rocksdb.write.buffer.size: 64m  # 增大写缓冲
  

5. 算子链优化

• 启用算子链合并（默认开启）：

  pipeline.operator-chaining: true  # 合并相邻算子，减少序列化开销
  

• 关键算子单独拆分：

  dataStream.map(...).startNewChain()  # 从此算子开始新链.filter(...).disableChaining();  # 禁用后续算子链
  

6. 其他关键参数

参数	作用	建议值
parallelism.default	全局默认并行度	等于CPU核心数
state.checkpoint.interval	Checkpoint间隔	1~5分钟
taskmanager.numberOfTaskSlots	每个TaskManager的Slot数	等于CPU核心数/2
pipeline.object-reuse	启用对象重用（减少GC）	true
execution.batch-shuffle-mode	批处理Shuffle模式	ALL_EXCHANGES_BLOCKING

7. 业务逻辑优化

• 使用ReduceFunction/AggregateFunction替代ProcessWindowFunction（增量计算更高效）。
• 避免在热点算子中使用同步IO，改用AsyncFunction。
• 提前过滤无效数据，减少处理的数据量。

87. Flink中的“算子链（Operator Chaining）”是什么？如何控制算子链的合并与拆分？

算子链（Operator Chaining） 是Flink的优化机制，将多个相邻算子合并为一个任务（Task），减少线程间切换和数据序列化/反序列化开销，提升性能。

算子链的合并条件

1. 算子并行度相同。
2. 算子间为一对一连接（Forward分区策略）。
3. 算子未禁用链合并。
4. 上游算子的输出未被多个下游算子消费。

控制算子链的方法

1. 全局启用/禁用：

   # flink-conf.yaml（默认启用）
   pipeline.operator-chaining: true
   

2. 编程方式控制：

   DataStream<String> stream = env.socketTextStream("localhost", 9999);// 1. 禁用算子链（当前算子不与前后算子合并）
   stream.filter(s -> s.length() > 5).disableChaining().map(s -> s.toUpperCase()).print();// 2. 启动新链（当前算子与后续算子形成新链，不与前面合并）
   stream.map(s -> s.trim()).startNewChain().filter(s -> !s.isEmpty()).print();// 3. 全局禁用链（针对整个作业）
   env.disableOperatorChaining();
   

算子链的优势与适用场景

• 优势：

  • 减少线程间通信开销（同一Task内共享内存）。
  • 避免数据序列化/反序列化（内存中直接传递对象）。
  • 简化作业拓扑，降低调度复杂度。

• 适用场景：

  • 轻量级算子（如map、filter）适合合并。
  • 高吞吐、低延迟的场景。

• 不适用场景：

  • 计算密集型算子（如复杂聚合）应单独拆分，避免资源竞争。
  • 需要单独监控或调整并行度的算子。

算子链的可视化

在Flink Web UI的“Job Graph”中，合并的算子会显示为一个节点（如Map -> Filter），未合并的算子为独立节点。

88. 什么是Flink的“本地性（Locality）”优化？它如何提升作业性能？

本地性优化指Flink调度任务时，尽量将Task分配到数据所在的节点，减少跨节点数据传输，提升作业性能。

本地性级别（从高到低）

1. PROCESS_LOCAL：Task与数据在同一进程内（最优）。
2. NODE_LOCAL：Task与数据在同一节点的不同进程。
3. RACK_LOCAL：Task与数据在同一机架的不同节点。
4. ANY：不考虑本地性，可分配到任意节点（最差）。

实现机制

1. 数据源本地性：

   • 对于分区数据源（如Kafka），Flink会将消费Task调度到Kafka分区所在的Broker节点。
   • 示例：Kafka Topic的分区0在node1，Flink的Kafka Source Task 0优先分配到node1。

2. 中间数据本地性：

   • 对于KeyBy后的算子，Flink通过哈希分区确保相同Key的数据进入同一Task，减少数据移动。
   • Shuffle阶段尽量将数据传输到本地Task，避免跨节点网络IO。

3. 调度策略：

   • TaskManager启动时向ResourceManager注册可用Slot及节点信息。
   • JobManager的Scheduler根据数据位置和Slot分布，优先选择本地性高的节点分配Task。
   • 若本地Slot不可用，会等待slot.request.timeout（默认5秒）后降级选择低本地性节点。

性能提升效果

• 减少网络传输：本地性高的任务可避免跨节点数据传输，降低延迟和网络带宽消耗。
• 提高资源利用率：数据本地化减少了远程IO，CPU和内存资源更高效。
• 案例：Kafka Source任务的本地性优化可使吞吐量提升30%~50%。

配置参数

# flink-conf.yaml
# 本地性等待超时时间（超时后降级选择）
slot.request.timeout: 5000ms# 启用本地性感知调度（默认开启）
taskmanager.slot-request.locality-aware: true

89. Flink与Kafka集成时，如何保证“端到端的Exactly-Once”语义？

端到端Exactly-Once指数据从Kafka生产者到Flink处理，再到Kafka消费者的整个链路中，每个数据只被处理一次，不重复、不丢失。

实现条件

1. Kafka版本：0.11+（支持事务消息）。
2. Flink Checkpoint：启用Checkpoint（enableCheckpointing）。
3. 语义配置：生产者和消费者均需支持事务或幂等性。

实现步骤

1. 配置Flink Checkpoint：

   StreamExecutionEnvironment env = StreamExecutionEnvironment.getExecutionEnvironment();
   // 启用Checkpoint，间隔1秒，精确一次语义
   env.enableCheckpointing(1000, CheckpointingMode.EXACTLY_ONCE);
   env.getCheckpointConfig().setCheckpointTimeout(60000);
   

2. Kafka Source配置：

   • 使用FlinkKafkaConsumer，开启偏移量提交到Checkpoint：

   Properties consumerProps = new Properties();
   consumerProps.setProperty("bootstrap.servers", "kafka-broker:9092");
   consumerProps.setProperty("group.id", "flink-consumer-group");FlinkKafkaConsumer<String> consumer = new FlinkKafkaConsumer<>("input-topic",new SimpleStringSchema(),consumerProps
   );
   // 从Checkpoint恢复偏移量（而非Kafka的__consumer_offsets）
   consumer.setCommitOffsetsOnCheckpoint(false);
   consumer.setStartFromGroupOffsets(); // 初始偏移量从消费组获取
   

3. Kafka Sink配置（事务模式）：

   • 使用FlinkKafkaProducer，配置事务ID前缀和超时时间：

   Properties producerProps = new Properties();
   producerProps.setProperty("bootstrap.servers", "kafka-broker:9092");
   // 事务配置
   producerProps.setProperty("transaction.timeout.ms", "60000"); // 事务超时需小于Kafka的transaction.max.timeout.msFlinkKafkaProducer<String> producer = new FlinkKafkaProducer<>("output-topic",new KeyedSerializationSchemaWrapper<>(new SimpleStringSchema()),producerProps,FlinkKafkaProducer.Semantic.EXACTLY_ONCE  // 启用Exactly-Once
   );
   // 设置事务ID前缀（确保唯一性）
   producer.setTransactionalIdPrefix("flink-prod-");
   

4. 状态后端配置：

   • 使用支持持久化的状态后端（如FsStateBackend、RocksDBStateBackend）：

   env.setStateBackend(new FsStateBackend("hdfs:///flink/checkpoints"));
   

原理说明

• Source端：Flink将Kafka消费偏移量存入Checkpoint，故障恢复时从Checkpoint恢复偏移量，避免重复消费。
• Processing端：Checkpoint机制确保状态仅在所有算子完成快照后提交，保证状态一致性。
• Sink端：Flink通过Kafka事务机制，在Checkpoint完成后才提交事务，确保数据仅被写入一次。若Checkpoint失败，事务会被中止，数据不会被提交。

90. Flink的“Tumbling Window”和“Sliding Window”在性能上有何差异？如何选择？

Tumbling Window（滚动窗口）和Sliding Window（滑动窗口）是两种常用的时间窗口类型，性能和适用场景不同：

性能差异

特性	Tumbling Window（滚动窗口）	Sliding Window（滑动窗口）
窗口重叠性	无重叠（窗口大小=滑动步长）	可能重叠（滑动步长<窗口大小）
数据处理量	每个元素仅属于一个窗口	每个元素可能属于多个窗口（重叠越多处理量越大）
状态存储	低（窗口独立，无重叠数据）	高（重叠窗口需重复存储数据）
计算开销	低（一次计算）	高（多次计算）
输出频率	低（与窗口大小一致）	高（与滑动步长一致）

选择依据

1. Tumbling Window适用场景：

   • 周期性统计（如每小时订单总量）。
   • 对实时性要求不高，更关注计算效率。
   • 数据量较大，需控制状态存储和计算开销。

   // 1小时滚动窗口
   dataStream.keyBy(...).window(TumblingEventTimeWindows.of(Time.hours(1))).sum(1);
   

2. Sliding Window适用场景：

   • 高频更新的监控指标（如每5分钟更新一次最近1小时的流量）。
   • 需平滑过渡的趋势分析（减少窗口边界波动）。
   • 可接受较高计算和存储开销。

   // 1小时窗口，每5分钟滑动一次（重叠55分钟）
   dataStream.keyBy(...).window(SlidingEventTimeWindows.of(Time.hours(1), Time.minutes(5))).sum(1);
   

性能优化建议

• 滑动窗口优化：

  • 避免滑动步长过小（如窗口大小1小时，步长1分钟会导致60倍计算量）。
  • 结合增量计算（AggregateFunction）减少重复计算。
  • 使用RocksDBStateBackend存储状态，应对重叠窗口的大状态。

• 滚动窗口优化：

  • 合理设置窗口大小（避免过大导致状态累积，过小导致频繁计算）。
  • 启用Checkpoint压缩，减少状态存储开销。

91. 如何配置Flink的JVM参数以优化内存使用（如堆内存、堆外内存）？

Flink的JVM内存配置直接影响作业稳定性和性能，需根据任务类型（批处理/流处理）和数据规模优化：

内存模型概述

Flink将JVM内存分为：

• 堆内存（Heap Memory）：用于用户代码对象、算子状态（非RocksDB）。
• 堆外内存（Off-Heap Memory）：用于网络传输、RocksDB状态、托管内存。

堆内存配置

1. 全局配置（flink-conf.yaml）：

   # JobManager堆内存（默认1024m）
   jobmanager.memory.heap.size: 2048m# TaskManager堆内存（默认1024m）
   taskmanager.memory.heap.size: 4096m
   

2. JVM参数调优：

   # 通用JVM参数
   env.java.opts: >--XX:+UseG1GC  # 使用G1垃圾收集器（适合大堆内存）-XX:MaxGCPauseMillis=200  # 最大GC暂停时间-XX:+HeapDumpOnOutOfMemoryError  # OOM时生成堆转储-XX:HeapDumpPath=/tmp/flink-oom-dumps  # 堆转储路径
   

3. 针对大堆内存的优化：

   # 堆内存>8GB时启用
   env.java.opts: >--XX:+UseG1GC-XX:G1HeapRegionSize=32m  # 增大Region大小（默认1-32m）-XX:InitiatingHeapOccupancyPercent=70  # 触发GC的堆占用阈值
   

堆外内存配置

1. TaskManager堆外内存：

   # 堆外内存总大小（默认128m）
   taskmanager.memory.off-heap.size: 1024m# 网络缓冲区内存（默认128m，影响吞吐量）
   taskmanager.network.memory.buffer-size: 64kb
   taskmanager.network.memory.min: 512m
   taskmanager.network.memory.max: 2048m
   

2. RocksDB堆外内存：

   # 启用RocksDB托管内存
   state.backend.rocksdb.memory.managed: true# 分配给RocksDB的托管内存（默认0）
   taskmanager.memory.managed.size: 4096m
   

按作业类型配置建议

作业类型	堆内存重点配置	堆外内存重点配置
流处理	适中（2-8GB），避免GC频繁	增大网络缓冲区和RocksDB内存
批处理	较大（8-32GB），提升排序性能	适中，主要用于Shuffle传输

验证内存配置

启动集群后，通过Web UI（http://<jobmanager>:8081）的“Configuration”页面查看内存配置，或通过以下命令检查：

./bin/flink run -m <jobmanager> -p 1 ./examples/streaming/WordCount.jar --help
# 输出中会显示实际内存配置

92. Flink的“metrics系统”有什么作用？如何自定义metrics监控业务指标？

Flink的metrics系统用于收集和暴露作业运行时的各项指标（如吞吐量、延迟、状态大小），帮助监控作业健康状态和性能瓶颈。

metrics系统的作用

1. 实时监控：跟踪作业吞吐量、延迟、Checkpoint成功率等关键指标。
2. 问题诊断：通过异常指标（如反压、GC频繁）定位性能瓶颈。
3. 告警触发：结合监控工具（如Prometheus + Alertmanager）设置阈值告警。
4. 性能优化：基于指标数据调整并行度、内存等配置。

内置metrics类型

• Counter：计数（如输入记录数numRecordsIn）。
• Gauge：瞬时值（如当前状态大小stateSize）。
• Meter：吞吐量（如每秒处理记录数recordsPerSecond）。
• Histogram：分布统计（如延迟分布latencyHistogram）。

自定义metrics实现

1. 在算子中定义metrics：

   public class CustomMetricsMapFunction extends RichMapFunction<String, String> {private transient Counter inputCounter;  // 计数器：输入记录数private transient Gauge<Long> latencyGauge;  //  gauge：处理延迟private long totalLatency = 0;private long count = 0;@Overridepublic void open(Configuration parameters) {// 获取metrics组MetricGroup metricGroup = getRuntimeContext().getMetricGroup();// 注册计数器inputCounter = metricGroup.counter("input.records");// 注册GaugelatencyGauge = metricGroup.gauge("avg.latency", () -> {return count == 0 ? 0 : totalLatency / count;});}@Overridepublic String map(String value) {long start = System.currentTimeMillis();inputCounter.inc();  // 计数+1// 业务逻辑处理String result = value.toUpperCase();// 更新延迟统计totalLatency += (System.currentTimeMillis() - start);count++;return result;}
   }
   

2. 使用自定义算子：

   DataStream<String> input = env.socketTextStream("localhost", 9999);
   input.map(new CustomMetricsMapFunction()).print();
   

3. 配置metrics报告器（如Prometheus）：

   # flink-conf.yaml
   metrics.reporters: prom
   metrics.reporter.prom.class: org.apache.flink.metrics.prometheus.PrometheusReporter
   metrics.reporter.prom.port: 9249  # Prometheus拉取端口
   

4. 查看metrics：

   • 访问http://<taskmanager>:9249获取Prometheus格式的metrics。
   • 在Grafana中配置Prometheus数据源，可视化自定义指标。

最佳实践

• 命名规范：使用.分隔层级（如user.orders.count）。
• 避免高频更新：Gauge的计算逻辑应轻量，避免影响算子性能。
• 关键指标监控：优先监控业务核心指标（如交易成功率）和系统指标（如反压）。

93. Flink与Hadoop生态（如HDFS、HBase）如何集成？有哪些注意事项？

Flink可无缝集成Hadoop生态组件，利用其存储和计算能力，适用于批处理和流处理场景。

1. 与HDFS集成

集成方式：

• 读取HDFS文件：使用readTextFile或readFile：

  DataStream<String> hdfsData = env.readTextFile("hdfs:///path/to/file.txt");
  

• 写入HDFS：使用TextOutputFormat：

  dataStream.writeAsText("hdfs:///path/to/output").setParallelism(4).outputStreamFormat(new TextOutputFormat<>());
  

• Checkpoint存储：将Checkpoint保存到HDFS：

  env.setStateBackend(new FsStateBackend("hdfs:///flink/checkpoints"));
  

2. 与HBase集成

集成方式：

• 添加依赖：

  <dependency><groupId>org.apache.flink</groupId><artifactId>flink-connector-hbase-2.2_2.12</artifactId><version>1.18.0</version>
  </dependency>
  

• 读取HBase：使用HBaseInputFormat：

  Configuration hbaseConfig = HBaseConfiguration.create();
  hbaseConfig.set(TableOutputFormat.OUTPUT_TABLE, "user_table");
  hbaseConfig.set("hbase.zookeeper.quorum", "zk-node1,zk-node2");DataSource<Tuple2<ImmutableBytesWritable, Result>> hbaseSource = env.createInput(new HBaseInputFormat(), TypeInformation.of(new TypeHint<Tuple2<ImmutableBytesWritable, Result>>() {})).setParallelism(2);// 解析HBase结果
  DataStream<String> userData = hbaseSource.map(tuple -> {Result result = tuple.f1;String id = Bytes.toString(result.getValue(Bytes.toBytes("cf"), Bytes.toBytes("id")));return id;
  });
  

• 写入HBase：使用HBaseOutputFormat：

  dataStream.addSink(new HBaseSinkFunction<>()).setParallelism(2);// 自定义HBase Sink
  public class HBaseSinkFunction<T> extends RichSinkFunction<T> {private transient Table table;@Overridepublic void open(Configuration parameters) {Configuration hbaseConfig = HBaseConfiguration.create();hbaseConfig.set(TableOutputFormat.OUTPUT_TABLE, "user_table");hbaseConfig.set("hbase.zookeeper.quorum", "zk-node1,zk-node2");try {Connection conn = ConnectionFactory.createConnection(hbaseConfig);table = conn.getTable(TableName.valueOf("user_table"));} catch (IOException e) {throw new RuntimeException(e);}}@Overridepublic void invoke(T value, Context context) throws Exception {// 构建Put对象并写入HBasePut put = new Put(Bytes.toBytes(...));put.addColumn(Bytes.toBytes("cf"), Bytes.toBytes("field"), Bytes.toBytes(...));table.put(put);}
  }
  

注意事项

1. 版本兼容性：

   • Flink与Hadoop/HBase版本需匹配（如Flink 1.18支持Hadoop 2.8+、HBase 2.2+）。
   • 冲突解决：使用flink-shaded-hadoop避免依赖冲突。

2. 性能优化：

   • 批量写入HBase（设置hbase.client.write.buffer增大缓冲区）。
   • 读取HBase时设置合理的并行度（与Region数量匹配）。

3. 容错配置：

   • 写入HBase时启用Checkpoint，确保Exactly-Once语义。
   • 配置HDFS高可用（HA），避免单点故障影响Checkpoint。

4. 资源配置：

   • 增加TaskManager内存（HBase客户端缓存占用较大）。
   • 调整hbase.rpc.timeout避免超时（尤其大数据量场景）。

94. 什么是Flink的“动态表（Dynamic Table）”？它与流数据的关系是什么？

动态表（Dynamic Table） 是Flink Table API/SQL中对流数据的抽象，表示随时间变化的关系型数据，是流处理与关系型查询的桥梁。

动态表的特性

1. 随时间变化：动态表的数据会随着新流入的数据不断更新（插入、更新、删除）。
2. 与静态表的兼容性：支持SQL的SELECT、JOIN、GROUP BY等操作，但结果会动态更新。
3. 惰性计算：动态表的查询不会立即执行，而是转换为DataStream程序，在提交后运行。

与流数据的关系

1. 流数据 → 动态表：

   • 流数据可被转换为动态表，每条流记录对应表的一行数据。
   • 示例：持续流入的用户行为流可转换为“用户行为动态表”。

2. 动态表 → 流数据：

   • 动态表的查询结果仍是动态表，可转换回流数据（称为“表到流的转换”）。
   • 转换方式：
     • Append-only流：仅包含插入操作的流（适用于无更新的场景）。
     • Retract流：包含添加（INSERT）和撤回（DELETE）操作的流。
     • Upsert流：包含更新（UPDATE）和插入（INSERT）操作的流（通过主键区分）。

示例：流与动态表的转换

// 1. 创建流执行环境
StreamExecutionEnvironment env = StreamExecutionEnvironment.getExecutionEnvironment();
StreamTableEnvironment tableEnv = StreamTableEnvironment.create(env);// 2. 读取流数据并转换为动态表
DataStream<Order> orderStream = env.socketTextStream("localhost", 9999).map(line -> {String[] fields = line.split(",");return new Order(fields[0], Double.parseDouble(fields[1]), Long.parseLong(fields[2]));});// 注册表（动态表）
tableEnv.createTemporaryView("orders", orderStream, $("user"), $("amount"), $("event_time").rowtime());// 3. 动态表查询（计算每个用户的总消费）
Table resultTable = tableEnv.sqlQuery("SELECT user, SUM(amount) as total_amount " +"FROM orders " +"GROUP BY user, TUMBLE(event_time, INTERVAL '1' HOUR)"
);// 4. 动态表转换回流数据（Upsert流，按user主键）
DataStream<Tuple2<Boolean, Tuple2<String, Double>>> resultStream = tableEnv.toRetractStream(resultTable, TypeInformation.of(new TypeHint<Tuple2<String, Double>>() {}));resultStream.print();

动态表的生命周期

1. 初始状态：动态表为空。
2. 数据流入：新记录插入动态表，触发查询重新计算。
3. 查询更新：查询结果随动态表变化而更新，生成新的流记录。
4. 持续运行：只要流数据不断，动态表的查询就会持续执行。

95. Flink SQL与传统SQL有哪些区别？如何使用Flink SQL进行流处理？

Flink SQL是基于流处理的SQL方言，支持在流数据上执行关系型查询，但与传统批处理SQL（如MySQL）存在本质区别。

与传统SQL的区别

特性	传统SQL（批处理）	Flink SQL（流处理）
数据处理方式	处理有限的静态数据	处理无限的流数据
执行模式	一次性执行，返回完整结果	持续执行，增量输出结果
时间语义	无时间概念	支持事件时间、处理时间、摄入时间
表的特性	静态表（数据不变化）	动态表（数据随时间更新）
窗口操作	无（基于全量数据计算）	核心操作（基于时间或计数划分窗口）
输出结果	单一结果集	持续输出更新结果（Append/Retract/Upsert）
状态管理	无状态	有状态（需维护中间结果）

使用Flink SQL进行流处理的步骤

1. 创建执行环境：

   StreamExecutionEnvironment env = StreamExecutionEnvironment.getExecutionEnvironment();
   env.setStreamTimeCharacteristic(TimeCharacteristic.EventTime);
   StreamTableEnvironment tableEnv = StreamTableEnvironment.create(env);
   

2. 定义数据源（创建动态表）：

   • 从Kafka读取流数据并定义事件时间：

   CREATE TABLE user_behavior (user_id STRING,behavior STRING,event_time TIMESTAMP(3),WATERMARK FOR event_time AS event_time - INTERVAL '5' SECOND  -- 定义Watermark
   ) WITH ('connector' = 'kafka','topic' = 'user_behavior','properties.bootstrap.servers' = 'kafka-broker:9092','properties.group.id' = 'flink-sql-group','format' = 'json','scan.startup.mode' = 'earliest-offset'
   );
   

3. 编写流处理SQL查询：

   • 示例：每10分钟统计用户点击量：

   CREATE TABLE click_stats (user_id STRING,window_start TIMESTAMP(3),window_end TIMESTAMP(3),click_count BIGINT
   ) WITH ('connector' = 'kafka','topic' = 'click_stats','properties.bootstrap.servers' = 'kafka-broker:9092','format' = 'json'
   );INSERT INTO click_stats
   SELECT user_id,TUMBLE_START(event_time, INTERVAL '10' MINUTE) AS window_start,TUMBLE_END(event_time, INTERVAL '10' MINUTE) AS window_end,COUNT(*) AS click_count
   FROM user_behavior
   WHERE behavior = 'click'
   GROUP BY user_id, TUMBLE(event_time, INTERVAL '10' MINUTE);
   

4. 执行查询：

   tableEnv.executeSql("INSERT INTO click_stats ...");
   

关键概念与技巧

• Watermark定义：通过WATERMARK FOR指定事件时间列和乱序容忍时间。
• 窗口函数：使用TUMBLE（滚动）、HOP（滑动）、SESSION（会话）窗口。
• 状态管理：通过table.exec.state.ttl设置状态TTL，避免状态膨胀。
• 输出模式：根据Sink类型选择Append/Retract/Upsert模式（如Kafka支持Upsert）。

96. Flink的“Table API”和“SQL”的执行原理是什么？如何优化Flink SQL的性能？

Flink的Table API和SQL提供了声明式编程接口，其执行原理和性能优化如下：

执行原理

1. 解析与验证：

   • SQL语句或Table API调用被解析为抽象语法树（AST）。
   • 验证语法正确性、表结构匹配性、函数存在性等。

2. 逻辑计划生成：

   • AST转换为逻辑执行计划（Logical Plan），表示查询的逻辑操作（如过滤、聚合、连接）。

3. 优化逻辑计划：

   • 基于规则的优化（RBO）：如谓词下推、常量折叠、投影裁剪。
   • 基于成本的优化（CBO，1.13+）：估算不同执行路径的成本，选择最优计划。

4. 物理计划生成：

   • 逻辑计划转换为物理计划（Physical Plan），绑定具体的执行算子（如HashAggregate、WindowJoin）。
   • 确定数据分区策略（如HashPartition、RangePartition）。

5. 转换为DataStream程序：

   • 物理计划被转换为Flink DataStream的Transformation对象。
   • 最终生成可执行的JobGraph，提交到集群运行。

性能优化方法

1. 优化逻辑计划：

   • 谓词下推：确保过滤条件在数据源附近执行，减少数据传输量：

     -- 优化前：先聚合后过滤（处理数据量大）
     SELECT user_id, SUM(amount) FROM orders GROUP BY user_id HAVING user_id LIKE 'VIP%';-- 优化后：先过滤后聚合（处理数据量小）
     SELECT user_id, SUM(amount) FROM (SELECT * FROM orders WHERE user_id LIKE 'VIP%') GROUP BY user_id;
     

   • Flink SQL会自动进行谓词下推，无需手动优化。

2. 调整状态后端：

   • 大状态场景使用RocksDBStateBackend：

     table.exec.state.backend: rocksdb
     state.backend.rocksdb.enable.incremental.checkpoint: true
     

3. 优化窗口性能：

   • 使用AGGREGATE替代PROCESS函数（增量计算更高效）。
   • 合理设置窗口大小和滑动步长，避免过度重叠。

4. 配置并行度和资源：

   • 设置合理的全局并行度：

     parallelism.default: 16
     

   • 为计算密集型算子单独设置并行度：

     SET table.exec.resource.default-parallelism = 32;  -- 仅对当前会话有效
     

5. 启用对象重用和内存管理：

   pipeline.object-reuse: true  # 减少对象创建和GC
   table.exec.spill-compression.enabled: true  # 启用溢出数据压缩
   

6. 优化Join操作：

   • 小表Join使用广播（Broadcast Join）：

     table.optimizer.broadcast-join-threshold: 10485760  # 表大小阈值（10MB）
     

   • 大表Join确保按Key分区，避免数据倾斜。

7. 监控与调优：

   • 通过Web UI查看SQL作业的执行计划，识别瓶颈算子。
   • 监控状态大小、Checkpoint耗时等指标，及时调整配置。

查看执行计划

使用EXPLAIN命令分析SQL的执行计划，识别优化点：

EXPLAIN PLAN FOR
SELECT user_id, COUNT(*) FROM user_behavior GROUP BY user_id;

97. 如何排查Flink作业的性能瓶颈？有哪些常用的诊断工具？

排查Flink作业性能瓶颈需结合监控指标、日志分析和诊断工具，定位问题根源（如反压、数据倾斜、资源不足）。

常用诊断工具

1. Flink Web UI：

   • 功能：实时查看作业拓扑、算子指标、Checkpoint状态、反压情况。
   • 关键页面：
     • “Job Graph”：查看算子链和并行度。
     • “Backpressure”：识别反压算子（红色表示严重反压）。
     • “Metrics”：查看吞吐量（numRecordsInPerSecond）、延迟（processingTime）等。
     • “Checkpoints”：分析Checkpoint成功率和耗时。

2. Flink CLI：

   • 提交作业、触发Savepoint、查看作业状态：

     # 查看作业列表
     ./bin/flink list# 查看作业详情
     ./bin/flink info <job-id># 触发Savepoint
     ./bin/flink savepoint <job-id> <path>
     

3. Metrics系统：

   • 集成Prometheus + Grafana监控关键指标：
     • 吞吐量：flink_taskmanager_job_task_operator_numRecordsInPerSecond
     • 反压：flink_taskmanager_job_task_operator_backpressure_timeMsPerSecond
     • 状态大小：flink_taskmanager_job_task_operator_state_size
     • GC时间：flink_taskmanager_JVM_G1_Young_CollectionTime

4. 日志分析工具：

   • TaskManager日志：位于log/目录，包含算子异常、GC日志、反压警告。
   • JobManager日志：包含Checkpoint失败原因、作业提交日志。
   • 使用grep快速搜索关键信息：

     grep "Backpressure detected" log/flink-*-taskmanager-*.log
     

5. 火焰图（Flame Graph）：

   • 生成CPU火焰图分析热点函数：

     # 安装async-profiler
     wget https://github.com/jvm-profiling-tools/async-profiler/releases/download/v2.9/async-profiler-2.9-linux-x64.tar.gz
     tar -xzf async-profiler-2.9-linux-x64.tar.gz# 对TaskManager进程采样（PID为TaskManager的进程ID）
     ./profiler.sh -d 60 -f flamegraph.html <PID>
     

性能瓶颈排查流程

1. 检查反压：

   • Web UI的“Backpressure”页面，确认是否有算子持续处于红色状态。
   • 若存在反压，下游算子处理能力不足，需优化下游逻辑或增加并行度。

2. 分析数据倾斜：

   • 查看算子的numRecordsIn指标，若某并行实例的数值远高于其他，则存在倾斜。
   • 解决方法：Key加盐、自定义分区器（见68题）。

3. Checkpoint问题：

   • 若Checkpoint频繁失败，查看JobManager日志中的Checkpoint failed原因。
   • 常见原因：超时（增大checkpointTimeout）、状态过大（启用增量Checkpoint）。

4. 资源不足：

   • 监控CPU利用率（持续>80%表示CPU不足）。
   • 监控JVM堆内存（频繁Full GC表示内存不足）。
   • 解决方法：增加TaskManager的CPU/内存资源。

5. 外部系统瓶颈：

   • 若Sink算子反压，检查下游系统（如Kafka、数据库）的写入性能。
   • 使用异步IO（AsyncSink）减少外部系统阻塞。

98. Flink中的“对象重用（Object Reuse）”机制是什么？开启后需要注意什么？

对象重用是Flink的性能优化机制，允许算子复用输入对象而非每次创建新对象，减少JVM垃圾回收（GC）开销，提升吞吐量。

工作原理

• 默认情况下，Flink会为每条输入数据创建新对象，避免多线程访问冲突。
• 开启对象重用后，Flink会在算子处理完一条数据后，将对象重置并复用给下一条数据，减少对象创建和销毁的开销。

开启方式

1. 全局配置：

   # flink-conf.yaml
   pipeline.object-reuse: true
   

2. 代码中设置：

   StreamExecutionEnvironment env = StreamExecutionEnvironment.getExecutionEnvironment();
   env.getConfig().enableObjectReuse();  // 启用对象重用
   

注意事项

1. 线程安全问题：

   • 重用的对象可能被多个线程同时访问（如异步操作、定时器），导致数据错乱。
   • 解决：避免在算子外缓存对象，或使用不可变对象。

2. 状态存储风险：

   • 若将重用对象直接存入状态（如ValueState.update(obj)），后续对象修改会导致状态数据被意外篡改。
   • 解决：存入状态前创建对象副本：

     // 错误：直接存储重用对象
     valueState.update(reusedObj);// 正确：存储副本
     MyObject copy = new MyObject(reusedObj);  // 深拷贝
     valueState.update(copy);
     

3. 跨算子传递问题：

   • 上游算子的重用对象若被下游算子修改，会影响上游后续处理。
   • 解决：在算子间传递时创建副本，或确保对象不可变。

4. 调试困难：

   • 对象内容会随处理过程动态变化，日志打印可能显示非预期值。
   • 解决：打印时创建对象副本，或禁用对象重用调试。

适用场景

• 高吞吐场景：数据量大、对象创建频繁（如日志处理）。
• 计算密集型算子：减少GC停顿对计算的影响。
• 对象体积大：重用大对象可显著降低内存分配开销。

不适用场景

• 复杂状态操作：频繁将对象存入状态，需大量拷贝抵消重用收益。
• 异步处理：存在多线程访问对象的场景，易引发线程安全问题。

99. 什么是Flink的“阴影类加载器（Shadow ClassLoader）”？它解决了什么问题？

阴影类加载器（Shadow ClassLoader） 是Flink用于隔离用户代码和框架依赖的类加载机制，避免因依赖版本冲突导致的作业失败。

解决的问题

• 依赖冲突：用户作业的依赖（如Kafka客户端、Jackson）可能与Flink框架自带的依赖版本冲突，导致NoSuchMethodError、ClassCastException等异常。
• 类隔离：确保不同作业的依赖相互独立，避免相互干扰（如作业A使用Jackson 2.8，作业B使用Jackson 2.12）。

工作原理

1. 类加载层次：

   • Flink框架类加载器：加载Flink核心类（如org.apache.flink.*）。
   • 阴影类加载器：为每个作业创建独立的类加载器，加载用户代码和其依赖的第三方库。
   • 父类委托机制：优先从框架类加载器加载类，若未找到则从阴影类加载器加载，避免重复加载。

2. 依赖隔离策略：

   • 优先加载框架类：Flink核心类（如org.apache.flink.streaming.api.*）始终从框架类加载器加载，确保一致性。
   • 用户依赖隔离：用户JAR中的第三方库（如com.fasterxml.jackson.*）由阴影类加载器加载，与框架版本隔离。

配置与使用

• 默认行为：Flink自动启用阴影类加载器，无需额外配置。

• 自定义阴影规则：通过flink-conf.yaml指定需要隔离或共享的类：

  # 强制使用框架类（不隔离）
  classloader.resolve-order: parent-first
  classloader.parent-first-patterns-additional: org.slf4j,org.apache.log4j# 强制使用用户类（隔离）
  classloader.child-first-patterns: com.fasterxml.jackson,org.apache.kafka
  

• 打包用户作业：

  • 使用maven-shade-plugin对用户依赖进行重命名（可选），彻底避免冲突：

    <plugin><groupId>org.apache.maven.plugins</groupId><artifactId>maven-shade-plugin</artifactId><version>3.2.4</version><configuration><relocations><relocation><pattern>com.fasterxml.jackson</pattern><shadedPattern>myapp.shaded.jackson</shadedPattern></relocation></relocations></configuration>
    </plugin>
    

常见问题处理

• ClassNotFoundException：用户依赖未包含在JAR中，需使用-include-dependencies打包。
• LinkageError：类版本冲突，可通过child-first-patterns强制使用用户类。
• 序列化问题：确保跨类加载器的对象可序列化（如实现Serializable）。

100. Flink未来的发展趋势是什么？有哪些新特性值得关注（如Flink 1.17+的改进）？

Flink作为主流流处理框架，持续向云原生、易用性、性能优化方向发展，Flink 1.17+的新特性和未来趋势如下：

1. 云原生深化

• Kubernetes原生支持：
  • Flink 1.17+增强了K8s Operator，支持作业自动扩缩容、滚动升级。
  • 引入KubernetesApplicationCluster，简化云环境部署。
• Serverless架构：
  • 探索Flink on Serverless模式，按需分配资源，降低运维成本。
  • 与AWS Lambda、阿里云函数计算等Serverless平台集成。

2. 性能与稳定性优化

• 增量Checkpoint增强：
  • Flink 1.18优化了RocksDB增量Checkpoint的上传效率，减少IO开销。
  • 支持Checkpoint并发上传，提升大状态场景的快照速度。
• 背压机制改进：
  • 引入更精细的背压反馈机制，避免全局性能下降。
  • 优化网络缓冲区管理，减少反压导致的吞吐量波动。

3. Table API/SQL增强

• 流批一体优化：
  • Flink 1.17+统一了流处理和批处理的执行计划，简化“一次开发，批量/流处理通用”。
  • 增强CBO（基于成本的优化），提升复杂SQL的执行效率。
• 时序数据支持：
  • 新增时序函数（如滑动窗口聚合、时序Join），优化IoT、监控场景处理。
  • 支持时序数据的高效存储和查询（与InfluxDB、TimescaleDB集成）。

4. 易用性提升

• Flink Web UI重构：
  • 1.17+版本优化了UI交互，增加作业诊断建议、性能瓶颈自动识别。
  • 支持实时查看状态数据、窗口内容，简化调试。
• Python API增强：
  • 完善Python Table API，支持更多SQL功能和自定义函数。
  • 提升PyFlink性能，缩小与Java API的差距。

5. 生态集成扩展

• 实时数据仓库：
  • 增强与Hudi、Iceberg、Delta Lake的集成，支持实时CDC同步和ACID事务。
  • 提供更完善的DML支持（UPDATE/DELETE），满足数据仓库场景需求。
• AI与流处理结合：
  • 集成机器学习框架（如TensorFlow、PyTorch），支持实时模型推理。
  • 提供流数据特征工程工具，简化实时推荐、异常检测等场景。

6. 多模态数据处理

• 除传统结构化数据外，增强对非结构化数据（如日志、图像、音频）的流处理支持。
• 引入流处理中的图计算能力，支持实时图分析（如社交网络关系更新）。

值得关注的版本特性（1.17+）

• Flink 1.17：引入K8s自动扩缩容、Python UDF性能优化、Checkpoint并发上传。
• Flink 1.18：增强流批一体执行引擎、优化RocksDB状态后端、新增时序函数。
• 未来版本：预计深化Serverless支持、提升AI集成能力、优化边缘计算场景适配。

Flink的发展将持续聚焦于“实时化、云原生化、易用化”，成为企业实时数据平台的核心组件。

二、100道Flink 面试题目录列表

文章序号	Flink 100道
1	Flink面试题及详细答案100道（01-20）
2	Flink面试题及详细答案100道（21-40）
3	Flink面试题及详细答案100道（41-60）
4	Flink面试题及详细答案100道（61-80）
5	Flink面试题及详细答案100道（81-100）