戳更多文章： 1-Flink入门 2-本地环境搭建&构建第一个Flink应用 3-DataSet API 4-DataSteam API 5-集群部署 6-分布式缓存 7-重启策略 8-Flink中的窗口 9-Flink中的Time 1概述 Flink支持不同的重启策略，以在故障发生时控制作业如何重启 集群在启动时会伴随一个默认的重启策略，在没有定义具体重启策略时会使用该默认策略。 如果在工作提交时指定了一个重启策略，该策略会覆盖集群的默认策略默认的重启策略可以通过 Flink 的配置文件 flink-
从之前的架构中我们可以很明显的发现 JobManager 有明显的单点问题(SPOF，single point of failure)。JobManager 肩负着任务调度以及资源分配，一旦 JobManager 出现意外，其后果可想而知。
前面写了一些flink的基础组件，但是还没有说过flink的环境搭建，现在我们来说下基本的环境搭建 1. 使用StatefulSet的原因 对于Flink来说，使用sts的最大的原因是pod的hostname是有序的；这样潜在的好处有 hostname为-0和-1的pod可以直接指定为jobmanager；可以使用一个statefulset启动一个cluster，而deployment必须2个；Jobmanager和TaskManager分别独立的deployment pod由于各种原因fail后，由于StatefulSet重新拉起的pod的hostname不变，集群recover的速度理论上可以比deployment更快（deployment每次主机名随机） 2.使用StatefulSet部署Flink 2.1 docker的entrypoint 由于要由主机名来判断是启动jobmanager还是taskmanager，因此需要在entrypoint中去匹配设置的jobmanager的主机名是否有一致 传入参数为：cluster ha；则自动根据主机名判断启动那个角色；也可以直接指定角色名称 docker-entrypoint.sh的脚本内容如下：
基于Standalone或者Yarn模式提交Flink任务后，当任务执行失败、取消或者完成后，可以在WebUI中查看对应任务的统计信息，这些统计信息在生产环境中对我们来说非常重要，可以知道一个任务异常挂掉前发生了什么，便于定位问题。
概述 Flink支持不同的重启策略，以在故障发生时控制作业如何重启 集群在启动时会伴随一个默认的重启策略，在没有定义具体重启策略时会使用该默认策略。 如果在工作提交时指定了一个重启策略，该策略会覆盖集群的默认策略默认的重启策略可以通过 Flink 的配置文件 flink-conf.yaml 指定。配置参数 restart-strategy 定义了哪个策略被使用。 常用的重启： 1.策略固定间隔 (Fixed delay) 2.失败率 (Failure rate) 3.无重启 (No restart) 如果
默认重启策略是通过Flink的配置文件设置的flink-conf.yaml。配置参数restart-strategy定义采用的策略。
上一篇博客博主已经为大家介绍了 Flink的简介与架构体系，本篇博客，我们来学习如何搭建Flink集群。
来源:https://www.jianshu.com/p/5b670d524fa5
在小编的记忆里，Flink 自从出现在大众视野中，一直在高速迭代。Flink1.10版本之前因为重大功能的缺失(主要是和Hive的兼容性)，笔者一直都不推荐直接应用在大规模的生产实践中，可以做小范围内业务尝试。Flink 1.10版本可以被认为是一个承上启下的革命性版本。
我们前面写的word count的例子，没有包含状态管理。如果一个task在处理过程中挂掉了，那么它在内存中的状态都会丢失，所有的数据都需要重新计算。从容错和消息处理的语义上(at least once, exactly once)，Flink引入了state和checkpoint。
flink-core-1.7.1-sources.jar!/org/apache/flink/configuration/JobManagerOptions.java
进入host147主机的/data/flink-1.13.5/zookeeper目录，新建文件myid，并填入1
我们在系列文章第一篇已经为大家介绍了 Flink 的基本概念以及安装部署的过程，希望能够帮助读者建立起对 Flink 的初步印象。这是系列文章第二篇，主要面向于初次接触 Flink 或者对 Flink 有了解但是没有实际操作过的同学。希望帮助大家更顺利地上手使用 Flink，并着手相关开发调试工作。
本文主要是讲解flink on yarn的部署过程，然后yarn-session的基本原理，如何启动多个yarn-session的话如何部署应用到指定的yarn-session上，然后是用户jar的管理配置及故障恢复相关的参数。
可以看到有3个Task Managers，1个Job Manager 为bigdata1
默认情况下，每个Flink集群只有一个JobManager，这将导致单点故障（SPOF，single point of failure），如果这个JobManager挂了，则不能提交新的任务，并且运行中的程序也会失败，这是我们可以对JobManager做高可用（High Availability，简称HA），JobManager HA集群当Active JobManager节点挂掉后可以切换其他Standby JobManager成为主节点，从而避免单点故障。用户可以在Standalone、Flink on Yarn、Flink on K8s集群模式下配置Flink集群HA,Flink on K8s集群模式下的HA将单独在K8s里介绍。
原文：https://www.cnblogs.com/ljygz/p/11727770.html
Flink还可以做机器学习，常用机器学习KMeans，LinearRegression，学习使用地址如下：
安装包下载地址：http://flink.apache.org/downloads.html ，选择对应Hadoop的Flink版本下载
https://www.apache.org/dyn/closer.lua/flink/flink-1.11.3/flink-1.11.3-bin-scala_2.12.tgz
本来打算在安装好的 Flink 集群上直接修改的，这样我增加个配置，这篇文章就完成了，考虑到大家可能对 Flink 不太了解，也不一定有兴趣从 0 开始装个 Linux 环境，所以我索性就从0开始配置一整套的环境。
flink-release-1.7.2/flink-dist/src/main/resources/flink-conf.yaml
Flink的安装和部署主要分为本地（单机）模式和集群模式，其中本地模式只需直接解压就可以使用，不用修改任何参数，一般在做一些简单测试的时候使用。本地模式在这里不再赘述。集群部署模式主要包含Standalone、Hadoop Yarn 、Kubernetes等，Flink可以借助以上资源管理器来实现分布式计算，目前企业使用最多的是Flink 基于Hadoop Yarn资源管理器模式，下面我们重点讲解Flink 基于Standalone集群、Yarn资源管理器以及Kubernetes集群部署方式。
Flink支持不同的重启策略，重启策略控制在作业失败后如何重启。可以使用默认的重启策略启动集群，这个默认策略在作业没有特别指定重启策略时使用。如果在提交作业时指定了重启策略，那么此策略将覆盖集群的默认配置策略。
一个Flink程序由多个Operator组成(source、transformation和 sink)。
在本地安装单机版本，能够实现快速体验 Flink Table Store 的目的，本文以 Flink 1.15.2、flink-table-store-dist-0.2.1 和 flink-shaded-hadoop-2-uber-2.8.3-10.0 为例，系统为 Centos 3.10。
Flink支持不同的重启策略，这些重启策略控制着job失败后如何重启。集群可以通过默认的重启策略来重启，这个默认的重启策略通常在未指定重启策略的情况下使用，而如果Job提交的时候指定了重启策略，这个重启策略就会覆盖掉集群的默认重启策略。
TaskManager界面：可以查看到当前Flink集群中有多少个TaskManager，每个TaskManager的slots、内存、CPU Core是多少
上一节我们讲了单机模式如何部署启动，这节我们基于CentOS 7虚拟机搭建一个3个节点的集群：
很期待用纯sql的形式来处理流式数据，flink 1.10推出了生产可用的 Hive 集成，拥有了更强的流式 SQL 处理能力。这次我们就来尝试一下啦~~
状态可以存储在Java的堆内或堆外。根据你的状态终端，Flink 也可以管理应用程序的状态，这意味着 Flink 可以处理内存管理（可能会溢出到磁盘，如果有必要），以允许应用程序存储非常大的状态。默认情况下，配置文件 flink-conf.yaml 为所有Flink作业决定其状态终端。
Flink支持运行与所有的类linux环境，比如linux，mac os x 和cygwin(windows)，要求一个master节点，一个或者多个worker节点。再部署启动flink集群之前，要准备一下环境，对每个节点的环境要求是：
1）重启策略，都有重试次数和重试之间等待时间的规定，不同点在于，分别限定了最大的失败次数和规定时间内失败次数。具体根据场景设置
如果配置了Checkpoint,而没有配置重启策略,那么代码中出现了非致命错误时,程序会无限重启
在一个企业中，为了最大化的利用集群资源，一般都会在一个集群中同时运行多种类型的 Workload。因此 Flink 也支持在 Yarn 上面运行。首先，让我们了解下 Yarn 和 Flink 的关系。
Flink的每个TaskManager为集群提供slot。 slot的数量通常与每个TaskManager节点的可用CPU内核数成比例。一般情况下你的slot数是你每个节点的cpu的核数。
checkpoint机制是Flink可靠性的基石，可以保证Flink集群在某个算子因为某些原因(如 异常退出)出现故障时，能够将整个应用流图的状态恢复到故障之前的某一状态，保 证应用流图状态的一致性。Flink的checkpoint机制原理来自“Chandy-Lamport algorithm”算法。
这次我们的目的是，在本地的 IDEA 中去 debug flink-clients 代码，然后远程提交给 flink standalone 集群上去执行，看一看 flink 客户端在提交代码之前都干了什么。
Kerberos，在古希腊神话故事中，指的是一只三头犬守护在地狱之门外，禁止任何人类闯入地狱之中。
Flink是依赖内存计算，计算过程中内存不够对Flink的执行效率影响很大。可以通过监控GC（Garbage Collection），评估内存使用及剩余情况来判断内存是否变成性能瓶颈，并根据情况优化。
看来要想任务顺利执行，首先要保证slot数量够用，目前机器内存是够用的，那么就把slot数量调大些吧；
序 本文主要研究下flink的checkpoint配置 sl21-1518991391479.jpg 实例 StreamExecutionEnvironment env = StreamExecutionEnvironment.getExecutionEnvironment(); // start a checkpoint every 1000 ms env.enableCheckpointing(1000); // advanced options: // set mode to exac
根据各种参数(如数据大小或集群中的机器数量)，Flink的优化器自动会为你的程序选择一个执行策略。很多情况下，准确的知道Flink如何执行你的程序是很有帮助的。
Apache Beam 是统一的批/流数据处理的编程模型。本文主要是参考官方文档，用 Docker 来快速跑起来一个用 Beam 来构建的 Flink 程序来处理数据的 Demo。
Storm作业称为Topology，由一系列的Spout组件，以及Bolt组件组成；如果要把运行在Storm的作业整体迁移到Flink上运行，则可以参考以下示意图和步骤：
Flink On Standalone 即Flink任务运行在Standalone集群中，Standlone集群部署时采用Session模式来构建集群，即：首先构建一个Flink集群，Flink集群资源就固定了，所有提交到该集群的Flink作业都运行在这一个集群中，如果集群中提交的任务多资源不够时，需要手动增加节点，所以Flink 基于Standalone运行任务一般用在开发测试或者企业实时业务较少的场景下。
1）下载安装包 2）上传安装包到/root下 3）解压 cd /root tar -zxvf flink-1.6.2-bin-hadoop28-scala_2.11.tgz -C hd 4）修改配置文件 vi flink-conf.yaml 第33行修改为： jobmanager.rpc.address: hd110 5）修改slaves vi slaves hd111 hd112 6）分发flink到其他机器 cd /root/hd scp -r flink-1.6.2/ hd111:$PWD
Flink 的 metrics 是 Flink 公开的一个度量系统，metrics 也可以暴露给外部系统，通过在 Flink 配置文件 conf/flink-conf.yaml 配置即可，Flink原生已经支持了很多reporter，如 JMX、InfluxDB、Prometheus 等等。
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
即时通信 IM
ICP备案
对象存储
实时音视频
