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

输出数据为“msgId, eventTime, inTime, outTime”。单条输出数据约 50 B。

Identity 流程图

2)Sleep

Sleep 用例主要模拟用户作业耗时较长的场景，反映复杂用户逻辑对框架差异的削弱，比较两个框架的调度性能。

输入数据和输出数据均与 Identity 相同。

读入数据后，等待一定时长(1 ms)后在字符串末尾追加时间戳后输出

Sleep 流程图

3)Windowed Word Count

• Windowed Word Count 用例主要模拟窗口统计场景，反映两个框架在进行窗口统计时性能的差异。
• 此外，还用其进行了精确计算场景的测试，反映 Flink 恰好一次投递的性能。
• 输入为 JSON 格式，包含 msgId、eventTime 和一个由若干单词组成的句子，单词之间由空格分隔。单条输入数据约 150 B。
• 读入数据后解析 JSON，然后将句子分割为相应单词，带 eventTime 和 inTime 时间戳发给 CountWindow 进行单词计数，同时记录一个窗口中最大最小的 eventTime 和 inTime，最后带 outTime 时间戳输出到 Kafka 相应的 Topic。
• Spout/Source 及 OutputBolt/Output/Sink 并发度恒为 1，增大并发度时仅增大 JSONParser、CountWindow 的并发度。
• 由于 Storm 对 window 的支持较弱，CountWindow 使用一个 HashMap 手动实现，Flink 用了原生的 CountWindow 和相应的 Reduce 函数。

Windowed Word Count 流程图

五、测试结果

① Identity 单线程吞吐量

Identity 单线程吞吐量

上图中蓝色柱形为单线程 Storm 作业的吞吐，橙色柱形为单线程 Flink 作业的吞吐。

Identity 逻辑下，Storm 单线程吞吐为 8.7万条/秒，Flink 单线程吞吐可达35万条/秒。

当 Kafka Data 的 Partition 数为 1 时，Flink 的吞吐约为 Storm 的 3.2 倍;当其 Partition 数为 8 时，Flink 的吞吐约为 Storm 的 4.6 倍。

由此可以看出，Flink 吞吐约为 Storm 的 3-5 倍。

② Identity 单线程作业延迟

Identity 单线程作业延迟

采用 outTime - eventTime 作为延迟，图中蓝色折线为 Storm，橙色折线为 Flink。虚线为 99 线，实线为中位数。

从图中可以看出随着数据量逐渐增大，Identity 的延迟逐渐增大。其中 99 线的增大速度比中位数快，Storm 的 增大速度比 Flink 快。

其中 QPS 在 80000 以上的测试数据超过了 Storm 单线程的吞吐能力，无法对 Storm 进行测试，只有 Flink 的曲线。

对比折线最右端的数据可以看出，Storm QPS 接近吞吐时延迟中位数约 100 毫秒，99 线约 700 毫秒，Flink 中位数约 50 毫秒，99 线约 300 毫秒。Flink 在满吞吐时的延迟约为 Storm 的一半。

③ Sleep吞吐量

Sleep 吞吐量

从图中可以看出，Sleep 1 毫秒时，Storm 和 Flink 单线程的吞吐均在 900 条/秒左右，且随着并发增大基本呈线性增大。

对比蓝色和橙色的柱形可以发现，此时两个框架的吞吐能力基本一致。

④ Sleep 单线程作业延迟(中位数)

Sleep 单线程作业延迟(中位数)

依然采用 outTime - eventTime 作为延迟，从图中可以看出，Sleep 1 毫秒时，Flink 的延迟仍低于 Storm。

⑤ Windowed Word Count 单线程吞吐量

Windowed Word Count 单线程吞吐量

单线程执行大小为 10 的计数窗口，吞吐量统计如图。

从图中可以看出，Storm 吞吐约为 1.2 万条/秒，Flink Standalone 约为 4.3 万条/秒。Flink 吞吐依然为 Storm 的 3 倍以上。

（编辑：ASP站长网）