Stray_Lambs的博客

官网图：由两个部分组成，JM，TM。JM中包含三个组件，。dispatch主要是负责提供了rest接口，接受客户端提供的jar包dataflow等信息，并且运行Flink UI也是该组件运行。jobmaster主要是负责将dataflow等数据流图转换成真正的物理执行图，如果资源足够启动任务，那么就会将图分发给对应的TM，并且负责任务启动后的协调运行管理，比如checkpoint的协调。resource manager主要负责资源的申请、释放、分配。管理着Flink的slot。

的思想：在 keyBy 上游算子数据发送之前，首先在上游算子的本地对数据进行聚合后再发送到下游，使下游接收到的数据量大大减少，从而使得 keyBy 之后的聚合操作不再是任务的瓶颈。如果 keyBy 之前就存在数据倾斜，上游算子的某些实例可能处理的数据较多，某些实例可能处理的数据较小，产生该情况可能是因为数据源的数据本身就不均匀。注意： Flink 是实时流处理，如果 keyby 之后的聚合操作存在数据倾斜，且没有开窗口的情况下，简单的任务使用两阶段聚合，是不能解决问题的。通常，数据倾斜也会引起反压。

另外 Sink 端要与下游的服务进行交互，并行度还得根据下游的服务抗压能力来设置，如果在 Flink Sink 这端的数据量过大的话，且 Sink 处并行度也设置的很大， 但下游的服务完全撑不住这么大的并发写入， 可能会造成下游服务直接被写挂，所以最终还是要在 Sink 处的并行度做一定的权衡。上，让多块磁盘来分担压力。Flink 性能调优的第一步，就是为任务分配合适的资源，在一定范围内，增加资源的分配与性能的提升是成正比的，实现了最优的资源配置后，在此基础上再考虑进行后面论述的心更难调优策略。

SplitEnumerator被认为是整个Source的“大脑”。SplitEnumerator的功能实现SplitEnumerator 可以在的帮助下完成所有上述工作，其会在 SplitEnumerator 的创建或者恢复的时候提供给 Source。SplitEnumeratorContext 允许SplitEnumerator 检索到 reader 的必要信息并执行协调操作。而在 Source 的实现中会将 SplitEnumeratorContext 传递给 SplitEnumerator 实例。

SourceReader是一个运行在Task Manager上的组件，主要是负责读取 SplitEnumerator 分配的source split。SourceReader 提供了一个拉动式(pull-based)处理接口。Flink任务会在循环中不断调用 pollNext(ReaderOutput) 轮询来自 SourceReader 的记录。pollNext(ReaderOutput) 方法的返回值指示 SourceReader 的状态。

目前可以看出，Souce接口的更新，其实是因为Flink在1.12之前将批处理任务与流处理任务分为两种实现模式。在底层实现中描述输入的数据如何被划分为不同的InputSplit，继承于 INputSplitSource描述如何从单个InputSplit读取记录，具体包括如何打开一个分配到的InputSplit，如何从这个INputSplit读取一条记录，如何得知记录已经读完和如何关闭这个Inputsplit描述如何获取输入数据的统计信息（比如文件的大小、记录的数目）

ExectionGraph执行图在Flink中ExecutionGraph执行图是协调数据流的分布式执行的中心数据结构，它保留了每个并行任务、每个中间流以及它们之间的的通信表示。StreamGraph和JobGraph的转化生成都是在Flink客户端，而最终Flink作业运行时调度层的核心执行图ExecutionGraph是在服务器的JobManager中生成的。ExecutionGraph在实际处理转换上只是改动了GobGraph的每个节点，并没有对整个拓扑结构进行改变。主要发生以下转...

时间概念由于Flink框架中实时流处理事件中，时间在计算中起到很大的作用。例如进行时间序列分析、基于特定时间段(窗口)进行聚合或者是重要情况下的事件处理。Flink的DataStream支持三种time：EventTime、IngestTime和ProcessingTime，并且有大量的基于time的operator。这三种时间进行比较：EventTime 事件生成的时间，在进入Flink之间就已经存在，可以从event的字段中抽取 必须指定watermarks的生成方式 优势..

目录Savepoints分配算子IDsavepoint操作配置savepoint触发savepoint恢复savepoint删除savepointF.A.Q我应该为我作业中的所有算子分配 ID 吗?如果我在作业中添加一个需要状态的新算子，会发生什么?如果从作业中删除有状态的算子会发生什么?如果我在作业中重新排序有状态算子，会发生什么?如果我添加、删除或重新排序作业中没有状态的算子，会发生什么?当我在恢复时改变程序的并行度时会发生什么?我可以将 sa

State对于Flink而言，状态是一个必不可少的需要了解的重要知识点。Flink具有三种状态Keyed State Operator State Broadcast State(1.5版本之后，特殊的Operator State)Operator State每一个operator中都并行的维护一个状态，与key无关的。这里放一段官网上面对于Operator State的解释。Operator State(ornon-keyed state) is state that is...

目录Flink恢复机制Checkpoint是什么Savepoint保存点检查点协调器CheckpointCheckpoint保存什么信息Checkpoint如何保存信息Barrier 对齐精准一次性(exactly once)端到端精准一次Job失败后，从检查点恢复应用自动恢复机制手动作业恢复机制Job失败后，从保存点恢复机制参考Flink恢复机制任何一个框架都存在出错的可能，所以都会有自己的一套恢复机制，例如Spark是采用血缘关系从头开

目录内存管理积极的内存管理MemorySegment堆内内存与堆外内存的比较序列化方法Flink序列化数据类型参考内存管理Flink是由Java语言所开发的，而基于JVM的数据分析引擎都需要面对将大量的数据存到内存当中，JVM存在以下几个问题：Java对象存储密度低。因为Java对象需要存储许多其他信息，比如一个boolean对象就占用了16个字节内存，其中包括了对象头占8个字节，boolean占一个字节，对齐填充占了7个。相当于浪费了15个字节。 Full GC会极.

目录JobGraph源码解读JobGraph生成过程入口函数createJobGraph函数参考JobGraph源码解读上回说到，StreamGraph的源码其中是在客户端生成，并且是生成Node节点和Edge，主要是通过StreamAPI生成，表示拓扑结构，这次给大家讲讲JobGraph的生成(以Yarn集群模式)。首先，JobGraph是基于StreamGraph进行优化(包括设置Checkpoint、slot分组策略，内存占比等)，最主要是将多个符合条件的StreamN

Flink反压机制反压是流式系统中关于处理能力的动态反馈机制，并且是从下游到上游的反馈，一般是在实时数据处理的过程中，上游节点的生产速度大于下游节点的消费速度。在Flink中，反压主要有两个部分：跨TaskManager的反压过程和TaskManager内的反压过程。Flink TaskManager内存结构先给大家看看Flink中网络传输场景下的内存管理。首先，每一个Task都是在TaskManager(TM)中运行，每个TM中都存在一个内存区域叫做NetworkBufferPo...

目录Flink流图基本概念StreamGraph源码StreamGraph的核心对象StreamNodeStreamEdgeStreamNode和StreamEdge之间的关系上传jar包生成StreamGraph生成StreamNode生成Edge核心方法参考Flink流图基本概念这里简单介绍一下Flink流图的一些基本概念和过程，详情可以看Flink基础概念。根据不同图的生成顺序，主要是分为4层：StreamGraph-->JobGrap

Flink 基本概念目前在实时的框架当中，Flink可以说是具有一席之地的。Flink 是一个分布式系统，需要有效分配和管理计算资源才能执行流应用程序。它集成了所有常见的集群资源管理器，例如Hadoop YARN、Apache Mesos和Kubernetes，但也可以设置作为独立集群甚至库运行。并且Flink是作为流批一体化的计算框架，可以对有限数据流和无限数据流进行有状态或无状态的计算（即可以流式计算或者批量计算）。Flink作为流批一体化的框架，其中流式处理是使用DataStream，而批处理