对比Flink与Storm性能,分布式架构即时测算框架结构该这样选-必威app下载_betway必威体育官网_必威体育亚洲官网

一、布景

Apache Flink 和 Apache Storm 是当时业界广泛运用的两个分布式实时核算结构。其间 Apache Storm(以下简称“Storm”)在美团点评实时核算事务中已航椒4号有较为老练的运用,有办理渠道、常用 API 和相应的文档,许多实时作业根据 Storm 构建。

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

而 Apache Flink(以下简称“Fli变声星途nk”)在近期倍受重视,具有高吞吐、低推迟、高牢靠和准确核算等特性,对事情窗口有很好的支撑,现在在美团点评实时核算事务中也已有必定运用。

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

为深化了解了解 Flink 结构,验证其稳定性和牢靠性,评价其实时处理功用,辨认该体系中的缺陷,找到其功用瓶颈并进行优化,给用户供给最适合的实时核算引擎,咱们以实践经验丰富的 Storm 高清mp4结构作为对照,进行了一系列试验测验 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 数比照Flink与Storm功用,分布式架构即时测算结构结构该这样选-必威app下载_betway必威体育官网_必威体育亚洲官网 量为 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比照Flink与Storm功用,分布式架构即时测算结构结构该这样选-必威app下载_betway必威体育官网_必威体育亚洲官网 Data 中读取数据后,比照Flink与Storm功用,分布式架构即时测算结构结构该这样选-必威app下载_betway必威体育官网_必威体育亚洲官网 在字符串结尾追加时刻戳,然后直接输出到 Kafka。

  • 输出数据为折纸飞机“msgId, eventTime, inTime, outTime”。单条输出数据约 50 B。

Identity 流程图

2)Sleep

  • Sleep 用例首要模仿用户作业耗时较长的场景,反映杂乱用户逻辑对结构差异的削弱,比较两个结构的调度功用

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

  • 读入数据后,等候必定时长(1 ms)后在字符串结尾追加时刻戳后输出

Sleep 流程图

3)Windowed Word Count

  • Windowed Word Count 用例首要模仿窗口核算场景,反映mvp是什么意思两个结构在进行窗口核算时功用的差异

  • 此外,还用其进行了准确核算场景的测验,反映 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 用了原生的 CountWind牵挂ow 和相应的 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 作为推迟,图中蓝色折线为 Sdb库伯torm,橙色折线为 F握笔的正确姿态li比照Flink与Storm功用,分布式架构即时测算结构结构该这样选-必威app下载_betway必威体育官网_必威体育亚洲官网 nk。虚线为 99 线,实线为中位数。

  • 从图中能够看出跟着数据量逐步增大,Identity 的推迟逐步增大。其间 99 线的增大速度比中位数快,Storm 的 增大速度比 Flink 快。

  • 其间 QPS 在 比照Flink与Storm功用,分布式架构即时测算结构结构该这样选-必威app下载_betway必威体育官网_必威体育亚洲官网 80000 以上的测验数据超越了 Storm 单线程的吞吐才能,无法对 Storm 进行测验,只要 Flink 的曲线。

  • 比照折线最右端的数据能够看出,Storm QPS 挨近吞吐时推迟中位数约 100 毫秒,99 线约 700 毫秒,Flink 中位数约 50 毫秒,99 线约 300 毫秒。Flink 在满吞吐时的推迟约为 Storm 的一半

③ Sleep吞吐量

Sleep 吞吐量

  • 从图中能够看出,Sleep 1 毫秒时,Storm 和 Flink 单线程的吞吐均在 900比照Flink与Storm功用,分布式架构即时测算结构结构该这样选-必威app下载_betway必威体育官网_必威体育亚洲官网 条/秒左右,且跟着并发增大根本呈线性增大。

  • 比照蓝色和橙色的柱形能够发现,此刻两个结构的吞吐才能根本共同

④ 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 倍以上

⑥ Windowed Word Count Flink At Least Once 与 Exactly Once 吞吐量比照

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%

⑦ Windowed Word Count Storm At Least Once 与 At Most Once 吞吐量比照

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%

⑧ Windowed Word Count 单线程作业推迟

Windowed Word Count 单线程作业推迟

  • Identity 和 Sl比照Flink与Storm功用,分布式架构即时测算结构结构该这样选-必威app下载_betway必威体育官网_必威体育亚洲官网 eep 观测的都是 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 在推迟上的优势开端表现出来

⑨ Windowed Word Count Flink At Least Once 与 Exactly Once 推迟比照

Windowed Word Count Flink At Least Once 与 Exactly Once 推迟比照

  • 图中黄色为 99 线,橙色为中位数,虚线为 At Least Once,实线为 Exactly Once。图中相应色彩的真假曲线都根本重合,能够看出 Flink Exactly Once 的推迟中位数曲线与 At Least Once 根本贴合,在推迟上功用没有太大差异

⑩ Windowed Word Count Storm At Least Once 与 At Most Once 推迟比照

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 的推迟较低

⑪Windowed Word Count Flink 不同 StateBackends 吞吐量比照

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

⑫Windowed Word Count Flink 不同 StateBackends 推迟比照

Windowed Word Count Flink 不同 StateBackends 推迟比照

  • 运用 FileSystem 和 Memory 作为 Backends 时,推迟根本共同且较低。

  • 运用 RocksDB 作为 Backends 时,推迟稍高,且因为吞吐较低,在抵达吞吐瓶颈前的推迟猛增。其间 on Yarn 形式下吞吐更低,挨近吞吐时的推迟更高。

六、结论及主张

1、结构自身功用

  • 的测验成果能够看出,Storm 单线程吞吐约为 8.7 万条/秒,Flink 单线程吞吐可达 35 万条/秒。Flink 吞吐约为 透明人Storm 的 3-5 倍。

  • 的测验成果能够看出,Storm QPS 挨近吞吐时推迟(含 Kafka 读写时刻)中位数约 100 毫秒,99 线约 700 毫秒,Flink 中位数约 50 毫秒,99 线约 300 毫秒。Flink 在满吞吐时的推迟约为 Storm 的一半,且跟着 QPS 逐步增大,Flink 在推迟上的优势开端表现出来。

  • 综上可得,Flink 结构自身功用优于 Storm

2、杂乱用户逻辑对结构差异的削弱

  • 比照的测验成果能够发现,单个 Bolt Sleep 时长抵达 1 毫秒时,Flink 的推迟仍低于 Storm,但吞吐优势已根本无法表现。

  • 因而,用户逻辑越杂乱,自身耗时越长,针对该逻辑的测验表现出来的结构的差异越小。

3、不同音讯投递隐婚100语义的差异

  • 的测验成果能够看出,Flink Exactly Once 的吞吐较 At Least Once 而言下降 6.3%,推迟差异不大;Storm At Most Once 语义下的吞吐较 At Least Once 提高 16.8%,推迟稍有下降。

  • 因为 Storm 会对每条音讯进行 ACK,Flink 是根据一批音讯做的检查点,不同的完成原理导致两者在 At Least Once 语义的花费差异较大,然后影响了功用。而 Flink 完成 Exactly Once 语义仅增加了对齐操作,因而在算子并发量不大、没有呈现慢节点的状况下对 Flink 功用的影响不大。Storm At Most Once 语义下的功用仍然低于 Flink。

4、Flink 状况存储后端挑选

  • Flink 供给了内存、文件体系、RocksDB 三种 StateBackends,结合的测验成果,三者的比照如下:

5、引荐运用 Flink 的场景

归纳上述测验成果,以下实时核算场景主张考虑运用 Flink 结构进行核算:

  • 要求音讯投递语义为 Exactly Once的场景;

  • 数据量较大,要求高吞吐低推迟的场景;

  • 需求进行状况办理或窗口核算的场景。

七、展望

  • 本次测验中尚有一些内容没有进行愈加深化的测验,有待后续测验弥补。例如:

    • Exactly Once 在并发量增大的时分是否吞吐会显着下降?

    • 用户耗时到 1ms 时结构的差异现已不再显着(Thread.sleep() 的精度只能到毫秒),用户耗时在什么范围内 Flink 的优势仍然能表现出来?

  • 本次测验仅调查了吞吐量和推迟两项目标,关于体系的牢靠性、可扩展性等重要的功用目标没有在核算数据层面进行重视,有待后续弥补。

  • Flink 运用 RocksDBStateBackend 时的吞吐较低,有待进一步探究和优化。

  • 关于 Flink 的更高档 API,如 Table API & SQL 及 CEP 等,需求进一步了解和完善。

>>>>

参阅资料

  • 分布式流处理结构——功用比照和功用评价.

  • intel-hadoop/HiBench: HiBench is a big data benchmark suite.

    https://github.com/Intel-bigdata/HiBench

  • Yahoo的流核算引擎基准测验.

    http://ifeve.com/yahoo%E7%9A%84%E6%B5%81%E8%AE%A1%E7%AE%97%E5%BC%95%E6%93%8E%E5%9F%BA%E5%87%86%E6%B5%8B%E8%AF%95/

  • Extending the Yahoo! Streaming Benchmark.

    https://www.ververica.com/blog/extending-the-yahoo-streaming-benchmark

作者:梦瑶

来历:美团技术团队(ID:meituantech)

dbaplus社群欢迎广阔技术人员投稿,投稿邮箱:editor@dbaplus.cn

对大数据技术运用尚不娴熟?

想玩转热门技术,一起掌握先机?

无妨来DAMS学点独家技术

↓↓扫码可了解更多概况及报名↓↓

2019 DAMS我国数据智能办理峰会-上海站

评论(0)