概览 Storm vs. Flink

根据StackOverflow15年的回答，大意是Storm和Flink的主要差距在于high-level API抽象得更好( 包括window机制、自定义节点状态), 一致性保证实现得更轻量。三年过去了，现在Storm和Flink的主要差异在哪里？本文试图从流处理的内部机制和运维能力方面概括他们的异同,本文是Storm和Flink差异的开篇，在后续的文章中会选一些核心功能来详细对比实现上的差异。

内部实现方面：

• 高级API: 在storm 1.0.x版本中，storm trident已经支持StormSQL，但在最新版本1.2.2中仍然被标注为试验阶段。Flink提供了Batch API,相当于Storm的Trident。
• Window机制实现：Flink和Storm都支持事件时间和处理时间, 都支持tumbing window和sliding window。
• Backpressure: 由于内部通信机制的不同，Storm和Flink的back pressure实现依然差异较大。Storm可以通过限制吞吐和队列高低水位两种方式实现backpressure。在实践过程中，我们使用队列高低水位backpressure时遇到了storm backpressure机制导致spout停止发送数据的问题，从STORM-1949看，似乎1.0.3+ 和1.1.0+有修复。比起Flink,Flink通过网络缓存高低水位和Buffer队列阻塞的方式实现backpressure。Storm可以通过metric日志查看历史所有的backpressure情况。Flink没有记录历史的backpressure, 但可以在Dashboard实时观察backpressure情况。
• Exactly-once保证: 从原理上来说，Strom和Flink的实现类似。都是基于分布式快照和两阶段提交协议，都需要上游可重播。 不同点在于，Flink的Stream和Batch都支持分布式快照，而Storm只有Trident API支持。
• 用户自定义的节点状态: storm和Flink都支持用户自定义节点状态， Flink支持in-memory , 本地磁盘, RocksDB而storm支持hbase和in-memory和redis作为状态的存储backend。

运维方面：

• metric管理：Flink的metric管理比storm更友好，支持所有metric查看、搜索及可视化 ，Storm UI只提供部分系统metric的查看且不支持可视化。Flink的metric支持JMX、Promethes、Graphite、StatsD、DataDog、Slf4j输出，而Storm支持日志输出或通过HTTP发送（格式不能自定义）。
• 日志查看：Flink dashboard提供日志查看。 storm提供了logviewer组件，但是STORM-3238提到logviewer存在bug,实际无法查看日志结果,这个bug至今未修复。
• Resource Mangement System支持: storm支持yarn,mesos。但storm on yarn已经几年没更新，storm mesos在不同的github repository，最近一次更新在4个月前，看起来并不活跃。Flink on yarn和mesos上一次更新皆为一个月内。(于2018.12.4观察)
• 调度机制： standalone模式下，Storm默认优先分配空闲slot最多的机器节点。支持多种分配机制（笔者偷懒，还没细看）　。Flink的task->slot分配只有一种机制，支持用户自定义slot group。

Storm在高级API层面上相对Flink落后，但不可否认的是，Storm在努力让差距变小。在hadoop生态支持上，storm似乎没有进展，而JStorm也半年未更新。Strom和JStorm也未合并完成,合并进度见cf。而在运维方面，storm的进展缓慢。