面试题_flink

明月清风，良宵美酒

已于 2022-01-21 15:37:28 修改

阅读量413

点赞数

分类专栏：大数据技术栈文章标签： flink

于 2019-12-28 16:59:17 首次发布

本文链接：https://blog.csdn.net/qq_40822132/article/details/103746368

版权

大数据技术栈专栏收录该内容

72 篇文章 32 订阅

订阅专栏

Flink及主流流框架比较

随着大数据时代的来临，大数据产品层出不穷。我们最近也对一款业内非常火的大数据产品 - Apache Flink做了调研，今天与大家分享一下。Apache Flink(以下简称flink) 是一个旨在提供‘一站式’ 的分布式开源数据处理框架。是不是听起来很像spark？没错，两者都希望提供一个统一功能的计算平台给用户。虽然目标非常类似，但是flink在实现上和spark存在着很大的区别，flink是一个面向流的处理框架，输入在flink中是无界的，流数据是flink中的头等公民。说到这里，大家一定觉得flink和storm有几分相似，确实是这样。那么有spark和storm这样成熟的计算框架存在，为什么flink还能占有一席之地呢？今天我们就从流处理的角度将flink和这两个框架进行一些分析和比较。

本文的流框架基于的实现方式，本文涉及的流框架基于的实现方式分为两大类。

第一类是Native Streaming，这类引擎中所有的data在到来的时候就会被立即处理，一条接着一条（HINT：狭隘的来说是一条接着一条，但流引擎有时会为提高性能缓存一小部分data然后一次性处理），其中的代表就是storm和flink。

第二种则是基于Micro-batch，数据流被切分为一个一个小的批次，然后再逐个被引擎处理。这些batch一般是以时间为单位进行切分，单位一般是‘秒‘，其中的典型代表则是spark了，不论是老的spark DStream还是2.0以后推出的spark structured streaming都是这样的处理机制；另外一个基于Micro-batch实现的就是storm trident，它是对storm的更高层的抽象，因为以batch为单位，所以storm trident的一些处理变的简单且高效。

流框架比较的关键指标

从流处理的角度将flink与spark和storm这两个框架进行比较，会主要关注以下几点，后续的对比也主要基于这几点展开：

功能性（Functionality）

是否能很好解决流处理功能上的痛点 , 比如event time和out of order data。容错性（Fault Tolerance）- 在failure之后能否恢复到故障之前的状态，并输出一致的结果；此外容错的代价也是越低越好，因为其直接影响性能。

吞吐量(throughputs)& 延时(latency)

性能相关的指标，高吞吐和低延迟某种意义上是不可兼得的，但好的流引擎应能兼顾高吞吐&低延时。

功能性（Functionality）Event time&Window Operation

①Event time

event time - 指数据或者事件真正发生时间 , 比如用户点击网页时产生一条点击事件的数据，点击时间就是这条数据固有的event time。

processing time - 指计算框架处理这条数据的时间。

park DStream和storm 1.0以前版本往往都折中地使用processing time来近似地实现event time相关的业务。显然，使用processing time模拟event time必然会产生一些误差，特别是在产生数据堆积的时候，误差则更明显，甚至导致计算结果不可用。在使用event time时，自然而然需要解决由网络延迟等因素导致的迟到或者乱序数据的问题。为了解决这个问题， spark、storm及flink都引入了watermark和lateness的概念。watermark: 是引擎处理事件的时间进度，代表一种状态，一般随着数据中的event time的增长而增长。比如 watermark(t)代表整个流的event time处理进度已经到达t，时间是有序的，那么streaming不应该会再收到timestamp t’ < t的数据，而只会接受到timestamp t’ >= t的数据。如果收到一条timestamp t’ < t的数据，那么就说明这条数据是迟到的。lateness: 表示可以容忍迟到的程度，在lateness可容忍范围内的数据还会参与计算，超过的会被丢弃。

②Window Operation下面主要比较在使用window的操作中，spark structured streaming 和flink对event time处理机制的不同。

flink

首先，我们结合图来看flink，时间轴从左往右增大。当watermark WM处于时间窗口区间内时，即WM ∈ [start, end] , event time落在窗口范围内的任何乱序数据都会被接受；随着WM的增长并超过了窗口的结束时间，但还未超过可容忍的lateness时间范围，即WM ∈ (window_end,window_end+ lateness]，这时乱序数据仍然可以被接受；只有当WM超过 window_end+lateness, 即WM ∈ (window_end+ lateness, ∞)，迟到的数据将会被丢弃。

fiink中watermark的算也比较灵活，可以选择build-in的（如最大时间戳），也可以通过继承接口自定义实现。此外，用户可以选择周期性更新或者事件触发更新watermark。

spark

首先,spark中watermark是通过上一个batch最大的timestamp再减去lateness得到的，即watermark = Max(last batch timestamps) - lateness。当数据的event time大于watermark时，数据会被接受，否则不论这条数据属于哪个窗口都会被丢弃。

下面来比较一下两者实现细节上的不同：

①lateness定义: 在spark中，迟到被定义为data的event time和watermark的比较结果，当data的event time < watermark时，data被丢弃；flink中只有在watermark > window_end + lateness的时候，data才会被丢弃。

②watermark更新: spark中watermark是上个batch中的max event time，存在延迟；而在flink中是可以做到每条数据同步更新watermark。

③window触发: flink中window计算会触发一次或多次，第一次在watermark >= window_end后立刻触发（main fire），接着会在迟到数据到来后进行增量触发。spark只会在watermark（包含lateness）过了window_end之后才会触发，虽然计算结果一次性正确，但触发比flink起码多了一个lateness的延迟。

上面三点可见flink在设计event time处理模型还是较优的：watermark的计算实时性高，输出延迟低，而且接受迟到数据没有spark那么受限。不光如此，flink提供的window programming模型非常的灵活，不但支持spark、storm没有的session window，而且只要实现其提供的WindowAssigner、Trigger、Evictor就能创造出符合自身业务逻辑的window，功能非常强大。

SQL API

目前flink相比spark，对streaming sql的支持还是比较初级的。在当前最新1.2版本中，仅支持Selection、Projection、Union、Tumble，不支持Aggregation、 Join、Top N、 Sort。计划中1.3版本将支持 Window Aggregation(sum、max、 min、avg), 但依然不支持Distinct。相比flink，当前最新版本的spark structured streaming仅仅不支持Top N、Distinct。

Kafka Source Integrationflink对于kafka的兼容性非常好，支持kafka 0.8、0.9、0.10；相反，spark structured streaming只支持kafka0.10或更高版本。

Interoperation with Static Dataspark底层对static batch data和streaming data有共同的rdd抽象，完美兼容互操作。而flink中DataSet 和 DataStream是完全独立的，不可以直接交互。此外，flink还可以运行storm的topology，带来较强的移植性。另外一个有趣的功能是可以自由调整job latency and throughputs的取舍关系，比如需要high throughputs的程序可以牺牲latency来获得更大的throughputs。

flink容错性（Fault Tolerance）

spark依赖checkpoint机制来进行容错，只要batch执行到doCheckpoint操作前挂了，那么该batch就会被完整的重新计算。spark可以保证计算过程的exactly once（不包含sink的exactly once）。

storm的容错通过ack机制实现，每个bolt或spout处理完成一条data后会发送一条ack消息给acker bolt。当该条data被所有节点都处理过后，它会收到来自所有节点ack，这样一条data处理就是成功的。storm可以保证数据不丢失，但是只能达到at least once语义。此外，因为需要每条data都做ack，所以容错的开销很大。storm trident是基于microbatched实现了exactly once语义。

flink使用Chandy-Chandy-Lamport Algorithm 来做Asynchronous Distributed Snapshots（异步分布式快照），其本质也是checkpoint。如下图，flink定时往流里插入一个barrier（隔栏），这些barriers把数据分割成若干个小的部分，当barrier流到某个operator时，operator立即会对barrier对应的一小部分数据做checkpoint并且把barrier传给下游（checkpoint操作是异步的，并不会打断数据的处理），直到所有的sink operator做完自己checkpoint后，一个完整的checkpoint才算完成。当出现failure时，flink会从最新完整的checkpoint点开始恢复。

CheckPoint是Flink实现故障容错的一种机制，系统会根据配置的检查点定期自动对程序计算状态进行备份。一旦程序在计算过程中出现故障，系统会选择一个最近的检查点进行故障恢复。SavePoint是一种有效的运维手段，需要用户手动触发程序进行状态备份，本质也是在做CheckPoint

flink的checkpoint机制非常轻量，barrier不会打断streaming的流动，而且做checkpoint操作也是异步的。其次，相比storm需要ack每条data，flink做的是small batch的checkpoint，容错的代价相对要低很多。最重要的是flink的checkpoint机制能保证exactly once。

吞吐量和延迟（Throughputs& Latency）

01.吞吐量（throughputs）spark是mirco-batch级别的计算，各种优化做的也很好，它的throughputs是最大的。但是需要提一下，有状态计算（如updateStateByKey算子）需要通过额外的rdd来维护状态，导致开销较大，对吞吐量影响也较大。storm的容错机制需要对每条data进行ack，因此容错开销对throughputs影响巨大，throughputs下降甚至可以达到70%。storm trident是基于micro-batch实现的，throughput中等。flink的容错机制较为轻量，对throughputs影响较小，而且拥有图和调度上的一些优化机制，使得flink可以达到很高 throughputs。

02.下图是flink官网给出的storm和flink的benchmark，我们可以看出storm在打开ack容错机制后，throughputs下降非常明显。而flink在开启checkpoint和关闭的情况下throughputs变化不大，说明flink的容错机制确实代价不高。对比官网的benchmark，我们也进行了throughputs的测试，实测结果是flink throughputs是storm的3.5倍，而且在解除了kafka集群和flink集群的带宽瓶颈后，flink自身又提高了1.6倍。

延迟（latency）spark基于micro-batch实现，提高了throughputs，但是付出了latency的代价。一般spark的latency是秒级别的。storm是native streaming实现，可以轻松的达到几十毫秒级别的latency，在几款框架中它的latency是最低的。storm trident是基于micro-batch实现的，latency较高。flink也是native streaming实现，也可以达到百毫秒级别的latency。下图是flink官网给出的和storm的latency对比benchmark。storm可以达到平均5毫秒以内的latency，而flink的平均latency也在30毫秒以内。两者的99%的data都在55毫秒latency内处理完成，表现都很优秀。

flink对延迟数据的处理方案

def sideOutputLateData(outputTag: OutputTag[T]): WindowedStream[T, K, W] = {
    javaStream.sideOutputLateData(outputTag)
    this
}
该方法是将迟来的数据保存至给定的outputTag参数，而OutputTag则是用来标记延迟数据的一个对象
DataStream.getSideOutput(tag: OutputTag[X])
通过window等操作返回的DataStream调用该方法，传入标记延迟数据的对象来获取延迟的数据

3.总结

综合对比spark、storm和flink的功能、容错和性能

不难发现， flink是一个设计良好的框架，它不但功能强大，而且性能出色。此外它还有一些比较好设计，比如优秀的内存管理和流控。但是，flink目前成熟度较低，还存在着不少问题，比如 SQL支持比较初级；无法像storm一样在不停止任务的情况下动态调整资源；不能像spark一样提供很好的streaming和static data的交互操作等。对于这些问题，flink社区还在积极的跟进，相信在更多公司和贡献者的共同努力下，flink会发展的越来越好。

Watermarker（水位线）

flink在做窗口计算的时候支持以下语义的window：Processing time、Event time、Ingestion time

Processing time:使用处理节点时间，计算窗口

Event time：使用事件产生时间，计算窗口- 精确

Ingestion time：数据进入到Flink的时间，一般是通过SourceFunction指定时间

默认Flink使用的是ProcessingTime ，因此一般情况下如果用户需要使用 Event time/Ingestion time需要设置时间属性

val fsEnv = StreamExecutionEnvironment.getExecutionEnvironment
fsEnv.setStreamTimeCharacteristic(TimeCharacteristic.EventTime)
//window  操作
fsEnv.execute("event time")

一旦设置基于EventTime处理，用户必须声明水位线的计算策略，系统需要给每一个流计算出水位线时间T，只有窗口的end time T’ < = watermarker(T)的时候，窗口才会被触发。在Flink当中需要用户实现水位线计算的方式，系统并不提供实现。触发水位线的计算方式有两种：

①一种是基于定时Interval（推荐）、

②通过记录触发，每来一条记录系统会立即更新水位线。

flink的状态存储

1.Keyed-state

类型	说明	方法
ValueState	这个状态主要存储一个可以用作更新的值	update(T) T value() clear()
ListState	这将存储List集合元素	add(T) addAll(List) Iterable get() update(List) clear()
ReducingState	这将保留一个值，该值表示添加到状态的所有值的汇总需要用户提供ReduceFunction	add(T) T get() clear()
AggregatingState<IN, OUT>	这将保留一个值，该值表示添加到状态的所有值的汇总需要用户提供AggregateFunction	add(IN) T get() clear()
FoldingState<T, ACC>	这将保留一个值，该值表示添加到状态的所有值的汇总需要用户提供FoldFunction	add(IN) T get() clear()
MapState<UK, UV>	这个状态会保留一个Map集合元素	put(UK, UV) putAll(Map<UK, UV>) entries() keys() values() clear()

State Time-To-Live（TTL）

可以将state存活时间（TTL）分配给任何类型的keyed-state，如果配置了TTL且状态值已过期，则Flink将尽力清除存储的历史状态值。

2.Operator State

如果用户想要使用Operator State，只需要实现通用的CheckpointedFunction 接口或者ListCheckpointed<T extends Serializable>，值得注意的是，目前的operator-state仅仅支持list-style风格的状态，要求所存储的状态必须是一个List，且其中的元素必须可以序列化。

3.broadcast 广播状态

支持Operator State的第三种类型是广播状态。引入广播状态以支持用例，其中需要将来自一个流的某些数据广播到所有下游任务，广播的状态将存储在本地，用于处理另一个流上所有传入的元素。

State Backend

State Backend决定Flink如何存储系统状态信息（Checkpoint形式），目前Flink提供了三种State Backend实现。

Memory （JobManagwer）：这是Flink的默认实现，通常用于测试，系统会将计算状态存储在JobManager的内存中，但是在实际的生产环境中，由于计算的状态比较多，使用Memory 很容易导致OOM（out of memory）。
FileSystem：系统会将计算状态存储在TaskManager的内存中，因此一般用作生产环境，系统会根据CheckPoin机制，将TaskManager状态数据在文件系统上进行备份。如果是超大规模集群，TaskManager内存也可能发生溢出。
RocksDB：系统会将计算状态存储在TaskManager的内存中，如果TaskManager内存不够，系统可以使用RocksDB配置本地磁盘完成状态的管理，同时支持将本地的状态数据备份到远程文件系统，因此，RocksDB Backend 是推荐的选择。

Flink Window简述

（对比spark讲解）

1.Tumbling Windows

滚动窗口长度固定，滑动间隔等于窗口长度，窗口元素之间没有交叠。

2.Sliding Windows

滑动窗口长度固定，窗口长度大于窗口滑动间隔，元素存在交叠。

3.Session Windows（MergerWindow）

通过计算元素时间间隔，如果间隔小于session gap，则会合并到一个窗口中；如果大于时间间隔，当前窗口关闭，后续的元素属于新的窗口。与滚动窗口和滑动窗口不同的是会话窗口没有固定的窗口大小，底层本质上做的是窗口合并。

4.Global Windows

全局窗口会将所有key相同的元素放到一个窗口中，默认该窗口永远都不会关闭（永远都不会触发），因为该窗口没有默认的窗口触发器Trigger，因此需要用户自定义Trigger。

Apache Flink - 数据流容错机制

Apache Flink提供了一种容错机制，可以持续恢复数据流应用程序的状态。该机制确保即使出现故障，程序的状态最终也会反映来自数据流的每条记录(只有一次)。

从容错和消息处理的语义上(at least once, exactly once)，Flink引入了state和checkpoint。

state一般指一个具体的task/operator的状态。而checkpoint则表示了一个Flink Job，在一个特定时刻的一份全局状态快照，即包含了所有task/operator的状态。

Flink通过定期地做checkpoint来实现容错和恢复，容错机制连续绘制了分布式流数据流的快照。对于小状态的流应用程序，这些快照非常轻量级并且可以经常绘制，而不会对性能产生太大的影响。流应用程序的状态存储在一个可配置的地方(例如主节点或HDFS)。

如果出现程序故障(由于机器、网络或软件故障)，Flink将停止分布式流数据流。然后系统重新启动操作符并将其重新设置为最新成功的检查点。输入流被重置到状态快照的点。默认情况下，检查点是禁用的。

要使此机制实现其全部的保证，数据流源(如消息队列或代理)需要能够将流倒回到其定义的最近点。Apache Kafka可以做到，而Flink的Kafka连接器可以利用这些。

因为Flink通过分布式检查点实现快照，我们使用快照和检查点互换。

checkpointing：

检查点默认情况下不被保留，并且仅用于从失败中恢复作业。当程序被取消时，检查点被删除，你可以配置定期的检查点使他们得以保留。
Flink容错机制的核心部分是绘制分布式数据流和操作符状态的一致的快照。这些快照充当一致的检查点，在出现故障时系统可以退回到检查点。
Barriers：Flink的分布式快照的核心元素是stream barriers。这些barriers被注入到数据流中和记录一样作为数据流的一部分流动。Barriers从不会超过记录。Barriers将数据流中的记录分为进入当前快照的记录集和进入下一个快照的记录。每个barriers都带有快照的ID，该快照的记录在其前面推送。Barriers不会阻断流的流动。流barriers被注入到流数据源的并行数据流中，快照n的barriers(我们称之为Sn*)被注入的点是源流中快照覆盖数据的位置。例如，在Apache Kafka中，此位置是分区中最后一条记录的偏移量。该位置Sn被报告给Flink的JobManager。然后barriers继续流动，当中间操作符从其所有输入流都收到快照n的barriers时，他会向所有输出流发出(emit)快照n的barriers。一旦操作符接收器(流DAG的末端)从它的所有输入流接收到barrier n，它就向快照n确认检查点协调器。在所有接收器确认快照后，它被视为已完成。一旦完成快照n*，作业将永远不再向源请求来自Sn之前的记录，因为此时这些记录(及其后代记录)将通过整个数据流拓扑。[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-UPMsNJ50-1577523470993)(https://ci.apache.org/projects/flink/flink-docs-release-1.6/fig/stream_aligning.svg)] 接收多个输入流的运算符需要在快照barriers上对齐输入流。上图说明了这一点：
- 一旦操作员从输入流接收到快照barriers n，它就不能处理来自该流的任何其他记录(而是缓存)，直到它从其他输入接收到barrier n为止。否则它会混合属于快照n和属于快照n + 1的记录。(begin aligning - aligning)
- 报告barrier n的流暂时被搁置。从这些流接收的记录不会被处理，而是放入输入缓冲区。(aligning)
- 一旦最后一个输入流接收到barrier n，操作符就会发出所有挂起的传出记录，然后自己发出快照n的barriers。(checkpoint - continue)
- 之后，它恢复处理来自所有输入流的记录，在处理来自流的记录之前处理来自输入缓冲区的记录。(continue)
State：当运算符包含任何形式的状态时，此状态也必须是快照的一部分。运算符状态有不同的形式：
- 用户定义的状态：这是由转换函数(如map()或filter())直接创建和修改的状态。
- 系统状态：此状态是指作为运算符计算一部分的数据缓冲区。此状态的典型示例是窗口缓冲区，系统在其中收集(和聚合)窗口记录，直到窗口被评估和逐出。运算符在他们从输入流接收到所有快照barriers时，在向其输出流发出barriers之前立即对其状态进行快照。此时，将根据barriers之前的记录对状态进行所有更新，并且在应用barriers之后不依赖于记录的更新。由于快照的状态可能很大，因此它存储在可配置的状态后端(state backend)中。默认情况下，这是JobManager的内存，但对于生产使用，应配置分布式可靠存储(例如HDFS)。在存储状态之后，运算符确认检查点，将快照barriers发送到输出流中，然后继续。
- 生成的快照现在包含：
- - 对于每个并行流数据源，启动快照时流中的偏移/位置。
  - 对于每个运算符，指向作为快照的一部分存储的状态的指针。[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-fDIkr44O-1577523470993)(https://ci.apache.org/projects/flink/flink-docs-release-1.6/fig/checkpointing.svg)]
仅有一次或至少一次：对齐(alignment)步骤可以增加流式传输程序的等待时间。Flink可以在检查点期间跳过流对齐。一旦运算符看到每个输入的检查点barrier，仍然会绘制检查点快照。当跳过对齐时，即使在检查点n的某些检查点barrier到达之后，运算符仍继续处理所有输入。这样，操作员还可以在获取检查点n的状态快照之前处理属于检查点n + 1的元素。在还原时，这些记录将作为重复记录出现，因为它们都包含在检查点n的状态快照中，并将在检查点n之后作为数据的一部分进行重放。对齐仅适用于具有多个前驱(连接)的运算符以及具有多个发送方的运算符(在流重新分区/随机播放之后)。正因为如此，即使在至少一次(at least once)模式中，数据流实际上在尴尬的并行流操作(map()，flatMap()，filter()，…)中给了正好一次(exactly once)保证。
异步状态快照：上述机制意味着运算符在将状态的快照存储在状态后端时停止处理输入记录。每次拍摄快照时，此同步状态快照都会引入延迟。可以让运算符在存储状态快照时继续处理，有效地让状态快照在后台异步发生。为此，运算符必须能够生成一个状态对象，该状态对象应以某种方式存储，以便对运算符状态的进一步修改不会影响该状态对象。在接收到输入的检查点barriers后，运算符启动其状态的异步快照复制。它立即释放其输出的barriers，并继续进行常规流处理。后台复制过程完成后，它会向检查点协调者(JobManager)确认检查点。检查点现在仅在所有接收器都已收到barriers并且所有有状态运算符已确认其完成备份(可能在barriers到达接收器之后)之后才完成。
恢复：当失败时，Flink选择最新完成的检查点k。然后，系统重新部署整个分布式数据流，并为每个操作符提供作为检查点k的一部分的快照的状态。设置源从位置Sk开始读取流。例如，在Apache Kafka中，这意味着告诉消费者从偏移量Sk开始提取。如果状态以递增方式快照，则运算符从最新完整快照的状态开始，然后对该状态应用一系列增量快照进行更新。
运算符快照实现：在执行运算符快照时，有同步和异步两部分。运算符和状态后端将他们的快照作为一个Java FutureTask。该任务包含已完成的同步部分且处于挂起状态的异步部分。然后异步部分由该检查点的后台线程执行。检查点纯粹同步地返回已经完成的运算符FutureTask，如果需要执行异步操作，则以该run()方法执行FutureTask。任务是可取消的，因此流和其他消耗句柄的资源是可以被释放的。