在大數據和人工智能時代，咱們是否須要分佈式流處理？

　　在中國大數據和人工智能時代，許多數據密集型應用程序表現出傳統批處理模型沒法知足的要求。流媒體應用，如流分析，物聯網數據處理，網絡監控，或金融欺詐檢測，必須支持高處理率，但始終達到亞秒級處理延遲。做爲響應，分佈式流處理系統，如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內核的基於羣集的部署具備更好的性能。咱們的結果還代表，填充單個節點仍然存在性能差距，咱們認爲這構成了設計下一代流處理引擎的機會。最後，關於雅虎流媒體基準測試的先前評論，咱們贊成基準測試不會捕捉真實世界的流媒體應用程序的行爲，而這些應用程序每每是計算密集型的。（黑客週刊）