我们想把业务处理做成插件，然后每个job的main都是一个，通过动态load业务自定义jar，但flink这种结构做起来很麻烦，我不得不写了个重新打包的功能，你们blink是怎么实现这个功能的？

我们一般都直接用SQL来描述业务逻辑。个性化一些的需求就用SQL里的udf，udtf，udaf这样的机制去满足

问：你们不是每个job用一个main来启动么？ 我感觉赤兔应该不是你说的仅仅用sql+udf那么简单啊，那个拖拽是不是table一层层套啊？

答： 我们确实都是用SQL的，你说的赤兔我不是特别了解

问：但是一个JOB能执行的SQL应该是有限的吧，比如我100个业务SQL，还是跑一个JOB里面吗？

答：看什么样的SQL，如果一大堆都在用with去定义cte，那写了一坨可能也就一个job。如果都是各种select加insert，我们现在是让用户人肉的切分一下先

问：明白。我还想问下，用flink sql的方式完成业务处理，在贵公司的应用范围是怎么样的？大概是多大的比例？还有什么场景适合sql处理，什么时候适合代码 ，有木有推荐？

答：几乎所有都可以搞定，甚至机器学习的场景，极个别才用代码

问： 那这样的话就会回到一个问题，如果特别复杂的业务逻辑，会不会维护一大堆的sql，那么程序的可读性，可维护性会降低？这个请问是怎么理解的

答：一般两种可能。第第一种是业务逻辑复杂在udx里，SQL的主体并不复杂，这种就看你平时自己如何维护代码了。第二种可能是SQL本身写的很复杂，那这个只能靠自己想办法精简啊提高可读性啊之类的了。如果不是复杂的ETL处理，很有可能是第一种情况

问： 腻害。对于你说的第二种情况，有木有可能，可以类似于sql，复杂业务逻辑 用中间表生成结果表数据

答：完全可以啊，有hive类似系统维护经验的人这方面套路应该很多

问题分支：

答：几乎所有都可以搞定，甚至机器学习的场景，极个别才用代码
问：比如全是group by 和 insert，我可以指定前50个跑job1，后50个跑job2吗，还是说这些都不需要关心
答：如果是100个互相独立的语句，建议还是各自单独跑，减小互相干扰的可能性
问：其中一些应该是可以结合在一起跑的，比如同一个source我可以放在一起group by，就是不太清楚执行SQL和JOB之间的关系是怎么样的，全是编译器自己优化的吗。
答：几个SQL编译成一个job是由用户决定的，比如我们拿到的就是一个SQL文本文件，里面可能有一句也可能多句SQL，我们会编译成一个job