上篇文章聊了我最近几天使用最新版本 Dinky(0.75) 的体验过程，以一个初次接触这款软件的视角出发，大致记录了整个使用过程中的使用感受，以及过程中遇到的一系列坑。

整体上给我留下了一个不太好用的印象，原因其实很简单，如果说一款本来初衷就是为了提高你开发效率的工具性软件，在部署的过程中需要你花大量时间、绞尽脑汁、各种费劲心思去研究怎么去填部署、配置过程中的坑，确实很容易劝退人。

但是就在我文章发出去后不久，一个热心的小伙伴就加了我微信，说自己已经使用了一年的 Dinky ，总体感受还不错，我遇到的坑，他知道怎么解决。

好嘛，这个声音出现的很及时。

1. 核心配置不对

其实上篇文章提到通过 Dinky 来部署 Flink on yarn，之所以没有玩起来，核心原因就在我在「 Flink 实例管理」中配置的不对：

至于为什么没有配置对，我觉得不能怪我(打死不认)。

因为啥呢？我们先来瞅一眼这个配置内容：

这里有3个必填项：

1. 实例名称：给它这个 yarn session 进程取的一个名字，这个不用多说，没有难度；

2. 类型：对于Yarn模式来说，可以选择Yarn session 以及 Yarn application，这里选前者；

3. JobManager高可用地址：需要你填写 JobManager 的Rest地址，如果启动了HA模式，则填多个。

也就是说，这个 JobManager 进程，需要你提前在 yarn 启动，否则这里就玩不了。

这个，就是这里最坑爹的地方，从填写给的示例来看呢，这个需要填的 IP 地址是 JobManger 进程运行的服务器地址，而这个端口则是其对应的 rest 通讯端口。

但是，作为一个 yarn 的资深用户，我知道，这个 JobManager 进程所在的服务器咱好找，通过yarn的web界面，点击这个app id进去：

就可以看到其对应的地址：

这个被我标出的 host 就是 JobManager 地址。

但是，至于端口，我会很自然的认为就是这里面显示的 8042，但其实不是，而且也不是默认的 8081。

那这个神秘的端口到底是多少呢？(官方文档对这块的描述几乎为0)

经过这位童鞋的提醒，想要得到这个端口号，你得这么来找：

先点击 yarn 上运行的这个 JobManager 任务的 APPMaster按钮：

跳转到对应 Flink 的 UI 界面：

然后，点击右方的 JobManager 按钮，进入到其监控页面后，再点击 Logs 按钮，打开其运行日志：

然后在日志中搜索「Rest endpoint」。

这才能找到正确的端口号(注意这个端口号，对于不同的jobmanager来说，是变动的)。

好嘛，这一番劲给费的，确实隐藏的够深的，难怪很多人玩不转这个 yarn 的配置方式呢。

但是，你以为找到了正确的IP跟端口之后，给原本不对的配置修改过来就好了吗？

来，看我碰到了个什么鬼：

当你信心满满填上这个你以为正确的地址后，再点击保存。

突然，啪叽给你一个暴击，它居然报错了。

这个时候但凡你信念动摇一点，我猜你就会放弃，怀疑刚才所有的操作都是徒劳。

但是，如果你抱着一种“老子就是不信邪”的决绝，和敢于坚持尝试到底的勇气，不妨重启一下你的 Dinky 服务：

然后再试一次：

然后发现它，居然正常了，就是这么神奇。

2. 小试牛刀

上面只能说是趟过了一个，最没有逻辑，最让人容易崩溃的坑王，那接下来发生的事情，会不会就一帆顺风了呢？

既然 yarn 相关的配置都已经OK了(详细配置，还需要结合我上一篇文章的内容一起看)，那么接下来，就要正儿八经来写个demo跑起来了。

先来个最简单的：

这只能说是个幼儿园水平的测试，目的就是看 yarn 集群环境好不好使。

来，点击右上方的运行按钮：

再来看一眼 yarn 上面的 Flink 任务UI：

可以看到能正常以 yarn session 的方式来提交，说明上面的 yarn 配置没有问题(观察一段时间后发现，确实没有问题)。

PS：但这里有个可以改进的地方就是，我在这个开发界面，没能顺利找到一个可以直接跳转到 Flink UI 界面的按钮，需要手动去找，有点不方便。

3. 来个水平稍微高一点的代码

这次，咱把demo改成，用Flink 读取 Kafka数据，然后再把数据写入到 Doris 表中，看要实现这个流程，用 Dinky 是否顺利(我从之前 IEDA 的 Flink 项目中 copy 过来的)。

于是，我写了个 test02：

一跑，就报错了，只不过，这个错误是意料之中的：

从错误来看，其实就是缺包。

确实，目前从 Dinky 的这个开发界面来看，并没有提供一个像 IDEA 那样，允许你添加依赖jar包的入口，通用 pom 文件或者直接添加都没有(至少我没有找到)。

那咋整？

好像只能把这些依赖包给上传到Dinky 能识别的，可以作为class path 的文件夹下。

比如，官网中提到的那个推荐的 plugins 目录。

因为依赖的包会比较多，一个个放，就显得效率太低，于是我就想着，把我之前在 IDEA 开发环境打的一个Flink任务依赖的fat jar，给放到这个目录下，应该就能解决这个依赖问题。

于是说干就干，很快我就把那个依赖的 fat jar 给放到了 这个 plugins 目录下，然后重启 Dinky。

结果，起不来了：

查看日志发现，哇了个去，这不就是典型的 jar 包冲突吗。

看来这招行不通，或者说在当下这个环境里解决冲突问题会比较麻烦。

于是，得换一种策略，只能遵循「缺啥补啥」的方式。

那么就先把这个fat jar给删除，再添加 Kafka connect 的包(刚才报错就是缺这个)。

包名：flink-connector-kafka-1.15.3.jar

重启，再运行，这回报了另一个错：

一查，这回缺的是：kafka-clients-2.x.x.jar (跟Kafka版本一致)

再重启，再报错：

很明显，是缺 Doris connector， 加：flink-doris-connector-1.15-1.4.0.jar

再重启，还报错：

只是这回这个报错，就多少有点让人恼火，说没有这个类，但明明这个类就包含在开始的 flink-connector-kafka-1.15.3.jar 包里面，而且当前环境包含这个类的包就只有这一个，不太像是 jar 包冲突才对，关键这种情况下，它不好分析到底是什么原因。

很迷惑，很沮丧。

当然，可能有的同学如果使用的组件版本跟我的不一样，可能就不会出现我描述的这些情况，那就最好了。

但同时也说明，当前 Dinky 提供的这种jar包依赖的方式，肯定是存在问题的，如果后续开发要对接的组件越来越多，引入的jar包也自然会越来越多，那么jar包之间冲突的情况就一定会发生，目前来看，Dinky 好像没有提供这种很好的「隔离」机制，以及能解决冲突的办法。

最后

这次虽然解决了 Dinky 的 yarn 集群配置问题，也验证了通过 Dinky 提交 Flink SQL 任务以 yarn session 方式运行的可行性。

但是，在面对一个依赖稍微多一点的流式任务(Kafka + flink + Doris)时，在解决其 jar 包依赖问题时，就出现了一些暂时让人不解，或者摸不着头脑的问题。

要知道，对比之下，相同的依赖，在 IDEA 环境里是非常顺畅的，但是移植到 Dinky 中就出现了各种妖魔鬼怪，让人很难受，让已经习惯了 IEDA 开发的我着实不适应。

当然，也有些同学可能没有碰到我以上描述的那些问题，并习惯了用 Dinky 来做开发，觉得它很好用，只能说每个人的开发习惯不一样，这里不予评价。

最后，还是希望新版本能尽快 release，并能优化以上提到的问题。