VinoYang的专栏

最近我们向Flink社区贡献了一个全新的Kafka连接器（https://github.com/apache/flink/pull/6703），关联JIRA issue FLINK-9697。它包含了近6000行代码变更，经历了社区近100次的review讨论与评论。这一大特性即将会随Flink 1.7一起发布。这一特性也得到了一众Flink PMC的赞赏：现状与问题Apache Kafk...

overview本文档以TO_BASE64函数为例，介绍如何实现、扩展Flink Table&SQL Scalar function。使用方式自定义的Scalar函数有多种使用方式，我们以测试代码来了解一下，具体是如何使用的： @Test def testToBase64(): Unit = { testAllApis( 'f0.toBas...

本文剖析一下Uber Athenax项目的核心技术点。AthenaX是一个流式分析平台，它可以让用户运行SQL来进行大规模可扩展的流式分析。由Uber开源，具备扩展到上百台节点处理日均千亿级别的实时事件。

streaming & table

关系型程序的公共部分下面的代码段展示了Table&SQL API所编写流式程序的程序模式

在接触关系型API之前，用户通常会采用DataStream、DataSet API来编写Flink程序，它们都提供了丰富的处理能力，以DataStream为例，它有如下这些优点：

对某些迭代而言并不是单次迭代产生的下一次工作集中的每个元素都需要重新参与下一轮迭代，有时只需要重新计算部分数据同时选择性地更新解集，这种形式的迭代就是增量迭代。

source作为Table&SQL API的数据源，同时也是程序的入口。当前Flink的Table&SQL API整体而言支持三种source：Table source、DataSet以及DataStream，它们都通过特定的API注册到Table环境对象。

EventTime，ProcessingTime，Watermark，out-of-order..

在一段时间之前我们已介绍过IP（Interesting Property）对于优化器的意义以及它将对优化器的优化决策产生的影响。本篇我们将介绍Flink的批处理优化器中涉及到的所有的IP，我们将其统称为数据属性。后续我们会介绍Flink如何为优化器节点计算IP，并在之后的“剪枝”（pruning）阶段发挥作用。

采样算法上一篇我们分析了RangePartitionRewriter的数据处理分支，接下来我们开始分析采样分支，采样分支的核心在于采样算法。因为范围分区输入端每个分区的数据量无从得知，也就是说我们无法得出采样比例。

为最终计划应用范围分区重写Flink的批处理程序允许用户使用partitionByRange API来基于某个（或某些）字段进行按范围分区且可以选择性地指定排序顺序，示例代码如下：

submitJob方法分析JobClientActor通过向JobManager的Actor发送SubmitJob消息来提交Job，JobManager接收到消息对象之后，构建一个JobInfo对象以封装Job的基本信息

客户端提交作业图作业图（JobGraph）是Flink的运行时所能理解的作业表示，无论程序通过是DataStream还是DataSet API编写的，它们的JobGraph提交给JobManager以及之后的处理都将得到统一。本篇我们将分析客户端如何提交JobGraph给JobManager。

成本估算在基于成本的优化器中，成本估算非常重要，它直接影响着候选计划的生成。在Flink中成本估算依赖于每个不同的运算符所提供的自己的“预算”，本篇我们将分析什么是成本、运算符如何提供自己的预算以及如何基于预算估算成本。

之前我们分析了CEP的API，接下来我们将分析CEP API的内部实现包括模式流与运算符。模式流模式流（PatternStream）是CEP模式匹配的流抽象，一个PatternStream对象表示模式检测到的序列所对应的流。该序列以映射来表示，以模式名关联一组事件对象。

NFAbNFA ^ b编译器的作用是将模式对象编译成NFA或者NFAFactory（用来创建多种NFA对象）。这个编译的过程，需要对模式进行拆分从而构建状态以及根据条件构建状态转换信息，最终根据构建好的状态集合来创建NFA。示意图如下：

NFAbNFA ^ b模型包含两个阶段：第一个阶段是模式匹配阶段，在这个阶段它将会向最终态过渡并随着事件被选择而扩展缓冲区；第二个阶段是匹配提取阶段，该阶段发生在超时或者到达最终态时，将会从缓冲区中检索所产生的匹配。

带版本的共享缓冲区当股票模式以一个事件流作为输入时，状态转换将会作用于事件流从而引起事件的状态变化。结合窗口对参与匹配的事件的限制以及模式中结合事件上下文（状态）的过滤条件，同一事件流随着时间的流动或者多次运行都会产生多种不同的匹配结果。

Flink CEP的论文与设计Flink的CEP设计与实现重度参考了论文《Efficient Pattern Matching over Event Streams》。下面我们就来结合论文谈谈Flink CEP的设计。

上一篇我们介绍了Flink CEP的API，这一篇我们将以结合一个案例来练习使用CEP的API编写应用程序，以强化对API的理解。所选取的案例是对网络遭受的潜在攻击进行检测并给出告警。当下互联网安全形势仍然严峻，网络攻击屡见不鲜且花样众多，这里我们以DDOS（分布式拒绝服务攻击）产生的流入流量来作为遭受攻击的判断依据。

CEP API的核心是Pattern API，它允许你快速定义复杂的事件模式。每个模式包含多个阶段（stage）或者我们也可称为状态（state）。为了从一个状态切换到另一个状态，用户可以指定条件，这些条件可以作用在邻近的事件或独立事件上。

生成作业图在分析完了流处理程序生成的流图（StreamGraph）以及批处理程序生成的优化后的计划（OptimizedPlan）之后，下一步就是生成它们面向Flink运行时执行引擎的共同抽象——作业图（JobGraph）。

批处理程序生成计划DataSet API所编写的批处理程序跟DataStream API所编写的流处理程序在生成作业图（JobGraph）之前的实现差别很大。流处理程序是生成流图（StreamGraph），而批处理程序是生成计划（Plan）并由优化器对其进行优化并生成优化后的计划（OptimizedPlan）。

Interesting Properties（以下简称IP）用来表述在对生成的计划进行分析时一些可能对优化产生重要影响的属性。

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

合久必分的特定任务前面我们谈到了TaskManager对每个Task实例会启动一个独立的线程来执行。在分析线程执行的核心代码时，我们看到最终执行的是AbstractInvokable这样执行体的invoke方法。所谓合久必分，鉴于流处理任务跟批处理任务执行模式上存在巨大的差异，在对AbstractInvokable的实现时，它们将会走向两个不同的分支。

TaskManager执行任务当一个任务被JobManager部署到TaskManager之后，它将会被执行。本篇我们将分析任务的执行细节。

这一篇，我们分析一下客户端协议栈中的核心的处理器PartitionRequestClientHandler，该处理器用于处理服务端的响应消息。

PartitionRequestClient分区请求客户端（PartitionRequestClient）用于发起远程PartitionRequest请求，它也是RemoteChannel跟Netty通信层之间进行衔接的对象。对单一的TaskManager而言只存在一个NettyClient实例。

概述本文以及接下来的几篇文章将介绍Flink运行时TaskManager间进行数据交换的核心部分——基于Netty通信框架远程请求ResultSubpartition。作为系列文章的第一篇，先列出一些需要了解的基础对象。

结果分区消费端在前一篇，我们讲解了生产者分区，生产者分区是生产者任务生产中间结果数据的过程。消费者任务在获得结果分区可用的通知之后，会发起对数据的请求。

生产端结果分区生产者结果分区是生产端任务所产生的结果。以一个简单的MapReduce程序为例，从静态的角度来看，生产端的算子（Map）跟消费端的算子（Reduce），两者之间交换数据通过中间结果集（IntermediateResult）。

上图中红框部分即为通信层API。通信层API通信层API介于任务执行与通信细节之间，主要用于对上层任务执行提供记录的读写服务同时屏蔽底层的通信细节。主要包括三个部件：将记录写入结果分区的写入器、将数据从输入网关中读出并反序列化为记录的读取器以及周旋在记录和二进制的Buffer数据之间对数据表示进行转换的序列化器。

统一的数据交换对象在Flink的执行引擎中，流动的元素主要有两种：缓冲（Buffer）和事件（Event）。Buffer主要针对用户数据交换，而Event则用于一些特殊的控制标识。但在实现时，为了在通信层统一数据交换，Flink提供了数据交换对象——BufferOrEvent。它是一个既可以表示Buffer又可以表示Event的类。

网络环境（NetworkEnvironment）是TaskManager进行网络通信的主对象，主要用于跟踪中间结果并负责所有的数据交换。每个TaskManager的实例都包含一个网络环境对象，在TaskManager启动时创建。NetworkEnvironment管理着多个协助通信的关键部件。

前面我们分析过Flink对迭代在流图中的特殊处理，使得迭代中的反馈环得以转化为普通的DAG模型。这一篇我们将剖析运行时的流处理迭代任务的执行机制。这里涉及到两个任务类：

我们都知道Flink在可迭代的流处理中引入了反馈边来将本次迭代的结果反馈给迭代头以进行下一次迭代，这在执行拓扑中引入了环（反馈环）。Flink主要应对的执行拓扑还是有向无环图（DAG），最终它选择了将反馈环进行化解使其能够适配有向无环图的结构，而如何对反馈环进行化解是我们这一篇主要探讨的话题。

Flink在DataStream中也是通过一个特定的可迭代的流（IterativeStream）来构建相关的迭代处理逻辑，这一点跟DataSet提供的可迭代的数据集（IterativeDataSet）的是类似的。

当前Flink将迭代的重心集中在批处理上，之前我们谈及了批量迭代和增量迭代主要是针对批处理（DataSet）API而言的，并且Flink为批处理中的迭代提供了针对性的优化。但是对于流处理（DataStream），Flink同样提供了对迭代的支持，这一节我们主要来分析流处理中的迭代，我们将会看到流处理中的迭代相较于批处理有相似之处，但差异也是十分之明显。