Summoner 是国玺部门推出的基于 MySQL+Redis+Zookeeper 的分布式并行计算调度和管理系统,李红红主设。
大家都可能做过 基于 MySQL 数据库的,大规模的、有步骤的、步骤与步骤之间有依赖关系的数据计算 。你可能定义了一堆彼此依赖的定时任务,也可能写成一个大进程跑。
举一个实际场景吧,在我们 O2O 业务体系下,我要做人员规模三四千人、有多条业务线、组织结构为大区-区域-城市-销售组的销售团队的昨日佣金和当月佣金,这里的挑战是:
那么,以前可能会定义一些定时任务,每天凌晨从各个业务数据库(毕竟全都拆库分表了)里抽取:
既有全量数据,也有增量数据,所以数据量是很大的。
先算签约数、开店数、交易量等,再把业绩归结在 BD 身上,根据不同业务线的佣金计算公式依次对 BD、BD主管、城市经理等展开各种计算。
虽然我们的 JobCenter 是很优秀的定时任务调度和管理平台, 但它没有步骤(即定时任务之间的依赖关系)的概念 ,所以以前我们只好拍脑袋定 Job1 凌晨1点执行,Job2 凌晨2点执行,Job3和Job4放在3点执行,显然这只是无奈之举, 万一 Job1 跑到凌晨3点才算完怎么办?万一 Job1 执行失败了怎么办?
什么是步骤?我们可以用下图来理解一个大计算任务下步骤之间的依赖关系:
图1
为了应对这种数据量很大的抽取和一环套一环的计算,我们需要 另行发展一个界面友好的、有步骤概念的、有集群调度的数据计算系统 ,以充分利用机器资源。
0x01,他山之玉:azkaban2/oozie/mesos
计算资源的调度,好学生有不少,如针对 hadoop 集群调度和管理的 azkaban2 和 oozie,抽象能力更高的分布式资源管理框架 apache mesos。
项目开始之初,我希望借鉴 oozie 和 azkaban2 的一些优秀设计思路,我们其实也是做调度和管理,只不过它们基于 hadoop,我们基于 mysql 而已。