Flink运行时之流处理程序生成流图

流处理程序生成流图

DataStream
API所编写的流处理应用程序在生成作业图(JobGraph)并提交给JobManager之前,会预先生成流图(StreamGraph)。

什么是流图

流图(StreamGraph)是表示流处理程序拓扑的数据结构,它封装了生成作业图(JobGraph)的必要信息。它的类继承关系如下图所示:

当你基于StreamGraph的继承链向上追溯,会发现它实现了FlinkPlan接口。

Flink效仿了传统的关系型数据库在执行SQL时生成执行计划并对其进行优化的思路。FlinkPlan是Flink生成执行计划的基接口,定义在Flink优化器模块中,流处理程序对应的计划是StreamingPlan,但是当前针对流处理程序没有进行优化,因此这个类可看作是一个预留设计。

一个简单的实现“word count”的流处理程序,其StreamGraph的形象化表示如下图:

Flink官方提供了一个计划可视化器来图形化执行计划,该计划可视化器基于Flink
API所生成的计划的JSON格式表示绘制图形。但是需要注意的是,计划的JSON形式表示缺失了很多属性以及部分节点(比如虚拟节点等);

上面的图是由“节点”和“边”组成的。节点在Flink中对应的数据结构是StreamNode,而边对应的数据结构是StreamEdge,StreamNode和StreamEdge之间有着双向的依赖关系。StreamEdge包含了其连接的源节点sourceVertex和目的节点targetVertex:

而StreamNode中包含了与其连接的入边集合inEdges和出边集合outEdges:

StreamEdge和StreamNode都有唯一的编号进行标识,但是各自编号的生成规则并不相同。

StreamNode的编号id的生成是通过调用StreamTransformation的静态方法getNewNodeId获得的,其实现是一个静态计数器:

protected static Integer idCounter = 0;
public static int getNewNodeId() {
    idCounter++;
    return idCounter;
}

StreamEdge的编号edgeId是字符串类型,其生成的规则为:

this.edgeId = sourceVertex + "_" + targetVertex + "_" + typeNumber + "_" + selectedNames
                + "_" + outputPartitioner;

它是由多个段连接起来的,语义的文字表述如下:

源顶点_目的顶点_输入类型数量_输出选择器的名称_输出分区器

edgeId除了用来实现StreamEdge的hashCode及equals方法之外并没有其他实际意义。

StreamNode是表示流处理中算子的数据结构,source和sink在StreamGraph中也是以StreamNode表示,它们也是一种算子,只是因为它们是流的输入和输出因而有特定的称呼。

StreamNode除了存储了输入端和输出端的StreamEdge集合,还封装了算子的其他关键属性,比如其并行度、分区的键信息、输入与输出类型的序列化器等。

从直观上来看你已经知道了StreamNode和StreamEdge是StreamGraph的重要组成部分,但是为了生成JobGraph,StreamGraph很显然必须得包含更多的内容。总结一下,StreamGraph中包含的属性可分为三大类:

  • 流处理程序的执行配置;
  • 流处理程序拓扑中包含的节点和边的信息;
  • 迭代相关的信息;

当然围绕这些属性的方法非常多,比如添加边和节点,创建迭代的source/sink等。

其中的一个关键方法getJobGraph将用于生成JobGraph:

public JobGraph getJobGraph() {
    if (isIterative() && checkpointConfig.isCheckpointingEnabled()
        && !checkpointConfig.isForceCheckpointing()) {
        throw new UnsupportedOperationException(
            "Checkpointing is currently not supported by default for iterative jobs, as we cannot guarantee exactly once semantics. "
            + "State checkpoints happen normally, but records in-transit during the snapshot will be lost upon failure. "
            + "\nThe user can force enable state checkpoints with the reduced guarantees by calling: env.enableCheckpointing(interval,true)");
    }
    StreamingJobGraphGenerator jobgraphGenerator = new StreamingJobGraphGenerator(this);
    return jobgraphGenerator.createJobGraph();
}

从上面的代码段也可见,当流处理程序中包含迭代逻辑时,检查点功能暂时不被支持,在异常信息中Flink阐述了缘由:在迭代作业中无法保证“恰好一次”的语义。

流处理程序依赖StreamingJobGraphGenerator来生成JobGraph,至于如何生成,后续会进行剖析。

生成流图的源码分析

了解了什么是流图(StreamGraph)之后,我们来分析它是如何生成的。流图的生成是通过StreamExecutionEnvironment的getStreamGraph实例方法触发的:

public StreamGraph getStreamGraph() {
    if (transformations.size() <= 0) {
        throw new IllegalStateException("No operators defined in streaming topology. Cannot execute.");
    }
    return StreamGraphGenerator.generate(this, transformations);
}

从代码段中可见,StreamGraph的生成依赖于一个名为transformations的集合对象,它是环境对象所收集到的所有的转换对象的集合,该集合中存储着一个流处理程序中所有的转换操作对应的StreamTransformation对象。

每当在DataStream对象上调用transform方法或者调用已经被实现了的一些内置的转换函数(如map、filter等,这些转换函数在内部也调用了transform方法),这些调用都会使得其对应的转换对象被加入到transformations集合中去。StreamTransformation表示创建DataStream对象的转换,流处理程序中存在多种DataStream,每种底层都对应着一个StreamTransformation。DataStream持有执行环境对象的引用,当调用transform方法时,它会调用执行环境对象的addOperator方法,将特定的StreamTransformation对象加入到transformations集合中去,这就是transformations集合中元素的来源。

DataStream API的设计存在着多重对象的封装,我们以flatMap转换操作为例图示各种对象之间的构建关系:

在Flink的源码中,这些对象的命名也并不是那么准确,比如上图中的SingleOutputStreamOperator其实是一种DataStream,但却以Operator结尾,让人匪夷所思。因此较为准确的鉴定它们类型的方式是通过查看它们的继承链来进行识别。

StreamGraph的生成依赖于生成器StreamGraphGenerator,每调用一次静态方法generate才会在内部创建一个StreamGraphGenerator的实例,一个实例对应着一个StreamGraph对象。StreamGraphGenerator调用内部的实例方法generateInternal来遍历transformations集合的每个对象:

private StreamGraph generateInternal(List<StreamTransformation<?>> transformations) {
    for (StreamTransformation<?> transformation: transformations) {
        transform(transformation);
    }
    return streamGraph;
}

在transform方法中,它枚举了Flink中每一种转换类型,并对当前传入的转换类型进行判断,然后将其分发给特定的转换方法进行转换,最终返回当前StreamGraph对象中跟该转换有关的节点编号集合。

这里我们以常用的单输入转换方法transformOnInputTransform为例来进行分析:

private <IN, OUT> Collection<Integer> transformOnInputTransform(
    OneInputTransformation<IN, OUT> transform) {
    //递归地对该转换的输入端进行转换
    Collection<Integer> inputIds = transform(transform.getInput());
    // 递归调用可能会产生重复,这里需要以转换过的对象进行检查
    if (alreadyTransformed.containsKey(transform)) {
        return alreadyTransformed.get(transform);
    }

    //结合输入端对应的节点编号来判断并得出槽共享组的名称
    String slotSharingGroup = determineSlotSharingGroup(transform.getSlotSharingGroup(), inputIds);
    //将当前算子(节点)加入到流图中
    streamGraph.addOperator(transform.getId(),
        slotSharingGroup,
        transform.getOperator(),
        transform.getInputType(),
        transform.getOutputType(),
        transform.getName());
    //如果有键选择器,则进行设置
    if (transform.getStateKeySelector() != null) {
        TypeSerializer<?> keySerializer =
            transform.getStateKeyType().createSerializer(env.getConfig());
        streamGraph.setOneInputStateKey(transform.getId(),
            transform.getStateKeySelector(), keySerializer);
    }
    streamGraph.setParallelism(transform.getId(), transform.getParallelism());
    //构建从当前转换对应的节点到输入转换对应的节点之间的边
    for (Integer inputId: inputIds) {
        streamGraph.addEdge(inputId, transform.getId(), 0);
    }
    //返回当前转换对应的节点编号
    return Collections.singleton(transform.getId());
}

每遍历完一个转换对象,就离构建完整的流图更近一步。不同的转换操作类型,它们为流图提供的“部件”并不完全相同,有的转换只构建节点(如SourceTransformation),有的转换除了构建节点还构建边(如SinkTransformation),有的只构建虚拟节点(如PartitionTransformation、SelectTransformation等)。

关于虚拟节点,这里需要说明的是并非所有转换操作都具有实际的物理意义(即物理上对应具体的算子)。有些转换操作只是逻辑概念(例如select,split,partition,union),它们不会构建真实的StreamNode对象。比如某个流处理应用对应的转换树如下图:

但在运行时,其生成的StreamGraph却是下面这种形式:

从图中可以看到,转换树中对应的一些逻辑操作在StreamGraph中并不存在,Flink将这些逻辑转换操作转换成了虚拟节点,它们的信息会被绑定到从source到map转换的边上。

Flink当前对于流处理的程序是不作优化的,所以StreamGraph就是它的执行计划。你可以通过Flink提供的执行计划的可视化器将StreamGraph所表述的信息以图形化的方式展示出来,就像上文我们展示的那幅图一样。那么我们如何查看我们自己所编写的程序的执行计划呢?其实很简单,我们以Flink源码中flink-examples-streaming模块中的SocketTextStreamWordCount为例,来看一下如何生成执行计划。

我们将SocketTextStreamWordCount最后一行代码注释掉:

env.execute("WordCount from SocketTextStream Example");

然后将其替换成下面这句:

System.out.println(env.getExecutionPlan());

这行语句的作用是打印当前这个程序的执行计划,它将在控制台产生该执行计划的JSON格式表示:

{"nodes":[{"id":1,"type":"Source: Socket Stream","pact":"Data Source","contents":"Source: Socket Stream",
"parallelism":1},{"id":2,"type":"Flat Map","pact":"Operator","contents":"Flat Map","parallelism":2,
"predecessors":[{"id":1,"ship_strategy":"REBALANCE","side":"second"}]},{"id":4,"type":"Keyed Aggregation",
"pact":"Operator","contents":"Keyed Aggregation","parallelism":2,"predecessors":[{"id":2,
"ship_strategy":"HASH","side":"second"}]},{"id":5,"type":"Sink: Unnamed","pact":"Data Sink",
"contents":"Sink: Unnamed","parallelism":2,"predecessors":[{"id":4,"ship_strategy":"FORWARD",
"side":"second"}]}]}

把上面这段JSON字符串复制到Flink的执行计划可视化器的输入框中,然后点击下方的“Draw”按钮,即可生成。

原文发布时间为:2017-02-05

本文作者:vinoYang

本文来自合作伙伴CSDN博客,了解相关信息可以关注CSDN博客。

时间: 2024-09-20 00:06:42

Flink运行时之流处理程序生成流图的相关文章

Flink运行时之生成作业图

生成作业图 在分析完了流处理程序生成的流图(StreamGraph)以及批处理程序生成的优化后的计划(OptimizedPlan)之后,下一步就是生成它们面向Flink运行时执行引擎的共同抽象--作业图(JobGraph). 什么是作业图 作业图(JobGraph)是唯一被Flink的数据流引擎所识别的表述作业的数据结构,也正是这一共同的抽象体现了流处理和批处理在运行时的统一. 相比流图(StreamGraph)以及批处理优化计划(OptimizedPlan),JobGraph发生了一些变化,已

Flink运行时之合久必分的特定任务

合久必分的特定任务 前面我们谈到了TaskManager对每个Task实例会启动一个独立的线程来执行.在分析线程执行的核心代码时,我们看到最终执行的是AbstractInvokable这样执行体的invoke方法.所谓合久必分,鉴于流处理任务跟批处理任务执行模式上存在巨大的差异,在对AbstractInvokable的实现时,它们将会走向两个不同的分支. 流处理相关的任务 流处理所对应的任务的继承关系图如下: 从上面的继承关系图可见,StreamTask是流处理任务的抽象.因为在DataStre

Flink运行时之客户端提交作业图-上

客户端提交作业图 作业图(JobGraph)是Flink的运行时所能理解的作业表示,无论程序通过是DataStream还是DataSet API编写的,它们的JobGraph提交给JobManager以及之后的处理都将得到统一.本篇我们将分析客户端如何提交JobGraph给JobManager. 流处理程序提交作业图 在前面讲解Flink的核心概念的时候我们谈到了Flink利用了"惰性求值"的概念,只有当最终调用execute方法时,才会真正开始执行.因此,execute方法是我们的切

Flink运行时之生产端结果分区

生产端结果分区 生产者结果分区是生产端任务所产生的结果.以一个简单的MapReduce程序为例,从静态的角度来看,生产端的算子(Map)跟消费端的算子(Reduce),两者之间交换数据通过中间结果集(IntermediateResult).形如下图: 而IntermediateResult只是在静态表述时的一种概念,在运行时,算子会被分布式部署.执行,我们假设两个算子的并行度都为2,那么对应的运行时模型如下图: 生产端的Map算子会产生两个子任务实例,它们各自都会产生结果分区(ResultPar

Flink运行时之统一的数据交换对象

统一的数据交换对象 在Flink的执行引擎中,流动的元素主要有两种:缓冲(Buffer)和事件(Event).Buffer主要针对用户数据交换,而Event则用于一些特殊的控制标识.但在实现时,为了在通信层统一数据交换,Flink提供了数据交换对象--BufferOrEvent.它是一个既可以表示Buffer又可以表示Event的类.上层使用者只需调用isBuffer和isEvent方法即可判断当前收到的这条数据是Buffer还是Event. 缓冲 缓冲(Buffer)是数据交换的载体,几乎所有

Flink运行时之基于Netty的网络通信上

概述 本文以及接下来的几篇文章将介绍Flink运行时TaskManager间进行数据交换的核心部分--基于Netty通信框架远程请求ResultSubpartition.作为系列文章的第一篇,先列出一些需要了解的基础对象. NettyConnectionManager Netty连接管理器(NettyConnectionManager)是连接管理器接口(ConnectionManager)针对基于Netty的远程连接管理的实现者.它是TaskManager中负责网络通信的网络环境对象(Netwo

Flink运行时之结果分区消费端

结果分区消费端 在前一篇,我们讲解了生产者分区,生产者分区是生产者任务生产中间结果数据的过程.消费者任务在获得结果分区可用的通知之后,会发起对数据的请求.我们仍然以生产者分区的例子作为假设,其在消费端示意图如下: 可以看到在生产端和消费端存在对等的模型,具体ResultSubpartition中的数据如何被消费,我们将在本篇进行深入剖析. 输入网关 输入网关(InputGate)用于消费中间结果(IntermediateResult)在并行执行时由子任务生产的一个或多个结果分区(ResultPa

Flink运行时之基于Netty的网络通信中

PartitionRequestClient 分区请求客户端(PartitionRequestClient)用于发起远程PartitionRequest请求,它也是RemoteChannel跟Netty通信层之间进行衔接的对象. 对单一的TaskManager而言只存在一个NettyClient实例.但处于同一TaskManager中不同的任务实例可能会跟不同的远程TaskManager上的任务之间交换数据,不同的TaskManager实例会有不同的ConnectionID(用于标识不同的IP地

Flink运行时之基于Netty的网络通信(下)

客户端核心处理器 这一篇,我们分析一下客户端协议栈中的核心的处理器PartitionRequestClientHandler,该处理器用于处理服务端的响应消息. 我们以客户端获取到响应之后回调该处理器的channelRead方法为入口来进行分析: public void channelRead(ChannelHandlerContext ctx, Object msg) throws Exception { try { //当没有待解析的原始消息时,直接解码消息,否则将消息加入到stagedMe