把Spark和Flink在计算模型和运维方式上的差异放到一起看，重点包括：

• 先看 Spark 处理流 与 Flink 处理批 的天然短板，理解为什么 Spark 更偏微批、Flink 更偏实时，而不是简单说谁“全能”
• 重点拆 Shuffle、checkpoint、反压、内存模型、代码生成 这些底层机制，解释两者性能差异为什么会落到 I/O、CPU 和延迟上
• 再把 spark-submit、Thrift Server、Spark Operator、Livy 与 flink run、Flink Kubernetes Operator、REST API、SQL Client、Application Mode 摆在一起比较
• 最后落到实用选择：如果目标是 批处理吞吐、流式低延迟、K8s 原生部署、CI/CD 自动化、SQL 接入，Spark 和 Flink 分别更适合什么场景

重点包括：

• MemorySegment 是 Flink 最小的内存分配单元，默认 32KB，既可以直接驻留内存，也可以在必要时借助序列化写到磁盘
• HeapMemorySegment、DataInputView、DataOutputView 这些基础抽象分别负责堆内内存访问、读取视图和写入视图，是上层算子和序列化框架的基础
• MemoryManager 主要管理排序、哈希、缓存等更偏离线计算的内存，而 NetworkBufferPool 则通过 MemorySegmentFactory 申请网络缓冲区使用的内存
• 调用链可以从 TaskManager -> TaskSlot -> MemorySegment 这条路径去理解，后面再结合 KryoSerializer 和 TypeInformation 看 Flink 的序列化体系怎么工作

重点包括：

• RPC 层：Flink 早期基于 Akka 构建 RPC，Dispatcher、JobMaster、ResourceManager 等组件都继承 RpcEndpoint，而 RpcServer 则通过 AkkaInvocationHandler 完成动态代理
• 网络栈：TaskManager 之间的数据传输走 Netty，数据从 RecordWriter 写入本地 buffer，再进入 ResultPartition，最后发给对端的 Netty，再转入 InputGate -> OperatorChain -> StreamTaskInput
• 任务执行模型：包括直接从外部源读取数据的 SourceStreamTask / SourceReaderStreamTask，以及支持从网络或本地消费数据的 OneInputStreamTask / TwoInputStreamTask
• Shuffle 与反压：ResultPartition 是 IntermediateResultPartition 的底层物理实现，包含多种实现形态；而基于 credit 的反压机制里，每个 credit 基本就对应一个上游 buffer（默认 32KB）

把 Flink 的状态数据、后端实现和 checkpoint 主线串起来：

• 先看 State 体系本身，包括 MapState、ValueState、BroadcastState 以及内部使用的 InternalKvState
• 再看 KeyedState 和 OperatorState 两条实现路径，以及 Heap、RocksDB、StateTable、OperatorStateBackend 这些核心组件
• 最后把 checkpoint 的触发、barrier 对齐、下游传播、ACK 回传和 job-manager 确认完成的过程连起来

主要看 Flink 集群是怎么被创建出来、怎么和外部资源管理器打交道的，重点包括：

• ClusterClientFactory -> ClusterDescriptor -> ClusterClientProvider -> ClusterClient 这条客户端侧的入口链路
• AbstractContainerizedClusterClientFactory、StandaloneClientFactory 这些不同部署模式下的工厂实现
• Yarn 和 Kubernetes 两条典型路径里，ResourceManager、TaskExecutor、fabric8、pod/Container 启动之间的关系

重点是把“提交一个 Flink 作业”拆成几个明确阶段：

• 从 CLIFrontend、PackagedProgram、DefaultExecutorServiceLoader 到不同集群类型下的 PipelineExecutor
• 从 ExecutionEnvironment、StreamExecutionEnvironment 生成 StreamGraph / JobGraph，再交给运行时调度
• 再往后看 Dispatcher、JobMaster、SlotPool、TaskDeploymentDescriptor、StreamTask、Mailbox、重启策略这些运行阶段的关键组件

DataStream 在运行时到底会落到哪些算子和线程模型上：

• 从 StreamOperator、AbstractStreamOperator、AbstractUdfStreamOperator 一路看到单输入、双输入算子的继承体系
• 再看 SourceFunction、SinkFunction、TwoPhaseCommitSinkFunction、ProcessFunction、KeyedProcessFunction 这些常用扩展点
• 最后顺着 SourceStreamTask -> StreamSource -> user function 和 StreamSink -> invoke() 这条路径，把 Watermark、TimerService、端到端一致性串起来

Flink 运行时的脑图，重点包括：

• Session 集群、Application 集群两种模式，以及客户端、JobManager、TaskManager 之间的基本关系
• 作业从提交到调度执行的主链路，包括心跳、checkpoint、slot 分配、任务状态汇报
• 运行时启动时会顺带拉起的组件，比如 RPC service、blob server、metric registry、HA service、heartbeat service 等

Flink 逻辑计划到物理执行的主线整理，重点包括：

• 流任务如何先转换成 StreamGraph，批任务如何进入 OptimizedPlan，最后统一落到 JobGraph
• StreamNode、StreamEdge、JobVertex、JobEdge、IntermediateDataSet 这些图结构节点和边分别代表什么
• 再往后如何结合并行度、算子链和调度需求，生成最终的 ExecutionGraph 并进入物理执行