人工智能時(shí)代需要分布式流處理嗎

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

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

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

實(shí)驗(yàn)裝置

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

單節(jié)點(diǎn)比較

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

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

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

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

吞吐量比較

在吞吐量方面的可擴(kuò)展性，因?yàn)槲覀冊(cè)黾恿丝捎肅PU核心的數(shù)量。通過單個(gè)節(jié)點(diǎn)，F(xiàn)link的性能比Spark和StreamBox都要好，將吞吐量提高了1.9倍以上。憑借8個(gè)CPU內(nèi)核，Spark和StreamBox分別擁有每秒1200萬和1100萬元的吞吐量，而Flink則達(dá)到了2200萬以上。

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

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

集群吞吐量比較

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

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

分銷的成本是多少？

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

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

得出結(jié)論

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

責(zé)任編輯：ct