对比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 表中。

（编辑：湖南网）

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