Meteor 实时计算平台架构与实践( 三 )


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

  • 正在浏览上海某五星级酒店详情页
  • 且三天内有访问过同样酒店的浏览历史
  • 且三个月内没有下过任何订单
  • 且是APP激活
  • 且会员等级是普通
  • 且如果是公众号关注用户 , 在A媒体投X广告 , 如果是渠道预装用户 , 在B媒体投放Y广告
B场景举例:
  • 正在浏览北京到上海机票列表页
  • 且三天内有访问过上海酒店的浏览历史
  • 且一个月内没有下过任何订单
  • 且是渠道预装用户
  • 且会员等级是普通
  • 如果用户权重指数为5 , 在B媒体投放Y广告 , 如果用户权重指数是8 , 在C媒体投放Z广告
以上场景传统解决方案 , 需要按照每一个业务需求进行分析 , 得出每一个条件判断的数据来源和依赖 , 对接数据源获取数据 , 在数据准备好后逐个进入Storm应用的开发、发布和部署 , 实时计算的数据结果可能还要对接不同的客户端 。
Meteor 实时计算平台架构与实践文章插图
Meteor平台的解决方案只需要三个步骤即可完成数据结果的输出 , 按照业务需求选择合适的计算类型和参数配置 , 启动计算场景 , 就可以得出相应的计算结果 , 并且可以实时调整计算逻辑(判断条件) 。
Meteor 实时计算平台架构与实践文章插图
以上两个场景 , 可以发现传统的解决方案和Meteor的差异还是比较明显的 , 主要体现在以下几个方面:
  • 业务场景多且复杂 , 单个场景开发效率低下;
  • 随着场景数据量和数据分类的增加 , 单个场景数据的计算、存储和维护成本越来越大;
  • 单个场景的开发应用不可复用 , 开发资源利用率不高;
  • 数据查询重度依赖底层数据框架和数据结构 , 查询效率得不到满足;
  • 单场景数据存储和处理对于实时性要求不能满足;
  • 单个场景开发作业 , 受限开发资源和周期;
Meteor平台通过统一的管理配置模式 , 实时进行计算节点的动态配置、调度和计算 , 业务人员可以很方便的进行业务场景的创建、运行、暂停、下线等操作 。 实现后台配置化 , 自动化交付上线 。 完成从被动的需求开发(业务驱动)到主动的满足需求(技术驱动)的重要转变 。 主要业务优势可以总结为以下几个方面:
  • 计算节点一次开发多次复用;
  • 场景条件支持任意搭配和多重组合;
  • 支持业务场景从原来的几十个场景扩展到上万个场景;
  • 提升数十倍的开发效率 , 交付效率从原来的平均4个工作日缩短到2个小时;
  • 满足业务需求快速上线 , 提升营销投放效率;
  • 平台场景状态、数据流量、节点计算、异常容错监控可控;
  • 平台投放场景运营数据可视化;
Meteor平台上线后 , 对市场营销业务提供实时数据计算和数据查询服务 , 目前已经实现每天几十亿级的数据查询 , 覆盖90%的实时数据计算任务 , 系统指标和性能指标主要体现在以下几个方面:
  • 计算节点的响应时间99%在50ms以内;
  • 计算节点插件化开发 , 大大降低系统复杂性和耦合度 , 提高系统稳定性可以达到99.9%;
  • 底层驱动多元化 , 可适配多种流处理计算框架;
六、结语
基于storm框架的meteor实时计算平台 , 是携程市场团队自行研发的自动化的实时计算平台 。
它基于storm框架 , 通过重新设计整个底层架构及运行逻辑 , 并添加权限管理、限速、监控、日志等辅助功能 , 经过产品化并与公司发布平台打通 , 达到了用户申请即可用、配置个性化、大规模集群的要求 , 操作高效且自动化 。