企业官网建设流程全解析

1. 这不是配置清单，而是一份Flink资源调优的实战手记

“Flink资源如何配置”——这道题在大数据面试中出现频率极高，但绝大多数候选人答得像背教科书：TaskManager内存分Heap、Off-Heap、Network、Managed四块，JobManager只配内存和CPU，YARN模式要设–ytm、–yjm……背得滚瓜烂熟，一问“为什么这么分”“如果反压持续30秒该怎么调”“StateBackend切换后Managed Memory要不要重算”，立刻卡壳。我带过十几轮校招和社招面试，发现一个共性问题：大家把Flink资源配置当成静态填空题，却忽略了它本质是一套动态平衡系统——就像给一辆高速行驶的赛车调悬架：弹簧刚度（TaskManager Heap）、防倾杆阻尼（Network Buffer）、油箱容积（Managed Memory）、变速箱逻辑（StateBackend）必须协同响应路况（数据倾斜、反压、Checkpoint失败）。本文不列参数表，不讲概念定义，而是还原一次真实线上故障的完整调优过程：某实时风控项目在双十一流量峰值下，Checkpoint平均耗时从2.3秒飙升至18秒，下游Kafka写入延迟超5分钟。我们用48小时完成根因定位与全链路资源重配，最终将Checkpoint稳定在1.7±0.3秒，反压率归零。所有配置值、计算依据、验证方法、踩坑记录全部公开，你可以直接抄作业，也可以拿去面试时讲出“为什么”。

核心关键词已自然嵌入：Flink资源、TaskManager内存、Managed Memory、Network Buffer、StateBackend、Checkpoint调优、反压治理、YARN资源申请、JVM GC优化。如果你是刚学完Flink API想进厂的应届生，或是正在被线上反压折磨的运维同学，又或是需要给团队做技术分享的TL，这篇文章会告诉你：参数不是拍脑袋定的，每个字节都该有它的物理意义。

2. 资源配置的本质：三重动态平衡模型

2.1 平衡模型一：内存分区的“水坝效应”

Flink的内存模型常被简化为“堆内+堆外”，但实际是五层嵌套结构。我画过上百张内存流向图，最终提炼出最贴切的类比：TaskManager内存像一座多级水坝系统。

• Heap Memory（主坝）：存储Operator状态、窗口聚合结果、用户UDF对象。水位过高（Heap过大）会导致Full GC风暴；过低（<2GB）则频繁Minor GC，吞吐骤降。关键点在于：它不直接参与数据流传输，只承载“计算结果”。
• Off-Heap Memory（泄洪道）：包含Network Buffer（网络缓冲区）和Managed Memory（托管内存）。前者是数据在Task间流动的“河道”，后者是RocksDB StateBackend的“蓄水池”。二者共享同一片Off-Heap区域，但用途截然不同——Network Buffer负责“瞬时通行”，Managed Memory负责“长期储水”。
• Network Buffer（一级闸门）：默认每Buffer 32KB，总数量由taskmanager.network.memory.fraction（默认0.1）和taskmanager.memory.size共同决定。它像高速公路的应急车道：太少则数据包排队溢出（反压），太多则挤占Managed Memory导致RocksDB写入卡顿。
• Managed Memory（二级水库）：专供RocksDB使用，大小直接影响State读写性能。计算公式不是简单乘法，而是需满足：Managed Memory ≥ RocksDB Block Cache + Write Buffer + MemTable。若设为固定值（如2GB），在State规模突增时必然成为瓶颈。
• Direct Memory（地下暗渠）：JVM Direct Memory用于Netty通信，独立于Off-Heap，但受-XX:MaxDirectMemorySize限制。曾遇到案例：YARN容器内存设为8GB，JVM Heap 4GB，Off-Heap 3GB，但未显式设置MaxDirectMemorySize，Netty在高并发下申请Direct Memory失败，报OutOfDirectMemoryError，日志里却只显示“Channel inactive”，排查耗时6小时。

提示：Flink 1.13+引入Unified Memory Model（统一内存模型），但生产环境仍建议显式配置各分区。原因很简单：统一模型将Managed Memory动态分配给RocksDB，当State膨胀时可能抢占Network Buffer，反而加剧反压。我们在线上集群坚持“静态划分+预留冗余”，实测稳定性提升40%。

2.2 平衡模型二：CPU与并行度的“齿轮咬合”

很多人以为“CPU核数越多，并行度越高越好”，这是最大误区。Flink的并行度（parallelism）不是单纯看CPU，而是由数据处理节奏、网络IO能力、GC压力三者共同约束。

以一个典型ETL链路为例：Kafka Source → Flink SQL Join → Redis Sink。假设Kafka Topic有12个Partition，YARN NodeManager有16核CPU，单个TaskManager分配4核。

• Source端：并行度=12（匹配Partition数）是理论最优，但若Kafka Broker负载高，单个Source Task拉取延迟大，此时降低到8并行度+增大fetch.max.wait.ms，反而能提升整体吞吐。
• Join算子：KeyBy后数据重分布（Shuffle），依赖Network Buffer和Netty线程数。若并行度设为16（CPU核数），但Network Buffer仅1024个，则Shuffle阶段大量Buffer等待，CPU空转。我们实测：当Network Buffer < 2048时，并行度超过12即出现性能拐点。
• Sink端：Redis Sink的连接池大小（redis.connection.pool.size）必须与Sink并行度匹配。曾配置并行度16，但连接池仅默认8，导致50%的Sink Task阻塞在获取连接，CPU使用率不足40%，吞吐卡在瓶颈。

注意：并行度不是全局统一值。Flink支持算子级并行度设置（env.setParallelism(1)+dataStream.map(...).setParallelism(8)）。我们线上对Source设12，Join设8，Sink设16，通过ExecutionConfig.setAutoWatermarkInterval(200)控制Watermark生成节奏，使各环节“齿轮咬合”而非“空转打滑”。

2.3 平衡模型三：Checkpoint与StateBackend的“潮汐调度”

Checkpoint不是越快越好，而是要匹配业务SLA和State增长速率。我们曾将Checkpoint间隔从30秒缩至10秒，结果RocksDB Compaction线程满负荷，Write Stall频发，吞吐下降35%。根本原因在于：Checkpoint触发的是State全量快照，而StateBackend决定了快照的物理形态。

• HeapStateBackend：State存于JVM Heap，快照即序列化对象。优点是快，缺点是OOM风险高，且无法支持增量Checkpoint。仅适用于State < 5MB的轻量作业。
• FsStateBackend：State存于分布式文件系统（HDFS/S3），快照为文件拷贝。适合中等State（< 10GB），但每次Checkpoint需上传完整State，网络开销大。
• RocksDBStateBackend：State存于本地RocksDB，快照为SST文件硬链接+增量日志。这是生产环境唯一选择，但配置极复杂：
  • state.backend.rocksdb.predefined-options：必须设为SPINNING_DISK_OPTIMIZED_HIGH_MEM（机械盘）或FLASH_SSD_OPTIMIZED（SSD），否则默认配置严重拖慢Compaction。
  • state.backend.rocksdb.options-factory：需自定义org.apache.flink.contrib.streaming.state.DefaultConfigurableOptionsFactory，显式设置max_open_files（建议2048）、block_cache_size（Managed Memory的60%）、write_buffer_size（16MB）。
  • state.checkpoints.dir与state.savepoints.dir：必须分离！Savepoint用于版本升级，Checkpoint用于故障恢复，混用会导致路径冲突。

实操心得：RocksDB的block_cache_size不是越大越好。我们测试过从512MB升至2GB，Cache Hit Rate从82%升至91%，但GC时间增加200ms。最终采用“动态计算法”：block_cache_size = Managed Memory × 0.6，既保障热点State缓存，又避免JVM内存压力。

3. 核心配置项详解与计算推演

3.1 TaskManager内存分区：从公式到现场计算

TaskManager总内存（taskmanager.memory.process.size）不是随意设的。它必须满足：YARN Container Memory = JVM Heap + Off-Heap + JVM Overhead。其中JVM Overhead是JVM自身开销，按Heap的1.2倍计算（Flink官方推荐值）。

以YARN集群单Container内存上限为16GB为例，计算步骤如下：

1. 确定JVM Heap上限：
   YARN Container Memory = 16GB
   JVM Overhead = Heap × 1.2
   设Heap = x，则 x + (16GB - x) + 1.2x ≤ 16GB → x ≤ 16GB / 2.2 ≈ 7.27GB
   实际取整为7GB（留0.27GB余量防Overhead波动）

2. 计算Off-Heap可用空间：
   Off-Heap = Container Memory - Heap - JVM Overhead
   = 16GB - 7GB - (7GB × 1.2) = 16 - 7 - 8.4 =0.6GB
   注意：此0.6GB是Network Buffer与Managed Memory的共享池。

3. Network Buffer分配：
   默认fraction=0.1，但生产环境必须调高。根据经验：

   • Kafka Source/Sink密集型作业：fraction=0.3（保障Shuffle）
   • 纯计算型作业（如CEP）：fraction=0.15
     本例为风控作业（含Kafka+Redis+RocksDB），取0.25 → Network Buffer = 0.6GB × 0.25 =153.6MB
     每Buffer 32KB → Buffer数量 = 153.6MB / 32KB ≈4915个
     验证：taskmanager.network.memory.buffers-per-channel=4，taskmanager.network.memory.floating-buffers-per-gate=8，总Buffer需求 = (4×inChannels + 8×outChannels)，按12并行度估算约需4000个，153.6MB足够。

4. Managed Memory计算：
   Managed Memory = Off-Heap - Network Buffer = 0.6GB - 0.1536GB =0.4464GB ≈ 450MB
   但RocksDB最低要求：Block Cache + Write Buffer > 256MB。450MB勉强够用，但无冗余。因此我们反向调整：将Off-Heap提升至0.8GB（需Container Memory升至17GB），Managed Memory = 0.8GB × 0.75 =600MB，Block Cache = 600MB × 0.6 = 360MB，完全满足。

最终配置：

# YARN提交参数 --yarn-container-vcores 4 \ --yarn-container-memory 17g \ # Flink配置 taskmanager.memory.process.size: 17g taskmanager.memory.jvm-metaspace.size: 512m taskmanager.memory.jvm-overhead.min: 1g taskmanager.memory.jvm-overhead.max: 2g taskmanager.memory.jvm-overhead.fraction: 0.1 taskmanager.memory.managed.fraction: 0.75 taskmanager.memory.network.fraction: 0.25 taskmanager.memory.network.min: 128m taskmanager.memory.network.max: 2g

3.2 JobManager资源配置：被严重低估的“交通指挥中心”

JobManager常被设为2核4GB，这是巨大浪费。它不处理数据，但承担着作业调度、Checkpoint协调、元数据管理、WebUI服务四大职能。当作业并发超50个，或State超10GB时，JobManager极易成为瓶颈。

• 内存分配逻辑：
  JobManager Heap =jobmanager.memory.process.size-jobmanager.memory.jvm-overhead
  JVM Overhead = Heap × 0.1（JobManager开销较小）
  关键参数：jobmanager.execution.failover-strategy必须设为region（默认），否则单Task失败触发全图重启。

• CPU核数真相：
  JobManager的CPU压力主要来自Checkpoint Coordinator线程。每个Checkpoint需协调所有TaskManager，线程数 =jobmanager.numberOfTaskManagers× 2。若集群有20个TM，Coordinator线程达40个，2核CPU必然争抢。我们线上设为4核，配合jobmanager.rpc.server.numThreads: 8，RPC响应时间稳定在5ms内。

• 高可用（HA）配置陷阱：
  high-availability: zookeeper是基础，但high-availability.storageDir必须指向HDFS（非本地路径），否则ZK仅存Leader信息，State丢失。曾因误配为file:///tmp/flink/ha，ZK选举成功但JobManager重启后State全丢，恢复耗时2小时。

JobManager最终配置：

# YARN提交 --jobmanager-memory 4096m \ --jobmanager-vcores 4 \ # Flink配置 jobmanager.memory.process.size: 4g jobmanager.memory.jvm-metaspace.size: 512m jobmanager.memory.jvm-overhead.min: 512m jobmanager.memory.jvm-overhead.max: 1g jobmanager.rpc.server.numThreads: 8 jobmanager.rpc.client.numThreads: 4 jobmanager.execution.failover-strategy: region high-availability: zookeeper high-availability.storageDir: hdfs://nameservice1/flink/ha high-availability.zookeeper.quorum: zk1:2181,zk2:2181,zk3:2181

3.3 Checkpoint深度调优：从参数到物理层

Checkpoint性能取决于三个层面：应用层（代码）→ Runtime层（配置）→ 存储层（硬件）。我们逐层拆解。

应用层优化：

• enableCheckpointing(30000, CheckpointingMode.EXACTLY_ONCE)：30秒是经验值，但需结合State增长速率。计算公式：Checkpoint Interval ≥ State Size / (Throughput × 0.8)。本例State 2GB，吞吐50MB/s → 最小间隔 = 2000MB / (50MB/s × 0.8) = 50秒，故设60秒更稳妥。
• setMaxConcurrentCheckpoints(1)：必须设为1！并发Checkpoint会争夺RocksDB资源，导致Write Stall。
• enableExternalizedCheckpoints(ExternalizedCheckpointCleanup.RETAIN_ON_CANCELLATION)：保留取消作业的Checkpoint，用于灰度发布回滚。

Runtime层配置：

• checkpoint.timeout: 600000（10分钟）：默认10分钟，但需确保大于state.checkpoints.dir的HDFS写入延迟（我们监控到P99为8.2分钟）。
• checkpoint.min-pause: 2000：两次Checkpoint最小间隔，防高频触发。
• state.checkpoints.dir: hdfs://nameservice1/flink/checkpoints：必须用HDFS，S3延迟太高。
• state.savepoints.dir: hdfs://nameservice1/flink/savepoints：与Checkpoints分离。

存储层硬件适配：

• HDFS NameNode需开启dfs.namenode.fs-limits.max-directory-items（默认100万），否则Checkpoint目录文件数超限报错。
• DataNode磁盘必须SSD，HDD下RocksDB Compaction延迟导致Checkpoint超时。我们实测：SSD下Compaction平均120ms，HDD下达2.3秒。

3.4 反压（Backpressure）的根因定位与资源响应

反压不是配置问题，而是数据处理能力失衡的报警灯。90%的反压源于资源配置不当，但需先精准定位。

定位三步法：

1. WebUI观察：访问http://jobmanager:8081/#/job/{jobId}/backpressure，看哪个Subtask Bar呈红色。注意：红色只表示该Subtask输出慢，不一定是它自身问题。
2. Metrics分析：查numBytesInLocalPerSecond与numBytesInRemotePerSecond。若前者高后者低，说明下游接收慢（如Kafka积压）；若两者均低，说明上游发送慢（如Kafka拉取慢）。
3. Thread Dump抓取：jstack -l {pid} > thread.log，搜索BLOCKED线程。曾定位到Redis Sink因连接池满，所有Sink Thread阻塞在pool.getResource()。

资源响应策略：

• Network Buffer不足：红色Subtask输入队列满 → 增加taskmanager.network.memory.fraction至0.3，重启TM。
• Managed Memory不足：RocksDB Write Stall → 增加Managed Memory，调大state.backend.rocksdb.block.cache-size。
• CPU瓶颈：Subtask CPU使用率100%，但吞吐低 → 降低并行度，让单Task处理更多数据（减少Shuffle开销）。

实操心得：反压时切忌盲目加资源。我们曾对一个Join作业加TM到8个，反压反而加剧。最后发现是KeyBy后数据倾斜，90%数据发往同一Key，该Subtask独占所有资源。解决方案：加盐（salting）预处理，将热点Key打散，资源消耗立降60%。

4. 全流程实操：从故障到稳定的48小时

4.1 故障现象与初步诊断（第1-2小时）

双十一流量高峰，监控告警：

• Checkpoint Duration P95从2.3秒 → 18.7秒
• Kafka Consumer Lag峰值达1200万条
• TaskManager GC时间占比超45%（正常<5%）
• WebUI显示Source Subtask持续红色

第一步：登录JobManager服务器，执行jstat -gc {pid}：

S0C S1C EC OC MC MU CCSC CCSU YGC YGCT FGC FGCT GCT 0.0 0.0 10240.0 20480.0 10240.0 9820.0 1024.0 950.0 1200 120.5 18 210.3 330.8

FGCT 210秒，FGC 18次，确认Heap严重不足。

第二步：检查Flink配置文件flink-conf.yaml：

taskmanager.memory.process.size: 8g # 错误！YARN Container设为8g，但Heap未预留Overhead taskmanager.memory.jvm-overhead.min: 1g taskmanager.memory.jvm-overhead.max: 1g

计算：Heap = 8g - 1g = 7g，但JVM Overhead实际需7g×1.2=8.4g，已超Container内存，触发频繁Full GC。

4.2 配置重算与灰度发布（第3-12小时）

根据2.1节模型重算：

• YARN Container Memory → 17g（原8g）
• Heap → 7g
• Off-Heap → 0.8g
• Network Buffer → 0.25×0.8g = 0.2g（6400个Buffer）
• Managed Memory → 0.6g（600MB）

修改配置并生成新flink-conf.yaml，同步至所有节点。
灰度发布策略：

• Step1：停止1个TaskManager，用新配置启动，观察Checkpoint Duration
• Step2：新TM加入后，WebUI显示Checkpoint降至3.1秒，但Source仍有轻微反压
• Step3：调整Source并行度从12→8，kafka.properties增加fetch.max.wait.ms=500，反压消失

注意：灰度期间必须关闭state.checkpoints.dir的自动清理，保留旧Checkpoint。我们用hdfs dfs -ls /flink/checkpoints/old备份，确保可回滚。

4.3 RocksDB深度调优（第13-36小时）

新配置下Checkpoint稳定在3秒，但P99仍波动（2.1~4.8秒）。jstack发现RocksDB Compaction线程频繁BLOCKED。

进入TM容器，执行：

# 查看RocksDB Stats echo "stats" | /opt/flink/bin/flink-sql-client.sh -f /tmp/rocksdb-stats.sql

输出关键指标：

• block-cache-hit-rate: 78.2%（偏低）
• compaction-pending: 3（有3个Compaction待执行）
• write-stall: 1（已发生Write Stall）

按3.1节公式重算：

• Managed Memory 600MB → Block Cache = 600MB × 0.6 = 360MB
• 当前RocksDB配置block_cache_size=128*1024*1024（128MB），立即扩容

修改flink-conf.yaml：

state.backend.rocksdb.options-factory: org.apache.flink.contrib.streaming.state.DefaultConfigurableOptionsFactory state.backend.rocksdb.predefined-options: FLASH_SSD_OPTIMIZED state.backend.rocksdb.block.cache-size: 360mb state.backend.rocksdb.write-buffer-size: 16mb state.backend.rocksdb.max-open-files: 2048

重启TaskManager，block-cache-hit-rate升至92.5%，Checkpoint P99稳定在1.9秒。

4.4 终极验证与文档沉淀（第37-48小时）

全量发布后，进行72小时稳定性压测：

• 持续注入10万QPS模拟流量
• 监控指标：
  • Checkpoint Duration P95 ≤ 2.0秒（达标）
  • GC时间占比 ≤ 6%（达标）
  • Kafka Lag ≤ 1000条（达标）
  • CPU使用率 65%±10%（健康区间）

最终沉淀《Flink资源调优Checklist》：

5. 常见问题与独家避坑指南

5.1 “配置生效了，但没效果”——配置加载失效的5种场景

Flink配置有多个加载优先级：flink-conf.yaml<StreamExecutionEnvironment代码配置 <YARN参数<CLI参数。曾因在代码中写env.getConfig().setGlobalJobParameters(params)覆盖了yaml配置，排查3小时。

• 场景1：YARN模式下CLI参数覆盖yaml
  ./bin/flink run -m yarn-cluster --yarn-container-vcores 4 --yarn-container-memory 17g ...中的--yarn-container-memory会覆盖yaml的taskmanager.memory.process.size。解决方案：统一用CLI参数，yaml仅作备份。

• 场景2：Kubernetes模式ConfigMap挂载错误
  ConfigMap挂载到/opt/flink/conf/flink-conf.yaml，但Flink启动脚本默认读/opt/flink/conf/下的文件。若挂载路径为/etc/flink/conf/，需加-Dconfig.dir=/etc/flink/conf。

• 场景3：StateBackend配置未同步
  state.backend.rocksdb需在JobManager和TaskManager两端同时配置。曾只配TM，JM仍用HeapBackend，导致Checkpoint失败。

• 场景4：动态参数未生效
  taskmanager.memory.network.fraction是静态参数，修改后必须重启TM。而execution.checkpointing.interval是动态参数，可通过WebUI实时修改。

• 场景5：Hadoop配置未继承
  Flink on YARN需读HDFS，但core-site.xml和hdfs-site.xml未放入/opt/flink/conf/，导致state.checkpoints.dir访问HDFS失败。解决方案：cp $HADOOP_CONF_DIR/core-site.xml $FLINK_HOME/conf/。

5.2 “重启后更慢了”——JVM参数的致命组合

Flink基于JVM，但很多参数与Flink内存模型冲突。

• -XX:+UseG1GC 与 Heap设置：G1GC需-XX:MaxGCPauseMillis=200，但Flink默认GC停顿容忍度为10秒。若设200ms，GC线程过于激进，反而增加CPU开销。我们线上设为-XX:MaxGCPauseMillis=500，平衡吞吐与延迟。

• -XX:MetaspaceSize 过小：Flink SQL作业加载大量UDF类，Metaspace易OOM。必须设-XX:MetaspaceSize=512m -XX:MaxMetaspaceSize=1g。

• -XX:+UseStringDeduplication：开启后减少字符串重复内存，但增加GC时间。实测对Flink无益，反而使Minor GC延长15%，已禁用。

• -Dio.netty.leakDetectionLevel=advanced：开发环境用于检测Netty内存泄漏，生产环境必须关，否则性能下降20%。

5.3 “明明配了HA，还是单点了”——高可用的3个隐藏雷区

• 雷区1：ZooKeeper Session Timeout
  zookeeper.session.timeout.ms默认6s，但网络抖动时易超时。必须设为30000（30秒），并同步调大zookeeper.connection.timeout.ms=60000。

• 雷区2：HA Storage Dir权限
  high-availability.storageDir指向HDFS路径，但Flink用户无写权限。需执行：hdfs dfs -chmod -R 777 /flink/ha（测试环境）或联系HDFS管理员授权。

• 雷区3：JobManager Leader Contention
  多个JM实例同时启动，ZK选不出Leader。根源是high-availability.cluster-id未设为唯一值。必须为每个集群设不同ID：high-availability.cluster-id: /flink-prod-cluster。

5.4 面试官最爱追问的5个“为什么”

• Q：为什么Network Buffer不能设太大？
  A：Network Buffer占用Off-Heap内存，过大会挤压Managed Memory，导致RocksDB Block Cache不足，State读取变慢，间接引发反压。我们测试过Buffer=1g，Managed Memory只剩50MB，Checkpoint失败率升至30%。

• Q：Managed Memory设为0会怎样？
  A：RocksDB无法初始化，TaskManager启动失败，日志报RocksDBException: Invalid argument: You have to increase the managed memory。Managed Memory是RocksDB的“启动资金”，必须>0。

• Q：Checkpoint失败后，Flink怎么恢复？
  A：Flink会回退到上一个成功的Checkpoint，从该点重放Kafka数据。但若启用了enableExternalizedCheckpoints，可手动从外部路径恢复，避免重放全部历史数据。

• Q：YARN模式下，TaskManager内存超限谁来杀进程？
  A：YARN NodeManager。当Container内存超yarn.nodemanager.vmem-pmem-ratio × Physical Memory时，NM强制Kill。因此taskmanager.memory.process.size必须≤YARN Container Memory。

• Q：Flink on Kubernetes和YARN，资源配置最大区别？
  A：K8s需显式设resources.limits.memory，且必须与taskmanager.memory.process.size一致；YARN则通过--yarn-container-memory传递。K8s下jobmanager.memory.process.size需单独配置，YARN下由--jobmanager-memory控制。

6. 我的个人体会：配置是手段，理解才是目的

写完这篇近六千字的实录，我翻出三年前第一次调优的笔记，那时连taskmanager.network.memory.fraction是什么都不知道，靠改一个参数试一小时。现在回头看，所有“灵光一现”的调优方案，都建立在对Flink内存模型、RocksDB原理、JVM GC机制的反复啃读上。Flink资源配置没有银弹，但有一条铁律：每个参数背后都有其物理约束，找到那个约束点，就找到了调优的支点。比如Network Buffer的约束是Shuffle带宽，Managed Memory的约束是RocksDB Compaction吞吐，Heap的约束是GC停顿时间。面试时被问“怎么配”，别急着背数值，先说清楚你针对哪个约束点，在什么场景下做了什么权衡——这才是资深工程师和应届生的本质区别。最后分享一个小技巧：把flink-conf.yaml里的所有内存参数，用Excel列出来，标上单位、计算公式、当前值、目标值、影响范围，每周更新一次。三个月后，你会发现自己已经能闭眼画出Flink内存水坝图了。