干货丨时序数据库DolphinDB做业管理概述

做业（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之因此不采用计算存储分离，主要有如下几个缘由：

1. 计算与存储分离会出现数据冗余。考虑存储与计算分离的Spark+Hive架构，Spark应用程序之间是不共享存储的。若N个Spark应用程序从Hive读取某个表T的数据，那么首先T要加载到N个Spark应用程序的内存中，存在N份，这将形成机器内存的的浪费。在多用户场景下，好比一份tick数据可能会被多个分析人员共享访问，若是采起Spark那种模式，将会提升IT成本。
2. 拷贝带来的延迟问题。虽说如今数据中心逐渐配备了RDMA，NVMe等新硬件，网络延迟和吞吐已经大大提升。可是这主要仍是在数据中心，DolphinDB系统的部署环境可能没有这么好的网络环境以及硬件设施，数据在网络之间的传输会成为严重的性能瓶颈。

综上这些缘由，DolphinDB采起了计算与存储耦合的架构。具体来讲：

1. 对于内存浪费的问题，DolphinDB的解决方案是Job（对应Spark应用程序）之间共享数据。在数据通过分区存储到DolphinDB的DFS中以后，每一个分区的副本都会有本身所属的节点，在一个节点上的分区副本将会在内存中只存在一份。当多个Job的子任务都涉及到同一个分区副本时，该分区副本在内存中能够被共享地读取，减小了内存的浪费。
2. 对于拷贝带来的延迟问题，DolphinDB的解决方案是将计算发送到数据所在的节点上。一个Job根据DFS的分区信息会被分解成多个子任务，发送到分区所在的节点上执行。由于发送计算到数据所在的节点上至关于只是发送一段代码，网络开销大大减小。