调度中心的资料收集

大众点评网

摘要：大众点评网从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接口，前端通过该接口查询任务状态，以及控制任务等。最右边是计算环境的适配层。------（没看懂）

企业大数据建设案例分享

http://www.csdn.net/article/2013-07-31/2816417-CTO-club-tecent

百度

数据平台架构

# 我们任何的平台和系统不可能解决所有的问题

# 仓库是解决了增量、批量、流式这种混杂的模型，跟全套的解决方案

# 一个系统，想做到高效，是一定有损失的。重点是实效，一定要快，会损失什么？会损失准确，可能会是不精准，不精准的意思可能会丢。--------------不同的应用场景，对数据的要求不一样。我们的产品是基于怎样的应用场景，要解决怎样的问题。

刘立萍：百度大数据平台介绍

http://www.csdn.net/article/a/2012-12-01/2812397

腾讯

数据服务总体框架

参看文章：

腾讯大规模Hadoop集群实践

http://www.csdn.net/article/2014-02-19/2818473-Tencent-Hadoop

数据平台的建设思考

现状与问题分析

在数据量日益增加的情况下，数据平台需要加强服务分层处理和调度中心统筹管理。

目前，公司的数据后台逐渐分层。分层设计，降低了系统之间的耦合，有助于新功能的实现，有助于更好的推动业务发展。

不过，层级之间的响应需要加强。各个层级不能各自为政，否则会导致层级之间响应缓慢，并且不便于日常维护、统一管理与新业务拓展。

问题

1、数据库job执行的问题，依赖数据库本身的job机制无法做到智能的多次处理以及有问题时及时提醒，另外，出现异常之后再人工处理耗时较多。如果能有一个完整的程序按照顺序和条件把需要补的过程有条不紊的补上会节省很多后期补报表数据的时间。

2、数据交换平台，对实时数据的交换，采用轮训数据库的方式，简单粗暴。如果升级成消息驱动机制，可以提高系统响应速度，便于工作流、任务流的连贯执行，降低数据库的压力。

3、数据流的连贯性存在问题，层与层之间缺少执行前的条件判断。如果过于紧凑，可能出现错误。如果过于松散，会影响到效率。

数据平台的思考（完善ing）

         基于以上的分析，思考数据平台的建设想法。

数据交换平台

         优化后台数据库之间的关联关系，从网状结构，过渡到中心结构。

网状结构

中心结构

调度中心的建设思考

调度中心的作用

1、梳理数据流，明确任务之间的依赖关系，可视化管理，便于维护扩展。

2、任务执行连贯，系统响应速度提高，吞吐提高。服务器的计算能力得到较为充分的发挥。

3、日常维护便捷。调度中心提供运行的数据指标，便于监控系统及时发现问题并报警，缩短故障发现时长与处理时长。

         调度中心的架构

有以下特点：

# redis：消息中间件，负责master与agent的通信，负责记录调度中心运行日志

# master：负责处理任务之间依赖关系（前置任务驱动后置任务）、日志记录、agent管理（注册等）、异常处理，等。

# agent：agent之间互不知晓，负责执行某类别的任务。关于同时执行的任务个数或是否立即执行，由agent自行控制，影响因素例如自身服务器性能等。

# Oracle：配置数据库，持久化任务配置参数。

#WebConsole：对后台任务进行可视化地实时性地查看与管理，连接redis。

几个难点：

# 数据库模型设计，存储任务之间的依赖关系，便于对任务类别的扩展

# redis的使用预研与demo开发（使用c++操作）

# master与agent的通信协议，便于扩展

# 数据库连接池的技术实现，避免出现后期瓶颈

问题与讨论

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