phpstormhtacc技巧_流计算框架 Flink 与 Storm 的机能比拟

作者：孙梦瑶

概述: 将分布式实时打算框架 Flink 与 Storm 进行性能比拟，为实时打算平台和业务供应数据参考。

Apache Flink 和 Apache Storm 是当前业界广泛利用的两个分布式实时打算框架。
个中 Apache Storm（以下简称“Storm”）在美团点评实时打算业务中已有较为成熟的利用（可参考 Storm 的可靠性担保测试），有管理平台、常用 API 和相应的文档，大量实时作业基于 Storm 构建。
而 Apache Flink（以下简称“Flink”）在近期倍受关注，具有高吞吐、低延迟、高可靠和精确打算等特性，对事宜窗口有很好的支持，目前在美团点评实时打算业务中也已有一定运用。

为深入熟习理解 Flink 框架，验证其稳定性和可靠性，评估其实时处理性能，识别该体系中的缺陷，找到其性能瓶颈并进行优化，给用户供应最适宜的实时打算引擎，我们以实践履历丰富的 Storm 框架作为对照，进行了一系列实验测试 Flink 框架的性能，打算 Flink 作为确保“至少一次”和“恰好一次”语义的实时打算框架时对资源的花费，为实时打算平台资源方案、框架选择、性能调头等决策及 Flink 平台的培植提出建议并供应数据支持，为后续的 SLA 培植供应一定参考。

Flink 与 Storm 两个框架比拟：

2. 测试目标

评估不同场景、不同数据压力下 Flink 和 Storm 两个实时打算框架目前的性能表现，获取其详细性能数据并找到处理性能的极限；理解不同配置对 Flink 性能影响的程度，剖析各种配置的适用场景，从而得出调优建议。

2.1 测试场景

“输入-输出”大略处理场景

通过对“输入-输出”这样大略处理逻辑场景的测试，尽可能减少其它成分的滋扰，反响两个框架本身的性能。

同时测算框架处理能力的极限，处理更加繁芜的逻辑的性能不会比纯粹“输入-输出”更高。

用户作业耗时较长的场景

如果用户的处理逻辑较为繁芜，或是访问了数据库等外部组件，其实行韶光会增大，作业的性能会受到影响。
因此，我们测试了用户作业耗时较长的场景下两个框架的调度性能。

窗口统计场景

实时打算中常有对韶光窗口或计数窗口进行统计的需求，例如一天中每五分钟的访问量，每 100 个订单中有多少个利用了优惠等。
Flink 在窗口支持上的功能比 Storm 更加强大，API 更加完善，但是我们同时也想理解在窗口统计这个常用场景下两个框架的性能。

精确打算场景（即投递语义为“恰好一次”）

Storm 仅能担保“至多一次” (At Most Once) 和“至少一次” (At Least Once) 的投递语义，即可能存在重复发送的情形。
有很多业务场景对数据的精确性哀求较高，希望投递不重不漏。
Flink 支持“恰好一次” (Exactly Once) 的语义，但是在限定的资源条件下，更加严格的精确度哀求可能带来更高的代价，从而影响性能。
因此，我们测试了在不同投递语义下两个框架的性能，希望为精确打算场景的资源方案供应数据参考。

2.2 性能指标

吞吐量（Throughput）

延迟（Latency）

为 Storm 和 Flink 分别搭建由 1 台主节点和 2 台从节点构成的 Standalone 集群进行本次测试。
个中为了不雅观察 Flink 在实际生产环境中的性能，对付部分测内容也进行了 on Yarn 环境的测试。

3.1 集群参数

3.2 框架参数

4. 测试方法

4.1 测试流程

数据生产

Data Generator 按特定速率天生数据，带上自增的 id 和 eventTime 韶光戳写入 Kafka 的一个 Topic（Topic Data）。

数据处理

Storm Task 和 Flink Task （每个测试用例不同）从 Kafka Topic Data 相同的 Offset 开始消费，并将结果及相应 inTime、outTime 韶光戳分别写入两个 Topic（Topic Storm 和 Topic Flink）中。

指标统计

Metrics Collector 按 outTime 的韶光窗口从这两个 Topic 中统计测试指标，每五分钟将相应的指标写入 MySQL 表中。

Metrics Collector 按 outTime 取五分钟的滚动韶光窗口，打算五分钟的均匀吞吐（输出数据的条数）、五分钟内的延迟（outTime - eventTime 或 outTime - inTime）的中位数及 99 线等指标，写入 MySQL 相应的数据表中。
末了对 MySQL 表中的吞吐打算均值，延迟中位数及延迟 99 线选取中位数，绘制图像并剖析。

4.2 默认参数

4.3 测试用例

Identity

Sleep

Windowed Word Count

5.1 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 倍。
__

5.2 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 的一半。
__

5.3 Sleep 吞吐量

从图中可以看出，Sleep 1 毫秒时，Storm 和 Flink 单线程的吞吐均在 900 条/秒旁边，且随着并发增大基本呈线性增大。
比拟蓝色和橙色的柱形可以创造，__此时两个框架的吞吐能力基本同等。
__

5.4 Sleep 单线程作业延迟（中位数）

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

5.5 Windowed Word Count 单线程吞吐量

单线程实行大小为 10 的计数窗口，吞吐量统计如图。
从图中可以看出，Storm 吞吐约为 1.2 万条/秒，Flink Standalone 约为 4.3 万条/秒。
Flink 吞吐依然为 Storm 的 3 倍以上。

5.6 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%。

5.7 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%。

5.8 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 在延迟上的上风开始表示出来。

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

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

5.10 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 的延迟较低。

5.11 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 模式下的吞吐稍高。

5.12 Windowed Word Count Flink 不同 StateBackends 延迟比拟

利用 FileSystem 和 Memory 作为 Backends 时，延迟基本同等且较低。
利用 RocksDB 作为 Backends 时，延迟稍高，且由于吞吐较低，在达到吞吐瓶颈前的延迟陡增。
个中 on Yarn 模式下吞吐更低，靠近吞吐时的延迟更高。
6. 结论及建议

6.1 框架本身性能

6.2 繁芜用户逻辑对框架差异的削弱

6.3 不同投递语义的差异

6.4 Flink 状态存储后端选择

StateBackend过程状态存储检讨点存储吞吐推举利用场景MemoryTM MemoryJM Memory高（3-5 倍 Storm）调试、无状态或对数据是否丢失重复无哀求FileSystemTM MemoryFS/HDFS高（3-5 倍 Storm）普通状态、窗口、KV 构造（建议作为默认 Backend）RocksDBRocksDB on TMFS/HDFS低（0.3-0.5 倍 Storm）超大状态、超长窗口、大型 KV 构造

6.5 推举利用 Flink 的场景

综合上述测试结果，以下实时打算场景建议考虑利用 Flink 框架进行打算：