Tip - Airflow DAG多少的思考

在做ETL任务时候，使用Airflow作为数据任务调度框架，就遇到了很多任务下，如何组织DAG的问题。

一个任务一个DAG

最开始做的方式就是一个任务一个DAG。比如要制作一个每日数量类统计，编写逻辑就是从ods取数，生成一个新表，存进去数据。那么一个DAG组织起来实现逻辑的SQL就够了，这时候就是一个任务一个DAG。

但是这样做的问题还是有的，比如我要做DW层，要对ods进行汇总得到多个DW层数据，然后我要制作报表，用到了 dw1,dw2.. ， 由于需要明确的先后顺序，其他人做法依然是多个DAG，设置不同的调用时间来实现。这显然不够精确。

多个任务集成进一个DAG

于是要充分发挥DAG的功能，DAG的设计就是任务可以有依赖关系，那么ETL过程就是很适合的场景。于是我就把多个DAG改造成一个DAG，因为他们有关联关系。后来我发现，其实只用一个DAG就够了，一个DAG启动，首先面对多个ods表的检查， 分裂成多组不同业务方向的操作，每组各自执行内部逻辑，无需存在多个DAG，任务之间的关系也清晰明了，所以我就把我的任务改造成了一个。但是这样也有弊端。

弊端就是，当新增采集表或者新增任务，历史回溯比较困难，因为会因此使得已经跑过的其他任务也跟着重跑。这并不是很大的事，但是当任务很多时候，原本只是为了新增的任务重跑，造成所有任务跟着重跑，性能急剧下降，耗时越来越多，而且，不同的业务类型都在一个DAG，只会越来越臃肿不利于模块化维护，所以要继续改造。

分类DAG

进行到分类DAG阶段。分类DAG是这样的一个想法， 对于一个业务类型的任务，放在一个DAG里，因为他们关联性最大。其他关联小的业务类型任务，新开DAG，这样他们之间互不影响，发挥足够的性能，也能使得任务关系清晰明了。

然后DAG内部，进行分组管理。一组只做一类事情，这样设计的DAG，不会像第一种一个任务一个DAG造成的那么多重复代码， 也不会像只一个DAG的结构复杂，相当于代码模块化， 一个模块一个DAG，这样管理起来就舒服多了。而且内部也是根据功能划分不同的组，更是结构清晰。

如下：

image-20221215111827110