本篇文章主要说明了设置调度依赖的原因，调度依赖的原理及其在DataWorks上的具体体现，同时介绍了在DataWorks上设置调度依赖的3种方式，并提出了一些常见问题和相应的解决方案

分享人：DataWorks技术支持团队

我们在开发者社区学习路线里有发布一个DataWorks的学习路线，里面包含了入门讲解和熟能生巧系列的直播内容，大家可以去学习一下，需要主账号登陆学习哦：https://developer.aliyun.com/learning/course/81

一、为什么要设置调度依赖

 

设置调度依赖是为了保证业务数据有效、适时地产出，形成规范化的数据研发场景。这里针对的是调度的场景，也就是表数据每天都有更新的情况，是为了保障每个节点在取数的时候都能取到准确的数据。

规范的依赖关系配置后，无需关心当前节点需要依赖表由哪个节点产出，通过DataWorks自动解析一键为您设置任务依赖。

 

假设某个节点B会产出表B数据，节点B任务执行成功后，平台默认数据已经准备就绪，下游依赖该表B数据的节点（表）就可以开始取数了。如下图，如果xc_rpt_user_info_d这个节点要运行，那这个节点需要正确地取到上游数据，也就是说上游的这些节点都需要先正确地执行完毕。这里有一个重要概念，就是“表之间的依赖”要转换成“产出该表的节点之间的依赖”。

DataWorks上通过节点输出来挂依赖，也就是上游节点的输出作为下游节点的输入形成依赖关系。比如节点B产出表 B数据，表 B数据依赖表 A，那么我们将产出表 A的节点A作为当前节点B的上游依赖。

二、如何设置调度依赖

 

方式一：自动解析

当前表A的数据是依赖于项目B下面的表B数据，自动解析时会将表A表作为节点输出，格式是“项目名.表名”，然后当前节点select 的表B表会作为节点的输入，也就是父节点的输出（B是A的上游）。

自动解析挂好以后可以看下依赖关系。上游节点b（父节点）产出表table_b作为父节点输出，而下游节点代码里用到了这个表，所以自动解析的时候会将table_b作为当前表a的上游（节点a的输入），通过这个输入可以找到父节点b，从而挂上依赖线。这样自动解析就能一键设置任务依赖。

为什么要推荐自动解析？

 

• 根据代码的逻辑，判断您在当前节点需要产出某张表。当您以project_name.tablename的方式将其作为本节点输出时，后续其它节点需要查询该表时，您无需关注要依赖哪个节点，您只需要关注要依赖该表当前周期产出的数据。
• 当您无法确定当前工作空间产出该表数据的具体节点时，您可以使用自动解析，帮助您快速开发业务流程。
• 使用自动解析该操作的前提是遵循自动解析规范。
• 同地域的工作空间支持自动解析依赖关系，即支持同地域跨工作空间配置节点调度依赖关系。

方式二：自定义依赖

有三种：代码编辑输入输出、手动添加上游依赖和自动推荐。

这里有个问题，如果某个表数据是本地上传的，自动解析将它解析出来了，但是提交的时候报错依赖的父节点输出不存在，这里的依赖关系又因为是自动解析出来的而不能删除，这个时候该怎么办呢？

 

第一种解决方案是直接在代码中编辑输入输出。假如ods_user_info_d这个表是本地上传的表数据，那么我们可以在代码中选中这个表，右键删除输入，随后右侧依赖的父节点就不会有表了，然后重新解析输入输出，不过这里会出现一个血缘关系不一致的提示。

为什么会有输入与代码血缘分析不匹配的提示呢？就是因为刚刚代码有删除输入输出，也就是在代码中select和insert这个表，但是节点的依赖关系没有将它作为输入或输出，通过代码的解析和配置的节点依赖不匹配。此时，我们就需要关注这张表的数据源来源，以采取不同的应对策略。

第二种方式是手动添加依赖。这里有两个场景，一个是需要依赖某个表数据，一个是需要依赖某个节点，不一定存在表血缘依赖。当需要依赖某个节点的时候，我们可以输入节点的输出，如果需要依赖某个表数据，可以直接在这个依赖的上游输入这个表名。

第三种方式是自动推荐，当对自动解析比较困惑或经常报错的时候可以选择。

拉线设置依赖关系也符合DataWorks挂依赖的原理，即上游节点的输出会作为下游节点的输入，这样形成的依赖关系。

最佳实践：这里有3点要注意

• 首先产出表数据的节点要设置该表作为该节点的输出，避免下游取这个表数据的时候，自动解析将它挂为依赖的父节点，但是通过这个表找不到产出这个表数据的节点，下一个节点用这个表的时候提交就会报错。
• 其次一张表数据由一个节点产出，保证节点输出同region下唯一。因为DataWorks通过节点输出来挂依赖，需要保证通过这个输出可以定位到唯一的节点。
• 最后建议任务名称和输出表名保持一致。

三、常见问题

因为同步任务是不支持调度依赖自动解析的，所以需要手动配置。DataWorks在节点输出时会默认添加两个输出，一个是_out，一个是节点名输出，而把节点名设置为该同步任务产出的表名，就可以避免再单独操作节点输出。

另外，出现血缘关系不正确的原因刚才也说过了，这个时候需要确认代码中用到的表是不是本地上传的，或者是周期调度产出的，要关注数据源的来源。

父节点输出不存在这个场景也经常遇到，我们首先要明确的就是依赖的父节点输出不存在并不是说这个表不存在，只是没有通过这个表找到产出这个表数据的节点，也就是没有任何一个节点的输出是这个表。

 

如果当前需要将节点提交上去不报错，有两种解决方式。一是直接将自动解析设置为否，但不推荐，因为会导致血缘关系不匹配，也会导致下游用当前节点产出表数据的时候，提交会报错。自动解析关掉后，它不会将当前界面insert的表作为节点的输出；第二是确认该表数据来源是什么，是本地上传的还是调度每天产出的。

关于节点输出相同，提交失败的情况。因为DataWorks需要保证节点输出唯一，通过这个唯一的输出定位到唯一的节点上，所以建议大家一个表数据由一个节点产出，如果有同名节点的情况，那也需要更改其中一个节点的输出。

删除节点失败，当前节点存在下游的情况。可以看到下图的这个节点没有下游依赖，但是删除的时候会报错说节点存在依赖。这个时候需要先检查一下这个节点，在配置页面看是否有下游节点依赖它，或者在运维中心搜索这个节点看有无任务，随后找到下一个节点去删除依赖关系。下游节点依赖去除干净后，这个节点才能下线。

举例演示一下，现在要删除dw_user_info_all_d这个节点，我们先把下游依赖线删除掉：

我们双击打开我们想删除的dw_user_info_all_d节点，找到下游依赖该节点的所有节点，本例中只有rtp_user_info_d，我们打开运维中心生产环境和开发环境，通过dw_user_info_all_d节点的节点ID搜索，可以发现dw_user_info_all_d节点下游依然有rtp_user_info_d节点。

 

我们回到DataWorks开发界面，双击rtp_user_info_d节点，因为提交节点需要有父节点，我们可以把rtp_user_info_d节点挂在根节点上，这样rtp_user_info_d节点不再依赖我们要删除的节点。我们提交rtp_user_info_d节点到开发环境，显示提交成功后，我们发布rtp_user_info_d节点到开发环境：

 

 

然后我们检查一下开发环境，rtp_user_info_d节点已经没有依赖我们要下线的那个任务节点了，但是生产环境还存在依赖。

 

接下来我们把更新操作发布到生产环境：

 

再到生产环境查看rtp_user_info_d节点，也已经不再依赖我们要下线的节点了：

 

 

同样，我们也可以到开发环境和生产环境看我们想删除的dw_user_info_all_d节点是否还有下游依赖。确认都没有了，就可以下线这个任务了。

 

这样我们就成功下线我们想删除的dw_user_info_all_d节点了。

以上就是本次调度依赖基本使用的全部内容了，有问题需要解答的同学可以加一下我们的钉钉大群，群里有直播回放可以观看。

感谢大家的关注！