monkeyboy_tech的博客

最近公司在做一些业务上的架构调整，有一部分是数据从mysql采集到Starrocks，之前的一套方法是走debezium到puslar到starrocks,这一套下来比较需要配置很多东西，而且出现问题以后，需要修改很多配置，而且现阶段问题比较多，且采集的是所有线上的数据库，维护起来很费劲。于是我们进行了采集的数据流调整，使用 Flink CDC这一套，这一套 是端到端的，且采用配置化的方式，支持schema的变更，无需再多一层中间存储层。

这里主要就是解析 yaml文件，以及根据source sink构建 pipeline并生成 filnk DataStream 任务 ，这种方式和 flink SQL的方式很像，只不过 SQL方式 是 解析SQL形成对应的flink DataStream任务。但是以上几种方式都是得写SQL或者写代码实现，这种是要一定的专业知识和门槛的，恰好 FLink CDC 提供了一种yaml文件配置化的方式来降低这种门槛，不需要掌握专业知识就能够进行快速的进行数据传输的工作，在此分析一下 Flink CDC的整个流程。

是用来Flink用来产生CDC数据的,Flink SQL Planner 会自动为 Upsert 类型的 Source 生成一个 ChangelogNormalize 节点，并按照上述操作将其转换为完整的变更流；所以这里我们选择把 kakfa的数据转换成的正常的 数据流，而不是CDC数据，因为我们最终存储的 Adb 是可以支持upsert操作。这里获取到的数据就是 正常的json数据，而不是 debezium-json数据，具体区别，可以参考下面的说明。，因为我们现在选择 kafka sink的是。

所以说 Flink SQL 调用 python UDF 还是采用了 Py4j ，这种方式也是采用了进程间通信的方式，在效率上还是比不了基于 java/scala 而写的UDF，这种方式和Spark SQL中怎么注册python以及使用python注册的UDF中数据流是怎么流转的类似。

（默认30000），这两个参数来控制kakfa的客户端从服务端请求超时，也就是说每次请求的超时时间是30s，超时之后可以再重试，如果在60s内请求没有得到任何回应，则会报。这里做的事情就是从持久化的State中恢复kafkaTopicOffset信息,我们这里假设是第一次启动。获取到要提交的kafka offset信息，并持久化保存kafka中。在Flink中对于Kafka的Connector的。，这里我们只讨论kafka作为source的情况，方法会被调用，所有kafka相关的操作都可以追溯到。

首先是反序列化CleanPlan,然后在进行清理，主要是删除1. 如果没有满足的分区，直接删除该分区，2. 否则删除该分区下的满足条件的文件,最后返回。HoodieFlinkMergeOnReadTable*类型的hudi表,用来做clean等操作。,也就是在写数据失败的时候，会立即进行这次写失败的数据的清理，在这种情况下，创建一个只有一个线程的线程池，改线程池的主要作用来异步执行hudi写操作。本文主要是具体说说Flink中的clean操作的实现。真正执行clean的部分，主要是调用。

最终会调用catalogManager.registerCatalog方法，用catalogManager管理了起来，这样在用到的时候就会调用该get方法得到对应的catalog。来说明一下Flink中createDynamicTableSource/createDynamicTableSink/createCatalog是什么时候被调用的。也说该方法的调用是在逻辑生成阶段的.（createDynamicTableSource方法的调用逻辑也是一样的）对应到SQL中的调用逻辑为。

在之前的文章中Apache Hudi初探(二)(与flink的结合)–flink写hudi的操作(JobManager端的提交操作) 有说到写hudi数据会涉及到写hudi真实数据以及写hudi元数据,这篇文章来说一下具体的实现这里的操作就是在HoodieFlinkWriteClient.upsert方法:initTable初始化HoodieFlinkTablepreWrite在这里几乎没什么操作getOrCreateWriteHandle创建一个写文件的handle(假如这里创建的是Flin

在Apache Hudi初探(一)(与flink的结合)中，我们提到了,这个操作真正写hudi是在方法下的,具体分析一下写入的过程。对于这个代码片段，我们主要看 这个对象(这个操作是Flink框架的操作):最主要的算子为,其中最主要的操作是由来完成的：操作，主要是做一些初始化的操作获取当前的task的索引下标，用来向发送event给,之后 StreamWriteOperatorCoordinator() 进行处理，后续会说到StreamWriteOperatorCoordinator初始化hu

long ckpTimeout = * 获取到。的方式，只需要引入了对应的jar包即可，以。的方式，所以不需要像使用。的超时时间，并设置为。

本文基于Flink 1.13.x。

在基于原生K8S做JobManager HA服务的前提下，随着部署在K8S的flink任务越来越多，JobManager节点挂的频率越来越高，这严重影响了整个Flink作业的运行。其实最主要的原因是flink集群对etcd的访问过于频繁(etcd是K8S的最为关键的组件),导致了整个K8S集群的不稳定。对于目前的flink的架构，画出如下的图，该图也是参考了。本文基于Flink 1.13.x。

本文基于Flink 1.13.3Flink计算引擎VVR版本的hbase Connector具体maven依赖如下：在基于VVR版本的cloudHbase维表查询的时候，发现同步查询的速度很慢，所以我们打算做基于异步的维表查询。在运行的过程中发现了NPE问题,具体的报错堆栈如下：先说结论Flink计算引擎VVR版本的hbase Connector把hbase的数据转化为RowData的时候存在多线程问题，这种会导致NPE问题相比Asynchronous I/O for External Dat

背景Flink 1.3最近在写Flink Sql的时候，遇到了java.lang.ClassCastException: java.lang.Integer cannot be cast to java.lang.Long 问题分析直接上报错的sql，如下：CREATE TABLE `xxx` ( `merchantId` BIGINT, `userId` BIGINT, `status` BIGINT) WITH ( );具体的问题堆栈如下：java.lang.C