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更新文章了(节假日加班时间除外),记得每天来看哈

  • 发表于:
  • 原文链接https://kuaibao.qq.com/s/20180913B1F4HT00?refer=cp_1026
  • 腾讯「云+社区」是腾讯内容开放平台帐号(企鹅号)传播渠道之一,根据《腾讯内容开放平台服务协议》转载发布内容。

扫码关注云+社区

领取腾讯云代金券

年度创作总结 领取年终奖励