最近遇到一个坑，已经第2次出现了，本来嫌麻烦不想改，但再也不想手动去重跑任务了。
问题描述
故事是这样的，我们使用的是阿里云的MaxCompute作为离线平台，我们的数据同步机制是这样的，
同步方式
由于种种原因吧，我们的同步的数据其实是备库数据，备库的数据是业务系统从库的数据，环节一多就容易出问题，现在的问题是备库的数据不完整，这次丢失了19:00以后的数据，零点同步数据时，导致我们同步过来的数据缺失。
当然也是我们目前的数据质量做的不好，没有好好使用验证机制。
上午来了以后发现报表数据不对，排查后发现，解决就是重新同步下备库（备库只是同步延迟），就需要同步XX库下的所有ods表及其下游。坑就坑在这，由于当初依赖配置的问题，我没有办法把这些表直接找出来，并且一起刷新下游，只能一层一层刷新(ods->dwd->dws-ads)，刚才为了快，直接把整个项目刷新了。
最佳实践
这个一方面是我们当初对MaxCompute不了解，依赖配置的不太对，一开始我们是这样配置依赖的：
原依赖配置
ABC可能是属于3个库的表，但是我们都直接从一个根节点输出的，这种操作并友好，出现上面的问题，解决起来很麻烦。
应该这样做：
抽象虚拟节点
我们给每一个库都抽象一个虚拟节点处理，这样以后如果某个库出现了问题，就可以直接从该虚拟节点重刷下游了。
