在之前的文章中，曾经吐槽过 Flink 的 jdbc 方案，你说既然都 jdbc 了，怎么还可以做到跟支持 jdbc 协议的数据库不直接兼容的呢，比如 clickhouse，关键人家不管是在低版本，还是现在的高版本，好像就没有想过去解决这件事。

既然 Flink 这么傲慢(或者直接说蠢)，那我就用 Spark 好了，从之前的测试案例可以看出来，人家就支持的挺好，简单且好用。

但最近一时兴起，就想用 flink 来读写 CK ，这可咋整？

网上找喽，通过关键词一搜，还真有好心人提供了解决方案。

那么这篇文章，就来看看这个 Google 搜索排名第一的回答(但 start 数却比较一般)，到底靠不靠谱。

0. 准备

从搜索结果你也看出来了，你得先备好梯子，否则就玩不了。

把这个项目先克隆到本地，用 IDEA 打开，你会发现它有3个子 module，

但有意思的是，就第一个是货真价实的，剩下两个都是空壳，也不知道作者的用意是啥。

以我的经验，面对这种野生的开源项目，不要指望把它一下载下来，小手轻轻这么一点，它就能轻松编译通过，你要做好各种修改、折腾、填坑的准备。

0.1 修改 pom 文件

既然是 Flink 的 CK connector，这里就涉及到两个技术组件，一个是 Flink，另一个就是 CK，那么对应它们的版本，你是不是就得考虑跟你的环境适配一下。

所以第一步，就要改 pom 文件里面，一些依赖包的版本，其中核心的主要是这下面3个。

分别是 Flink 的版本、对应的 Scala 的版本，以及 CK jdbc 的版本(所以还是用到了 jdbc)。

本来在我的环境里，更倾向于用 Flink 1.15，但是，这里趟了第一个坑。

在后面启动程序时，抛出找不到的这个类，只有在 Flink 1.16 及以上版本才有，于是我就干脆就用 Flink 1.18 了(当前环境里也部署了1.18)。

至于 Scala 的版本，现在主流都用的是2.12，而 CK jdbc，就默认用它的高版本好了。

0.2 编译第1次报错

搞定了核心组件的版本，接下来就应该可以轻点鼠标，直接编译项目了。

可是，编译报错：

从提示来看，是飘红的这个包找不到对应的版本。

但是从 pom 文件来看，这是个测试才会用到的包，而我在测试用例里面，又没有看到对这个包的引用。

所以干脆把它给删了，这个报错解除。

0.3 编译第2次报错

从错误提示来看，有同学估计会认为是代码的问题。

但其实，它是编译插件的问题：

我看在父 pom 文件中定义有好几个类似的插件

想着反正这么多，那就删一个应该也没事吧。

于是，我就把报错的这个插件配置给删了，结果就是，打包成功了，上哪说理去？

打出来的几个包，长这样，其中第一个圈出来的，就是我们的目标包。

1. 重新构建 flink 工程

flink-connector-clickhouse 构建成功后，就需要把打好的目标包给引入到 Flink 工程，这里又引出一系列操蛋的事情。

由于 Flink 已经被迫从之前的 1.15 升级到了 1.18，导致工程里面所有原本是基于 1.15 写的 DataStream API，全部都要重写(这设计者脑子应该是进si了吧)，就问你窝不窝火。

编译时抛出异常的 Datastream API

此外，还有每次升级几乎逃不掉的保留项目，「jar 包冲突」，解决起来，那叫一个酸爽。

此处省略一千三百七十一个字......

2. 跑起来

2.1 第1种写法

根据这个 github 项目文档说明，先尝试用第一种写法，也就是 Flink SQL API，来个依葫芦画瓢。

但是这个瓢，没能画成功。

也不知道问题到底出在哪，要知道，我可是用了各种花样排列组合的方式尝试了的，可就是它娘的不行。

2.2 第2种写法

同样，也是根据 GitHub 文档的案例，写了个一样的。

虽然写法不太一样，但本质也是个 Flink SQL API。

不过效果是一样的，那就是没有效果，依然跑不出来。

至于这个报错嘛，看球不懂，罢了，不折腾了，举小白旗了。

最后

也不知道是我水平不行呢，还是这个解决方案确实比较难用，或者说是我的环境过于刁钻，恰好卡到这个 bug 了。

如果有好心人能告诉我问题在哪，那可真就太好了。