在中國大數據和人工智能時代，許多數據密集型應用程序表現出傳統批處理模型無法滿足的要求。流媒體應用，如流分析，物聯網數據處理，網絡監控，或金融欺詐檢測，必須支持高處理率，但始終達到亞秒級處理延遲。作為響應，分佈式流處理系統，如SparkStreaming或ApacheFlink，利用計算集群的資源進行流式應用。他們的目標是從許多處理節點的總吞吐量中受益。與任何分佈式系統一樣，這引發了分佈式流處理系統如何利用每個節點上的可用硬件資源的問題。單個處理節點的性能至關重要，因為它決定了滿足給定流應用程序的吞吐量和延遲要求所需的計算集群的大小。
當談到單節點性能時，流處理系統必須考慮（a）節點提供什麼類型的並行處理器（即多核CPU，GPU，FPGA）和（b）如何有效地並行處理流計算。隨著高度並行的異構體系結構在數據中心中的普及，流處理系統甚至可以從單個節點開始利用先前看不見的並行處理級別。
在這篇博客文章中，我們比較了針對單一服務器SABRE設計的高效流處理引擎與受歡迎的分佈式流處理系統ApacheSpark和ApacheFlink所實現的性能。我們還將結果與StreamBox進行了比較，StreamBox是最近提出的另一個強調數據亂序處理的單服務器設計。根據我們的結果，我們認為單個多核服務器可以為多個流應用程序提供比多節點群集更好的吞吐量。這為通過用可能複製的單個服務器部署替換基於集群的流處理系統打開了一個降低系統複雜性和運營成本的機會。
實驗裝置
對於我們的比較，我們使用YahooStreamingBenchmark作為工作量。其他人（ApacheFlink，ApacheApex，差異數據流）也報告了此基準的侷限性，它無法捕獲流式應用程序中滑動窗口計算的豐富語義。滑動窗口可以說是流處理中最具挑戰性的方面之一，並且對如何高效並行化計算有著深遠的影響。儘管有這些限制，但該基準最近已被用於工業（數據布雷克，數據工匠）和學術界（SparkStreaming，Drizzle）。這使我們的結果與先前的努力相媲美。
單節點比較
在模擬廣告流應用程序，它有一個包含四個操作符的流式查詢：過濾器，項目，連接（關係數據）和聚合（窗口計數）。在我們的實現中，輸入元組是128個字節，並直接存儲在JavaByteBuffer中。
我們使用2個IntelXeonE5-2660v32.60GHzCPU，共有20個物理CPU核心，25MB最後一級緩存（LLC）緩存和32GB內存，在6臺服務器（1個主服務器和5個從服務器）上執行實驗。機器連接10Gbps以太網。我們用SABRE（沒有GPU支持），Spark2.4.0，Flink1.3.2和StreamBox的最後一個版本來評估查詢。對於分佈式實驗，我們每個節點只使用8個內核，因為在這個數字之後我們沒有看到任何顯著的吞吐量變化。
我們設計實驗的目的是將流處理系統的性能與外部影響隔離開來。為此，我們以下列方式進行實驗：
對於SABER，我們最初在一臺單獨的機器上生成數據。由於只有一個CPU核心設法使10Gbps網絡連接飽和（每秒830萬個元組），我們改為在內存中生成數據。
吞吐量比較
在吞吐量方面的可擴展性，因為我們增加了可用CPU核心的數量。通過單個節點，Flink的性能比Spark和StreamBox都要好，將吞吐量提高了1.9倍以上。憑藉8個CPU內核，Spark和StreamBox分別擁有每秒1200萬和1100萬元的吞吐量，而Flink則達到了2200萬以上。
與其他系統相比，SABRE的吞吐量分別比Spark，Flink和StreamBox分別高出7倍，3倍和7倍。它使用8個CPU內核每秒處理近7,900萬個元組。只有兩個CPU核心，SABRE超過了其他系統的最佳單節點吞吐量。除了不利用存儲器層次並最小化數據複製外，Flink和Spark的吞吐量都受到通信和串行化開銷的不利影響。這是預期的，他們的分佈式設計試圖利用多個節點的聚合性能。
有了這樣一個簡單的查詢，我們的實驗主要測量系統可以執行數據移動的速度，因為花在有意義的計算上的時間很短。SABRE將工作線程和生成線程綁定到CPU內核，以最大限度地減少L2緩存之外的內存訪問。另外，我們維護一個512KB的輸入緩衝區，確保所有活動數據都保存在LLC中。我們使用原子操作來編寫和讀取這個緩衝區的部分內容，同步代價可以忽略不計。
集群吞吐量比較
有趣的是觀察到，與最近的結果相比，即使在集群部署的情況下，Flink的性能也比Spark好。Flink吞吐量的增長是由於更快的10Gbps網絡所致，我們認為這在以前的工作中並未使用（請參閱結構化流媒體文件）。使用StreamBox，我們觀察到致命的內存洩漏，當我們將攝取率提高到超過我們在圖中報告的數量時。
總之，只有8個CPU內核的SABRE比具有5個工作節點（40個內核，5500萬元組/秒）和Flink（40個內核;6700萬元組/秒）的Spark性能更好。仔細調整的單服務器系統可以勝過計算集群，將所需資源減少一半以上。
分銷的成本是多少？
根據先前提出的優於單線程（COST）的配置指標，我們通過將單核實現與手寫C++程序進行比較來分析系統的性能。C++實現在我們的測試臺服務器上每秒處理近2300萬個元組（即它比SABER快2倍）。這個結果與FrankMcSherry的實現（3500萬tuples/sec）基本一致，後者運行在具有更高基本時鐘速度的筆記本電腦上。
理解此性能差距背後的原因並將其用於設計具有硬件意識的流處理系統非常重要。我們已經開始設計利用超標量執行和SIMD並行性的高效流媒體運算符實現。我們還致力於基於編譯的技術，儘可能將數據保存在CPU寄存器中，從而最大限度地提高數據和代碼的局部性（Hyper）。正如我們從上面的結果看到的那樣，在LLC中維護數據已經帶來了主要的性能優勢。我們還設想了一組硬件無關的基元，它們考慮到現代擴展架構上多個CPU插槽引起的非均勻內存訪問（NUMA）。
得出結論
隨著大容量DRAM，數據中心中的許多CPU內核和加速器的可用性，流處理系統的設計必須專注於硬件意識技術。在YahooStreamingBenchmark的修改版本中，SABRE每秒處理7千萬個元組，並擁有8個CPU內核，性能優於Flink（3x），SparkStreaming（7x）和StreamBox（7x）。它比具有40個CPU內核的基於群集的部署具有更好的性能。我們的結果還表明，填充單個節點仍然存在性能差距，我們認為這構成了設計下一代流處理引擎的機會。最後，關於雅虎流媒體基準測試的先前評論，我們同意基準測試不會捕捉真實世界的流媒體應用程序的行為，而這些應用程序往往是計算密集型的。（黑客週刊）
閱讀更多 IT八卦陣 的文章
