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

创建表时，默认的表类型是 Changelog 表。用户可以在该表中插入、更新或删除记录。

管理小文件

许多用户关注小文件问题，可能导致以下情况：

本文旨在澄清不同文件操作对文件的影响。

本页面提供具体示例和实用技巧，以有效地管理这些操作。此外，通过对提交（commit）和压实（compact）等操作的深入探讨，我们旨在提供有关文件创建和更新的见解。

一张表的所有文件都存储在一个基本目录下，Paimon 文件以分层方式组织。从快照文件开始，可以递归地访问表中的所有记录。

Snapshot

快照（Snapshot）是在某个时间点上捕捉表状态的方式。用户可以通过最新的快照访问表的最新数据。通过时间回溯，用户还可以通过较早的快照访问表的先前状态。

从 Flink Table Store 演进而来

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

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

该项目用于在 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 日志推送给应用开发人员呢，接下来我们将讲解日志的处理方案。