flink官网（flink官网中文）

本篇文章给大家谈谈flink官网，以及flink官网中文对应的知识点，希望对各位有所帮助，不要忘了收藏本站喔。

本文目录一览：

• 1、Flink内存管理
• 2、Flink HistoryServer配置（简单三步完成）
• 3、FlinkKafkaConsumer官网文档翻译
• 4、Storm，Spark，Flink对比

Flink内存管理

java所有数据类型对应的字节大小

java对象的组成 : 对象头,实例数据,对齐部分

jvm 序列化缺点

上面图为TaskManager内存模型,左边为细分的内存模型,右边为整体内存模型,该图摘自Flink官网

heap内存在jvm启动的时候申请的一块不变的内存区域,该内存实际上是Flink和task公用的一块区域,在flink层面通过闷衡控制来区分框架使用和task内存,heap内存管理起来是比较容易的,实际上non-heap的内存是难管理的一块,如果管理不当或者使用不当可能造成内存泄漏或者内存无限增长等问题

内存参数配置

在flink中对内存进行了抽象成了MemorySegment,�默认情况下,一个 MemorySegment 对应着一个 32KB 大小的内存块,这块内存既可以是堆上内存( byte数组) ,也可以是堆外内存(nio的ByteBufferr ) .

同时MemorySegment也提供了对二进制数据轿陵的操作方法,以及读取字节数组序列化以及序列化字节数组的方法等

下面是类继承图,该类有两MemorySegment实现类有两个分别为使用heap的以及混合的即有heap和non-heap,对于内存的访问有子类具体的实现

MemorySemgent是flink内存分配的最小单元了,对于数据夸MemorySemgent保存,那么对于上层的使用者来说闭罩戚,需要考虑考虑所有的细节,由于过于繁琐,所以在MemorySemgent上又抽象了一层内存也,内存也是在MemorySemgent数据访问上的视图,对数据输入和输出分别抽象为DataInputView/DataOutputView,有了这一层,上层使用者无需关心跨MemorySemgent的细节问题,内存也对自动处理跨MemorySemgent的内存操作

DataInputView

DataInputView继承DataInput,DataInputView是对MemorySemgent读取的抽象视图,提供一系列读取二进制数据不同类型的方法,AbstractPageInputView是DataInputView的一个抽象实现类,并且基本所有InputView都实现了该类,即所有实现该类的InputView都支持Page

InputView持有了多个MemorySemgent的引用(可以基于数组,list,deque等),这些MemorySemgent被视为一个内存页,可以顺序,随机等方式读取数据,要基于不同的实现类,实现类不同读取方式不同

方法图

DataOutputView

与DataInputView相对应,继承Output,并有一个拥有Page功能的抽象类(AbstractPagedOutputView),其大部outputView的实现都是继承自该抽象类,对一组MemorySemgent提供一个基于页的写入功能

方法图

类继承图

用于网络io数据的包装,每个buffer持有一个MemorySegment的引用,resultPartition写数据的时候,会向LocalBufferPool申请Buffer,会返回BufferBuilder,通过BufferBuilder想Buffe r实际写入的是MemorySegment 写数据

BufferBuilder是在上游Task中,负责想Buffer写入数据,BufferConsumer位于下游,与BufferBuilder相对应,用于消费Buffer的数据,每个bufferBuilder对应一个bufferConsumer

常用参数介绍

buffer申请

buffer回收

当buffer用完之后需要进行回收比如在netty的clientHandler收到响应之后进行处理就会把buffer回收掉,buffer回收之后并不会释放memorySegment,而是放回池中,变为可用内存,反复使用

flink托管的内存,托管内存使用堆外内存,用于批处理缓存排序等以及提供rocksDB内存

NetworkBufferPool是一个固定大小的MemorySegment实例吃,用于网络栈中,NettyBufferPool会为每个ResultPartition创建属于自己的LocalBufferPool,NettyBufferPool会作为全局的pool来提供内存,LocalBufferPool会通过限制来控制自己内存的申请,防止过多申请

LocalBufferPool继承关系,实现了bufferRecycler的接口,用于回收自己持有的buffer

在数据接收的时候会将数据封装成NettyBuffer,在数据发送的时候会通过BufferBilder向MemorySegment写入数据,然后通过BufferConsumer读取MemorySegment的数据

BufferManager主要用于为RemoteInputChannel提供buffer的,bufferManager在启动的时候会向全局bufferPool请求自己的独有buffer,当bufferManager的buffer不够的时候,则会向localBufferPool请求buffer,此时请求的buffer为浮动buffer

实际上提供的buffer是

Flink HistoryServer配置（简单三步完成）

允许您查询JobManager存档的已完成作业的状态和统计信息。(官网原话)

最适合用于：了解 flink过去完成任务的状态，以及有状态作业的恢复（保存了最后一次的checkpoint地消卜址）

官网地址：

官网配置参数：

修改flink-1.11.2/conf/flink-conf.yaml文件

两张图：

historyserver.web.tmpdir的默认配置图：

historyserver.web.tmpdir的自定义路径配置图：

在hdfs的/flink目录下创建completed-jobs目录含桥简（权限可以改成777）

启动/关闭命令:

1、查看启动状态

2、分别启一个per-job任务、sql任务、基于session启的任务，过一会全部cancel掉，都可以在hdfs路径和/tmp下的自定义目录看到相关数据，最后可以在host:8082上面看到你刚才canceled的任务，如下图：

3、访问hdfs路径：

4、访问 可以查看到历史完成任务状态：

生产中遇到突然这个服务丢失，然后重启任务失败。通过谈裤排查任务是historyserver.web.tmpdir: /tmp/flinkhistoryserver/这个路径被删除了。

FlinkKafkaConsumer官网文档翻译

以下内容翻译者段空自 Apache Flink Kafka Connector官网(内容顺序稍作修改)

Flink为Kafka topic读取和写入数据提供了特殊的Kafka连接器。Flink Kafka消费者与Flink的检查点机制集成可以保证下游的exactly-once语义。为了实现这一点，Flink并不完全依赖Kafka自身维护的消费者组offset，而燃渣是在Flink内部管理这些offset。

通用kafka（1.0.0版本及以后）：

kafka版本（0.11版本及以前）：

构造器有以下参数：

Flink Kafka Consumer如何将Kafka中的二进制数据转换为Java / Scala对象。这就需要指定序列化和反序列化方式。每个Kafka消息都会调用 T deserialize(byte[] message) 方法。

后边的太难了，自己去官网看吧：

说明：

启用Flink的checkpoint机制后，Flink Kafka Consumer在消费kafka消息的同时，会周期的并保持一致性的将offset写入checkpoint中。如果作业失败，Flink会将程序恢复到最新的checkpoint的状态，并从存储在checkpoint中的偏移量开始重新消费Kafka中的消息。

注意，只有在有足够的slots可用来首瞎重新启动时，Flink才能重新启动。

如果没有启用checkpoint机制，Kafka使用者将定期向Zookeeper提交偏移量。

Flink Kafka Consumer可以将偏移量提交到Kafka broker(或0.8中的Zookeeper)。注意，Flink Kafka Consumer并不依赖提交的偏移量来保证容错。提交的偏移量只是用于方便查看Consumer消费的进度。

提交偏移量有多种不同的方式，与是否为Job启用了checkpoint机制有关。

Storm，Spark，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是基于micro¬batched实现了旁橡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点开始恢复。

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。

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

02 延迟（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内处理完成，表现都很优秀。

三、 总 结

综合对比spark、storm和flink的功能、容错和性能（总结如下图）

[img]

关于flink官网和flink官网中文的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。