Flink实时写入StarRocks NullPointerException问题解决

问题

最近出现很多任务经常跑着跑着就failed了，也不怎么重启，翻了下异常信息如下，大概意思就是进行stream load的时候失败了，然后回滚了下，然后就空指针了

原因分析

1.根据经验，NPE的问题一般是数据异常导致的，但是这里没打出来数据，所以无法判断是不是数据问题

2.注意关键字rollback，意思是写入失败了在回滚，问题是StarRocks版本是2.3.x，StarRocks的事务是2.4才支持的，有啥好回滚的，根本不支持，再想一下最近升级了connector版本到1.2.5，另外sink的执行的是StarRocksDynamicSinkFunctionV2。

翻了下文档，这个V2是1.2.4版本增加的事务接口，不支持事务的sr版本默认用的非事务接口，也就是v1，有点不对，我们的sr版本明明不支持事务，为啥还是用了v2版本呢。

源码分析

1.我们找到StarRocks connector的1.2.5版本源码的SinkFunctionFactory.java类，可以看到核心方法是StarRocksDynamicSinkFunctionBase

2.这个方法的第一步是getSinkVersion，从option中判断是v1、v2、还是auto，我们从低版本升级来的，低版本connector完全没有v1、v2的概念，这里肯定是走的auto了

3.auto执行了一个chooseSinkVersionAutomatically方法，然后调用了isStarRocksSupportTransactionLoad判断是否支持事务，这个方法向fe发送一个http请求，根据返回值来判断是否支持事务

4.我们的StarRocks是在云上的，和本地网络不通，debug有点困难，我照着isStarRocksSupportTransactionLoad中的逻辑构造了一个http请求发送给fe，返回值长这样

再和代码中对比一下，正常返回的情况下，用msg和status就能判断出当前的服务端不支持事务了，connector判断逻辑是没问题的

5.既然判断逻辑没问题，为啥我们还是走了v2版本呢，再看看发送http请求外层还有个try-catch，如果访问fe失败，就无法判断了，无法判断服务端是否支持事务时默认是使用v2版本来sink，根本原因找到了，就是走了这个默认值所以回滚失败了

解决

原因确定了，解决方案其实很简单，在sink option中加上默认用v1版本就好了。改完代码，重新上线，问题解决。

思考

如果我是StarRocks connector的开发者，有没有更好的办法避免这个问题。想了一下是有的，现在的版本实际上是每次sink触发都会去判断到底用v2还是v1，这个其实很没有必要，设置一个全局变量，在任务启动的时候判断一次是否支持事务决定v1还是v2，以后的sink直接用上面的结论，如果启动时http请求就失败了，直接启动失败，比运行一段时间之后再失败会好一些。