1.Flink源码算子
2.Flink常见面试问题（原理）
3.flink 并行度

Flink源码算子

       Flink应用程序的核心组件包括源(source)、转换(transformation)和目的地(sink)，它们共同构成有向图，数据流从源开始，流向sink结束。源算子如env.addSource的新版卡盟源码底层实现涉及监控函数和连续读取文件操作，如env.readTextFile()调用了一系列方法，最终通过add.source添加到流处理环境。

       转换算子种类繁多，如map和sum。map算子通过函数转换，经过层层调用，最终调用transformations.add方法，返利裂变系统源码将算子添加到作业的血缘依赖列表中。print算子作为sink，通过addSink操作生成StreamSink operator，其SinkFunction负责数据处理，如PrintSinkFunction的打印操作。

       构建过程中，付款小程序源码每次转换都会产生新的数据流，这些StreamTransformation会以隐式链表或图的形式组织起来，input属性记录上下游关系。执行阶段，会生成StreamGraph和JobGraph，然后提交到集群进行调度。c语言罗盘源码

Flink常见面试问题（原理）

       Flink面试中常见的问题概述

       Flink任务提交流程涉及以下几个步骤:

       当部署在YARN上时，首先由Client将Flink的Jar包和配置上传到HDFS，接着向YARN的ResourceManager提交任务。

       ResourceManager分配Container资源后，会通知NodeManager启动ApplicationMaster。ApplicationMaster负责启动JobManager，推拿网站源码大全加载和配置后，它会申请资源启动TaskManager。

       TaskManager在NodeManager的指导下启动，向JobManager发送心跳并等待任务分配。

       Flink的执行图包括四个阶段：StreamGraph、JobGraph、ExecutionGraph和物理执行图。StreamGraph表示代码的拓扑结构，JobGraph是经过优化的并行版本，而ExecutionGraph是根据并行度进行规划的核心结构，最后的物理执行图将任务分配给实际的TaskSlot运行。

       关于slot和任务的关系，一个任务所需的slot数量取决于并行度最大的算子，而并行度和slot数量是两个不同的概念：并行度是动态配置的，而slot数量是TaskManager的静态配置。

       Flink通过任务链（Operator Chains）技术优化算子间的连接，减少序列化/反序列化等开销，提高性能。

       Flink的SQL部分依赖Apache Calcite进行校验、解析和优化，SQL解析过程涉及复杂步骤。

       在数据抽象和交换方面，Flink通过MemorySegment和相关的数据转换类来管理内存，避免JVM的性能瓶颈。

flink 并行度

       Flink 作为一套分布式执行框架，计算资源可以不断的扩展。

        不同的任务类型，可以控制需要的计算资源。在flink整个runtime的模型中

        并行度是一个很重要的概念，通过设置并行度可以为认为分配合理的计算资源，

        做到资源的合理配置。

        整个flink的架构简单的说是 中心控制（jobManager）+ 多点分布执行（taskManager）

        弹性的资源分配主要来自于taskManager的有效管理和配置。

        在启动flink 之前，在核心的配置文件里面，需要指定两个参数。

        taskmanager.numberOfTaskSlots 和 parallelism.default。

        首先需要明白slot的概念。对于 taskManager，他其实是一个 JVM 程序。

        这个JVM 可以同时执行多个task，每个task 需要使用本机的硬件资源。

        slot 的属于 jvm 管理的 一些列资源卡槽。 每个slot 只能执行一个task。

        每个slot分配有固定的内存资源，但是不做cpu的隔离。 JVM管理一个 slot的pool，

        用来执行相应的task。taskmanager.numberOfTaskSlots = ，则理论上可以同时执行个子任务。

        那么对于1个5节点，numberOfTaskSlots= 6的集群来说，那么就有个slot可以使用。

        对于具体的一个job来说，他会贪婪的使用所有的 slot吗？

        使用多少slot 是由parallelism.default 决定的。如果是 5， 那么对于一个job 他最多同时使用5个slot。

        这个配置对于多job平台的集群是很有必要的。

        那么给定一个stream api 编写的flink 程序，被分解的task是否和map 到slot 上执行的呢？

        flink 有几个经典的graph， stream-api对应的stream_graph-> job_graph->execution_graph->物理执行图。

        execution_graph 基本就决定了如何分布执行。

        我们知道一个 stream-api, 主要有 source, operate, sink 这几部分。那么我们可以从source开始看 并行的控制。

        source 有并行source和 非并行。我们主要看并行，想类似与kafka 这种生成消费者模式的数据源，能够 并行消费source是非常重要的。

        所以可以看到kafka，FlinkKafkaConsumerBase<T> extends RichParallelSourceFunction<T>，可以充分利用并行度，大大提高吞吐量。

        对应到具体的物理执行上，就是多个 source task 任务执行，他们属于一个kafka group同时消费 不同的partition。

        对于parallelSource，默认使用cpu 核心做并行度。我们可以通过api进行设置。

        接下来是 operate，每个operate都可以设置parallel，如果没有设置将会使用其他层次的设置，比如env，flink.conf中的配置，parallelism.default。

        比如 source. map1().map2().grouby(key).sink()

        这样一个程序，默认，source和 map1，map2有同样的parallel，上游的output 可以直接one-one forwarding.

        在flink 的 优化中，甚至可以把这些 one-one 的operate 合成一个，避免转发，线程切换，网络通信开销。

        对于groupby 这样的算子，则属于另外的一类。上游的output 需要 partion 到下游的不同的节点，而不能做位一个chain。

        由于operate可以设置独自的parallel，如果与上游不一致。上游的output必然需要某种partion策略来 rebalnce数据。kafka有很多策略来处理这个细节。

        对于partion放在专门的章节来说明。

        对于sink，则可以理解位一个特定的operate，目前看没什么特殊处理逻辑。