江苏龙网

  1. 首页 > 人文 > >

Meteor 实时计算平台架构与实践

来源:微信公众号:携程技术
作者:何彬
出处:
作者简介何彬 ， 携程市场营销研发部高级研发经理 ， 10多年互联网研发和架构经验 。 2014年加入携程 ， 负责携程广告、新媒体推广和市场大数据平台的构建、研发工作 。
一、前言
营销场景计算需求多种多样 ， 场景模型也纷繁复杂 ， 计算要求的资源配置也大小不一 ， 系统更新部署步骤繁琐 ， 人工操作亦有极大的安全风险 。 随着公司个性化营销的推广 ， 类似的资源需求也越来越多 ， 大集群支持、资源共享、资源效率是重点关注的问题 。
本文将介绍携程市场营销基于storm框架的meteor实时计算平台 ， 解决日益增长的市场部业务需求 。
二、什么是Meteor
随时市场业务的不断发展 ， 对实时计算的需求也逐渐增大 。 一直以来 ， 我们根据市场的不同需求定制开发所要计算的Storm应用 ， Storm实时运行的应用包逻辑上是一个topology ， 一个Storm的topology相当于MapReduce的一个job ， 不同是MapReduce的job有明确的起始和结束 ， 而Storm的topology一旦被初始化就会一直运行下去 ， 形成的topology是有spout、bolt通过数据流分组连接起来的图结构 。 如下：
Meteor 实时计算平台架构与实践文章插图
按照以上的结构拓扑图 ， 很多情况下出现一个问题 ， 针对一个实时计算的场景topology ， 当我们需要改变当前拓扑的某一个或者某几个spout、bolt ， 又或者我们仅需要增加一个处理节点 ， 我们该如何处理？
Storm虽然可以通过rebalance 进行动态调整worker, executor等并发数 ， 但是不支持spout、bolt节点的动态调整 ， 一旦topology被初始化 ， 其spout、bolt节点的数量和配置参数也就相对固定 。传统的架构方法是新增一个Storm应用 ， 面对很多实时计算的需求 ， 就需要新增这样的Storm应用 ， 这些应用所要求的开发资源和集群规模也就越来越多、越来越大且难于管理 。
传统的解决方案已经成为业务发展的一个瓶颈 。 如何满足日益增长的计算需求、提高开发及系统资源的利用率成了我们急迫需要解决的问题 。
因此 ， 我们对Storm进行了二次封装 ， 结合节点管理 ， 图形计算、自动编译、动态打包、自动发布及部署等工具进行了一次系统的封装 ， 封装后的平台在我们内部称之为Meteor ， 意思是快速达成美好的愿景 。
三、技术架构实现
下图给出的是Meteor的系统架构 ， 自底向上分为驱动层、数据操作层、图计算层、服务层、应用层 ， 其中驱动层、数据操作层、图计算层是Meteor的核心层 。
最下层是驱动层 。 驱动层包括Meteor分别在Storm、Spark等分布式计算系统上的实现 ， 也就是对上层提供了一个统一的接口 ， 使上层只需要处理场景计算等逻辑 ， 而不需要关心在分布式计算系统上的实现过程 。
【Meteor 实时计算平台架构与实践】其上是数据操作层 ， 主要包括逻辑表达式算法等操作 。 再往上是图计算层 ， 也是我们要了解的核心 ， 包含Graph DAG数据流图的实现（图的创建、编译、打包、发布和执行） 。 再往上是服务层和应用层 。
Meteor 实时计算平台架构与实践文章插图
Meteor 是用数据流图做处理的 ， Meteor的数据流图是由计算节点（node）组成的有向无环图（directed acycline graph ， DAG） 。 我们先创建一个数据流图（也称为网络结构图） ， 如图所示 ， 看一下数据流图中的各个要素 。 图中讲述了Meteor的运行原理 。 图中包含输入（input）、逻辑计算（function）、输出（output）等部分 。
它的计算过程是 ， 首先从输入流开始 ， 一层一层进行前向传播运算 。 逻辑计算可以定义一个或多个节点 ， 每个节点代表一种算法 ， 不同算法定义不同的传参 ， 根据参数的配置可以调整计算的结果 。 然后进入输出层 ， 输出层根据不同的客户端输出不同的数据格式 ， 最后生成数据 。 如图所示 ， 生成的每个数据流图从上往下依次进行计算 。


推荐阅读


上一篇：FLASK数据库模型

下一篇：复合事件处理CEP简介