Dataphin v3.10 版本对调度依赖配置做了比较大的调整，主要的变更点有:
- 统一了 集成同步任务，计算任务和逻辑表的调度依赖交互
- 上游依赖列表调整
- 本周期依赖和上周期依赖合并到同一个列表
- 增加了依赖任务筛选
- 依赖任务列表项扩展展示更多信息，如: 调度周期，依赖周期，是否开启条件调度
- 自动解析优化，自动解析不再依赖节点输出名，而是直接使用任务与表的血缘关系，本文将着重说明。
- 弱化节点输出名，用户无需再配置输出名，也不用刻意关注。
自动解析流程
下图为 v3.10 版本自动解析的流程
新的流程与原来的旧流程的区别对比如下:
对比项 |
v3.9 及之前版本 |
v3.10 版本 |
改进点 |
解析结果 |
输入表 |
输入表 |
|
维护 输入表与产出任务关系 的系统 |
调度系统内部(节点输出名) |
资产血缘 |
1. 集成任务，SQL 计算任务，逻辑表提交发布时，系统自动根据任务的逻辑生成任务与该任务的输出表的映射关系(即 表与产出任务 血缘)，无须用户人工干预 2. shell/python/mr 等任务用户可以通过自定义血缘补充血缘数据 3. 血缘数据覆盖度和准确度比较高，原来的节点输出名覆盖度和准确度相对较低(节点输出名可以被人工干预，准确性不足) |
找不到输入表对应产出任务时的处理策略 |
直接忽略 |
列举在依赖列表中，需要用户人工处理 |
可以帮助发现没有产出任务的依赖表，避免出现依赖缺失的情况 |
资产血缘
v3.10 自动解析使用了资产血缘，这又是什么呢？
在资产目录中，打开一个表，进入表资产详情，可以在资产信息中，看到该表的产出信息，见下图。
- 当集成任务，SQL 计算任务，逻辑表提交发布时，系统会自动将当前任务节点的信息与输出表之间的关系维护到资产中。
- 对于 shell/python/mr 等非 SQL 任务，Dataphin 无法从任务代码中解析到输出表，用户可以通过自定义血缘的方式补充血缘信息，见下图。
大部分的表与任务的映射关系都是由系统自动生成和维护的，保障了数据的准确度；人工填报的自定义血缘，提高了覆盖度。
节点输出名
v3.10 的自动解析已经不依赖节点输出名，此处还是解释下节点输出名是做什么的。
在此之前，先来说明几个概念:
- Dataphin 节点就是任务，包含 集成任务，计算任务，逻辑表任务 等
- 节点名称(任务名称) ，集成任务和计算任务创建时由用户输入的用户名称，逻辑表任务名称与逻辑表名相同。由于历史原因，节点名称没有设计为全局唯一，而是在导航目录下唯一。
- 节点(任务) ID，是节点(任务)提交时，系统自动生成的全局唯一 ID。任务发布后，开发环境与生成环境的 ID 需要保持一致。但由于历史原因，这个原则在历史版本中未落实(指向不唯一)。
- 任务提交发布后，调度系统需要一个全局唯一 ID 来明确定位某一个节点(任务)，以生成调度依赖图(DAG)。
由于节点名称和节点 ID 无法确保全局唯一且指向唯一，因此引入了“节点输出名”来承担节点全局唯一 ID 的作用。
在 v3.9 及之前版本，节点输出名还承载着输出表与节点任务映射关系的作用。节点输出名称如果与某一个表的名称(格式为 {生产项目名.表名称})一致，则认为该节点产出了该表。节点输出名的生成机制:
- SQL 计算任务自动解析时，系统会自动为每一个输出表生成一个节点输出名
- 逻辑表任务的输出名就是逻辑表名
- 集成任务的输出名在早期版本需要用户人工填写，后期的版本自动解析为每一个输出表生成一个节点输出名
- shell/python/mr 等任务的节点输出名需要用户人工填写
存在以下问题:
- 系统自动生成的节点输出名可以被人工编辑修改，存在误操作风险
- 输出名的格式有严格的要求，必须是 {生产项目名.表名称}，用户人工填写时，容易错误输入
以上问题导致节点输出名的准确度和覆盖度都不如资产血缘，因此 v3.10 自动解析升级后，切换到了后者。
