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

1. 概述

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

2. 实时计算在有赞发展

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

2.1 起步阶段

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

2.1.1 Storm 登场

2014年初，第一个 Storm 应用在有赞内部开始使用，最初的场景是把实时事件的统计从业务逻辑中解耦出来，Storm 应用经过监听 MySQL 的 binlog 更新事件作实时计算，而后将结果更新到 MySQL 或者 Redis 缓存上，供在线系统使用。相似的场景获得了业务开发的承认，逐渐开始支撑起大量的业务场景，详见2017年整理的一篇博客文章-《基于 Storm 的实时应用实践》。

早期，用户经过登陆一组线上环境的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在有赞的实践》。

目前实时计算在有赞的总体技术架构以下图：

3. 将来规划

首先要落地并的是实时任务SQL化，提升SQL化任务能够覆盖的业务场景（目标是70%），从而经过提升业务开发效率的角度赋能业务。

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

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

4. 总结

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

最后打个小广告，有赞大数据团队基础设施团队，主要负责有赞的数据平台（DP), 实时计算(Storm, Spark Streaming, Flink)，离线计算(HDFS,YARN,HIVE, SPARK SQL)，在线存储（HBase），实时 OLAP(Druid) 等数个技术产品，欢迎感兴趣的小伙伴联系 hefei@youzan.com

相关连接

1. Druid在有赞的实践
2. Flink 在有赞实时计算的实践
3. 基于Storm的实时计算应用实践