面向大数据的分布式调度
|
字段级别的回溯，主要依赖2+1的方式完成，前面的2是指血缘关系+可更新目标引擎;通过开放式SQL可以梳理出数据的血缘关系，便于分析出整个链条中可以上下游依赖的点和并发的点。另外的1是指在调度的图形化界面中，可以针对一个具体实例化的Job选择需要回溯的transformer或者某些算子。 同样，根据上图4中的流程，我们走一个具体的实例。图中标识的黑色0/6代表的是开放式SQL中黑盒的部分，这部分对数据来说无法解释的生产过程;三个标识图形2代表的是Check算子，其他圆角方形颜色相同代表有上下游血缘关系依赖，例如7会依赖上游的1。下面我们了解下几个场景的回溯： 1)回溯1：在这种情况下算子1/2/3/4/6会被进行回溯，而算子0和5则不会被执行到，同样因为1后面有紧邻的check算子2，则1执行完，算子7不会马上被并发执行，因为有一个黑色的算子6。但是在算子2执行成功之后，如果能暴露出算子6的依赖和产出关系，算子7就可以被执行，不需要等待算子3/4/6的执行完成。所以节约了一定的时间。其他场景也是类似 2)回溯Transformer2，这种场景算子7和算子9会同时触发执行，同样，如果算子9在完成的情况下，下游transformer3中的11不会被执行，因为是非首节点，但是在算子7执行完成之后，算子13和算子10都会被同时调起。 可更新目标引擎是指非SQL On Hadoop的文件解决方案，类似GreenPlum、Hbase、ES都是可以被实时更新。这里不详细展开。 3.7 信号灯 信号灯在大数据分布式调度中作为一个消息中间件，主要作用是生产者(Producer)在数据生产结束、数据质量核验通过等过程对外释放信号，这里面包含具体的库表、字段和本批次的数据范围等信息，消费者(Consumer)可以根据需要监听不同的表主题，来完成后续的操作。通过信号灯的方式，可以很好的对数据下游依赖解耦合，同时信号灯也可以被应用在数据集市中库表、字段的数据完成情况标识，可以让用户进行查看，免去了数据是否可用，是否交付的交互。 总结 大数据分布式调度的应用场景和ETL的定义过程、数据引擎和业务场景的需求有着至关重要的关联，分布式调度的过程是通过场景化驱动逐步完善的过程，百度外卖大数据的调度V2.0是满足了通用的调度之后，发现存在的数据解释和细粒度更新延迟等问题之后，开启了逐步迭代完善过程，后期也期待我们的系统开源的一天。 （编辑：核心网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
