序
工作中用Flink做批量和流式处理有段时间了，感觉只看文档或论坛是没有办法很好的debug或者优化。其实我也没怎么仔细研究过文档和论坛，只是感觉，效果不会很好， 程序员还是看代码最简单，直接。
举个例子，我们在Flink-SQL基础上构建了一个SQL Engine， 使懂SQL非技术人员能够使用SQL代替程序员直接实现Application， 然后在此基础上在加上一些拖拽的界面，是不懂SQL非技术人员 利用拖拽实现Application . 公司的数据源非常庞大，发布渠道也很丰富， 我们在SQL Engine 里实现了各种各样的Table Source （数据源） , Table Sink （数据发布）和 UDF （计算器）, 用户真的可以简简单单，托托拽拽的操作大数据，建立计算模型，以及发布和上线了。
可是后台并非这么简单， 数据倾斜的经常发生的事情。比如一个大数据源和一个小数据源做Inner Join, 如果大数据源的数据项很大部分（比如50%）都使用极少数的几个join key , Flink optimizer 会把SQL join 优化成Hash Join, 最后的结果是无论你实现分配了多少个TaskSlots, 50%的数据都跑到某一个TaskSlot里，缓慢运行直至将个这Slot的资源耗尽。这种情况最好是将小数据集合广播给所有的slot, 大数据集按原始的分片并行。然而标准SQL里没有办法指定joinhint , Flink sql也不支持这个，只能通过debug flink 来看看哪里能做一些改变解决这个问题。我们在最后一章，从Flink client , flink optimizer, flink run-time (job manager, task manager) 一步一步的 在源码里设置断点， debug, 将数据流过一遍，看看有哪些方案可以将这个小数据集合广播起来。
为了使本文读起来流畅一些， 我先通过几个章节大概介绍一下Flink 。