共计 2993 个字符，预计需要花费 8 分钟才能阅读完成。
作业（Job）是 DolphinDB 中最根本的执行单位，能够简略了解为一段 DolphinDB 脚本代码在 DolphinDB 零碎中的一次执行。Job 依据阻塞与否可分成同步作业和异步作业。
同步作业
同步作业也称为交互式作业（Interactive Job），它的次要起源有：
- Web notebook
- DolphinDB GUI
- DolphinDB 命令行界面
- 通过 DolphinDB 提供的各个编程语言 API 接口
因为这种类型的作业对实时性要求较高，DolphinDB 在执行过程中会主动给予较高的优先级，使其更快地失去计算资源。
异步作业
异步作业是在 DolphinDB 后盾执行的作业，包含：
- 通过 submitJob 或 submitJobEx 函数提交的批处理作业。
- 通过 scheduleJob 函数提交的定时作业。
- Streaming 作业。
这类工作个别对后果的实时反馈要求较低，且须要长期执行，DolphinDB 个别会给予较低的优先级。
子工作
在 DolphinDB 中，若数据表数据量过大，个别都须要进行分区解决。如果一个 Job A 里含有分区表的查问计算工作（如 SQL 查问），将会分解成多个子工作并送到不同的节点上并行执行，期待子工作执行结束之后，再合并后果，持续 Job A 的执行。相似的，DolphinDB 的分布式计算也会产生子工作。因而，Job 也能够了解成一系列的子工作。
Worker 与 Executor
DolphinDB 是一个 P2P 架构的零碎，即每一个 Data Node 的角色都是雷同的，它们都能够执行来自用户提交的 Job，而因为一个 Job 可能产生子工作，每个 Data Node 须要有负责 Job 外部执行的调度者，咱们称它为 Worker，它负责解决用户提交的 Job，简略计算工作的执行，并执行 Job 的工作合成，工作散发，并会集最终的执行后果。Job 中合成进去的子工作将会被散发到集群中的 Data Node 上（也有可能是本地 Data Node），并由 Data Node 上的 Worker 或 Executor 线程负责执行。
具体 Worker 与 executor 在执行 job 的时候次要有以下几种状况：
- 当一个表没有进行分区，对其查问的 Job 将会有 Worker 线程执行掉。
- 当一个表被分区寄存在单机上时候，对其的查问 Job 可能会分解成多个子工作，并由该节点上的多个 Executor 线程执行，达到并行计算的成果。
- 当一个表被分区存储在 DFS 时，对其查问的 Job 可能会被分解成多个子工作，这些子工作会被分发给其余 Node 的 Worker 上执行，达到分布式计算的成果。
为了最大化性能，DolphinDB 会将子工作发送到数据所在的 Data Node 上执行，以缩小网络传输开销。比方：
- 对于存储在 DFS 中的分区表，Worker 将会依据分区模式以及分区以后所在 Data Node 来进行工作合成与散发。
- 对于分布式计算，Worker 将会依据数据源信息，发送子工作到相应的数据源 Data Node 执行。
Job 调度
Job 优先级
在 DolphinDB 中，Job 是依照优先级进行调度的，优先级的取值范畴为 0 -9，取值越高优先级则越高。对于优先级高的 Job，零碎会更及时地给与计算资源。每个 Job 个别默认会有一个 default priority，取值为 4，而后依据 Job 的类型又会有所调整。
Job 调度策略
基于 Job 的优先级，DolphinDB 设计了多级反馈队列来调度 Job 的执行。具体来说，系统维护了 10 个队列，别离对应 10 个优先级，零碎总是调配线程资源给高优先级的 Job，对于处于雷同优先级的 Job，零碎会以 round robin 的形式调配线程资源给 Job；当一个优先级队列为空的时候，才会解决低优先级的队列中的 Job。
Job 并行度
因为一个 Job 可能会分成多个并行子工作，DolphinDB 的 Job 还领有一个并行度 parallelism，示意在一个 Data Node 上，将会最多同时用多少个线程来执行 Job 产生的并行任务，默认取值为 2，能够认为是一种工夫片单位。举个例子，若一个 Job 的并行度为 2，Job 产生了 100 个并行子工作，那么 Job 被调度的时候零碎只会调配 2 个线程用于子工作的计算，因而须要 50 轮调度能力实现整个 Job 的执行。
Job 优先级的动态变化
为了避免处于低优先级的 Job 被长时间饥饿，DolphinDB 会适当升高 Job 的优先级。具体的做法是，当一个 job 的工夫片被执行结束后，如果存在比其低优先级的 Job，那么将会主动升高一级优先级。当优先级达到最低点后，又回到初始的优先级。因而低优先级的工作迟早会被调度到，解决了饥饿问题。
设置 Job 的优先级
DolphinDB 的 Job 的优先级能够通过以下形式来设置：
- 对于 console、web notebook 以及 API 提交上来的都属于 interactive job，其优先级取值为 min(4，一个可调节的用户最高优先级)，因而能够通过扭转用户本身的优先级值来调整。
- 对于通过 submitJob 提交上的 batch job，零碎会给与 default priority，即为 4。用户也能够应用 submitJobEx 函数来指定优先级。
- 定时工作的优先级无奈扭转，默认为 4。
计算容错
DolphinDB database 的分布式计算含有肯定的容错性，次要得益于分区正本冗余存储。当一个子工作被发送到一个分区正本节点上之后，若节点呈现故障或者分区正本产生了数据校验谬误 (正本损坏），Job Scheduler(即某个 Data Node 的一个 worke 线程) 将会发现这个故障，并且抉择该分区的另一个正本节点，从新执行子工作。用户能够通过设置 dfsReplicationFactor 参数来调整这种冗余度。
计算与存储耦合以及作业之间的数据共享
DolphinDB 的计算是尽量凑近存储的。DolphinDB 之所以不采纳计算存储拆散，次要有以下几个起因：
- 计算与存储拆散会呈现数据冗余。思考存储与计算拆散的 Spark+Hive 架构，Spark 应用程序之间是不共享存储的。若 N 个 Spark 应用程序从 Hive 读取某个表 T 的数据，那么首先 T 要加载到 N 个 Spark 应用程序的内存中，存在 N 份，这将造成机器内存的的节约。在多用户场景下，比方一份 tick 数据可能会被多个剖析人员共享拜访，如果采取 Spark 那种模式，将会进步 IT 老本。
- 拷贝带来的提早问题。尽管说当初数据中心逐步装备了 RDMA，NVMe 等新硬件，网络提早和吞吐曾经大大提高。然而这次要还是在数据中心，DolphinDB 零碎的部署环境可能没有这么好的网络环境以及硬件设施，数据在网络之间的传输会成为重大的性能瓶颈。
综上这些起因，DolphinDB 采取了计算与存储耦合的架构。具体来说：
- 对于内存节约的问题，DolphinDB 的解决方案是 Job（对应 Spark 应用程序）之间共享数据。在数据通过分区存储到 DolphinDB 的 DFS 中之后，每个分区的正本都会有本人所属的节点，在一个节点上的分区正本将会在内存中只存在一份。当多个 Job 的子工作都波及到同一个分区正本时，该分区正本在内存中能够被共享地读取，缩小了内存的节约。
- 对于拷贝带来的提早问题，DolphinDB 的解决方案是将计算发送到数据所在的节点上。一个 Job 依据 DFS 的分区信息会被分解成多个子工作，发送到分区所在的节点上执行。因为发送计算到数据所在的节点上相当于只是发送一段代码，网络开销大大减少。
