海豚调度数仓任务管理规范

本文主要是介绍海豚调度数仓任务管理规范，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

一、DolphinScheduler调度数仓任务现状分析

2.1 一个任务流构建数仓所有的逻辑节点

2.2 每个逻辑节点构建一个任务流

二、数仓任务管理调度需求分析

三、DolphinScheduler数仓开发任务管理规范

四、结语

前言：大数据领域对多种任务都有调度需求，以离线数仓的任务应用最多，许多团队在调研开源产品后，选择DolphinScheduler作为调度场景的技术选型。得益于DS优秀的特性，在对数仓任务做运维和管理的时候，往往比较随意，或将所有任务节点写到一个工作流里，或将每个逻辑节点单独定义一个工作流，缺少与数仓建模对应的任务管理规范；这造成了数据管理困难和异常容错繁琐等痛点，本文基于数仓建模标准的方法论，构建一套用于DS管理数仓任务的规范，避免以上痛点。

一、DolphinScheduler调度数仓任务现状分析

在使用DS做数仓任务管理时，数据建模分层落地到调度上缺少规范，社区用户用起来比较乱，一些常见的场景如下：

2.1 一个任务流构建数仓所有的逻辑节点

DolphinScheduler里有任务血缘的概念，这个概念和数据血缘有许多类似的地方；在构建调度任务的时候，用户容易将任务血缘和数据血缘混淆，希望在构建数仓生命周期的时候，通过任务血缘呈现出数据血缘的关系，这导致丢失了数据建模规范的分层管理。

类似例子如下：

单个工作流：

包含所有计算逻辑：

优点：这样做的好处是可以在一个工作流里直观的复现数据建模；

缺点：对于数据管理困难，只能人为的观察定位数据情况；

任务运行异常后，容错困难，要排查所有逻辑节点，并将计算逻辑回滚，这是特别繁琐的过程；

2.2 每个逻辑节点构建一个任务流

除了将整个数仓的逻辑包装到一个工作流，还有另外一种方式：将每个逻辑节点包装成一个工作流；这种能很好的将计算逻辑解耦，任务运行异常的时候逻辑回归也清晰简单；但是依旧没有做到合理的数仓建模分层管理，且操作繁琐，面对超大量任务时，创建工作流将成为一种负担。

类似例子如下：

优点：优秀的异常容错，任务出现异常计算的时候，前后任务逻辑就能异常回滚重跑；

缺点：任务流创建繁琐，且没有做好数仓规范的数据分层管理。

二、数仓任务管理调度需求分析

从数仓的视角，任务调度核心需求是：任务类型、依赖关系、定时调度、任务优先级，以及数仓分层管理，层级依赖（调度系统的视角，还有高可用、告警、资源管理、用户安全、易用性、可扩展等能力）。

任务类型、依赖关系、定时调度、任务优先级是系统提供的能力，数仓分层管理和层级依赖是调度能力之上的任务管理规范。这里参考数据建模规范构建与之对应的任务管理规范。

数据建模架构如下：

数据建模分析与数仓维度建模规范-CSDN博客

数据建模到数仓开发过程中需要关注4点：

逻辑开发：数据需求的实现；
数据管理：各层级数据划分；
开发依赖：数据层级依赖实现；
异常容错：异常任务定位和数据复原重跑。

构建在调度系统之上的数仓任务编排规范，需要满足以上要求。

三、DolphinScheduler数仓开发任务管理规范

为了和数据建模规范保持一致，我们按照数据建模的分层理论，设计调度任务的编排规范。

从顶层设计上将工作流定义为3类：

数仓分层工作流：ODS、DIM、DW、ADS每层一个工作流； DW层可以根据业务需求，细分出三个DWD、DWM、DWS等好实现业务需求的单独任务流管理；
数仓任务Master管理工作流：将数仓分层，按照开发依赖串联到一个工作流中统一管理；
异常容错工作流：数仓运行过程中，中途出错或者结果异常，需要数据环境复原，就可以将中间表清理逻辑包装在异常容错工作流，做统一数据清理，然后再从头跑数仓任务。

数仓开发工作流规范如下：