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

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

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

實驗裝置

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

單節(jié)點比較

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

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

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

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

吞吐量比較

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

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

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

集群吞吐量比較

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

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

分銷的成本是多少？

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

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

得出結論

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