flink基本原理

一、简介

开源流式处理系统在不断地发展，从一开始只关注低延迟指标到现在兼顾延迟、吞吐与结果准确性，在发展过程中解决了很多问题，编程api的易用性也在不断地提高。本文介绍一下 flink 中的核心概念，这些概念是学习与使用 flink 十分重要的基础知识，在后续开发 flink 程序过程中将会帮助开发人员更好地理解 flink 内部的行为和机制。

这里引用一张图来对常用的实时计算框架做个对比：

flink 是有状态的和容错的，可以在维护一次应用程序状态的同时无缝地从故障中恢复。它支持大规模计算能力，能够在数千个节点上并发运行。它具有很好的吞吐量和延迟特性。同时，flink 提供了多种灵活的窗口函数。flink 在流式计算里属于真正意义上的单条处理，每一条数据都触发计算，而不是像 spark 一样的 mini batch 作为流式处理的妥协。flink的容错机制较为轻量，对吞吐量影响较小，而且拥有图和调度上的一些优化，使得 flink 可以达到很高的吞吐量。而 strom 的容错机制需要对每条数据进行ack，因此其吞吐量瓶颈也是备受诟病。

二、工作原理

flink基本工作原理如下图：

jobclient：负责接收程序，解析和优化程序的执行计划，然后提交执行计划到jobmanager。这里执行的程序优化是将相邻的operator融合，形成operator chain，operator的融合可以减少task的数量，提高taskmanager的资源利用率。

jobmanagers：负责申请资源，协调以及控制整个job的执行过程，具体包括，调度任务、处理checkpoint、容错等等。

taskmanager：taskmanager运行在不同节点上的jvm进程，负责接收并执行jobmanager发送的task,并且与jobmanager通信，反馈任务状态信息，如果说jobmanager是master的话，那么taskmanager就是worker用于执行任务。每个taskmanager像是一个容器，包含一个或者多个slot。

slot：slot是taskmanager资源粒度的划分，每个slot都有自己独立的内存。所有slot平均分配taskmanager的内存，值得注意的是，slot仅划分内存，不涉及cpu的划分，即cpu是共享使用。每个slot可以运行多个task。slot的个数就代表了一个程序的最高并行度。

task：task是在operators的subtask进行链化之后形成的，具体flink job中有多少task和operator的并行度和链化的策略有关。

subtask：因为flink是分布式部署的，程序中的每个算子，在实际执行中被分隔为一个或者多个subtask，运算符子任务(subtask)的数量是该特定运算符的并行度。数据流在算子之间流动，就对应到subtask之间的数据传输。flink允许同一个job中来自不同task的subtask可以共享同一个slot。每个slot可以执行一个并行的pipeline。可以将pipeline看作是多个subtask的组成的。

三、核心概念

1、time（时间语义）

flink 中的 time 分为三种：事件时间、达到时间与处理时间。

1）事件时间：是事件真实发生的时间。

2）达到时间：是系统接收到事件的时间，即服务端接收到事件的时间。

3）处理时间：是系统开始处理到达事件的时间。

在某些场景下，处理时间等于达到时间。因为处理时间没有乱序的问题，所以服务端做基于处理时间的计算是比较简单的，无迟到与乱序数据。

flink 中只需要通过 env 环境变量即可设置time：

//创建环境上下文
val env = streamexecutionenvironment.getexecutionenvironment
// 设置在当前程序中使用 processingtime
env.setstreamtimecharacteristic(timecharacteristic.processingtime);

2、window（窗口）

窗口本质就是将无限数据集沿着时间（或者数量）的边界切分成有限数据集。

1）time window：基于时间的，分为tumbling window和sliding window 。

2）count window：基于数量的，分为tumbling window和sliding window。 

3）session window：基于会话的，一个session window关闭通常是由于一段时间没有收到元素。

4）global window：全局窗口。

在实际操作中，window又分为两大类型的窗口：keyed window 和 non-keyed window，两种类型的窗口操作api有细微的差别。

 3、trigger

1）自定义触发器

触发器决定了窗口何时会被触发计算，flink 中开发人员需要在 window 类型的操作之后才能调用 trigger 方法传入触发器定义。flink 中的触发器定义需要继承并实现 trigger 接口，该接口有以下方法：

• onelement(): 每个被添加到窗口中的元素都会被调用
• oneventtime(): 当事件时间定时器触发时会被调用，比如watermark到达
• onprocessingtime(): 当处理时间定时器触发时会被调用，比如时间周期触发
• onmerge(): 当两个窗口合并时两个窗口的触发器状态将会被调动并合并
• clear(): 执行需要清除相关窗口的事件

以上方法会返回决定如何触发执行的 triggerresult：

• continue: 什么都不做
• fire: 触发计算
• purge: 清除窗口中的数据
• fire_and_purge: 触发计算后清除窗口中的数据

2）预定义触发器

如果开发人员未指定触发器，则 flink 会自动根据场景使用默认的预定义好的触发器。在基于事件时间的窗口中使用 eventtimetrigger，该触发器会在watermark通过窗口边界后立即触发（即watermark出现关闭改窗口时）。在全局窗口（globalwindow）中使用 nevertrigger，该触发器永远不会触发，所以在使用全局窗口时用户需要自定义触发器。

4、state

managed state 是由flink runtime管理来管理的，自动存储、自动恢复，在内存管理上有优化机制。且managed state 支持常见的多种数据结构，如value、list、map等，在大多数业务场景中都有适用之处。总体来说是对开发人员来说是比较友好的，因此 managed state 是 flink 中最常用的状态。managed state 又分为 keyed state 和 operator state 两种。

raw state 由用户自己管理，需要序列化，只能使用字节数组的数据结构。raw state 的使用和维度都比 managed state 要复杂，建议在自定义的operator场景中酌情使用。

5、状态存储

flink中状态的实现有三种：memorystate、fsstate、rocksdbstate。三种状态存储方式与使用场景各不相同，详细介绍如下：

1）memorystatebackend

构造函数：memorystatebackend(int maxstatesize, boolean asyncsnapshot)

存储方式：state存储于各个 taskmanager内存中，checkpoint存储于 jobmanager内存

容量限制：单个state最大5m、maxstatesize<=akka.framesize（10m）、总大小不超过jobmanager内存

使用场景：无状态或者jobmanager挂掉不影响的测试环境等，不建议在生产环境使用

2）fsstatebackend

构造函数：fsstatebackend(uri checkpointuri, boolean asyncsnapshot)

存储方式：state存储于 taskmanager内存，checkpoint存储于 外部文件系统（本次磁盘 or hdfs）

容量限制：state总量不超过taskmanager内存、checkpoint总大小不超过外部存储空间

使用场景：常规使用状态的作业，分钟级的窗口聚合等，可在生产环境使用

3）rocksdbstatebackend

构造函数：rocksdbstatebackend(uri checkpointuri, boolean enableincrementcheckpoint)

存储方式：state存储于 taskmanager上的kv数据库（内存+磁盘），checkpoint存储于 外部文件系统（本次磁盘 or hdfs）

容量限制：state总量不超过taskmanager内存+磁盘、单key最大2g、checkpoint总大小不超过外部存储空间

使用场景：超大状态的作业，天级的窗口聚合等，对读写性能要求不高的场景，可在生产环境使用

根据业务场景需要用户选择最合适的 statebackend ，代码中只需在相应的 env 环境中设置即可：

// flink 上下文环境变量
val env = streamexecutionenvironment.getexecutionenvironment
// 设置状态后端为 fsstatebackend，数据存储到 hdfs /tmp/flink/checkpoint/test 中
env.setstatebackend(new fsstatebackend("hdfs://ns1/tmp/flink/checkpoint/test", false))

6、checkpoint

checkpoint 是分布式全域一致的，数据会被写入hdfs等共享存储中。且其产生是异步的，在不中断、不影响运算的前提下产生。

用户只需在相应的 env 环境中设置即可：

// 1000毫秒进行一次 checkpoint 操作
env.enablecheckpointing(1000)
// 模式为准确一次
env.getcheckpointconfig.setcheckpointingmode(checkpointingmode.exactly_once)
// 两次 checkpoint 之间最少间隔 500毫秒
env.getcheckpointconfig.setminpausebetweencheckpoints(500)
// checkpoint 过程超时时间为 60000毫秒，即1分钟视为超时失败
env.getcheckpointconfig.setcheckpointtimeout(60000)
// 同一时间只允许1个checkpoint的操作在执行
env.getcheckpointconfig.setmaxconcurrentcheckpoints(1)

7、watermark

flink 程序并 不能自动提取数据源中哪个字段/标识为数据的事件时间，从而也就无法自己定义 watermark 。

开发人员需要通过 flink 提供的 api 来 提取和定义 timestamp/watermark，可以在 数据源或者数据流中 定义。

1）自定义数据源设置 timestamp/watermark

自定义的数据源类需要继承并实现 sourcefunction[t] 接口，其中 run 方法是定义数据生产的地方：

//自定义的数据源为自定义类型mytype
class mysource extends sourcefunction[mytype]{
    //重写run方法，定义数据生产的逻辑
    override def run(ctx: sourcecontext[mytype]): unit = {
        while (/* condition */) {
            val next: mytype = getnext()
            //设置timestamp从mytype的哪个字段获取(eventtimestamp)
            ctx.collectwithtimestamp(next, next.eventtimestamp)

            if (next.haswatermarktime) {
                //设置watermark从mytype的那个方法获取(getwatermarktime)
                ctx.emitwatermark(new watermark(next.getwatermarktime))
            }
        }
    }
}

2）在数据流中设置 timestamp/watermark

在数据流中，可以设置 stream 的 timestamp assigner ，该 assigner 将会接收一个 stream，并生产一个带 timestamp和watermark 的新 stream。

val withtimestampsandwatermarks: datastream[myevent] = stream
        .assigntimestampsandwatermarks(new mytimestampsandwatermarks())

8、广播状态（broadcast state）

和 spark 中的广播变量一样，flink 也支持在各个节点中各存一份小数据集，所在的计算节点实例可在本地内存中直接读取被广播的数据，可以避免shuffle提高并行效率。

广播状态（broadcast state）的引入是为了支持一些来自一个流的数据需要广播到所有下游任务的情况，它存储在本地，用于处理其他流上的所有传入元素。

// key the shapes by color
keyedstream<item, color> colorpartitionedstream = shapestream.keyby(new keyselector<shape, color>(){...});

// a map descriptor to store the name of the rule (string) and the rule itself.
mapstatedescriptor<string, rule> rulestatedescriptor = new mapstatedescriptor<>("rulesbroadcaststate",basictypeinfo.string_type_info, typeinformation.of(new typehint<rule>() {}));
        
// broadcast the rules and create the broadcast state
broadcaststream<rule> rulebroadcaststream = rulestream.broadcast(rulestatedescriptor);

datastream<match> output = colorpartitionedstream.connect(rulebroadcaststream).process(new keyedbroadcastprocessfunction<color, item, rule, string>(){...});

9、operator chain

flink作业中，可以指定相关的chain将相关性非常强的转换操作（operator）绑定在一起，使得上下游的task在同一个pipeline中执行，避免因为数据在网络或者线程之间传输导致的开销。

一般情况下flink在map类型的操作中默认开启 operator chain 以提高整体性能，开发人员也可以根据需要创建或者禁止 operator chain 对任务进行细粒度的链条控制。

//创建 chain
datastream.filter(...).map(...).startnewchain().map(...)
//禁止 chain
datastream.map(...).disablechaining()

创建的链条只对当前的操作符和之后的操作符有效，不不影响其他操作，如上代码只针对两个map操作进行链条绑定，对前面的filter操作无效，如果需要可以在filter和map之间使用 startnewchain方法即可。