Flink 开发日志 【成品可视化实时报表项目】

背景：自研

公司自研在flink基础上做的平台，在此基础上做SQL语言开发。

版本：

项目：大型实时报表

介绍

逻辑复杂的，数据量很大，跨EWM和 ERP两个平台数据，涉及30个底表的 微批转实时项目

框架

平台：物信开发工作台

数据源：kafka   

计算引擎 ：基于flink 二次开发的计算引擎  ：Hlink 1.15.0

集群管理器：YARN

状态持久化存储：HDFS

数据持久化数据库：基于Doris二次开发的数据库 ：海燕数据库

初始化

全量数据使用离线计算分批次导入

开发日志

2025.1.15

开发注意事项：

flink语法

1.不分大小写，注意接入kafka及其他数据源字段名的大小写

linux查找文件指令：

find . -type -f -name "*application_17135*" 2>/dev/null 

【注意：该指令无法查找yarn日志】

linux查看yarn日志

yarn logs -applicationId application_1701363143014_551184 > ys1601.log

vim ys1601.log

【在其中可以查看 /error /Exception/Caused 等关键词】

报错：

1.Caused by:Time out of 60000ms expired before the position for partition T_ERP_LIKP-2 could be determined

翻译：连接kafka partition分区超时

项目问题：flink起起来了以后一小段时间后报错，然后挂掉

问题原因：source表地址配置有问题

解决方案：查看并重新配置source 表上 Kafka地址集合

'properties.boostrap.servers' = '10.1.183.xx:30305,10.1.183.xx:30215'

2.javax.management.InstanceAlreadyExistsException: kafka.consumer:type=

翻译：客户端注册报错

项目问题：挂了以后查看日志搜索 /Exception 发现有很多这个报错 

问题原因：当使用Flink连接Kafka时遇到InstanceAlreadyExistsException警告，实际上是由于多个相同topic的Kafka源客户端ID相同导致。解决方法是在Kafka source配置中设置不同的client.id前缀以进行区分。

解决方案：告警不是报错不用管

2025.1.16

报错：

1.Error sending fetch request

翻译：发送 获取信息请求时出错

项目问题：观察到托管内存Managed Memory占满了

解决方案：观察托管内存Managed Memory后，调大托管内存占比：

taskmanager.memory.managed.fraction 【默认0.4】-> 0.7

2.Exceeded checkpoint tolerable failure threshold.

翻译：检查点失效

项目问题：数据卡住了，没有存储到检查点

解决方案：拉长检查点检查超时时间，调整参数：

execution.checkpointing.timeout :1800000 -> 7200000

3.java.net.SocketTimeoutException : Read time out

翻译： 在指定的超时时间内，套接字操作没有完成。

项目问题：输出到海燕数据堵塞

解决方案：sink表增加并行度配置 ：

 'sink.parallelism' = '1' -> '5'

4.背压过大，kafka消费组偏移量过大fa

将几个大表的数据通过BO_TS 限制为今天开始，LIPS，VBAK，ZHAE_TLINE_TMPL

全量数据通过离线ETL跑

2025.01.17

开发注意事项：

1.更改任务后，记得更改ck地址，和 任务名，否则会报错

2.任务起不来的情况，调大jobmanager 并调小 托管内存占比

业务问题：

1.kafka只储存7天数据，部分流数据需要关联很久之前的流数据，如何解决

痛点：

需要以另外一张实时业务表作为维度数据，限制范围后数据量近8kw，无法通过做成海燕维度表的方式存入内存中，只能通过流表的方式进行关联。

方案1：

1.采用全量导入海燕数据，union all kafka数据，再通过rownumber去重

2.调大相应的内存进行初始化。

taskmanager.memory.process.size: 10240M -> 20480M
parallelism.default: 10 -> 25
taskmanager.memory.task.off-heap.size:5120M

3.改完后起不起来，调大jobmanager 和 调小 托管内存占比

4.调整后 检查点检查报错，地址更改后依旧报错，更改任务名

方案2：

1.采用集成工作台 将HANA 导入 kafka其中一个 topic，并在flink里面和原来的topic  union 后去重

2.调大相应的内存进行初始化

taskmanager.memory.process.size: 10240M -> 20480M
parallelism.default: 10 -> 25
taskmanager.memory.task.off-heap.size:5120M

报错：

1.org.apache.flink.util.StateMigrationException: The new state serializer must not be incompatible with the old state serializer

翻译：新旧序列号不匹配

项目问题：增加字段后，重启flink报错

问题原因：Flink的状态是按key组织并保存的，如果程序逻辑内改了keyBy()逻辑或者key的序列化逻辑，就会导致检查点/保存点的数据无法正确恢复。所以如果必须要改key相关的东西，就弃用之前的状态数据吧。

解决方案：弃用之前的状态数据，更改存储路径

state.checkpoints.dir : hdfs:///user/accountXXXXXX/checkpoints/f_xxxxx_0117

2.Failed to create brpc source:java.net.SocketTimeoutException: connect timed out

翻译： 连接超时 没有返回结果

项目问题：

问题原因：

解决方案：

3.Buffer pool has already been destroyed.

翻译：缓冲池已被销毁。

项目问题：查看任务失败后日志的时候看到该报错

问题原因：绝大部分原因是因为TaskManager crash down，也就是TaskManager宕机了或者是TaskManager restart前在关闭的过程中的报错. 所以收到这个错误我们应该去顺着查找TaskManager容器的错误，例如发生了作业失败导致的restart之类的错误

解决方案：不进行处理

4.Could not forward element to next oprator

翻译：无法将元素转发到下一个操作器

项目问题：查看任务失败后日志的时候看到该报错

问题原因：当flink的数据流中的元素字段内存在字段值为null的时候可能会报该异常信息

解决方案：不进行处理

当flink的数据流中的元素字段内存在字段值为null的时候可能会报以下异常信息

5.The execution attempt xxx was not found

翻译：无未找到执行尝试

项目问题：查看任务失败后日志的时候看到该报错

问题原因：

解决方案：不进行处理

2025.01.20

开发注意事项：

1.大数据块的join尽量放在后面,前面的join shuffle 完后再join

2.kafka join kafka，属于流流join， 比 kafka join海燕的 流批join 性能更好,建议把所有的 海燕表导入进kafka。包括维表

3.所有表都需要进行排序去重，而且是先排序去重再限制范围

4.初始化采用替换kafka的topic方式，先将全量kafka 的topic跑完以后再替换成实时的kafkatopic

5.flink最重要的步骤是需求分析，画ERP图，再开发，分析比重要占大头

6.连接kafka使用mysql 连接，而不是starock连接

7.全量初始化，从HANA到kafka存量topic时，bo_ts设立为当前时间-7天，目的是为了保证排序去重的时候，数据优先取实时topic而不是存量topic。

8.集成台的DDL 和 元数据管理可以创建 kafka 的 topic。集成台输出表的主键记得选。

2025.01.21

报错：

1.flink Slot request bulk is not fulfillable! Could not allocate the required slot within slot request timeout

翻译：flink 槽请求批量不可满足！无法在槽请求超时内分配所需的槽。

项目问题：任务日志报该错误后就结束了任务

问题原因：网上查找信息后，发现是yarn资源不足，查看资源管理平台，发现该任务所属项目CPU已经满了

解决方案：

1.调整其他占yarn资源的任务，如SPARK任务。

2.通过checkpoint存储路径去hdfs上查找最新的checkpoint状态路径，通过选择最新数据，路径停止到 chk-数字 

3.然后在CPU空闲时候，增加 execution.savepoint.path 配置进行初始化接续。

execution.savepoint.path:【hdfs:///user/acountxxxxxx/checkpoint/f_xx_xxx_xxx_01211/1231231xxxxxx131231xxxx/chk-4】

2025.01.22

报错：

卡死在写入数据库的算子上，前面的算子全灰，背压都满了

解决方案：将数据库source 写入表的 并行度调整 5 -> 10

'sink.parallelism' = '5' -> '10'

2025.02.10

报错

1.SplitFetcher thread 0 received unexpected exception while polling the records。

TimeoutException: Timeout of 60000ms expired before the position for partition device_meter_data-0 could be determined

翻译：SplitFetcher 线程 0 在轮询记录时收到意外异常

项目问题：初始化后，将历史的kafka的topic切换成实时topic时，五个表有四个无法连接

问题原因：

1. 首先怀疑是source表地址配置有问题，因为更换了主表，检查过后，发现kafka的Brokers 有7个地址，于是给'properties.boostrap.servers'地址增加了Broker ID 567的地址后，依旧报错。
2. 于是怀疑是参数原因，复制出来，删除了chk，只跑增量topic的flink任务不会报错。
3. 怀疑是akka 和 slot 的参数问题，调整参数

   1. taskmanager.numberOfTaskSlots:【5】->【1】
      yarn.containers.vcores:【5】->【1】
      parallelism.default:【25】->【5】

   2. 后续内存消耗会变大，可能会出现 flink Slot request bulk is not fulfillable! Could not allocate the required slot within slot request timeout 的错误
4. Flink 的 Checkpoint 机制会保存 Kafka Source 的状态，包括每个 Kafka 分区的消费偏移量。当 Flink 作业从 Checkpoint 恢复时，它会尝试从 Checkpoint 中记录的偏移量开始消费数据。如果 Checkpoint 中记录的偏移量对应的是旧的 Topic，而 Kafka Source 已被配置为新的 Topic，Flink 作业可能会尝试从旧的 Topic 的偏移量恢复，导致连接失败。
   1. 调整动态查询分区参数

   2. 'scan.topic-partition-discovery.interval' = '10s'

   3. 未起效果

解决方案：

/我在网上没有搜索到 flink kafka source表 有scan.topic-partition-discovery.interval的使用案例，给我个 flink kafka source表使用案例，要求使用scan.topic-partition-discovery.interval 参数配置。并且给我案例的原网址链接。

2025.02.12

报错

1.