转载

#研发解决方案#分布式并行计算调度和管理系统Summoner

  1. 为什么要做“数据”并行计算调度?
  2. 他山之玉:azkaban2/oozie/mesos
  3. Summoner的特性

Summoner 是国玺部门推出的基于 MySQL+Redis+Zookeeper 的分布式并行计算调度和管理系统,李红红主设。

0x00,为什么要做“数据”并行计算调度?

大家都可能做过 基于 MySQL 数据库的,大规模的、有步骤的、步骤与步骤之间有依赖关系的数据计算 。你可能定义了一堆彼此依赖的定时任务,也可能写成一个大进程跑。

举一个实际场景吧,在我们 O2O 业务体系下,我要做人员规模三四千人、有多条业务线、组织结构为大区-区域-城市-销售组的销售团队的昨日佣金和当月佣金,这里的挑战是:

  • 涉及到商户、门店、交易、折扣、核销物料等等,数据量很大,至少每天都要算一次,要算得快,
  • 激励政策和佣金计算公式随着竞争态势变化,一般一两个月变一次,
  • 数据抽取尽可能少影响正常业务,
  • 计算逻辑调整后要能快速部署和运行。

那么,以前可能会定义一些定时任务,每天凌晨从各个业务数据库(毕竟全都拆库分表了)里抽取:

  1. 人员组织架构
  2. 大区、区域和城市的对照关系
  3. 合同以及合同拥有者
  4. 商户和门店
  5. 门店下的收单交易
  6. 佣金计算公式、规则以及各种权重因子
  7. ……

既有全量数据,也有增量数据,所以数据量是很大的。

先算签约数、开店数、交易量等,再把业绩归结在 BD 身上,根据不同业务线的佣金计算公式依次对 BD、BD主管、城市经理等展开各种计算。

虽然我们的 JobCenter 是很优秀的定时任务调度和管理平台, 但它没有步骤(即定时任务之间的依赖关系)的概念 ,所以以前我们只好拍脑袋定 Job1 凌晨1点执行,Job2 凌晨2点执行,Job3和Job4放在3点执行,显然这只是无奈之举, 万一 Job1 跑到凌晨3点才算完怎么办?万一 Job1 执行失败了怎么办?

什么是步骤?我们可以用下图来理解一个大计算任务下步骤之间的依赖关系:

#研发解决方案#分布式并行计算调度和管理系统Summoner

#研发解决方案#分布式并行计算调度和管理系统Summoner

图1

为了应对这种数据量很大的抽取和一环套一环的计算,我们需要 另行发展一个界面友好的、有步骤概念的、有集群调度的数据计算系统 ,以充分利用机器资源。

0x01,他山之玉:azkaban2/oozie/mesos

计算资源的调度,好学生有不少,如针对 hadoop 集群调度和管理的 azkaban2 和 oozie,抽象能力更高的分布式资源管理框架 apache mesos。

项目开始之初,我希望借鉴 oozie 和 azkaban2 的一些优秀设计思路,我们其实也是做调度和管理,只不过它们基于 hadoop,我们基于 mysql 而已。

正文到此结束
Loading...