干货 | Meteor实时计算平台架构与实践

作者简介

何彬，携程市场营销研发部高级研发经理，10多年互联网研发和架构经验。2014年加入携程，负责携程广告、新媒体推广和市场大数据平台的构建、研发工作。

一、前言

营销场景计算需求多种多样，场景模型也纷繁复杂，计算要求的资源配置也大小不一，系统更新部署步骤繁琐，人工操作亦有极大的安全风险。随着公司个性化营销的推广，类似的资源需求也越来越多，大集群支持、资源共享、资源效率是重点关注的问题。

本文将介绍携程市场营销基于storm框架的meteor实时计算平台，解决日益增长的市场部业务需求。

二、什么是Meteor

随时市场业务的不断发展，对实时计算的需求也逐渐增大。一直以来，我们根据市场的不同需求定制开发所要计算的Storm应用，Storm实时运行的应用包逻辑上是一个topology，一个Storm的topology相当于MapReduce的一个job，不同是MapReduce的job有明确的起始和结束，而Storm的topology一旦被初始化就会一直运行下去，形成的topology是有spout、bolt通过数据流分组连接起来的图结构。如下：

按照以上的结构拓扑图，很多情况下出现一个问题，针对一个实时计算的场景topology，当我们需要改变当前拓扑的某一个或者某几个spout、bolt，又或者我们仅需要增加一个处理节点，我们该如何处理？

Storm虽然可以通过rebalance 进行动态调整worker, executor等并发数，但是不支持spout、bolt节点的动态调整，一旦topology被初始化，其spout、bolt节点的数量和配置参数也就相对固定。传统的架构方法是新增一个Storm应用，面对很多实时计算的需求，就需要新增这样的Storm应用，这些应用所要求的开发资源和集群规模也就越来越多、越来越大且难于管理。

传统的解决方案已经成为业务发展的一个瓶颈。如何满足日益增长的计算需求、提高开发及系统资源的利用率成了我们急迫需要解决的问题。

因此，我们对Storm进行了二次封装，结合节点管理，图形计算、自动编译、动态打包、自动发布及部署等工具进行了一次系统的封装，封装后的平台在我们内部称之为Meteor，意思是快速达成美好的愿景。

三、技术架构实现

下图给出的是Meteor的系统架构，自底向上分为驱动层、数据操作层、图计算层、服务层、应用层，其中驱动层、数据操作层、图计算层是Meteor的核心层。

最下层是驱动层。驱动层包括Meteor分别在Storm、Spark等分布式计算系统上的实现，也就是对上层提供了一个统一的接口，使上层只需要处理场景计算等逻辑，而不需要关心在分布式计算系统上的实现过程。

其上是数据操作层，主要包括逻辑表达式算法等操作。再往上是图计算层，也是我们要了解的核心，包含Graph DAG数据流图的实现（图的创建、编译、打包、发布和执行）。再往上是服务层和应用层。

Meteor是用数据流图做处理的，Meteor的数据流图是由计算节点（node）组成的有向无环图（directed acycline graph，DAG）。我们先创建一个数据流图（也称为网络结构图），如图所示，看一下数据流图中的各个要素。图中讲述了Meteor的运行原理。图中包含输入（input）、逻辑计算（function）、输出（output）等部分。

它的计算过程是，首先从输入流开始，一层一层进行前向传播运算。逻辑计算可以定义一个或多个节点，每个节点代表一种算法，不同算法定义不同的传参，根据参数的配置可以调整计算的结果。然后进入输出层，输出层根据不同的客户端输出不同的数据格式，最后生成数据。如图所示，生成的每个数据流图从上往下依次进行计算。

Meteor数据流图由Meteor治理中心统一管理和运维，所有的数据层和计算节点统一在Meteor Service中进行注册，分配和调度。Meteor Service是整个系统的核心模块，用户通过RestAPI调用Service接口服务，提交场景配置和节点算法参数，目前由人工的方式根据不同的业务需求创建计算场景和计算节点参数配置。（计划由机器学习取代，机器学习直接生成数据流图）

生成后的数据流图注入Meteor Factory进行加工，Meteor Factory是Meteor的应用引擎模块，主要是将组合场景的计算节点模块进行代码集成并编译打包，根据数据流图中配置的计算算法和参数，从节点算法库中调取相应的代码，触发Factory代码生成器，代码生成器根据Storm驱动模板生成相应的代码，生成好的代码执行自动编译并打成Storm可执行的应用包。

Meteor CI Service模块将编译好的应用包和发布系统进行集成，由发布系统调用底层Storm客户端驱动，自动将应用包发布到Storm。Meteor CI Service和Storm客户端驱动的任务调度通过Meteor Service进行管理。

Meteor任务调度由不同的状态控制和管理，以保证整个系统运行的有序性。

1、场景被创建，不同的场景由不同的节点模块组成，场景创建时选取相应的节点模块，此时场景的数据状态为NEW；

2、新建完成的场景需要被审核，场景新建完成后提交给相应的审核，提交审核过程中的的场景数据状态为REVIEW；

3、当审核通过后场景代码开始生成，代码生成过程中的场景状态为GENCODE；

4、代码生成完成后进行编译动作，编译过程的场景状态为BUILD；

5、编译结束该场景就可以被执行了，可以被执行的场景状态为CANRUN；

6、当场景在运行过程中状态为RUNNING。

四、Meteor的特性

1、高可用

Topology HA

Meteor Service会定期与topology进行心跳交互，若Meteor Service检测到topology心跳超时，则会重新调起一个新的topology，新的topology会将自身信息写入Zookeeper中，其它Container与Supervisor将通过Zookeeper来识别到新的topology，从而保障topology的HA。

Container/Worker HA

Container会定期与Meteor Service进行交互，若Meteor Service检测到Container心跳超时，则会重新从资源池里调起一个新的Container接管原来失效Container的任务，并把新的任务分配写入Zookeeper中，以便其它Container识别新的Container的位置，从而保障Container的HA。

2、二级调度

封装后的Storm只需管理topology的调度，其它如UI访问、任务下发、拓扑、metrics、节点心跳等，均由Meteor Service的二级调度。

3、资源隔离

封装后每个topology实例下只有一个supervisor，并且每个supervisor里只用一个worker，通过每个worker来进行资源隔离。此外，不同节点可以任意组合一个新的topology，同时我们引入权限管理，不用用户申请的计算资源（数据和节点算法）可以做到相互隔离，每个任务只能运行在授权的通道内，以此保证不同用户申请的资源不会被他人调用。

4、自动发布和部署

由于一个场景一个topology，而一个topology实例可以理解为一个虚拟机，用户资源申请具有随机性、配置个性化等特点，因此对我们配置管理上必需具有自适应性。对此我们通过本地生成应用包，通过产品化把计算管理配置、Storm与CD-CI发布系统打通，并把资源配置、应用包的发布和部署等功能产品化，以达到自动发布和部署的目的。

五、应用效果

如前言中介绍，由于携程市场营销要面对非常复杂的业务场景，携程的数据本身就会有很多的维度和指标细分，数据分析团队和BI人员也会针对数据的不同维度和各种维度组合进行各种各样的分析和计算。

A场景举例：

• 正在浏览上海某五星级酒店详情页
• 且三天内有访问过同样酒店的浏览历史
• 且三个月内没有下过任何订单
• 且是APP激活
• 且会员等级是普通
• 且如果是公众号关注用户，在A媒体投X广告，如果是渠道预装用户，在B媒体投放Y广告

B场景举例：

• 正在浏览北京到上海机票列表页
• 且三天内有访问过上海酒店的浏览历史
• 且一个月内没有下过任何订单
• 且是渠道预装用户
• 且会员等级是普通
• 如果用户权重指数为5，在B媒体投放Y广告，如果用户权重指数是8，在C媒体投放Z广告

以上场景传统解决方案，需要按照每一个业务需求进行分析，得出每一个条件判断的数据来源和依赖，对接数据源获取数据，在数据准备好后逐个进入Storm应用的开发、发布和部署，实时计算的数据结果可能还要对接不同的客户端。

Meteor平台的解决方案只需要三个步骤即可完成数据结果的输出，按照业务需求选择合适的计算类型和参数配置，启动计算场景，就可以得出相应的计算结果，并且可以实时调整计算逻辑（判断条件）。

以上两个场景，可以发现传统的解决方案和Meteor的差异还是比较明显的，主要体现在以下几个方面：

• 业务场景多且复杂，单个场景开发效率低下；
• 随着场景数据量和数据分类的增加，单个场景数据的计算、存储和维护成本越来越大；
• 单个场景的开发应用不可复用，开发资源利用率不高；
• 数据查询重度依赖底层数据框架和数据结构，查询效率得不到满足；
• 单场景数据存储和处理对于实时性要求不能满足；
• 单个场景开发作业，受限开发资源和周期；

Meteor平台通过统一的管理配置模式，实时进行计算节点的动态配置、调度和计算，业务人员可以很方便的进行业务场景的创建、运行、暂停、下线等操作。实现后台配置化，自动化交付上线。完成从被动的需求开发(业务驱动)到主动的满足需求(技术驱动)的重要转变。主要业务优势可以总结为以下几个方面：

• 计算节点一次开发多次复用；
• 场景条件支持任意搭配和多重组合；
• 支持业务场景从原来的几十个场景扩展到上万个场景；
• 提升数十倍的开发效率，交付效率从原来的平均4个工作日缩短到2个小时；
• 满足业务需求快速上线，提升营销投放效率；
• 平台场景状态、数据流量、节点计算、异常容错监控可控；
• 平台投放场景运营数据可视化；

Meteor平台上线后，对市场营销业务提供实时数据计算和数据查询服务，目前已经实现每天几十亿级的数据查询，覆盖90%的实时数据计算任务，系统指标和性能指标主要体现在以下几个方面：

• 计算节点的响应时间99%在50ms以内；
• 计算节点插件化开发，大大降低系统复杂性和耦合度，提高系统稳定性可以达到99.9%；
• 底层驱动多元化，可适配多种流处理计算框架；

六、结语

基于storm框架的meteor实时计算平台，是携程市场团队自行研发的自动化的实时计算平台。

它基于storm框架，通过重新设计整个底层架构及运行逻辑，并添加权限管理、限速、监控、日志等辅助功能，经过产品化并与公司发布平台打通，达到了用户申请即可用、配置个性化、大规模集群的要求，操作高效且自动化。