本示例知识点
1.学习如何管理和运行Flink Jobs
2.如何部署和监视应用程序
3.体验Flink如何从作业失败中恢复（重点）
4.执行日常操作任务，例如升级和缩放命令：
docker-compose 常用命令
docker-compose exec kafka kafka-console-consumer.sh --bootstrap-server localhost:9092 --topic input
可以使用docker编排kafka的方式，启动kafka集群，用户测试项目知识点：
1.通过flink-playgrouds项目中的ops-playground-image子项目项目学习流处理简易流程2.在提交ClickEventCount应用的时候，通过传入参数--checkpointing启用检查点；通过传入--event-time为Job启用事件时间语义。
有多种方法可以在各种环境中部署和操作Apache Flink。 不管这种多样性如何，Flink群集的基本构建块都相同，并且适用类似的操作原理。
游乐场示例解析
这个（playground）游乐场由一个寿命长的Flink（Session）会话群集和一个Kafka群集组成。
一个Flink群集始终由一个JobManager和一个或多个Flink TaskManager组成。
- JobManager负责处理作业提交，作业的监督以及资源管理。
- Flink TaskManager是工作进程，负责执行构成Flink作业的实际任务。
在这个操场上，您将从一个TaskManager开始，但以后可以扩展到更多TaskManager。 此外，该游乐场还带有一个专用的客户端容器，我们可以使用该容器最初提交Flink作业，并在以后执行各种操作任务。 Flink群集本身不需要客户端容器，而只是为了易于使用而包含客户端容器。
Kafka群集由Zookeeper服务器和Kafka代理组成。
当游乐场启动时，名为Flink Event Count的Flink作业将被提交到JobManager。 此外，还将创建两个Kafka Topics输入和输出。
作业使用输入主题中的ClickEvent，每个事件都有一个时间戳和一个页面。 然后按页面键入事件并在15秒窗口中计数。 结果将写入输出主题。
有六个不同的页面，我们每页面15秒生成1000次点击事件。 因此，Flink作业的输出应在每个页面和窗口显示1000个浏览次数。
启动游乐场示例
只需几个步骤即可设置游乐场环境。 我们将引导您完成必要的命令，并演示如何验证一切是否正常运行。
我们假设您在计算机上安装了Docker（1.12+）和docker-compose（2.1+）。
所需的配置文件在flink-playgrounds存储库中可用。 检查一下并优化环境：
git clone --branch release-1.11 https://github.com/apache/flink-playgrounds.git
cd flink-playgrounds/operations-playground
docker-compose build
docker-compose up -d之后，您可以使用以下命令检查正在运行的Docker容器：
docker-compose ps这表明客户端容器已成功提交Flink作业（退出0），并且所有群集组件以及数据生成器都在运行（启动）。
您可以通过以下方式停止游乐场环境：
docker-compose down -v进入游乐场
您可以在这个游乐场尝试多种尝试。 在以下两个部分中，我们将向您展示如何与Flink群集进行交互，并演示Flink的一些关键功能。
Flink WebUI
观察Flink群集的最自然的起点是在http://localhost:8081下公开的WebUI。 如果一切顺利，您将看到群集最初由一个TaskManager组成，并执行一个名为Click Event Count的作业。
Flink WebUI包含有关Flink群集及其作业的许多有用和有趣的信息（JobGraph，指标，检查点统计信息，TaskManager状态等等）。
Logs
JobManager
JobManager日志可以通过docker-compose查看。
docker-compose logs -f jobmanager初始启动后，您应该主要看到每个检查点完成的日志消息。
TaskManager
TaskManager日志可以通过docker-compose查看。
docker-compose logs -f taskmanager初始启动后，您应该主要看到每个检查点完成的日志消息。
Flink CLI
可以在客户端容器内使用Flink CLI。 例如，要打印Flink CLI的帮助消息，您可以运行
docker-compose run --no-deps client flink --help
Flink REST API
Flink REST AP可以通过主机上的localhost:8081或通过客户端容器中的jobmanager:8081访问，例如 要列出所有当前正在运行的作业，您可以运行：
curl localhost:8081/jobs
Kafka Topics
您可以通过运行以下命令查看写入Kafka主题的记录
//input topic (1000 records/s)
docker-compose exec kafka kafka-console-consumer.sh \
--bootstrap-server localhost:9092 --topic input
//output topic (24 records/min)
docker-compose exec kafka kafka-console-consumer.sh \
--bootstrap-server localhost:9092 --topic output
玩耍的时间到啦！
现在，您已经了解了如何与Flink和Docker容器进行交互，让我们看一些可以在我们的游乐场上尝试的常见操作任务。 所有这些任务都是相互独立的，即您可以按任何顺序执行它们。 大多数任务可以通过CLI和REST API执行。
列出运行的job
命令
docker-compose run --no-deps client flink list
或者
curl localhost:8081/jobsJobID在提交时已分配给作业，通过CLI或REST API对作业执行操作时需要JobID。
观察故障与恢复
Flink在（部分）故障下提供一次精确的处理保证。在这个操场上，您可以观察并（在某种程度上）验证此行为。
步骤1：观察输出
如上所述，生成该运动场中的事件，使得每个窗口正好包含一千条记录。因此，为了验证Flink是否已成功从TaskManager故障中恢复而没有数据丢失或重复，您可以跟踪输出主题，并检查-恢复后所有窗口均存在且计数是否正确。
为此，请从输出主题开始读取并使该命令运行，直到恢复为止（步骤3）。
docker-compose exec kafka kafka-console-consumer.sh \
--bootstrap-server localhost:9092 --topic output
步骤2：介绍故障
为了模拟部分故障，您可以杀死TaskManager。在生产设置中，这可能对应于TaskManager进程的丢失，TaskManager计算机的丢失或仅是从框架或用户代码引发的临时异常（例如，由于外部资源的暂时不可用）。
docker-compose kill taskmanager
几秒钟后，JobManager将注意到TaskManager丢失，取消受影响的Job，然后立即重新提交以进行恢复。作业重新启动后，其任务将保持“已安排”状态，该状态由紫色正方形指示（请参见下面的屏幕截图）。
注意：即使作业的任务处于SCHEDULED状态且尚未处于RUNNING状态，作业的整体状态仍显示为RUNNING。
此时，作业的任务无法从“已安排”状态转移到“正在运行”，因为没有资源（任务管理器提供的TaskSlot）来运行任务。 在新的TaskManager可用之前，作业将经历一个取消和重新提交的循环。
同时，数据生成器不断将ClickEvent推送到输入主题中。 这类似于实际的生产设置，在实际的生产设置中，要处理的Job处于关闭状态时将生成数据。
步骤3：恢复
重新启动TaskManager后，它将重新连接到JobManager。
docker-compose up -d taskmanager当JobManager收到有关新TaskManager的通知时，它将把正在恢复的Job的任务安排到新可用的TaskSlot。 重新启动后，任务将从失败之前执行的最后一个成功检查点恢复其状态，并切换到RUNNING状态。
Job将快速处理来自Kafka的输入事件（在中断期间累积）的完整积压，并以更高的速率（> 24个记录/分钟）产生输出，直到到达流的开头。 在输出中，您将看到所有时间窗口都存在所有键（页面），并且每个计数正好是一千。 由于我们在“至少一次”模式下使用FlinkKafkaProducer，因此有机会看到一些重复的输出记录。
注意：大多数生产设置都依赖资源管理器（Kubernetes，Yarn，Mesos）来自动重启失败的进程。
升级和扩容或缩容一个作业
升级Flink作业始终涉及两个步骤：
首先，使用Savepoint正常停止Flink作业。 保存点是在定义良好的全局一致时间点（类似于检查点）的完整应用程序状态的一致快照。
其次，从保存点启动升级的Flink作业。 在这种情况下，“升级”可能意味着不同，包括：
- 升级配置（包括作业的并行性）
- 作业拓扑的升级（已添加/已删除的操作员）
- 作业的用户定义功能的升级
在开始升级之前，您可能需要开始跟踪输出主题，以观察到在升级过程中没有数据丢失或损坏。
docker-compose exec kafka kafka-console-consumer.sh \
--bootstrap-server localhost:9092 --topic output
步骤1：停止工作
要正常停止作业，您需要使用CLI或REST API的“停止”命令。 为此，您将需要Job的JobID，可以通过列出所有正在运行的Job或从WebUI获得。 使用JobID，您可以继续停止作业：
命令
docker-compose run --no-deps client flink stop <job-id>
期望输出
Suspending job "<job-id>" with a savepoint.
Suspended job "<job-id>" with a savepoint.
保存点已存储到flink-conf.yaml中配置的state.savepoint.dir中，该文件安装在本地计算机上的/tmp/flink-savepoints-directory/下。 下一步将需要此保存点的路径。 如果是REST API，则此路径已经是响应的一部分，您将需要直接查看文件系统。
命令
ls -lia /tmp/flink-savepoints-directory
期望输出
total 0
17 drwxr-xr-x 3 root root 60 17 jul 17:05 .
2 drwxrwxrwt 135 root root 3420 17 jul 17:09 ..
1002 drwxr-xr-x 2 root root 140 17 jul 17:05 savepoint-<short-job-id>-<uuid>
步骤2a：无需更改即可重新启动作业
您现在可以从此保存点重新启动升级的作业。 为简单起见，您可以先重新启动它，而无需进行任何更改。
命令
docker-compose run --no-deps client flink run -s <savepoint-path> \
-d /opt/ClickCountJob.jar \
--bootstrap.servers kafka:9092 --checkpointing --event-time
期望输出
Starting execution of program
Job has been submitted with JobID <job-id>
一旦作业再次运行，您将在输出主题中看到，在作业处理中断期间累积的积压时，记录的生成速度更高。 此外，您会看到在升级过程中没有数据丢失：所有窗口都以一千个的数量存在。
步骤2b：以不同的并行度重新启动作业（重新缩放）
或者，您也可以通过在重新提交期间传递不同的并行度来从此保存点重新调整作业。
命令
docker-compose run --no-deps client flink run -p 3 -s <savepoint-path> \
-d /opt/ClickCountJob.jar \
--bootstrap.servers kafka:9092 --checkpointing --event-time
期望输出
Starting execution of program
Job has been submitted with JobID <job-id>
现在，作业已提交，但是由于没有足够的任务槽来执行并行性增强的任务槽（2个可用，需要3个），因此无法启动。 用
docker-compose scale taskmanager=2
您可以将另一个带有两个TaskSlot的TaskManager添加到Flink集群，该集群将自动向JobManager注册。 添加TaskManager后不久，作业应重新开始运行。
一旦作业再次处于“运行中”状态，您将在输出主题中看到在重新缩放过程中没有数据丢失：所有窗口的数量都恰好为一千。
查询作业指标
JobManager通过其REST API公开系统和用户指标。
端点取决于这些指标的范围。 可以通过jobs/<job-id>/metrics列出范围为Job的指标。 度量标准的实际值可以通过get查询参数来查询。
请求
curl "localhost:8081/jobs/<jod-id>/metrics?get=lastCheckpointSize"预期响应（打印精美；无占位符）
[
{
"id": "lastCheckpointSize",
"value": "9378"
}
]REST API不仅可以用于查询指标，而且还可以检索有关正在运行的作业状态的详细信息。
请求
curl localhost:8081/jobs/<jod-id>预期响应（打印精美）
请查阅REST API参考，获取可能查询的完整列表，包括如何查询不同范围的指标（例如TaskManager指标）；
变体（其他playgrouds玩法）
您可能已经注意到，单击事件计数应用程序始终以--checkpointing和--event-time程序参数启动。通过在docker-compose.yaml中的客户端容器命令中省略这些内容，可以更改Job的行为。
- --checkpointing启用检查点，这是Flink的容错机制。如果没有此参数运行，并且经历了故障和恢复，您应该会看到数据实际上已经丢失。
- --event-time为您的Job启用事件时间语义。禁用此参数后，作业将根据机器时钟时间而不是ClickEvent的时间戳将事件分配给窗口。因此，每个窗口的事件数将不再精确到一千。
Click Event Count应用程序还具有另一个选项（默认情况下处于关闭状态），您可以启用该选项来探索此工作在背压下的行为。您可以在docker-compose.yaml中的客户端容器的命令中添加此选项。
- --backpressure在作业的中间添加了一个额外的运算符，该操作符在偶数分钟内（例如10:12期间，但10:13期间没有）导致严重的背压。可以通过检查各种网络指标（例如outputQueueLength和outPoolUsage）和/或使用WebUI中可用的背压监视来观察到这一点。
