如何基于 Spark Streaming 构建实时计算平台

GitChat 作者：潘国庆
原文：如何基于 Spark Streaming 构建实时计算平台
关注微信公众号：「GitChat 技术杂谈」 一本正经的讲技术

【不要错过文末彩蛋】

前言

随着互联网技术的迅速发展，用户对于数据处理的时效性、准确性与稳定性要求越来越高，如何构建一个稳定易用并提供齐备的监控与预警功能的实时计算平台也成了很多公司一个很大的挑战。

自2015年携程实时计算平台搭建以来，经过两年多不断的技术演进，目前实时集群规模已达上百台，平台涵盖各个SBU与公共部门数百个实时应用，全年JStorm集群稳定性达到100%。目前实时平台主要基于JStorm与Spark Streaming构建而成，相信关注携程实时平台的朋友在去年已经看到一篇关于携程实时平台的分享：携程实时大数据平台实践分享。

本次分享将着重于介绍携程如何基于Spark Streaming构建实时计算平台，文章将从以下几个方面分别阐述平台的构建与应用：

• Spark Streaming vs JStorm

• Spark Streaming设计与封装

• Spark Streaming在携程的实践

• 曾经踩过的坑

• 未来展望

Spark Streaming vs JStorm

携程实时平台在接入Spark Streaming之前，JStorm已稳定运行有一年半，基本能够满足大部分的应用场景。接入Spark Streaming主要有以下几点考虑：首先携程使用的JStorm版本为2.1.1版本，此版本的JStorm封装与抽象程度较低，并没有提供High Level抽象方法以及对窗口、状态和Sql等方面的功能支持，这大大的提高了用户使用JStorm实现实时应用的门槛以及开发复杂实时应用场景的难度。在这几个方面，Spark Streaming表现就相对好的多，不但提供了高度集成的抽象方法（各种算子），并且用户还可以与Spark SQL相结合直接使用SQL处理数据。

其次，用户在处理数据的过程中往往需要维护两套数据处理逻辑，实时计算使用JStorm，离线计算使用Hive或Spark。为了降低开发和维护成本，实现流式与离线计算引擎的统一，Spark为此提供了良好的支撑。

最后，在引入Spark Streaming之前，我们重点分析了Spark与Flink两套技术的引入成本。Flink当时的版本为1.2版本，Spark的版本为2.0.1。相比较于Spark，Flink在SQL与MLlib上的支持相对弱于Spark，并且公司许多部门都是基于Spark SQL与MLlib开发离线任务与算法模型，使得大大降低了用户使用Spark的学习成本。

下图简单的给出了当前我们使用Spark Streaming与JStorm的对比：

默认情况下，作业每次都是基于上次存储的Kafka Offset继续消费，但是用户也可以自行决定Offset的消费起点。下图中展示了设置消费起点的三种方式:

如此做的用意在于能够确保无论是宕机还是人为重启，重启后的第一个批次与重启前的最后一个批次数据一模一样。这样的设计使得后面用户在后面对于第一个批次的数据处理非常灵活可变，如果用户直接忽略第一个批次的数据，那此时保证的是at most once的语义，因为我们无法获知重启前的最后一个批次数据操作是否有成功完成；如果用户依照原有逻辑处理第一个批次的数据，不对其做去重操作，那此时保证的是at least once的语义，最终结果中可能存在重复数据；最后如果用户想要实现exactly once，muise spark core提供了根据topic、partition与offset生成UID的功能，只要确保两个批次消费的Offset相同，则最终生成的UID也相同，用户可以根据此UID作为判断上个批次数据是否有存储成功的依据。下面简单的给出了重启后第一个批次操作的行为。

容错

其实在上面Exactly Once一章中已经详细的描述了muise spark core如何在程序宕机后能够保证数据正确的处理。但是为了能够让Spark Sreaming能够长时间稳定的运行在Yarn集群上，还需要添加许多配置，感兴趣的朋友可以查看：Long running Spark Streaming Jobs on Yarn Cluster。

除了上述容错保证之外，Muise Portal（后面会讲）也提供了对Spark Streaming作业定时检测的功能。目前每过5分钟对当前所有数据库中状态标记为Running的Spark Streaming作业进行状态检测，通过Yarn提供的REST APIs可以根据每个作业的Application Id查询作业在Yarn上的状态，如果状态处于非运行状态，则会尝试重启作业。

Muise Portal

在封装完所有的Spark Streaming之后，我们就需要有一个平台能够管理配置作业，Muise Portal就是这样的存在。Muise Portal目前主要支持了Storm与Spark Streaming两类作业，支持新建作业、Jar包发布、作业运行与停止等一系列功能。下图展现了新建作业的界面：

整体架构

最后这边给出一下目前携程实时平台的整体架构。

实时报表统计

实时报表统计与展现也是Spark Streaming使用较多的一个场景，数据可以基于Process Time统计，也可以基于Event Time统计。由于本身Spark Streaming不同批次的job可以视为一个个的滚动窗口，某个独立的窗口中包含了多个时间段的数据，这使得使用Spark Streaming基于Event Time统计时存在一定的限制。一般较为常用的方式是统计每个批次中不同时间维度的累积值并导入到外部系统，如ES；然后在报表展现的时基于时间做二次聚合获得完整的累加值最终求得聚合值。下图展示了携程IBU基于Spark Streaming实现的实时看板。

来源：软件供应链