Flink的DAG可视化开发实践

1. 引言

笔者早年间有很长一段时间都在阿里云DataWorks上带着团队进行数据开发，后来因为一个契机自己搞起了大数据平台XSailboat。刚开始开发平台的主要的数据开发能力是基于DAG图的可视化离线分析开发和运维。后来手头有一个项目需要使用流式计算功能，所以就想把Flink也引入到XSailboat。

引入进来以后，它应该至少起以下作用：

1. 降低Flink计算任务开发的门槛。因为现在小公司做服务型项目，波动性比较大、利润也不高，人员变动大，如果不降低门槛，让新人很快能够入手做一些开发，那么项目是很难做的。
2. 提升开发的便捷性。做服务型项目基本都是客场作战，要在用户的环境和网络条件下开展工作，再加上安全限制要求，如果没有一个平台支撑，单纯在IDE中写代码开发，是做不到的。
3. 提升开发的规范性，尽力避免事故。
4. 降低维护和部署的劳动强度。
5. 提升实时计算任务的可靠性和可用性。

首先确立了以下2个主要目标：
a. 像离线分析一样，支持基于DAG的可视化开发；
b. 在平台里应该有开发和生产两套环境；

平台要支持Flink基于DAG可视化开发，不像离线分析，有阿里云DataWorks的样板可以参考。DataWorks当时在实时计算这一块也仅支持实时同步。所以这件工作刚开始完全是一个摸着石头过河，心里没底的事情，只能怀着一定有一条路的信念摸索着干下去。经过将近大半年在实际项目中的实践探索，已经找到了一条可行之路，并且已经相对成熟，正在不断完善辅助支撑功能。

2. 我们的做法

离线分析之所以适合用DAG进行开发，是因为它的主要逻辑表达语言工具是SQL，再辅以循环、分支、归并等结构，更复杂的情况可以用MR和Python节点解决，这样几乎能完全适应所有离线分析的场景。而Flink虽然支持FlinkQL，但是它在实际工作场景下的适用性太弱了，关键的原因就在于离线分析是属于统计，而流式计算式是计算。SQL擅长统计，但并不适合计算（离线分析中复杂点的计算也基本用UDF来做）。

Flink之所以难以用DAG可视化开发，关键的问题就是它的算子只定义了基本特性，内部的逻辑完全自由。这种自由定义，对纯代码开发来说是可以的且强大的，但却对可视化开发不友好。如果可视化仅仅是拖出一个节点来，然后在里面用Java/Scala实现特定的方法，那这就不是可视化开发了，而是另一种Flink专用IDE了。

可视化开发的核心思想是配置驱动。通过界面配置逻辑，引擎执行逻辑，实现预期的行为。而配置是需要抽象出一套模式框架，在它的约束下，把一个个可调节的点变成界面配置项。

对于计算而言，少不了加减乘除计算和条件等的判定，要实现这种能力，是无法单纯通过界面来引导配置的。在离线分析中有SQL，在这里也同样需要一种语言，一种简单、又适合计算的语言。我选择了表达式语言Aviator。

在离线分析中，从一个节点到另一个节点，其实是一张表到另外一张表，而在流式计算中，我们可以把它视为一行或多行数据变成另外一行或多行数据。基于这个思想，我设定了如下的模式框架。大多数的节点都遵循如下的逻辑模式，部分算子结合其特性及通常的使用方式，略有调整。

如此我们就能通过DAG图构建出计算管道，配置各个节点。

在算子上增加这种模式限制，会牺牲算子的一部分表达能力，但这种牺牲我觉得是值得的。一旦能够使用DAG图进行可视化开发以后，很多辅助的设施都能因此构建上。例如：
a. 开发环境和生产环境分离。在开发环境开发的计算管道，经过提交发布，在生产环境部署。
b. Flink集群的自动化、多集群部署能力。目前我们的Flink是基于Yarn运行的，在开发环境，点击运行，那么首先会检查有没有这个工作空间的开发用的Flink集群，如果没有会自动启动部署一个Flink集群，然后把计算管道部署进去执行。生产环境也一样，计算管道在生产环境，可以按需部署在多个集群里面形成多个计算管道实例，由参数可以控制它们处理不同的源。这个具体做法，笔者后续将用另一篇文档详细描述。
c. 调试日志支持，对于已部署的任务可以开启/关闭调试日志，使用平台提供的界面查看某个节点的日志。
d. 状态数据查看支持。
e. 生产环境多集群自动化部署的能力，使得我们的计算管道可以实现中心/边缘部署的能力。