Flink的DAG可视化开发实践_数据开发工具 dag(1)，2024年最新只有搞大数据开发开发的才知道

先自我介绍一下，小编浙江大学毕业，去过华为、字节跳动等大厂，目前阿里P7

深知大多数程序员，想要提升技能，往往是自己摸索成长，但自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年最新大数据全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友。

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上大数据知识点，真正体系化！

由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新

如果你需要这些资料，可以添加V获取：vip204888 （备注大数据）

正文

笔者早年间有很长一段时间都在阿里云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。

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

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化的资料的朋友，可以添加V获取：vip204888 （备注大数据）

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！

鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！**