消息调度中心的学习资料汇总

消息调度中心作为云计算的中枢系统，承载的功能很多，需要兼容各种类型的任务需求。借鉴优秀企业的做法，以及开源项目，做最适合我们自己的系统。

红薯爱帅

3068人浏览 · 2014-11-03 16:05:29

红薯爱帅 · 2014-11-03 16:05:29 发布

调度中心的资料收集

大众点评网

摘要：大众点评网从2011年中开始使用Hadoop，并专门建立团队。Hadoop主分析集群共有60多个节点、700TB的容量，月运行30多万个HadoopJob，还有2个HBase线上集群。作者将讲述这各个阶段的技术选择及改进之路。

2011年小规模试水

这一阶段的主要工作是建立了一个小的集群，并导入了少量用户进行测试。为了满足用户的需求，我们还调研了任务调度系统和数据交换系统。

集群搭建好，用户便开始使用，面临的第一个问题是需要任务级别的调度、报警和工作流服务。当用户的任务出现异常或其他情况时，需要以邮件或者短信的方式通知用户。而且用户的任务间可能有复杂的依赖关系，需要工作流系统来描述任务间的依赖关系。我们首先将目光投向开源项目Apache Oozie。Oozie是Apache开发的工作流引擎，以XML的方式描述任务及任务间的依赖，功能强大。但在测试后，发现Oozie并不是一个很好的选择。

Oozie采用XML作为任务的配置，特别是对于MapReduce Job，需要在XML里配置Map、Reduce类、输入输出路径、Distributed Cache和各种参数。在运行时，先由Oozie提交一个Map only的Job，在这个Job的Map里，再拼装用户的Job，通过JobClient提交给JobTracker。相对于Java编写的Job Runner，这种XML的方式缺乏灵活性，而且难以调试和维护。先提交一个Job，再由这个Job提交真正Job的设计，我个人认为相当不优雅。

另一个问题在于，公司内的很多用户，希望调度系统不仅可以调度Hadoop任务，也可以调度单机任务，甚至Spring容器里的任务，而Oozie并不支持Hadoop集群之外的任务。

所以我们转而自行开发调度系统Taurus（https://github.com/dianping/taurus）。Taurus是一个调度系统，通过时间依赖与任务依赖，触发任务的执行，并通过任务间的依赖管理将任务组织成工作流；支持Hadoop/Hive Job、Spring容器里的任务及一般性任务的调度/监控。

图1 Taurus的结构图

图1是Taurus的结构图，Taurus的主节点称为Master，Web界面与Master在一起。用户在Web界面上创建任务后，写入MySQL做持久化存储，当Master判断任务触发的条件满足时，则从MySQL中读出任务信息，写入ZooKeeper；Agent部署在用户的机器上，观察ZooKeeper上的变化，获得任务信息，启动任务。Taurus在2012年中上线。

可视化界面

总结

图5是各系统总体结构图，深蓝部分为自行开发的系统。

图5大众点评各系统总体结构图

在这2年多的Hadoop实践中，我们得到了一些宝贵经验。

· 建设一支强大的技术团队是至关重要的。Hadoop的生态系统，还处在快速演化中，而且文档相当匮乏。只有具备足够强的技术实力，才能用好开源软件，并在开源软件不能满足需求时，自行开发解决问题。

· 要立足于解决用户的需求。用户需要的东西，会很容易被用户接受，并推广开来；某些东西技术上很简单，但可以解决用户的大问题。

· 对用户的培训，非常重要。

架构图（另一篇关于大众点评的数据平台的文章）

思考总结：

1、前置条件驱动后置条件。任务的依赖关系处理有master统一管理，因此所有客户端的状态管理，master必须得知。

2、 Zookeeper是消息中间件，负责master与agent之间的消息传输，属于核心模块。

3、亮点：web界面可以控制任务启动。但是，为什么Web界面与Master在一起。

4、框架介绍得比较清楚，关键技术不清楚，例如master与agent的通信协议（或者zookeeper的内部处理机制）、数据库模型（如何处理任务之间的依赖，如何避免任务依赖产生回路）

5、调度中心、数据传输、监控是数据平台的基础组件，像高速公路一样，只有铺设好了，汽车才能跑得更快。

参考文章：

大众点评的大数据实践：

http://www.csdn.net/article/2013-12-18/2817838-big-data-practice-in-dianping

大众点评数据平台架构变迁：

http://blog.csdn.net/yfkiss/article/details/16838941

阿里巴巴

淘宝海量数据产品技术架构

数据产品的一个最大特点是数据的非实时写入，正因为如此，我们可以认为，在一定的时间段内，整个系统的数据是只读的。这为我们设计缓存奠定了非常重要的基础。

按照数据的流向来划分，我们把淘宝数据产品的技术架构分为五层，分别是数据源、计算层、存储层、查询层和产品层。位于架构顶端的是我们的数据来源层，这里有淘宝主站的用户、店铺、商品和交易等数据库，还有用户的浏览、搜索等行为日志等。这一系列的数据是数据产品最原始的生命力所在。

文章结束时，提到：尽管如此，整个系统中仍然存在很多不完善的地方。一个典型的例子莫过于各个分层之间使用短连接模式的HTTP协议进行通信。这样的策略直接导致在流量高峰期单机的TCP连接数非常高。所以说，一个良好的架构固然能够在很大程度上降低开发和维护的成本，但它自身一定是随着数据量和流量的变化而不断变化的。我相信，过不了几年，淘宝数据产品的技术架构一定会是另外的样子。

SKYNET

天网调度系统（SKYNET）作为淘宝数据平台的核心调度系统，承载着淘宝数据跨部门/数十条业务线/超过一万个作业的调度和运维工作，具有图形化、跨平台、自动部署、线上运维、智能容灾的特点，是淘宝数据平台的中枢系统。

思考总结：

1）结合我们自己的数据交换平台。同样存在服务器单机的TCP连接数较高的问题，与王老师、郑辉、项老师讨论，考虑使用数据库连接池实现。难度较大。

2）思考我们的数据平台，面向层级的设计需要加强。应尽可能降低各模块之间的耦合，降低维护成本。

参考文章：

淘宝数据魔方技术架构解析

http://www.alidata.org/archives/1789

阿里数据平台的技术罗列，重点查看天网调度系统：

http://www.alidata.org/about-us/tech

淘宝的数据产品：

## 淘宝魔方：http://mofang.taobao.com/

## 淘宝指数：http://shu.taobao.com/

迅雷

大数据的重要性已毋庸置疑，但大数据的采集、存储、处理、分析、研究，却不是一朝一夕炼成的！数据平台如何建设，推荐系统如何运算，等等，都是我们所关注的话题。

迅雷的大数据架构

# 文章简单介绍迅雷数据平台的建设方案，分为五层：采集、原始数据存储、ETL计算、DW层存储、业务层。

# 贯穿五层的两个重要模块：认证与授权、事件驱动调度。

##一块是认证与授权，从上到下所有东西都需要经过认证和授权，作为一个公司级集中式的存储平台，每个部门存储都会在这儿做，所以你必须保障数据安全和资源合理分配.

##另一块是事件驱动调度：需要把后置依赖前置改成前置驱动后置，前置任务跑成功了之后，将该任务对应的“数据事件”扔到调度总线里面去，由总线把需要依赖这个“数据事件”的其他任务调起来。当然该任务能够立即跑，还要考虑到底层计算引擎目前的负载等情况。

上图是调度引擎大体的架构：最核心部分是调度总线，数据分为是Task和Job，Task维护计算逻辑，如执行的SQL脚本等；Job维护调度逻辑，如依赖什么“数据事件”，一个Task可以配置多个Job。最左边是Web接口，前端通过该接口查询任务状态，以及控制任务等。最右边是计算环境的适配层。------（没看懂）