Flink,Storm,SparkStreaming效能對比
Yahoo 的 Storm 團隊曾發表了一篇部落格文章 ,並在其中展示了 Storm、Flink 和 Spark Streaming 的效能測試結果。該測試對於業界而言極 具價值,因為它是流處理領域的第一個基於真實應用程式的基準測試。
該應用程式從 Kafka 消費廣告曝光訊息,從 Redis 查詢每個廣告對應的廣 告宣傳活動,並按照廣告宣傳活動分組,以 10 秒為視窗計算廣告瀏覽量。 10 秒視窗的最終結果被儲存在 Redis 中,這些視窗的狀態也按照每秒記錄 一次的頻率被寫入 Redis,以方便使用者對它們進行實時查詢。
在最初的效能 測評中,因為 Storm 是無狀態流處理器(即它不能定義和維護狀態),所以 Flink 作業也按照無狀態模式編寫。所有狀態都被儲存在 Redis 中。
在效能測評中,Spark Streaming 遇到了吞吐量和延遲性難 兩全的問題。隨著批處理作業規模的增加,延遲升高。如果為了降低延遲而縮減規模,吞吐量就會減少。Storm 和 Flink 則可以在吞吐量增加時維持低延遲。
為了進一步測試 Flink 的效能,測試人員設定了一系列不同的場景,並逐步測試。
最初的效能測評專注於在相對較低的吞吐量下,測量端到端的延遲,即 使在極限狀態下,也不關注容錯性。此外,應用程式中的 key 基數非常小 (100),這使得測試結果無法反映使用者量大的情況,或者 key 空間隨著時間增長的情況.
由於最初的測試結果顯示 Spark Streaming 的效能欠佳,因此這次的測試對 象只有 Storm 和 Flink,它們在最初的測試中有著類似的表現。
第 1 個變化是利用 Flink 提供的狀態容錯特性重新實現應用程式,如圖 5-15 所示。這使得應用程式能保證 exactly-once。
第 2 個變化是通過用每秒可以生成數百萬事件的資料生成器來增加輸入流 的資料量。
結果如下:
使用高吞吐資料生成器的結果:(A)當Storm 與 Kafka 一起使用時,應用程式可以保持每秒 40 萬事件的處理速度,並且瓶頸在於 CPU;當 Flink 與 Kafka 一起使用時,應用程式可以保持每秒300 萬事件的處理速度,並且瓶頸在於網路;
(B)當消除網路瓶頸時,Flink 應用程式可以保持每秒1500 萬事件的處理速度;
(C)在額外的測試中,訊息佇列由MapR Streams 提供,並且採用10 個高效能網路節點(硬體與前兩種情況中的不同);Flink 應用程式可以保持每秒1000 萬事件的處理速度.
Storm 能夠承受每秒 40 萬事件,但受限於 CPU;Flink 則可以達到每秒 300 萬事件(7.5 倍),但受限於 Kafka 叢集和 Flink 叢集之間的網路。
為了看看在沒有網路瓶頸問題時 Flink 的效能如何,我們將資料生成器移到 Flink 應用程式的內部。在這樣的條件下,Flink 可以保持每秒 1500 萬事件的處理速度(這是 Storm 的 37.5 倍)
將資料生成器整合到 Flink 應用程式中,可以測試效能極限,但這種 做法並不現實,因為現實世界中的資料必須從應用程式的外部流入。
值得注意的是,這絕對不是 Kafka 的極限(Kafka 可以支撐比這更大的吞吐量),而僅僅是測試所用的硬體環境的極限——Kafka 叢集和 Flink 叢集 之間的網路連線太慢。
最後一個變化是增加 key 基數(廣告宣傳活動的數量)。在最初的測試中, key 基數只有 100。這些 key 每秒都會被寫入 Redis,以供查詢。當 key 基數 增加到 100 萬時,系統的整體吞吐量減少到每秒 28 萬事件,因為向 Redis寫入成了系統瓶頸。使用 Flink 可查詢狀態的一個早期原型可以消除這種瓶頸,使系統的處理速度恢復到每秒 1500 萬事件,並 且有 100 萬個 key 可供查詢.
通過將查詢功能移入Flink 可查詢狀態的一個原型,系統甚至可以在key 基數非常大的情況下仍然維持每秒 1500 萬事件的處理速度.
本例說明了什麼呢?通過避免流處理瓶頸,同時利用 Flink 的有狀態流處理 能力,可以使吞吐量達到Storm 的 30 倍左右,同時還能保證exactly-once 和高可用性。大致來說,這意味著與 Storm 相比,Flink 的硬體成本或雲端計算成本僅為前者的 1/30,同樣的硬體能處理的資料量則是前者的 30 倍。
更多Flink相關文章:
穿梭時空的實時計算框架——Flink對時間的處理
Flink快速入門--安裝與示例執行
大資料實時處理的王者-Flink
更多實時計算,Flink,Kafka的技術文章歡迎關注實時流式計算
相關推薦
Flink,Storm,SparkStreaming效能對比
Yahoo 的 Storm 團隊曾發表了一篇部落格文章 ,並在其中展示了 Storm、Flink 和 Spark Streaming 的效能測試結果。該測試對於業界而言極 具價值,因為它是流處理領域的第一個基於真實應用程式的基準測試。 該應用程式從 Kafka 消費廣告曝光訊息,從 Redis 查詢每
【Flink】流計算框架Flink與Storm的效能對比
1. 背景 Apache Flink 和 Apache Storm 是當前業界廣泛使用的兩個分散式實時計算框架。其中 Apache Storm(以下簡稱“Storm”)在美團點評實時計算業務中已有較為成熟的運用(可參考 Storm 的可靠性保證測試),有管理平臺、常用
流計算框架 Flink 與 Storm 的效能對比
1. 背景 Apache Flink 和 Apache Storm 是當前業界廣泛使用的兩個分散式實時計算框架。其中 Apache Storm(以下簡稱“Storm”)在美團點評實時計算業務中已有較為成熟的運用(可參考 Storm 的可靠性保證測試),有管理平臺、常用 AP
Storm VS Flink ——效能對比
1.背景 Apache Flink 和 Apache Storm 是當前業界廣泛使用的兩個分散式實時計算框架。其中 Apache Storm(以下簡稱“Storm”)在美團點評實時計算業務中已有較為成熟的運用(可參考 Storm 的 可靠性保證測試),有管理平臺、常用 API 和相應的文件,大量實時作業基
hibernate抓取策略效能分析,子查詢/連線查詢效能對比
https://blog.csdn.net/qq_40762011/article/details/82993283 https://blog.csdn.net/lzm18064126848/article/details/50578285 https://blog.csdn.net/luckarecs/
C++ Vector遍歷的幾種方式及效能對比
幾種容器遍歷方法 1.迭代器 for (std::vector<int>::iterator it = vecTest.begin(); it != vecTest.end(); ++it) { tempNum = *it; } 2.C++11 新增關鍵字auto f
redis 使用管道pipeline和不使用管道的效能對比
predis3.php程式碼如下所示: <?php include('runtime.php'); try{ $redis = new Redis(); $redis->connect('127.0.0.1', 6379); $runtime= new runtime
Python霧裡看花-list與set十萬資料查詢效能對比
# -*- coding: utf-8 -*- import random import time num = 100000 listA = [random.randint(1, i) for i in range(1, num)] setB = set() while len(set
expdp和exp效能對比與原理分析
分享一下我老師大神的人工智慧教程!零基礎,通俗易懂!http://blog.csdn.net/jiangjunshow 也歡迎大家轉載本篇文章。分享知識,造福人民,實現我們中華民族偉大復興!  
轉載:Python Web 框架:Django、Flask 與 Tornado 的效能對比
原文地址: https://www.jianshu.com/p/9960a9667a5c 寫在前面: 本文的資料涉及到我面試時遇到過的問題,大概一次 http 請求到收到響應需要多少時間。這個問題在實際工作中與框架有比較大的關係,因此特別就框架的效能做了一次分析。
redis和kafka的寫效能對比
kafka插入程式碼如下所示: <?php $conf = new RdKafka\Conf(); $rk = new RdKafka\Producer($conf); $rk->setLogLevel(LOG_DEBUG); $rk->addBrokers("127.0.
ios中pthread_mutex和dispatch_semaphore效能對比
因為自旋鎖有風險已經別踢出局不再使用,所以對比了一下pthread提供的pthread_mutex_t以及dispatch_semaphore。 測試時候特別注意debug模式和release模式,結果可能會完全不一樣。 測試方法 模擬實際使用的執行緒搶佔,分別在不同執行緒迴圈很多次
MyISAM與InnoDB兩者之間區別與選擇,總結,效能對比
1、MyISAM:預設表型別,它是基於傳統的ISAM型別,ISAM是Indexed Sequential Access Method (有索引的順序訪問方法) 的縮寫,它是儲存記錄和檔案的標準方法。不是事務安全的,而且不支援外來鍵,如果執行大量的select,insert MyISAM比較適合。 2、Inn
ND4J求多元線性迴歸以及GPU和CPU計算效能對比
上一篇部落格《梯度下降法求多元線性迴歸及Java實現》簡單了介紹了梯度下降法,並用Java實現了一個梯度下降法求迴歸的例子。本篇部落格,嘗試用dl4j的張量運算庫nd4j來實現梯度下降法求多元線性迴歸,並比較GPU和CPU計算的效能差異。 一、ND4J簡介 &nb
Flink與SparkStreaming之Counters& Accumulators累加器雙向應用案例實戰-Flink牛刀小試
版權宣告:本套技術專欄是作者(秦凱新)平時工作的總結和昇華,通過從真實商業環境抽取案例進行總結和分享,並給出商業應用的調優建議和叢集環境容量規劃等內容,請持續關注本套部落格。版權宣告:禁止轉載,歡迎學習。QQ郵箱地址:[email protected],如有任何問題,可隨時聯絡。 1 累加器應用場
MySQL的統計總數count(*)與count(id)或count(欄位)的之間的各自效率效能對比
執行效果: 1. count(1) and count(*) 當表的資料量大些時,對錶作分析之後,使用count(1)還要比使用count(*)用時多了! 從執行計劃來看,count(1)和count(*)的效果是一樣的。 但是在表做過分析之後,count
PhpSpreadsheet VS Box\Spout讀取excel效能對比
phpspreadsheet版本:1.5.0 spout版本:2.7.3 在同樣的環境下,執行程式碼,spout的在記憶體使用和時間花費上都佔優,在phpspreadsheet讀取失敗的文件spout依然能正確完成讀取。 spout程式碼 <?php
PG copy&insert效能對比
目錄 測試環境 表結構 CASE1 結果 CASE 2 結果 CASE 3 結果 TPS修正 CASE 4 結果 結論 測試環境 Intel(R) Core(TM) i7-4790 CPU @ 3.60GHz 32G
函式效能對比工具之JMH
概述 JMH 是一個由 OpenJDK/Oracle 裡面那群開發了 Java 編譯器的大牛們所開發的 Micro Benchmark Framework 。何謂 Micro Benchmark 呢?簡單地說就是在 method 層面上的 benchmark,精度可以精
iOS中保證執行緒安全的幾種方式與效能對比
一、前言 前段時間看了幾個開源專案,發現他們保持執行緒同步的方式各不相同,有@synchronized、NSLock、dispatch_semaphore、NSCondition、pthread_mutex、OSSpinLock。後來網上查了一下,發現他們的實現機制各不相同,效能也各不一