copy from
http://wiki.sankuai.com/pages/viewpage.action?pageId=528017128
| Storm | ||
|---|---|---|
| Spark Streaming | Storm | |
| 数据一致性 | 能够保证至少一次的语义，但是一次且仅一次的语义很难保证 | acker机制+事务拓扑机制，可以保证一次且仅一次的语义 |
| 可用性 | 在美团是Spark Streaming On YARN的模式，YARN一旦运维，就会挂；与已经有spark streaming使用经验的思源沟通后发现，挂掉的情况比较多 | storm无论是nimbus、supervisor，还是topology、worker，都有很强的健壮性，挂掉不会有太大的影响；同时只要自己代码中做好完善的宕机恢复机制，不会有太大的问题 |
| join操作 | 可以方便的实现batch+batch的join，但是要实现精准的全量join，非常难 | storm同样也支持batch+batch的join，但是可以自己手工编码，基于外部缓存（比如tair），灵活的根据自己的业务需求实现全量join算法 |
| 吞吐量 | 相对较好 | 相对较差 |
| 实时性 | 秒级 | 毫秒级 |
| 操作易用性 | 相对比较易用 | 相对较难使用 |
| 项目本身的成熟性和稳定性 | 比较新，在业界成熟大规模应用的案例较少，特别是在美团使用的经验非常少而且对比之前的spark core/spark sql使用经验，spark streaming本身依赖spark core，因此很可能有未知的bug，稳定性未知 | storm在业界，特别是美团内部，有多年大量的线上项目使用经验，经历了足够的考研，非常的成熟，稳定性非常好 |
| 与机器学习的结合使用 | 天然能够与spark mllib/ spark graphx整合使用，非常适合online learning | 与在线机器学习的算法结合使用，较为困难 |
| 对SQL的支持 | 天然能够支持SQL | 没有成熟的SQL支持方案 |
结论：
1、spark streaming：不适合在直接面向外部用户（用户/商家）大规模直接使用；较为适合在面向内部（PM/运营）的项目中使用，特别是需要结合机器学习的场景，同时需要给RD足够的机会和时间踩坑，积累经验
2、storm：适合在所有实时计算的场景中使用；如果是面向内部的，而且与机器学习相结合的场景，建议使用spark streaming，不建议用storm