Location:Home > Spark streaming vs JStorm

Spark streaming vs JStorm

最近在调研如何把阿里内部的流数据源接入Spark Streaming。也对接了几个使用JStorm的用户。目前看来大部分时候大家在选择技术方案的时候还是比较迷茫,是该选择JStorm还是Spark Streaming,一般会流于一些并不重要问题的讨论,最后做出目光非常短浅的选择,几个月之后再改变技术方案。造成严重的开发量的浪费,甚至拖延关键产品的上线,或者上线后问题层出不穷,不断和业务方妥协谈判。所以,明确这两个最主流的流计算框架的应用场景至关重要,下面我说下自己的经验之谈,避免更多的人走弯路。
Spark Streaming和JStorm的本质区别是想要解决的问题不同:Spark Streaming是批量处理的Spark向流计算多迈了一步,JStorm是真正的流式流水线计算向批量计算(trident可以有部分的批量处理)多迈出了一步。使得看似毫不相关的两个问题有了交集。这个交集让很多人困惑。其实根本的问题是真正理解流计算本质的项目负责人少之又少。流计算不是实时计算。实时计算和离线计算对应,是计算的场景,是需求。流计算和批量计算对应是计算的方式。流计算的本质是:无状态性!批量计算的本质是有状态计算,或者说没有状态性的批量计算根本就是流计算,只是把时间维度的计算变成了空间维度的计算。而有状态的流计算本质也是批量计算,只是把状态的需求藏在流式之外的闭包中。这么看了,一切了然,根本没什么交集,判断自己的项目使用哪种技术方案根本不需要问询需求方:你要多少的延迟?如果你只是需要低延迟,那你只是在挑战现在计算机的计算能力。真正你要关心的是业务计算的逻辑是不是主要是无状态的。
下面举一个使用流计算的主要场景,因为我主要在阿里负责对接不同项目使用Spark的技术方案。所以主要是阿里的不同项目如何应用流计算框架。
用户行为log的基本sum,count,distinct需求。这里的log数据量巨大,如果技术方案不对,将对公司资源造成极大浪费。这个需求中,sum,count都是无状态的计算,但是distinct确实有状态的计算,所以最好的解决方案是sum,count在JStorm中计算,distinct在Spark中计算。但是两个系统同时存在会带来很多问题,数据落地拉起的延迟,这在阿里还是很大的瓶颈。但如果不考虑数据落地拉起,那么Storm接Spark是最好的技术方案之一。
其实还有很多项目都存在大量的状态保存的需求,都是需要使用Spark Streaming来计算的。其实就算使用Spark和Storm的混合架构,数据两次进内存(进程间数据流)也是对网络带宽的浪费,所以如果在不考虑很高的实时要求的情况下,完全可以用Spark Streaming取代掉Storm,对于有状态运算的项目。对于没有状态的项目,当然可以完全用Storm了。

Related
Your Answer
(Ctrl+Enter To Post)   
    Newest
    Copyright © 2015-2017 163JAVA.COM All Rights Reserved.