Home

1. 为什么要有任务依赖？ 大数据的离线场景中，任务每次执行更新一个新的 Hive 分区，分区基本都是时间相关的，比如天、小时分区。 写入 ODS 表新分区的任务执行完成后，接着执行写入 DWD 表新分区的任务，因此任务之间是有严格的依赖关系的。因为 ODS 是 DWD 的输入，如果任务启动时间过早，DWD 任务就会读不到或者读到一个空分区导致任务失败/数据错误。 所以任务依赖是任务调度系统中非常重要的一环。 扩展任务类型，诸如 ShellTask、FlinkTask、SQLTask 等好比是兵器，多多益善，但是可以按需添加，积少成多。任务依赖、调度及时性则是基本功，一旦依赖计算不准确、调度不及时，就等于自废武功了。 2. 触发/轮询/Crontab 我们是否可以只基于任务...

接上一篇笔记，这里总计下普通任务在 master 的处理过程。 DolphinScheduler 里的任务类型，按照逻辑可以分为两种： 普通任务：具体执行的任务，例如 Shell、SQL、Flink 等，相当于编程语言里的函数、计算 条件分支：用于判断下一个任务是否执行，例如 Dependent、Conditions、Switch 等，相当于编程语言里的 while/for/if 对于普通任务，master 打包发送到 worker 执行；对于逻辑分支，master 交给自身执行。 显然这两种类型的任务处理过程是不同的：前者分发到 worker，需要考虑负载均衡、字段协议、网络延迟等；后者在 master 执行，需要考虑线程隔离、CPU占用。 同时两者又都有相同点：...

如果要设计一套 Master-Worker 架构的任务调度系统，Master 的复杂度无疑更高一些。因为 Master 相当于系统的“大脑”，从宏观上管理着任务调度的准确性和稳定性。其中核心又在于需要准确的管理工作流的状态以及调度下一步的行为。 在了解 DolphinScheduler 的实现之前，我们不妨先思考几个任务调度的问题： 分布式的常见问题，例如如何避免同一个任务被不同 Master 实例分别启动？或者都没有启动任务？ 工作流实例是由多个任务实例的 DAG 组成，先启动哪个？什么时候启动下一个？ 任务应该发送到哪个 Worker 执行？发送 Worker 超时或者失败怎么处理，重试还是发送到其他 Worker？ Worker 需要分组么？有什么好处？ ...

1. 任务状态 任务调度系统里，任务状态管理对准确性和可靠性至关重要。 准确性无需多言，例如工作流实例应该在何时初始化、DAG的算子应当是 WAIT(上游算子尚未完成) 还是 RUNNING(上游全部算子完成) 状态、工作流实例是否可以更新为 SUCCESS 状态。 可靠性主要是针对各种异常状态的管理：例如任务的容错、任务的重试。 在 Apache DolphinScheduler 的具体实现里，对于任务状态有明确的枚举值，状态之间的转换遵循固定规则。代码里也有类似 Trigger/Event/Action 等的概念，因此按照状态机的模型去阅读事半功倍。 2. DolphinScheduler里的任务状态 理论上，任务的状态有提交、运行、成功、失败等。 实际状态...

1. 日志的作用 对架构RD而言，对模块的了解不应当仅仅局限于正常流程本身，而是能够分析各种异常场景，提前添加对应的日志和Metrics等信息。例如日志的格式、位置，日志级别能否Change on-the-fly等，目的是能够通过日志分析流量、追查问题。 日志有两种： write-ahead logging，例如leveldb笔记之2:日志 diagnostic logs，例如glog源码解析一：整体结构 这篇笔记想要谈的是第2种。 任务调度系统除了模块自身的日志，还需要打印不同任务的日志，日志互不影响。 举个例子，ds-worker 模块日志有两个appender: WORKERLOGFILE、TASKLOGFILE. WORKERLOGFILE 负责输...

Master、Worker是DolphinScheduler最重要的两个模块，Master负责任务的调度，Worker负责任务的执行。 DolphinScheduler 官网的这张图概括了整体的流程： 注：图片基于V1.3.0，跟当前略有出入 1. 线程模型 任务提交过程中，使用到了众多线程，其中最重要的单线程、线程池，如图所示： DolphinScheduler 的线程模型总的来说： 串联了多个生产者-消费者，队列使用内存队列 线程定义了独立的名字区分 Master-Worker 之间通过 Netty 通信 2. Master线程模型 定时调度的处理入口类是class MasterSchedulerBootstrap extends BaseDaemo...