git仓库地址 https://github.com/deepmodeling/dpdispatcher
dpdispatcher目前(20210622)进展
总体
dpdispatcher总体接近looks good。
已经可以被其他软件/开发者集成使用。
后续dpdispatcher软件和文档都会持续维护，更新。
接口基本稳定,之后的更新如无意外，接口应该是兼容的。
（此处”接口”是指会被用户直接import的类，它们的构造函数和”public方法”的名称和参数列表。）
开发
功能
提供了一套抽象，能够定义计算作业，单个计算任务，计算资源，计算批处理系统。
实现了一个状态机，负责完成计算作业从生成，提交，运行，回收的整个生命周期的记录和管理。
实现了简单的恢复续算功能。
实现了对不同作业调度系统(slrum, pbs, lsf, dpcloudserver, 本地shell)的支持。
测试
单元测试：Submission，Resources，Job, Task等类的重要的方法已经有单元测试。
集成测试较少。有一个用本地shell交任务的集成测试。难点在需要对状态机进行测试，暂不清楚实现的技术路径。
文档
主要类有注释，dargs生成的文档，使用案例，样例json等。
使用
集成软件：
目前已经被dpgen dpti rid-kit集成了。
帮助rid-kit在阿里ehpc 2080Ti的slurm集群上顺利跑完30万+任务,计算水的自由能面等。
帮助dpti完成Sn相图的相关计算，和支援松山湖小伙伴金属Zr的相关计算。
使用集群：
一般被应用软件集成和使用，有时也会单独使用。目前在阿里ehpc（pbs和slurm），普林斯顿，北大, Rugster（晋哲组），温翰组的slurm集群。刘云霈所在的LSF集群，一些单节点GPU（包括单卡多卡机器，以及某些docker或者k8s集群提供，），dp-lebesgue-dpgen上都有使用(Lebesgue提供(高性能)计算批处理作业服务,并集成了dpgen软件，对外提供服务， api文档地址)。
可用性：
断点恢复：
目前实现了任务续算和恢复。
目前使用json记录任务状态，Ctrl+C方式中断dpdispatcher进程，dpdispatcher会在退出前尝试保存任务状态，下次运行时自动恢复。但kill -9 方式终止进程会导致不能恢复。
最大机器数：
目前晋哲尝试了同时提交6000个Task，预估单dpdispatcher进程维护几百个Job（几百台机器）是没问题的。切换后端数据库之后能变得更多。
需求：
切换后端数据库
目前希望切换到SQLite数据库上去。
需要在dpdispatcher运行过程中记录Job状态。
需要记录的内容：task的内容，resources的内容，submission的内容，查询作业调度系统得到的job_id，目前任务状态，失败计数等信息。
目前是用json记录以上内容。
但目前这种方式遇到了以下瓶颈：
- 难以实现更新的原子性。每次更新任务状态需要更新整个json文件。单个文件大小在6000个task时约有3.6MB，ssh传输整个文件耗时。并且传输数据过程可能中断，造成json文件损坏，无法恢复和续算。
所以就考虑使用单文件数据库SQLite
同时希望提供工具对现有运行任务的查询和操作。
比如能处理用户用 dispatcher 错误地交了一大波任务，想终止这些任务的情况。
需要讨论的内容：
如何实现记录状态的后端数据库：
dpdispatcher代码实现：
可能方式1：不新增抽象层，直接改操作json成操作sqlite数据库。优势:较为简单直接。
可能方式2:再加一层抽象。把目前读写json的操作，抽象成”数据持久化”。 希望有多种database，用json还是database由用户选择。
- 给目前现有的需要保存状态的类，新增个数据持久化方法方法。
- 新增个”数据库上下文”， json，SQLite database等类成为DatabaseContext这个基类的子类。
code example:
class Submission(object):# other method ...def save_to_database(self, database_context):save_return = database_context.save_submission(self)return save_return
数据库的设计
database
一个Submission对应一个SQLite文件？还是一个unix用户一个（方便之后可能的加守护进程和统一查询）？
table设计
传统关系型数据库，还是json-based(SQL or NoSQL)。
需要几张表，里面的字段，是否外键等。
加一个守护进程？
目前的情况是，如果一台机器上，某个unix用户下，同时有多个进程都在跑使用dpdispatcher的应用。比方说同时跑10个dpgen应用，那么此时就会有10个dpdispatcher在轮询作业调度系统。 当轮询的进程变多时，可能会对作业调度系统造成压力。
此时就希望加一个守护进程，负责统一的查询。
是希望dpdispatcher向服务化/微服务化发展？ 成为一个能被工作流软件集成的服务，能够单独部署，通过http/RPC交换信息，而不是目前以一个python包和几个类的方式被集成？
invlove外部力量？
设计数据库，设计表，开发高性能高可用的基于SQL数据库应用，是”互联网后端开发”有优势的领域。或许可以involve进一些计算机背景的小伙伴？
开发dpdispatcher需要一部分超算，作业调度系统的“系统管理员”知识。
这部分内容已经和操作数据库的部分基本解耦了。
推广使用？
进行更多宣传？看dpdispatcher是否能解决开发者痛点？
目前dpdispatcher更像是一个开发者工具，为计算作业到”计算作业批处理系统”这一过程，提供一到多的能力。
开发者们是否借助dpdispatcher来开发工作流软件，很依赖于开发者是否希望自己的软件拥有这个一对多的能力。 以及是否想要借助dpdispatcher自动完成提交任务到回收这一流程。
某种真正的智能（自动）派发机制？
需求：多个机器存在时，自动选择空余机器/价格最小机器。
可以让别的层次解决？比如让dpcloudserver解决？
允许用户自定义提交脚本的header（模板替代）？
目前的实现是支持实现这一需求的。
用户是在什么场景下，需要用到这一feature的？
sqlite 数据库
我们目前使用dpdispatcher的应用软件，一般是利用文件系统(dpgen)或者借助工作流框架(dpti-airflow)来记录流程的。dpdispatcher为了实现恢复重试等功能，会在出现意外状况时，把自身信息保存在一个json文件中。
这些json文件，会连同一次Submission的结束而删除。
但张与之开发时应用软件时，希望历史提交信息也能被追溯和查询。也就是本来跑完即删的json文件，里面所含的作业信息，现在希望保存在一个sqlite数据库中，以供后续查询。
[
若有收获，就点个赞吧
0 人点赞
