分布式并行计算调度和管理系统Summoner
- 为什么要做“数据”并行计算调度？
- 他山之玉：azkaban2/oozie/mesos
- Summoner的特性
Summoner 是国玺部门推出的基于 MySQL+Redis+Zookeeper 的分布式并行计算调度和管理系统，李红红主设。
大家都可能做过 基于 MySQL 数据库的，大规模的、有步骤的、步骤与步骤之间有依赖关系的数据计算 。你可能定义了一堆彼此依赖的定时任务，也可能写成一个大进程跑。
</div>举一个实际场景吧，在我们 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 而已。