《Flink 实战与性能优化》—— 如何设置 Flink Job RestartStrategy(重启策略)?

在使用 Flink 中不知道你有没有觉得配置的管理很不方便,比如像算子的并行度配置、Kafka 数据源的配置(broker 地址、topic 名、group.id)、Checkpoint 是否开启、状态后端存储路径、数据库地址、用户名和密码等,反正各种各样的配置都杂乱在一起,当然你可能说我就在代码里面写死不就好了,但是你有没有想过你的作业是否可以不修改任何配置就直接在各种环境(开发、测试、预发、生产)运行呢?可能每个环境的这些配置对应的值都是不一样的,如果你是直接在代码里面写死的配置,那这下子就比较痛苦了,每次换个环境去运行测试你的作业,你都要重新去修改代码中的配置,然后编译打包,提交运行,这样你就要花费很多时间在这些重复的劳动力上了。有没有什么办法可以解决这种问题呢?

《Flink 实战与性能优化》—— 如何设置 Flink Job RestartStrategy(重启策略)?

第十章 —— Flink 最佳实践

本章将介绍两个最佳实践,第一个是如何合理的配置重启策略,笔者通过自己的亲身经历来讲述配置重启策略的重要性,接着介绍了 Flink 中的重启策略和恢复策略的发展实现过程;第二个是如何去管理 Flink 作业的配置。两个实践大家可以参考,不一定要照搬运用在自己的公司,同时也希望你可以思考下自己是否有啥最佳实践可以分享。

从使用 Flink 到至今,遇到的 Flink 有很多,解决的问题更多(含帮助微信好友解决问题),所以对于 Flink 可能遇到的问题及解决办法都比较清楚,那么在这章就给大家讲解下几个 Flink 中比较常遇到的问题的解决办法。

《Flink 实战与性能优化》—— Flink 中如何保证 Exactly Once?

在分布式场景下,我们的应用程序随时可能出现任何形式的故障,例如:机器硬件故障、程序 OOM 等。当应用程序出现故障时,Flink 为了保证数据消费的 Exactly Once,需要有相应的故障容错能力。Flink 是通过周期性 Checkpoint 的方式来实现故障容错,这里使用的是基于 Chandy-Lamport 改进的算法。本节会介绍 Flink 内部如何保证 Exactly Once 以及端对端如何保证 Exactly Once。

《Flink 实战与性能优化》—— 如何合理的设置 Flink 作业并行度?

在 9.2 节中讲解了 Flink Job 中的执行计划,并详细分析了 Flink 中的 operator chain 在一起的各种条件,在 9.3 节中也通过真实生产环境的案例来分享并行度与 Slot 的概念与关系。相信大家也都有一定的理解,但是有时候生产环境如果 Job 突然消费不及时了,或者 Job 就根本不在消费数据了,那么该怎么办?首先得看下相关的监控查看 Job 是否在正常运行,是否出现反压的情况,是否这会生产数据量过大然而并行度却是根据之前数据量设置的,种种原因都需要一个个排查一下,然后找到根因才能够对应的去解决。这节来讲解下遇到这种问题后如何合理配置并行度呢?

《Flink 实战与性能优化》—— 如何查看 Flink 作业执行计划?

当一个应用程序需求比较简单的情况下,数据转换涉及的 operator(算子)可能不多,但是当应用的需求变得越来越复杂时,可能在一个 Job 里面算子的个数会达到几十个、甚至上百个,在如此多算子的情况下,整个应用程序就会变得非常复杂,所以在编写 Flink Job 的时候要是能够随时知道 Job 的执行计划那就很方便了。

《Flink 实战与性能优化》—— 如何处理 Flink Job BackPressure (反压)问题?

第九章 —— Flink 性能调优

通过第八章的监控图表信息,我们可以发现问题,在发现问题后,需要去分析为什么会发生这些问题以及我们该如何去解决这些问题。本章将会介绍很多 Flink 生产环境遇到的问题,比如作业出现反压、作业并行度配置不合理、作业数据倾斜等,除了引出这种常见问题之外,笔者还将和你一起去分析这种问题造成的原因以及如何去优化作业。比如合理的配置并行度、让作业算子尽可能的 chain 在一起已达到最优等。希望通过本章的内容,你可以将这些解决方法运用在你的公司,帮助公司解决类似的问题。

反压(BackPressure)机制被广泛应用到实时流处理系统中,流处理系统需要能优雅地处理反压问题。反压通常产生于这样的场景:短时间的负载高峰导致系统接收数据的速率远高于它处理数据的速率。许多日常问题都会导致反压,例如,垃圾回收停顿可能会导致流入的数据快速堆积,或遇到大促、秒杀活动导致流量陡增。反压如果不能得到正确的处理,可能会导致资源耗尽甚至系统崩溃。反压机制是指系统能够自己检测到被阻塞的 Operator,然后自适应地降低源头或上游数据的发送速率,从而维持整个系统的稳定。Flink 任务一般运行在多个节点上,数据从上游算子发送到下游算子需要网络传输,若系统在反压时想要降低数据源头或上游算子数据的发送速率,那么肯定也需要网络传输。所以下面先来了解一下 Flink 的网络流控(Flink 对网络数据流量的控制)机制。

《Flink 实战与性能优化》—— 如何搭建一套 Flink 监控系统?

8.1 节中讲解了 JobManager、TaskManager 和 Flink Job 的监控,以及需要关注的监控指标有哪些。本节带大家讲解一下如何搭建一套完整的 Flink 监控系统,如果你所在的公司没有专门的监控平台,那么可以根据本节的内容来为公司搭建一套属于自己公司的 Flink 监控系统。

《Flink 实战与性能优化》—— 如何实时监控 Flink 及其作业?

第八章 —— Flink 监控

Flink 相关的组件和作业的稳定性通常是比较关键的,所以得需要对它们进行监控,如果有异常,则需要及时告警通知。本章先会教会教会大家如何利用现有 Flink UI 上面的信息去发现和排查问题,会指明一些比较重要和我们非常关心的指标,通过这些指标我们能够立马定位到问题的根本原因。接着笔者会教大家如何去利用现有的 Metrics Reporter 去构建一个 Flink 的监控系统,它可以收集到所有作业的监控指标,并会存储这些监控指标数据,最后还会有一个监控大盘做数据可视化,通过这个大盘可以方便排查问题。

《Flink 实战与性能优化》—— Flink 作业如何在 Standalone、YARN、Mesos、K8S 上部署运行?

前面章节已经有很多学习案列带大家使用 Flink,不仅有讲将 Flink 应用程序在 IDEA 中运行,也有讲将 Flink Job 编译打包上传到 Flink UI 上运行,在这 UI 背后可能是通过 Standalone、YARN、Mesos、Kubernetes 等运行启动的 Flink。那么这节就系统讲下如何部署和运行我们的 Flink Job,大家可以根据自己公司的场景进行选择使用哪种方式进行部署 Flink 作业!

《Flink 实战与性能优化》—— Flink 配置详解及如何配置高可用?

第七章 —— Flink 作业环境部署

在第一章中介绍过 Flink 是可以以多种方式部署的,比如 Standalone、YARN、Mesos、K8S。本章将先对 Flink 中的所有配置文件做一个详细的讲解,接下来将讲解 JobManager 高可用部署相关的配置,最后会分别讲解如何在不同的平台上部署运行 Flink 作业。虽然在你们公司可能只会用到其中的一种,但是仍然建议你将每种方式都熟悉一下。

《Flink 实战与性能优化》—— Flink 扩展库——Machine Learning

随着人工智能的火热,机器学习这门技术也变得异常重要,Flink 作为一个数据处理的引擎,虽然目前在该方面还较弱,但是在 Flink Forward Asia 2019 北京站后,阿里开源了 Alink 平台的核心代码,并上传了一系列的算法库,该项目是基于 Flink 的通用算法平台,开发者和数据分析师可以利用 Alink 提供的一系列算法来构建软件功能,例如统计分析、机器学习、实时预测、个性化推荐和异常检测。相信未来 Flink 的机器学习库将会应用到更多的场景去,本节将带你了解一下 Flink 中的机器学习库。