flink流处理特点

flink的流处理特性:支持高吞吐量、低延迟和高性能流处理。支持带事件时间的窗口 *** 作。支持有状态计算的恰好一次语义支持高度灵活的窗口 *** 作，支持基于时间、计数、会话和数据驱动的窗口 *** 作。支持带背压功能的连续流模型基于轻量级分布式快照支持容错运行时支持流处理上的批处理和流处理。Flink在JVM中实现了自己的内存管理。支持迭代计算支持程序自动优化:避免特定情况下的洗牌、排序等代价高昂的 *** 作，需要缓存中间结果。API支持数据流API是为流数据类应用程序提供的。对于批处理应用，提供数据集API(支持Java/Scala)图书馆支持支持机器学习(FlinkML)支持图分析(Gelly)支持关系数据处理(表)支持复杂事件处理(CEP)支持集成在纱线上支撑弗林克HDFS支持支持来自Kafka的输入数据Apache HBase支持Hadoop程序支持支持超光速粒子支持ElasticSearch。支持兔子阿帕奇风暴支援S3支持XtreemFS支持

为了使 Flink 应用程序能够可靠地大规模运行，必须满足两个条件：

监控 Checkpoint 行为的最简单方法是通过 WebUI 界面。有两个 Checkpoint Metric 最值得关注的是：

理想情况下，这两个值都应该是低值，持续出现较高的值意味着 checkpoint barrier 在 job graph 中缓慢移动，通常是由于 backpressure 存在（没有足够的资源来处理记录）。也可以通过增加处理记录的端到端延迟来观察。

应用程序可以配置固定时间间隔触发 checkpoint。当一个 checkpoint 的完成时间长于固定间隔时，在进行中的 checkpoint 完成之前不会触发下一个（默认情况下，下一个 checkpoint 将在正在进行的 checkpoint 完成后立即触发）。

当 checkpoint 结束的时间经常超过固定间隔时，系统会不断地触发 checkpoint（完成后立即启动新）。这可能意味着在两个 checkpoint 之间，Operator 处理进展过少，并且 checkpoint 占用了过多的资源。此行为对使用异步 checkpoint 的流应用程序的影响较小，但仍可能对整体应用程序性能产生影响。

为了防止这种情况，应用程序可以定义一个 checkpoint 的最小间隔（在最新 checkpoint 结束和下一个 checkpoint 开始前必须经过的最小时间间隔。）：

下图说明了这是如何影响 checkpoint 的，避免了 checkpoint 持续不断的进行。

可以配置应用程序允许同时进行多个 checkpoint。当手动触发 savepoint 时，可能与正在进行的 checkpoint 同时进行。

许多大规模 Flink 流计算应用程序的 State 存储使用的是 RocksDB state Backend。扩展性远远超过主内存，并可靠地存储大的 keyed state 。

RocksDB 的性能会因配置而异，下面介绍一些使用 RocksDB state Backend 的最佳实践。

在减少 checkpoint 所需时间方面，开启增量 checkpoint 应该是首要考虑因素之一。与完全 checkpoint 相比，增量 checkpoint 可以显著减少时间，因为只记录与前一次完成的 checkpoint 相比所做的更改。

定时器（Timer）默人存储在 RocksDB 中，当 Job 只有很少的 Timer 时，放在堆上存储可以提高性能。

请小心使用此功能，因为基于堆的 Timer 可能会增加 checkpoint 时间，并且无法在内存之外扩展。

RocksDB State Backend 的性能在很大程度上取决于其可用的内存量。为了提高性能，增加内存会有很大帮助，或者调整内存使用。

默认情况，RocksDB State Backend 使用 Flink 托管内存用于 RocksDBs buffer 和 cache（ statebackendrocksdbmemorymanaged: true ）。 要调整与内存相关的性能问题，以下步骤可能会有所帮助：

本节讨论如何决定一个 Flink 作业应该使用多少资源才能可靠地运行。容量规划的基本经验法则是：

Flink 为所有 checkpoint 和 savepoint 提供可选的压缩（默认值：off）。目前，压缩总是使用 snappy compression algorithm（version 114） 但计划在未来支持自定义压缩算法。压缩的粒度是 keyed state 的 key-group，每个 key-group 可以单独压缩，这对于缩放程序非常重要。

压缩可以通过 ExecutionConfig 开启

压缩选项对增量快照（RocksDB）没有影响。

在 Flink 的 checkpoint 中，每个 Task 都会生成一个 State snapshot，然后将其写入分布式存储。每个 Task 通过发送一个描述 State 在分布式存储中的位置的句柄来确认 State 成功写入 JobManager。JobManager 依次从所有 Task 收集句柄，并将绑定到到 checkpoint 对象中。

在恢复的情况下，JobManager 打开最新的 checkpoint 对象并将句柄发送回相应的 Task，然后这些 Task 可以从分布式存储中恢复 State。使用分布式存储来存储 State 有两个重要的优点。首先，存储是容错的，其次，分布式存储中的所有 State 对所有节点都是可访问的，并且可以很容易地重新分配（例如，用于重新缩放）。

然而，使用远程分布式存储也有一个很大的缺点：所有 Task 都必须通过网络从远程位置读取其状态。在一些情况下，恢复可以将 Task 重新安排到与上一次运行相同的 TaskManager 中，但仍然要读取远程状态。这可能会导致大状态的恢复时间长。

任务本地 State 恢复是针对这一类问题，主要思想如下：对于每个 checkpoint，每个 Task 不仅将 State snapshot 写入分布式存储，而且还将 state snapshot 的辅助副本保存在该 Task 所在的本地存储中（例如，本地磁盘或内存中）。State 的主存储必须仍然是分布式存储，因为本地存储不能确保节点故障下的持久性，也不能为其他节点提供重新分发 State 的访问。

对于每个可以重新安排到上一个位置进行恢复的 Task，可以从本地辅助副本恢复 State，并避免远程读取的开销。考虑到许多故障不是节点故障，节点故障通常一次只影响一个或极少数节点，在恢复过程中，大多数 Task 很可能返回到其以前的位置，并发现其本地 State 完好无损，可以有效地缩短恢复时间。

需要注意的是，根据所选的 state backend 和 checkpoint 策略，在创建和存储本地辅助副本时，每个 checkpoint 可能需要一些额外的成本。在大多数情况下，实现只需将对分布式存储的写入复制到本地文件。

任务本地恢复在默认情况下是停用的，可以通过 Flink 的配置开启（ statebackendlocal-recovery 指定为 false 或 true，还可以在 Job 上设置 CheckpointingOptionsLOCAL_RECOVERY ）。

任务本地恢复假设在失败情况下保持分配的 Task 调度，其原理如下：每个 Task 都会记住之前分配的 Slot，在恢复过程中会请求完全相同的 Slot 进行重启。如果 Slot 不可用，任务将从 Resource Manager 请求一个全新的 Slot。

如果一个 TaskManager 不再可用，则之前分配该 TaskManager 上的 Task 必须在其他的 TaskManager 上运行，但是不会让其他可以在原 Slot 上恢复的 Task 改变位置。在这种策略下，会让尽可能多的 Task 在原 Slot 上启动，并从本地恢复 State。

1）java对象的存储密度比较低，对象主要包含 对象头，对象数据，对齐填充。 其中对齐填充是没用的，纯粹是为了让对象的大小到达8的倍数

2）Full GC非常影响性能，对大数据量的计算来说，fullGC可能会持续很久(秒级甚至分钟级)

3）OOM导致JVM崩溃，因为是大数据计算，很有可能会分配出大的对象。

4）缓存未命中，CPU在进行计算时，会先从CPU的缓存中抓取数据，但是jvm堆上的内存不是连续的，会导致CPU缓存不命中，CPU空转，影响效率。

5）传输过程，要序列化和反序列化

Flink将对象存储在堆外内存中，或者存在 memorySegment上

memorySegment： 

1 翻译为内存段，存储序列化后的对象

2 它是一段固定长度的内存（大小为32KB）

3 是FLink中最小的内存分配单元

4 读写非常高效，很多算子可以直接 *** 作其二进制数据，不需要反序列化

5 Java本身自带的序列化和反序列化的功能，但是辅助信息占用空间比较大，在序列化对象时记录了过多的类信息。

Flink实现了自己的序列化框架，使用TypeInformation表示每种数据类型，所以可以只保存一份对象Schema信息，节省存储空间。又因为对象类型固定，所以可以通过偏移量存取。

jobmanagerheapsize:1024m

jobmanagermemoryprocesssize:1600m

主要包含 堆内存和非堆内存，相对比较简单一些。

关于rocksDb内存管理：

由于rocksdb分配的是堆外内存，内存量理论上不受jvm控制。于是产生问题，如果进程的内存使用超过容器限定的量，就会被资源管理器杀死。

以上就是关于flink流处理特点全部的内容，包括:flink流处理特点、Flink Checkpoint 和 Large State 调优、5 一文看完flink的内存管理等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！