1.背景

Apache Flink 和 Apache Storm 是当前业界广泛使用的两个分布式实时计算框架。其中 Apache Storm（以下简称“Storm”）在美团点评实时计算业务中已有较为成熟的运用（可参考 Storm 的 可靠性保证测试），有管理平台、常用 API 和相应的文档，大量实时作业基于 Storm 构建。而 Apache Flink（以下简称“Flink”）在近期倍受关注，具有高吞吐、低延迟、高可靠和精确计算等 特性，对事件窗口有很好的支持，目前在美团点评实时计算业务中也已有一定应用。
为深入熟悉了解 Flink 框架，验证其稳定性和可靠性，评估其实时处理性能，识别该体系中的 缺点，找到其性能瓶颈并进行优化，给用户提供最适合的实时计算引擎，我们以实践经验丰富 的 Storm 框架作为对照，进行了一系列实验测试 Flink 框架的性能，计算 Flink 作为确保“至 少一次”和“恰好一次”语义的实时计算框架时对资源的消耗，为实时计算平台资源规划、框 架选择、性能调优等决策及 Flink 平台的建设提出建议并提供数据支持，为后续的 SLA 建设提供一定参考。
Flink 与 Storm 两个框架对比：

流计算框架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）
  • 单位时间内由计算框架成功地传送数据的数量，本次测试吞吐量的单位为：条/秒。
  • 反映了系统的负载能力，在相应的资源条件下，单位时间内系统能处理多少数据。 •
  • 吞吐量常用于资源规划，同时也用于协助分析系统性能瓶颈，从而进行相应的资源调整以 保证系统能达到用户所要求的处理能力。假设商家每小时能做二十份午餐（吞吐量 20 份/ 小时），一个外卖小哥每小时只能送两份（吞吐量 2 份/小时），这个系统的瓶颈就在小哥配 送这个环节，可以给该商家安排十个外卖小哥配送。
• 延迟（Latency）
  • 数据从进入系统到流出系统所用的时间，本次测试延迟的单位为：毫秒。
  • 反映了系统处理的实时性。
  • 金融交易分析等大量实时计算业务对延迟有较高要求，延迟越低，数据实时性越强。
  • 假设商家做一份午餐需要 5 分钟，小哥配送需要 25 分钟，这个流程中用户感受到了 30 分钟的延迟。如果更换配送方案后延迟变成了 60 分钟，等送到了饭菜都凉了，这个新的方案就是无法接受的。

3.测试环境

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

3.1 集群参数