对比Flink与Storm性能，分布式实时计算框架该这样选

⑥ Windowed Word Count Flink At Least Once 与 Exactly Once 吞吐量对比

Windowed Word Count Flink At Least Once 与 Exactly Once 吞吐量对比

由于同一算子的多个并行任务处理速度可能不同，在上游算子中不同快照里的内容，经过中间并行算子的处理，到达下游算子时可能被计入同一个快照中。这样一来，这部分数据会被重复处理。因此，Flink 在 Exactly Once 语义下需要进行对齐，即当前最早的快照中所有数据处理完之前，属于下一个快照的数据不进行处理，而是在缓存区等待。当前测试用例中，在 JSON Parser 和 CountWindow、CountWindow 和 Output 之间均需要进行对齐，有一定消耗。为体现出对齐场景，Source/Output/Sink 并发度的并发度仍为 1，提高了 JSONParser/CountWindow 的并发度。具体流程细节参见前文 Windowed Word Count 流程图。

上图中橙色柱形为 At Least Once 的吞吐量，黄色柱形为 Exactly Once 的吞吐量。对比两者可以看出，在当前并发条件下，Exactly Once 的吞吐较 At Least Once 而言下降了 6.3%。

⑦ Windowed Word Count Storm At Least Once 与 At Most Once 吞吐量对比

Windowed Word Count Storm At Least Once 与 At Most Once 吞吐量对比

Storm 将 ACKer 数量设置为零后，每条消息在发送时就自动 ACK，不再等待 Bolt 的 ACK，也不再重发消息，为 At Most Once 语义。

上图中蓝色柱形为 At Least Once 的吞吐量，浅蓝色柱形为 At Most Once 的吞吐量。对比两者可以看出，在当前并发条件下，At Most Once 语义下的吞吐较 At Least Once 而言提高了 16.8%。

⑧ Windowed Word Count 单线程作业延迟

Windowed Word Count 单线程作业延迟

Identity 和 Sleep 观测的都是 outTime - eventTime，因为作业处理时间较短或 Thread.sleep 精度不高，outTime - inTime 为零或没有比较意义;Windowed Word Count 中可以有效测得 outTime - inTime 的数值，将其与 outTime - eventTime 画在同一张图上，其中 outTime - eventTime 为虚线，outTime - InTime 为实线。

观察橙色的两条折线可以发现，Flink 用两种方式统计的延迟都维持在较低水平;观察两条蓝色的曲线可以发现，Storm 的 outTime - inTime 较低，outTime - eventTime 一直较高，即 inTime 和 eventTime 之间的差值一直较大，可能与 Storm 和 Flink 的数据读入方式有关。

蓝色折线表明 Storm 的延迟随数据量的增大而增大，而橙色折线表明 Flink 的延迟随着数据量的增大而减小(此处未测至 Flink 吞吐量，接近吞吐时 Flink 延迟依然会上升)。

即使仅关注 outTime - inTime(即图中实线部分)，依然可以发现，当 QPS 逐渐增大的时候，Flink 在延迟上的优势开始体现出来。

⑨ Windowed Word Count Flink At Least Once 与 Exactly Once 延迟对比

Windowed Word Count Flink At Least Once 与 Exactly Once 延迟对比

图中黄色为 99 线，橙色为中位数，虚线为 At Least Once，实线为 Exactly Once。图中相应颜色的虚实曲线都基本重合，可以看出 Flink Exactly Once 的延迟中位数曲线与 At Least Once 基本贴合，在延迟上性能没有太大差异。

⑩ Windowed Word Count Storm At Least Once 与 At Most Once 延迟对比

Windowed Word Count Storm At Least Once 与 At Most Once 延迟对比

图中蓝色为 99 线，浅蓝色为中位数，虚线为 At Least Once，实线为 At Most Once。QPS 在 4000 及以前的时候，虚线实线基本重合;QPS 在 6000 时两者已有差异，虚线略高;QPS 接近 8000 时，已超过 At Least Once 语义下 Storm 的吞吐，因此只有实线上的点。

可以看出，QPS 较低时 Storm At Most Once 与 At Least Once 的延迟观察不到差异，随着 QPS 增大差异开始增大，At Most Once 的延迟较低。

⑪Windowed Word Count Flink 不同 StateBackends 吞吐量对比

Windowed Word Count Flink 不同 StateBackends 吞吐量对比

Flink 支持 Standalone 和 on Yarn 的集群部署模式，同时支持 Memory、FileSystem、RocksDB 三种状态存储后端(StateBackends)。由于线上作业需要，测试了这三种 StateBackends 在两种集群部署模式上的性能差异。其中，Standalone 时的存储路径为 JobManager 上的一个文件目录，on Yarn 时存储路径为 HDFS 上一个文件目录。

对比三组柱形可以发现，使用 FileSystem 和 Memory 的吞吐差异不大，使用 RocksDB 的吞吐仅其余两者的十分之一左右。

对比两种颜色可以发现，Standalone 和 on Yarn 的总体差异不大，使用 FileSystem 和 Memory 时 on Yarn 模式下吞吐稍高，使用 RocksDB 时 Standalone 模式下的吞吐稍高。

（编辑：衡阳站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!