整理自己发在知识星球和公众号的系列文章，方便查找。

从一个小需求（任务异常或者失败时排查问题不便）出发，开始调研业界常见的解决方案进行解决我们的需求，接着有对应的代码实现和效果展示。

记录一个比较有意义的故障，没遇到的可以避坑，已经被坑过的只能握手🤝了。

该项目用于在 Flink 中为流处理和批处理构建动态表，支持超大流量的数据提取和及时的数据查询。

批读 Iceberg

Iceberg 提供了两个配置：

批读 Hive

HiveOptions 中有两个配置

问题

在 flink on k8s 默认提交作业的命令下，我们会指定作业的 JM/TM 的 CPU 和 Memory，最后作业生成的 pod 它的 CPU/Memory 的 request/limit 都是一样的资源，但是作业真实运行时使用的资源远达不到 limit 的值，这样就会造成机器资源浪费（水位不高，但是机器又不能再申请 pod）。

背景

因宕机了一台物理机器，实时集群不少作业发生 failover，其中大部分作业都能 failover 成功，某个部门的部分作业一直在 failover，始终未成功，到 WebUI 查看作业异常日志如下：

为啥会出现多个版本？

12.3 基于 Flink 的实时监控告警系统

在如今微服务、云原生等技术盛行的时代，当谈到说要从 0 开始构建一个监控系统，大家无非就首先想到三个词：Metrics、Tracing、Logging。

12.2 基于 Flink 的百亿数据去重实践

在工作中经常会遇到去重的场景，例如基于 APP 的用户行为日志分析系统：用户的行为日志从手机 APP 端上报到 Nginx 服务端，然后通过 Logstash、Flume 或其他工具将日志从 Nginx 写入到 Kafka 中。由于用户手机客户端的网络可能出现不稳定，所以手机 APP 端上传日志的策略是：宁可重复上报，也不能漏报日志，所以导致 Kafka 中可能会出现日志重复的情况，即：同一条日志出现了 2 条或 2 条以上。通常情况下，Flink 任务的数据源都是 Kafka，若 Kafka 中数据出现了重复，在实时 ETL 或者流计算时都需要考虑基于日志主键对日志进行去重，否则会导致流计算结果偏高或结果不准确的问题，例如用户 a 在某个页面只点击了一次，但由于日志重复上报，所以用户 a 在该页面的点击日志在 Kafka 中出现了 2 次，最后统计该页面的点击数时，结果就会偏高。这里只阐述了一种可能造成 Kafka 中数据重复的情况，在生产环境中很多情况都可能造成 Kafka 中数据重复，这里不一一列举，本节主要讲述出现了数据重复后，该如何处理。

第十二章 —— Flink 案例

本章将介绍 Flink 在多个场景下落地实现的大型案例，第一个是实时处理海量的日志，将从日志的收集、日志的传输、日志的实时清洗和异常检测、日志存储、日志展示等方面去介绍 Flink 在其中起的作用，希望整个日志处理的架构大家可以灵活的运用在自己的公司；第二个是百亿数据量的情况下如何使用 Flink 实时去重，在这个案例中将对比介绍其他几种常见的去重实现方案；第三个是 Flink 在监控告警系统中的落地实现，在这个案例中同样很详细的介绍了一个监控告警系统的全链路，每一个关节都不可或缺，并且还介绍了 Flink 在未来结合机器学习算法做一些 AIOps 的事情。三个案例都比较典型，如果你也在做类似的项目，希望对你们的技术选型有一定的帮助。

12.1 基于 Flink 实时处理海量日志

在 11.5 节中讲解了 Flink 如何实时处理异常的日志，并且对比分析了几种常用的日志采集工具。我们也知道通常在排查线上异常故障的时候，日志是必不可缺的一部分，通过异常日志我们可以快速的定位到问题的根因。那么通常在公司对于日志处理有哪些需求呢？

11.5 如何实时将应用 Error 日志告警？

大数据时代，随着公司业务不断的增长，数据量自然也会跟着不断的增长，那么业务应用和集群服务器的的规模也会逐渐扩大，几百台服务器在一般的公司已经是很常见的了。那么将应用服务部署在如此多的服务器上，对开发和运维人员来说都是一个挑战。一个优秀的系统运维平台是需要将部署在这么多服务器上的应用监控信息汇总成一个统一的数据展示平台，方便运维人员做日常的监测、提升运维效率，还可以及时反馈应用的运行状态给应用开发人员。举个例子，应用的运行日志需要按照时间排序做一个展示，并且提供日志下载和日志搜索等服务，这样如果应用出现问题开发人员首先可以根据应用日志的错误信息进行问题的排查。那么该如何实时的将应用的 Error 日志推送给应用开发人员呢，接下来我们将讲解日志的处理方案。

11.4 如何利用广播变量动态更新告警规则？

一个在生产环境运行的流作业有时候会想变更一些作业的配置或者数据流的配置，然后作业可以读取并使用新的配置，而不是通过修改配置然后重启作业来读取配置，毕竟重启一个有状态的流作业代价挺大，本节将带你熟悉 Broadcast，并通过一个案例来教会你如何去动态的更新作业的配置。

11.3 如何利用 Async I/O 读取告警规则？

Async 中文是异步的意思，在流计算中，使用异步 I/O 能够提升作业整体的计算能力，本节中不仅会讲解异步 I/O 的 API 原理，还会通过一个实战需求（读取告警规则）来讲解异步 I/O 的使用。

11.2 如何使用 Flink ProcessFunction 处理宕机告警?

在 3.3 节中讲解了 Process 算子的概念，本节中将更详细的讲解 Flink ProcessFunction，然后教大家如何使用 ProcessFunction 来解决公司中常见的问题 —— 宕机，这个宕机不仅仅包括机器宕机，还包含应用宕机，通常出现宕机带来的影响是会很大的，所以能及时收到告警会减少损失。

第十一章 —— Flink 实战

本章主要是 Flink 实战，介绍了一些常见的需求，比如实时统计网站页面的 PV/UV、宕机告警、动态更新配置、应用 Error 日志实时告警等，然后分别去分析这些需求的实现方式，明白该使用 Flink 中的哪些知识点才能够很好的完成这种需求，并提供完整的案例代码供大家参考。在实现完成这些需求之后，笔者还将会更深一步的去讲解下这些知识点背后的实现方式，希望可以加深你对这些知识点的印象，以便后面你可以灵活的处理类似的需求。

11.1 如何统计网站各页面一天内的 PV 和 UV？

大数据开发最常统计的需求可能就是 PV、UV。PV 全拼 PageView，即页面访问量，用户每次对网站的访问均被记录，按照访问量进行累计，假如用户对同一页面访问了 5 次，那该页面的 PV 就应该加 5。UV 全拼为 UniqueVisitor，即独立访问用户数，访问该页面的一台电脑客户端为一个访客，假如用户对同一页面访问了 5 次，那么该页面的 UV 只应该加 1，因为 UV 计算的是去重后的用户数而不是访问次数。当然如果是按天统计，那么当天 0 点到 24 点相同的客户端只被计算一次，如果过了今天 24 点，第二天该用户又访问了该页面，那么第二天该页面的 UV 应该加 1。 概念明白了那如何使用 Flink 来统计网站各页面的 PV 和 UV 呢？通过本节来详细描述。

10.2 如何使用 Flink ParameterTool 读取配置？

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

第十章 —— Flink 最佳实践

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

10.1 如何设置 Flink Job RestartStrategy（重启策略）？

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