提前锁票 InfoQ 最具价值感的视频栏目 | InfoQ 大咖说 了解详情
写点什么

实时计算在有赞的实践 - 效率提升之路

2020 年 3 月 18 日

实时计算在有赞的实践-效率提升之路

一、概述

有赞是一个商家服务公司,提供全行业全场景的电商解决方案。在有赞,大量的业务场景依赖对实时数据的处理,作为一类基础技术组件,服务着有赞内部几十个业务产品,几百个实时计算任务,其中包括交易数据大屏,商品实时统计分析,日志平台,调用链,风控等多个业务场景,本文将介绍有赞实时计算当前的发展历程和当前的实时计算技术架构。


二、实时计算在有赞发展

从技术栈的角度,我们的选择和大多数互联网公司一致,从早期的 Storm,到 JStorm, Spark Streaming 和最近兴起的 Flink。从发展阶段来说,主要经历了两个阶段,起步阶段和平台化阶段;下面将按照下图中的时间线,介绍实时计算在有赞的发展历程。



2.1 起步阶段

这里的的起步阶段的基本特征是,缺少整体的实时计算规划,缺乏平台化任务管理,监控,报警工具,用户提交任务直接通过登录 AG 服务器使用命令行命令提交任务到线上集群,很难满足用户对可用性的要求。 但是,在起步阶段里积累了内部大量的实时计算场景。


2.1.1 Storm 登场

2014 年初,第一个 Storm 应用在有赞内部开始使用,最初的场景是把实时事件的统计从业务逻辑中解耦出来,Storm 应用通过监听 MySQL 的 binlog 更新事件做实时计算,然后将结果更新到 MySQL 或者 Redis 缓存上,供在线系统使用。类似的场景得到了业务开发的认可,逐渐开始支撑起大量的业务场景,详见 2017 年整理的一篇博客文章-《基于 Storm 的实时应用实践》(https://tech.youzan.com/storm-in-action/)。


早期,用户通过登录一组线上环境的 AG 服务器,通过 Storm 的客户端向 Storm 集群做提交任务等操作, 这样在 2 年多的时间里,Storm 组件积累了近百个实时应用。 Storm 也同样暴露出很多问题,主要体现在系统吞吐上,对吞吐量巨大,但是对延迟不敏感的场景,显得力不从心。


2.1.2 引入 Spark Streaming

2016 年末,随着 Spark 技术栈的日益成熟,又因为 Storm 引擎本身在吞吐/性能上跟 Spark Streaming 技术栈相比有明显劣势,所以从那时候开始,部分业务团队开始尝试新的流式计算引擎。 因为有赞离线计算有大量 Spark 任务的使用经验,Spark Streaming 很自然的成为了第一选择,随着前期业务日志系统和埋点日志系统的实时应用的接入,大量业务方也开始逐渐接入。 同 Storm 一样,业务方完成实时计算应任务开发后,通过一组 AG 服务器,使用 Spark 客户端,向大数据 Yarn 集群提交任务。


初步阶段持续的时间比较长,差不多在 2017 年年末,有赞实时计算的部署情况如下图所示:



2.1.3 小结

这种架构在业务量少的情况下问题不大,但是随着应用方任务数目的增加,暴露出一些运维上的问题,主要在以下几个方面:


  1. 缺少业务管理机制。大数据团队平台组,作为集群管理者,很难了解当前集群上运行着的实时任务的业务归属关系,也就导致在集群出现可用性问题或者集群要做变更升级时,无法高效通知业务方做处理,沟通成本很高

  2. Storm 和 Spark Streaming 的监控报警,是各自实现的,处于工具化的阶段,很多业务方,为了可用性,会定制自己的监控报警工具,导致很多重复造轮,影响开发效率

  3. 计算资源没有隔离。资源管理粗糙,没有做离线系统和实时系统的隔离;早期离线任务和 Spark Streaming 任务运行在同一组 Yarn 资源上,凌晨离线任务高峰时,虽然 Yarn 层有做 CapacityScheduler 的 Queue 隔离,但是 HDFS 层公用物理机,难免网卡和磁盘 IO 层面会相互影响,导致凌晨时间段实时任务会有大量延迟

  4. 缺少灵活的资源调度。用户通过 AG 服务器启动实时任务,任务所使用的集群资源,也在启动脚本中指定。这种方式在系统可用性上存在很大弊端,当实时计算所在的 Yarn 资源池出现故障时,很难做实时任务的集群间切换


总的来说就是缺少一个统一的实时计算平台,来管理实时计算的方方面面。


2.2 平台化阶段

2.2.1 构建实时计算平台

接上一节,面对上面提到的这四个问题,对实时计算平台的初步需求如下:


  1. 业务管理功能。主要是记录实时应用的相关信息,并且和业务的接口人做好关联

  2. 提供任务级别的监控,任务故障自动拉起,用户自定义基于延迟/吞吐等指标的报警,流量趋势大盘等功能

  3. 做好集群规划,为实时应用构建独立的计算 Yarn 集群,避免离线任务和实时任务互相影响

  4. 提供任务零花的切换计算集群,保证在集群故障时可以方便迁移任务到其他集群暂避


所以在 18 年初,我们立项开始做实时平台第一期,作为尝试起初我们仅仅完成对 Spark Streaming 实时计算任务的支持, 并在较短时间内完成了所有 Spark Streaming 任务的迁移。 试运行 2 个月后,明显感觉到对业务的掌控力变强。随后便开始了对 Storm 任务的支持,并迁移了所有的 Storm 实时计算任务. AG 服务器全部下线,业务方再也不需要登录服务器做任务提交。


2018 年中,有赞线上运行着 Storm,Spark Streaming 两种计算引擎的实时任务,可以满足大部分业务需求,但是,两种引擎本身也各自存在着问题。


Storm 本身存在着吞吐能力的限制。和 Spark Streaming 对比,选择似乎更难一些。我们主要从以下几个角度考虑:


  1. 延迟, Flink 胜出,Spark Streaming 本质上还是以为微批次计算框架,处理延迟一般跟 Batch Interval 一致,一般在秒级别,在有赞的重吞吐场景下,一般 batch 的大小在 15 秒左右

  2. 吞吐, 经过实际测试,相同条件下,Flink 的吞吐会略低于 Spark Streaming,但是相差无几

  3. 对状态的存储支持, Flink 在这方面完胜,对于数据量较大的状态数据,Flink 可以选择直接存储计算节点本地内存或是 RocksDB,充分利用物理资源

  4. 对 SQL 的支持,对当时两种框架的最新稳定版本的 SQL 功能做了调研,结果发现在对 SQL 的支持度上,Flink 也具有较大优势,主要体现在支持更多的语法

  5. API 灵活性, Flink 的实时计算 API 会更加友好


出于以上几点原因,有赞开始在实时平台中增加了对 Flink 引擎的支持,选择 Flink 的更具体的原因可以参考我们另一篇博客文章-《Flink 在有赞实时计算的实践》


在完成 Flink 引擎的集成后,有赞实时计算的部署情况如下图所示:



2.2.2 新的挑战

以上完成之后,基本上就可以提供稳定/可靠的实时计算服务;随之,业务方开发效率的问题开始显得突出。用户一般的接入流程包含以下几个步骤:


  1. 熟悉具体实时计算框架的 SDK 使用,第一次需要半天左右

  2. 申请实时任务上下游资源,如消息队列,Redis/MySQL/HBase 等在线资源,一般几个小时

  3. 实时任务开发,测试,视复杂程度,一般在 1~3 天左右

  4. 对于复杂的实时开发任务,实时任务代码质量很难保证,平台组很难为每个业务方做代码 review, 所以经常会有使用不当的应用在测试环境小流量测试正常后,发布到线上,引起各种各样的问题


整个算下来,整个流程至少需要 2~3 天,实时应用接入效率逐渐成了眼前最棘手的问题。 对于这个问题。在做了很多调研工作后,最终确定了两个实时计算的方向:


  1. 实时任务 SQL 化

  2. 对于通用的实时数据分析场景,引入其他技术栈, 覆盖简单场景


2.2.2.1 实时任务 SQL 化

实时任务 SQL 化可以大大简化业务的开发成本,缩短实时任务的上线周期。 在有赞,实时任务 SQL 化 基于 Flink 引擎,目前正在构建中,我们目前的规划是首先完成对以下功能的支持:


  1. 基于 Kafka 流的流到流的实时任务开发

  2. 基于 HBaseSink 的流到存储的 SQL 任务开发

  3. 对 UDF 的支持


目前 SQL 化实时任务的支持工作正在进行中。


2.2.2.2 引入实时 OLAP 引擎

通过对业务的观察,我们发现在业务的实时应用中,有大量的需求是统计在不同维度下的 uv,pv 类统计,模式相对固定,对于此类需求,我们把目光放在了支持数据实时更新,并且支持实时的 Olap 类查询上的存储引擎上。


我们主要调研了 Kudu,Druid 两个技术栈,前者是 C++ 实现,分布式列式存储引擎,可以高效的做 Olap 类查询,支持明细数据查询;后者是 Java 实现的事件类数据的预聚合 Olap 类查询引擎~


综合考虑了运维成本,与当前技术栈的融合,查询性能,支持场景后,最终选择了 Druid,关于 Druid 在有赞的实践,可以参考我们另一篇博客文章-《Druid在有赞的实践》


目前实时计算在有赞的整体技术架构如下图



三、未来规划

首先要落地并的是实时任务 SQL 化,提高 SQL 化任务可以覆盖的业务场景(目标是 70%),从而通过提高业务开发效率的角度赋能业务。


在 SQL 化实时任务初步完成后,流数据的复用变成了提高效率上 ROI 最高的措施,初步计划会着手开始实时数仓的建设,对于实时数仓的初步设计如下图:



当然,完整的实时数仓绝没有这么简单,不只是实时计算相关的基础设施要达到一定的平台化水平,还依赖实时元数据管理,实时数据质量管理等配套的组件建设,路漫漫其修远~


四、总结

有赞实时计算在业务方的需求下推动前进,在不同的阶段下,技术方向始终朝着当前投入产出比最高的方向在不断调整。本文并没有深入技术细节,而是循着时间线描述了实时计算在有赞的发展历程,有些地方因为作者认知有限,难免纰漏,欢迎各位同行指出。


2020 年 3 月 18 日 19:54204

评论

发布
暂无评论
发现更多内容

DSN 主流项目调研 0——IPFS&&Filecoin白皮书总结

AIbot

区块链 分布式存储 分布式文件存储 IPFS Filecoin

【FCC前端教程】28关学会HTML与HTML5基础

三钻

CSS html 前端 前端训练

区块链技术在银行业的运用

CECBC区块链专委会

区块链 信息安全 金融

LeaRun快速开发平台,快速开发.net/java项目

力软.net/java开发平台

IDEA直连服务器,进行项目Docker部署,实现一键部署、启动

xcbeyond

Java Docker idea插件

【FCC前端教程】44关学习CSS与CSS3基础「一」

三钻

CSS css3 程序员成长 前端训练

更优雅的编写JavaScript

三钻

Java 前端 程序员素养 经验分享 ES6

你真的懂怎么写`服务层`吗?

三钻

php 后端 服务 程序员成长 架构思维

docker-compose构建springcloud微服务项目

xcbeyond

Java Docker Docker-compose springboot

国内外低/零代码的有哪些代表?

代码制造者

编程语言 低代码 零代码 信息化 开发应用

5大法则助你 成为更出色的开发者

三钻

学习 编程 敏捷开发 程序员成长 经验分享

Git分支管理策略及简单操作

王坤祥

git git flow

解读CDN的应用场景与产品价值

阿里云Edge Plus

CDN

用“易于改编”原则,提升编程水平,写出更好的代码

三钻

前端 后端 程序员成长 经验分享 编程风格

前端必看的8个HTML+CSS技巧

三钻

Java html html5 css3 前端

VSCode插件大全|VSCode高级玩家之第二篇

三钻

程序员人生 vscode 编辑器 插件 技巧

SpringCloud服务注册与发现(Eureka)

xcbeyond

Java SpringCloud Eureka 服务注册与发现

CentOS7 下Docker安装、启动

xcbeyond

Docker 软件安装

图解JavaScript——代码实现(六种异步方案,重点是Promise、Async、发布/订阅原理实现,真香)

执鸢者

原理 异步 Promise Async

VSCode常用快捷键大全|VSCode高级玩家宝典之第一篇

三钻

学习 效率工具 程序员人生 vscode 快捷键

VSCode配置同步|VSCode高级玩家宝典之第三篇

三钻

效率工具 程序员人生 vscode 开发工具

6个高效学习编程的方法

三钻

学习 程序人生 前端 后端

带你体验Vue2和Vue3开发组件有什么区别

三钻

Java Vue 前端 Vue3 React

职业发展的迷茫与困境:你真的了解晋升机制吗?

伴鱼技术团队

职业规划 技术管理 技术交流 职业成长 技术人生

憋再PS抠图了,3行代码给你安排的明明白白!

王坤祥

生产力 图像识别

Lambda架构已死,去ETL化的IOTA才是未来

易观大数据

国家央行数字货币的优势与挑战

CECBC区块链专委会

数字货币 央行 商业银行

【第十周】学习笔记

Aldaron

【第十周作业】

Aldaron

DSN主流项目调研1——Storj和Arweave的简介

AIbot

分布式存储 区块链+ 分布式文件存储 Storj Arweave

写给想学和在学编程的你们,学习编程的7个好处

三钻

学习 软件开发 编程之路 程序员成长 经验分享

打造 VUCA 时代的 10 倍速 IT 团队

打造 VUCA 时代的 10 倍速 IT 团队

实时计算在有赞的实践-效率提升之路-InfoQ