流引擎常见问题

怎样评估流作业并发度和流引擎集群资源？

流作业的并发度和集群资源需要根据峰值数据量和计算复杂度综合评估，主要考虑以下因素：

• 上游峰值写入速率、消息大小及Kafka分区数。

• SQL算子的计算复杂度，例如Join、窗口、聚合、UDF和外部服务调用。

• 作业状态大小及Checkpoint耗时。

• 下游Kafka、Lindorm等存储的写入能力。

• 业务峰值、故障切换和后续增长所需的资源余量。

如果无法提前准确评估，可以先开通起步规格，以较小并发度运行作业，并重点观察以下指标：

• 上游Pending或Kafka Lag是否持续增长。

• 各算子的输入输出速率、Busy和反压情况。

• 集群CPU、内存、GC和Slot使用率。

• Checkpoint耗时和失败率。

• 下游写入延迟和失败率。

根据监控结果进行调整：

完成压测后，可以使用以下方式估算所需并发度：

作业并发度 ≈ 峰值目标吞吐 ÷ 单并发实测吞吐

流引擎集群资源需要覆盖所有作业并发及每个并发实例的资源消耗，并为业务峰值和故障恢复预留余量。

Kafka、Lindorm等存储网络不通或无法访问怎么办？

可以先使用流任务运维管理平台的网络探测功能，从流作业实际运行的网络环境探测目标域名、IP地址和端口。

建议按照以下顺序排查：

1. 确认流引擎和目标存储处于同一VPC，或者已经通过流引擎支持的私网链路打通。

2. 在Kafka、Lindorm等存储侧添加访问白名单。白名单可以配置为流引擎使用的IP地址段，或流引擎所在vSwitch的网段。

3. 检查目标域名、IP地址、端口和连接串是否正确。

4. 检查账号、密码、AccessKey、SASL/SSL等鉴权配置是否正确。

5. 修改白名单、连接地址或鉴权参数后，重新提交或重启作业，避免作业继续复用旧连接。

出现ClassNotFound、NoSuchMethod或Jar冲突怎么处理？

此类错误通常由运行环境缺少依赖，或者作业依赖与流引擎服务端依赖版本不一致导致。

常见错误及原因如下：

按照以下步骤处理：

1. 保存完整异常堆栈，确认报错的类、方法及其所属依赖。

2. 记录流引擎、Flink、Connector、客户端和作业依赖的完整版本。

3. 使用以下命令检查Maven依赖树，定位重复依赖和版本覆盖：

   mvn dependency:tree

4. 检查作业Fat Jar中是否重复打入Flink、Kafka Connector、Log4j或Lindorm客户端依赖。

5. 统一服务端和作业侧的Connector版本，删除重复或不兼容的Jar。

6. 重新打包并提交作业。必要时停止旧作业并重启相关TaskManager，清理由ClassLoader加载的旧依赖。

使用Kafka Connector时，需要特别注意：

• 如果服务端使用flink-sql-connector-kafka，作业侧必须使用与服务端及Flink版本兼容的同版本依赖。

• 如果平台已经内置flink-sql-connector-kafka，作业中通常不应再次打入另一个版本。

• 不要同时引入多个版本的flink-sql-connector-kafka、flink-connector-kafka或其传递依赖。

通过JDBC Connector写入Lindorm较慢怎么办？

使用JDBC Connector写入Lindorm时，可以在JDBC连接串中增加以下参数：

useServerPrepStmts=true&cachePrepStmts=true

完整连接串示例如下：

jdbc:mysql://<host>:<port>/<database>?useServerPrepStmts=true&cachePrepStmts=true

参数说明：

修改连接串后，需要重新提交或重启作业，并对比修改前后的写入吞吐、Sink延迟和反压情况。

如果写入性能仍未达到预期，请继续检查以下因素：

• JDBC Connector的批量写入大小和刷新间隔。

• Sink并发度是否合理。

• Lindorm节点负载、热点主键和写入延迟。

• 网络带宽和连接稳定性。

• 是否存在逐条提交或过于频繁的Flush。