Spark Streaming 对比 JStorm

001

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的对比：

002Spark Streaming设计与封装

在接入Spark Streaming的初期，首先需要考虑的是如何基于现有的实时平台无缝的嵌入Spark Streaming。原先的实时平台已经包含了许多功能：元数据管理、监控与告警等功能，所以第一步我们先针对Spark Streaming进行了封装并提供了丰富的功能。整套体系总共包含了Muise Spark Core、Muise Portal以及外部系统。

003

Muise Spark Core

Muise Spark Core是我们基于Spark Streaming实现的二次封装，用于支持携程多种消息队列，其中Hermes Kafka与源生的Kafka基于Direct Approach的方式消费数据，Hermes Mysql与Qmq基于Receiver的方式消费数据。接下来将要讲的诸多特性主要是针对Kafka类型的数据源。

Muise spark core主要包含了以下特性：

Kafka Offset自动管理

支持Exactly Once与At Least Once语义

提供Metric注册系统，用户可注册自定义metric

基于系统与用户自定义metric进行预警

Long running on Yarn，提供容错机制

004

Kafka Offset自动管理

封装muise spark core的第一目标就是简单易用，让用户以最简单的方式能够上手使用Spark Streaming。首先我们实现了帮助用户自动读取与存储Kafka Offset的功能，用户无需关心Offset是如何被处理的。

其次我们也对Kafka Offset的有效性进行了校验，有的用户的作业可能在停止了较长时间后重新运行会出现Offset失效的情形，我们也对此作了对应的操作，目前的操作是将失效的Offset设置为当前有效的最老的Offset。下图展现了用户基于muise spark core编写一个Spark streaming作业的简单示例，用户只需要短短几行代码即可完成代码的初始化并创建好对应的DStream：

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

Tips：

以后我都固定每天17:40更新文章了（节假日加班时间除外），记得每天来看哈