在中國大數(shù)據(jù)和人工智能時代，許多數(shù)據(jù)密集型應(yīng)用程序表現(xiàn)出傳統(tǒng)批處理模型無法滿足的要求。流媒體應(yīng)用，如流分析，物聯(lián)網(wǎng)數(shù)據(jù)處理，網(wǎng)絡(luò)監(jiān)控，或金融欺詐檢測，必須支持高處理率，但始終達到亞秒級處理延遲。作為響應(yīng)，分布式流處理系統(tǒng)，如SparkStreaming或ApacheFlink，利用計算集群的資源進行流式應(yīng)用。他們的目標是從許多處理節(jié)點的總吞吐量中受益。與任何分布式系統(tǒng)一樣，這引發(fā)了分布式流處理系統(tǒng)如何利用每個節(jié)點上的可用硬件資源的問題。單個處理節(jié)點的性能至關(guān)重要，因為它決定了滿足給定流應(yīng)用程序的吞吐量和延遲要求所需的計算集群的大小。

當談到單節(jié)點性能時，流處理系統(tǒng)必須考慮（a）節(jié)點提供什么類型的并行處理器（即多核CPU，GPU，FPGA）和（b）如何有效地并行處理流計算。隨著高度并行的異構(gòu)體系結(jié)構(gòu)在數(shù)據(jù)中心中的普及，流處理系統(tǒng)甚至可以從單個節(jié)點開始利用先前看不見的并行處理級別。

在這篇博客文章中，我們比較了針對單一服務(wù)器SABRE設(shè)計的高效流處理引擎與受歡迎的分布式流處理系統(tǒng)ApacheSpark和ApacheFlink所實現(xiàn)的性能。我們還將結(jié)果與StreamBox進行了比較，StreamBox是最近提出的另一個強調(diào)數(shù)據(jù)亂序處理的單服務(wù)器設(shè)計。根據(jù)我們的結(jié)果，我們認為單個多核服務(wù)器可以為多個流應(yīng)用程序提供比多節(jié)點群集更好的吞吐量。這為通過用可能復制的單個服務(wù)器部署替換基于集群的流處理系統(tǒng)打開了一個降低系統(tǒng)復雜性和運營成本的機會。

實驗裝置

對于我們的比較，我們使用YahooStreamingBenchmark作為工作量。其他人（ApacheFlink，ApacheApex，差異數(shù)據(jù)流）也報告了此基準的局限性，它無法捕獲流式應(yīng)用程序中滑動窗口計算的豐富語義?；瑒哟翱诳梢哉f是流處理中最具挑戰(zhàn)性的方面之一，并且對如何高效并行化計算有著深遠的影響。盡管有這些限制，但該基準最近已被用于工業(yè)（數(shù)據(jù)布雷克，數(shù)據(jù)工匠）和學術(shù)界（SparkStreaming，Drizzle）。這使我們的結(jié)果與先前的努力相媲美。

單節(jié)點比較

在模擬廣告流應(yīng)用程序，它有一個包含四個操作符的流式查詢：過濾器，項目，連接（關(guān)系數(shù)據(jù)）和聚合（窗口計數(shù)）。在我們的實現(xiàn)中，輸入元組是128個字節(jié)，并直接存儲在JavaByteBuffer中。

我們使用2個IntelXeonE5-2660v32.60GHzCPU，共有20個物理CPU核心，25MB最后一級緩存（LLC）緩存和32GB內(nèi)存，在6臺服務(wù)器（1個主服務(wù)器和5個從服務(wù)器）上執(zhí)行實驗。機器連接10Gbps以太網(wǎng)。我們用SABRE（沒有GPU支持），Spark2.4.0，F(xiàn)link1.3.2和StreamBox的最后一個版本來評估查詢。對于分布式實驗，我們每個節(jié)點只使用8個內(nèi)核，因為在這個數(shù)字之后我們沒有看到任何顯著的吞吐量變化。

我們設(shè)計實驗的目的是將流處理系統(tǒng)的性能與外部影響隔離開來。為此，我們以下列方式進行實驗：

對于SABER，我們最初在一臺單獨的機器上生成數(shù)據(jù)。由于只有一個CPU核心設(shè)法使10Gbps網(wǎng)絡(luò)連接飽和（每秒830萬個元組），我們改為在內(nèi)存中生成數(shù)據(jù)。

吞吐量比較

在吞吐量方面的可擴展性，因為我們增加了可用CPU核心的數(shù)量。通過單個節(jié)點，F(xiàn)link的性能比Spark和StreamBox都要好，將吞吐量提高了1.9倍以上。憑借8個CPU內(nèi)核，Spark和StreamBox分別擁有每秒1200萬和1100萬元的吞吐量，而Flink則達到了2200萬以上。

與其他系統(tǒng)相比，SABRE的吞吐量分別比Spark，F(xiàn)link和StreamBox分別高出7倍，3倍和7倍。它使用8個CPU內(nèi)核每秒處理近7，900萬個元組。只有兩個CPU核心，SABRE超過了其他系統(tǒng)的最佳單節(jié)點吞吐量。除了不利用存儲器層次并最小化數(shù)據(jù)復制外，F(xiàn)link和Spark的吞吐量都受到通信和串行化開銷的不利影響。這是預期的，他們的分布式設(shè)計試圖利用多個節(jié)點的聚合性能。

有了這樣一個簡單的查詢，我們的實驗主要測量系統(tǒng)可以執(zhí)行數(shù)據(jù)移動的速度，因為花在有意義的計算上的時間很短。SABRE將工作線程和生成線程綁定到CPU內(nèi)核，以最大限度地減少L2緩存之外的內(nèi)存訪問。另外，我們維護一個512KB的輸入緩沖區(qū)，確保所有活動數(shù)據(jù)都保存在LLC中。我們使用原子操作來編寫和讀取這個緩沖區(qū)的部分內(nèi)容，同步代價可以忽略不計。

集群吞吐量比較

有趣的是觀察到，與最近的結(jié)果相比，即使在集群部署的情況下，F(xiàn)link的性能也比Spark好。Flink吞吐量的增長是由于更快的10Gbps網(wǎng)絡(luò)所致，我們認為這在以前的工作中并未使用（請參閱結(jié)構(gòu)化流媒體文件）。使用StreamBox，我們觀察到致命的內(nèi)存泄漏，當我們將攝取率提高到超過我們在圖中報告的數(shù)量時。

總之，只有8個CPU內(nèi)核的SABRE比具有5個工作節(jié)點（40個內(nèi)核，5500萬元組/秒）和Flink（40個內(nèi)核;6700萬元組/秒）的Spark性能更好。仔細調(diào)整的單服務(wù)器系統(tǒng)可以勝過計算集群，將所需資源減少一半以上。

分銷的成本是多少？

根據(jù)先前提出的優(yōu)于單線程（COST）的配置指標，我們通過將單核實現(xiàn)與手寫C++程序進行比較來分析系統(tǒng)的性能。C++實現(xiàn)在我們的測試臺服務(wù)器上每秒處理近2300萬個元組（即它比SABER快2倍）。這個結(jié)果與FrankMcSherry的實現(xiàn)（3500萬tuples/sec）基本一致，后者運行在具有更高基本時鐘速度的筆記本電腦上。

理解此性能差距背后的原因并將其用于設(shè)計具有硬件意識的流處理系統(tǒng)非常重要。我們已經(jīng)開始設(shè)計利用超標量執(zhí)行和SIMD并行性的高效流媒體運算符實現(xiàn)。我們還致力于基于編譯的技術(shù)，盡可能將數(shù)據(jù)保存在CPU寄存器中，從而最大限度地提高數(shù)據(jù)和代碼的局部性（Hyper）。正如我們從上面的結(jié)果看到的那樣，在LLC中維護數(shù)據(jù)已經(jīng)帶來了主要的性能優(yōu)勢。我們還設(shè)想了一組硬件無關(guān)的基元，它們考慮到現(xiàn)代擴展架構(gòu)上多個CPU插槽引起的非均勻內(nèi)存訪問（NUMA）。

得出結(jié)論

隨著大容量DRAM，數(shù)據(jù)中心中的許多CPU內(nèi)核和加速器的可用性，流處理系統(tǒng)的設(shè)計必須專注于硬件意識技術(shù)。在YahooStreamingBenchmark的修改版本中，SABRE每秒處理7千萬個元組，并擁有8個CPU內(nèi)核，性能優(yōu)于Flink（3x），SparkStreaming（7x）和StreamBox（7x）。它比具有40個CPU內(nèi)核的基于群集的部署具有更好的性能。我們的結(jié)果還表明，填充單個節(jié)點仍然存在性能差距，我們認為這構(gòu)成了設(shè)計下一代流處理引擎的機會。最后，關(guān)于雅虎流媒體基準測試的先前評論，我們同意基準測試不會捕捉真實世界的流媒體應(yīng)用程序的行為，而這些應(yīng)用程序往往是計算密集型的。