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

 一、背景

Apache Flink 和 Apache Storm 是当前业界广泛使用的两个分布式实时计算框架。其中 Apache Storm(以下简称“Storm”)在美团点评实时计算业务中已有较为成熟的运用，有管理平台、常用 API 和相应的文档，大量实时作业基于 Storm 构建。

Apache Storm参考链接：http://storm.apache.org/

而 Apache Flink(以下简称“Flink”)在近期倍受关注，具有高吞吐、低延迟、高可靠和精确计算等特性，对事件窗口有很好的支持，目前在美团点评实时计算业务中也已有一定应用。

Apache Flink参考链接：https://flink.apache.org/

为深入熟悉了解 Flink 框架，验证其稳定性和可靠性，评估其实时处理性能，识别该体系中的缺点，找到其性能瓶颈并进行优化，给用户提供最适合的实时计算引擎，我们以实践经验丰富的 Storm 框架作为对照，进行了一系列实验测试 Flink 框架的性能。

计算 Flink 作为确保“至少一次”和“恰好一次”语义的实时计算框架时对资源的消耗，为实时计算平台资源规划、框架选择、性能调优等决策及 Flink 平台的建设提出建议并提供数据支持，为后续的 SLA 建设提供一定参考。

Flink 与 Storm 两个框架对比：

二、测试目标

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

1、测试场景

1)“输入-输出”简单处理场景

通过对“输入-输出”这样简单处理逻辑场景的测试，尽可能减少其它因素的干扰，反映两个框架本身的性能。

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

2)用户作业耗时较长的场景

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

3)窗口统计场景

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

4)精确计算场景(即消息投递语义为“恰好一次”)

Storm 仅能保证“至多一次” (At Most Once) 和“至少一次” (At Least Once) 的消息投递语义，即可能存在重复发送的情况。

有很多业务场景对数据的精确性要求较高，希望消息投递不重不漏。Flink 支持“恰好一次” (Exactly Once) 的语义，但是在限定的资源条件下，更加严格的精确度要求可能带来更高的代价，从而影响性能。

因此，我们测试了在不同消息投递语义下两个框架的性能，希望为精确计算场景的资源规划提供数据参考。

2、性能指标

1)吞吐量(Throughput)

• 单位时间内由计算框架成功地传送数据的数量，本次测试吞吐量的单位为：条/秒。
• 反映了系统的负载能力，在相应的资源条件下，单位时间内系统能处理多少数据。
• 吞吐量常用于资源规划，同时也用于协助分析系统性能瓶颈，从而进行相应的资源调整以保证系统能达到用户所要求的处理能力。假设商家每小时能做二十份午餐(吞吐量 20 份/小时)，一个外卖小哥每小时只能送两份(吞吐量 2 份/小时)，这个系统的瓶颈就在小哥配送这个环节，可以给该商家安排十个外卖小哥配送。

2)延迟(Latency)

• 数据从进入系统到流出系统所用的时间，本次测试延迟的单位为：毫秒。
• 反映了系统处理的实时性。
• 金融交易分析等大量实时计算业务对延迟有较高要求，延迟越低，数据实时性越强。
• 假设商家做一份午餐需要 5 分钟，小哥配送需要 25 分钟，这个流程中用户感受到了 30 分钟的延迟。如果更换配送方案后延迟变成了 60 分钟，等送到了饭菜都凉了，这个新的方案就是无法接受的。

三、测试环境

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

1、集群参数

2、框架参数

四、测试方法

1、测试流程

1)数据生产

Data Generator 按特定速率生成数据，带上自增的 id 和 eventTime 时间戳写入 Kafka 的一个 Topic(Topic Data)。

2)数据处理

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

3)指标统计

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

Metrics Collector 按 outTime 取五分钟的滚动时间窗口，计算五分钟的平均吞吐(输出数据的条数)、五分钟内的延迟(outTime - eventTime 或 outTime - inTime)的中位数及 99 线等指标，写入 MySQL 相应的数据表中。最后对 MySQL 表中的吞吐计算均值，延迟中位数及延迟 99 线选取中位数，绘制图像并分析。

2、默认参数

Storm 和 Flink 默认均为 At Least Once语义。

Storm 开启 ACK，ACKer 数量为 1。

Flink 的 Checkpoint 时间间隔为 30 秒，默认 StateBackend 为 Memory。

保证 Kafka 不是性能瓶颈，尽可能排除 Kafka 对测试结果的影响。

测试延迟时数据生产速率小于数据处理能力，假设数据被写入 Kafka 后立刻被读取，即 eventTime 等于数据进入系统的时间。

测试吞吐量时从 Kafka Topic 的最旧开始读取，假设该 Topic 中的测试数据量充足。

3、测试用例

1)Identity

Identity 用例主要模拟“输入-输出”简单处理场景，反映两个框架本身的性能。

输入数据为“msgId, eventTime”，其中 eventTime 视为数据生成时间。单条输入数据约 20 B。

进入作业处理流程时记录 inTime，作业处理完成后(准备输出时)记录 outTime。

作业从 Kafka Topic Data 中读取数据后，在字符串末尾追加时间戳，然后直接输出到 Kafka。

（编辑：ASP站长网）