阿华田的博客

需求背景目前奥格运营平台提供的下单相关的实时标签（如用户最近一次实物购买时间等），都是基于来加工的，即不考虑用户后续的逆向退款情况。然而，运营同学需要实时圈选出近一段时间未成功购买（未下单或下单后退款）的人群，制定运营策略及发放权益，提高复购率。因此，该需求可以明确为：构建的实时标签。问题分析用户的下单行为和退款行为是有时序性的，因此当用户在下单后发生逆向退款行为时，需要回撤之前的订单结果，并回溯最近一次支付成功且未退款的订单信息。

在湖仓业务开发中，进行宽表开发是常见的业务需求， 常规方式都是通过双流或者多流进行join实现将多个表的数据合成一条数据写入宽表，但是join的方式会导致flink任务状态很大，任务不好维护。为了解决状态大的问题paimon提供了partial update，可以不使用join，完成多个insert into 写入或更新同一张表的同一条数据，本文将详细介绍partial update的使用方式和注意事项。

通过设置consumer-id参数，您可以给流作业中的Paimon源表算子赋予一个Consumer ID，其值可以是任意的字符串。Consumer ID第一次创建时，它的起始消费位点根据中的规则确定。后续只要继续使用相同的Consumer ID，即可恢复Paimon表的消费进度。例如，为Paimon源表算子设置名为test-id的Consumer ID的SQL语句示例如下。

manifest-list-4ccc-c07f-4090-958c-cfe3ce3889e5-1 是增量清单列表（上图中的 manifest-list-1-delta），它包含一组对数据文件进行操作的清单条目，在此情形下指的是 manifest-1-0。manifest-list-4ccc-c07f-4090-958c-cfe3ce3889e5-0 是基础清单列表（上图中的 manifest-list-1-base），实际上是空的。小文件的数量会随着快照的增加而增多，这可能会导致读取性能下降。

对于任何数据库查询操作想要查询的性能好，都离不开索引，同样在查询Paimon非主键表的时候，我们可以通过排序过滤、索引过滤等方式提高查询速率。

在日常的开发中,最常用的数据格式是 JSON ,并且有的时候 JSON 的格式是非常复杂的(嵌套的格式),那在 Flink SQL 中进行解析的时候也会相当麻烦一点,下面将会演示如何在 DDL 里面定义 Map、Array、Row 类型的数据,以及在 SQL 里面如何获里面的值。目前，JSON 模式总是从表模式派生。下表列出了从 Flink 类型到 JSON 类型的映射。说明数据都可以正常的解析出来,如果遇到更加复杂的 JSON 格式的数据,只需要比葫芦画瓢就可以了,在复杂的格式都不是问题.

WITH ('connector' = 'kafka', -- 使用 kafka connector'properties.bootstrap.servers' = 'master:9092,storm1:9092,storm2:9092', -- broker连接信息'properties.group.id' = 'jason_flink_test', -- 消费kafka的group_id'scan.startup.mode' = 'latest-offset', -- 读取数据的位置。

x 轴表示抽样数，如果一个函数在 x 轴占据的宽度越宽，就表示它被抽到的次数多，即执行的时间长。注意，x 轴不代表时间，而是所有的调用栈合并后，按字母顺序排列的。如果某个方法调用在其中一个并行任务中占用了100%的资源，但在其他任务中没有占用，则可能会被平均化而掩盖住瓶颈。选择一个对应的子任务，您可以看到相应子任务的火焰图。调用栈越深，火焰就越高，顶部就是正在执行的函数，下方都是它的父函数。混合模式的火焰图是由处于所有可能状态的线程的堆栈跟踪构建而成。级别上进行的， 即该算子的所有。

其实是不适用的, 上面我们提到 None 模式的流读其实就是读取 L0的文件, 那么我们只要看 L0的文件是否包含 Key 的变更记录. 因为 write buffer 会有合并的逻辑, 所以, 对于 CDC 的数据, L0中可能会是已经在内存合并后的数据. 比如同一个 key 的-U 和+U 消息, 同时写入, 那么在 writer buffer 写入的时候就已经只保留+U 消息了, 所以 None 模式中 L0文件中的数据, 可能已经是合并后的数据, 对于 CDC 的数据也不适用.

一个Flink程序的运行，会依赖到一个或多个Connector（连接器），而这些连接器分为Source（主要用于读）和Sink（主要用于写），那么如果要监听到Flink作业流动的数据，我们这里可以简单尝试去查看支持Sink的Connector(例如：flink-connector-jdbc)，看看 是否有实现一个公共的接口，然后对这个接口做监听，即可“读取”写入前的数据?接下来可以开始编写一个Agent类了，这里直接上代码。

Paimon仅支持主键表和Append Only表。由于主键表需要按照主键更新，且要满足各种场景的数据更新，因此针对主键表piamon又提供的表的数据合并引擎。Paimon主键表创建Paimon表时指定了主键（primary key），则该表即为Paimon主键表。语法结构例如，创建一张分区键为dt，主键为dt、shop_id和user_id，分桶数固定为4的Paimon主键表。dt STRING,Paimon主键表中每行数据的主键值各不相同，如果将多条具有相同主键的数据写入Paimon主键表，将根据。

paimon系统表按照元数据的分类，划分了如下10个系统表，通过系统表可以获取paimon表各维度的元数据和消费组信息。通过收集这些元信息，不仅可以排查问题使用，还可以构建统一的paimon元数据管理和消费组管理平台，比如paimon-web就是通过查询系统表来实现表的元数据管理和展示的，本文将详细介绍各系统表的含义和用途。

Apache Paimon 原名 Flink Table Store，2022年1月在 Apache Flink 社区从零开始研发，Flink 社区希望能够将 Flink 的 Streaming 实时计算能力和 Lakehouse 新架构优势进一步结合，促进数据在数据湖上真正实时流动起来，并为用户提供实时离线一体化的开发体验。

看到好些人在写更新缓存数据代码时，，而后续的操作会把数据再装载的缓存中。。试想，两个并发操作，一个是更新操作，另一个是查询操作，更新操作删除缓存后，查询操作没有命中缓存，先把老数据读出来后放到缓存中，然后更新操作更新了数据库。于是，在缓存中的数据还是老的数据，导致缓存中的数据是脏的，而且还一直这样脏下去了。我不知道为什么这么多人用的都是这个逻辑，当我在微博上发了这个贴以后，我发现好些人给了好多非常复杂和诡异的方案，所以，我想写这篇文章说一下几个缓存更新的Design Pattern（让我们多一些套路吧）

作为一种特定领域语言，SQL 的设计初衷是隐藏底层数据处理的复杂性，让用户通过声明式语言来进行数据操作。而Flink SQL 由于其架构的特殊性，在实现层面通常需引入状态后端 配合 checkpoint 来保证计算结果的最终一致性。目前 Flink SQL 生成状态算子的策略由优化器根据配置项 + SQL 语句来推导，想要在处理有状态的大规模数据和性能调优方面游刃有余的话，用户还是需要对 SQL 状态算子生成机制和管理策略有一定了解。

在 Flink 中，状态管理是流处理应用的核心概念之一，它允许算子（operators）在处理事件时保持和操作状态信息。在 Flink 中，状态可以被视为算子的“记忆”，它使得算子能够在处理无界流数据时保持对历史数据的跟踪。状态可以是简单的键值对，也可以是更复杂的数据结构，如列表、集合或自定义对象。状态的更新和查询对于实现复杂的流处理逻辑至关重要。具体说来，首先，Checkpoint 是 Flink 的一种容错机制。

Flink 社区希望能够将 Flink 的 Streaming 实时计算能力和 Lakehouse 新架构优势进一步结合，推出新一代的 Streaming Lakehouse 技术，促进数据在数据湖上真正实时流动起来，并为用户提供实时离线一体化的开发体验。Flink 社区内部孵化了 Flink Table Store （简称 FTS ）子项目，一个真正面向 Streaming 以及 Realtime的数据湖存储项目。

想要对 Flink 任务的消息处理能力进行分析，第一步便是获取该实时任务的 Kafka 数据源 Topic，目前如果数据源不是 Kafka 的话，我们不会进行分析。我们实时平台每天会定时扫描所有正在运行的 Flink 任务，在任务内存方面，我们能够结合 实时任务 GC 日志，同时根据内存优化规则，计算出 Flink 任务推荐的堆内存大小，并与实际分配的 Flink 任务的堆内存进行比较，如果两者相差的倍数过大时，我们认为 Flink 任务的内存配置存在浪费的情况，接下来我们会报警提示到平台管理员进行优化。

自定义listener，只需要实现对应的接口。并将您的逻辑写入重写的函数中。Flink JobListener 接口有两种方法，一种是提交，一种是完成。接口的定义如下。两种方法都有两个参数。一个常见的参数是 Throwable。Throwable 参数是进程抛出的错误（如果有）。让我们分别看看这两种方法。Flink JobListener接口：onJobSubmitted顾名思义，只要提交作业以供执行，就会调用此函数内的代码，并调用该方法。

为了实现hive, trino等组件实时查询hudi表的数据，可以通过使用Hive sync。在Flink操作表的时候，自动同步Hive的元数据。Hive metastore通过目录结构的来维护元数据，数据的更新是通过覆盖来保证事务。但是数据湖是通过追踪文件来管理元数据，一个目录中可以包含多个版本的文件。这一点和Hive元数据管理是不同的。所以说为了兼容Hive metastore，Hudi需要实时从Timeline同步元数据到Hive metastore。