作业(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的分区信息会被分解成多个子工作,发送到分区所在的节点上执行。因为发送计算到数据所在的节点上相当于只是发送一段代码,网络开销大大减少。