一周一论文（翻译）——[IEEE 14] Elastic scaling for data stream processing
Abstract
本文討論與通用分布式數據流處理應用程序的自動并行化相關的盈利問題。自動并行化涉及在應用程序的數據流圖中定位區域，這些區域可以在運行時復制以應用數據分區，以實現擴展。為了使自動并行化在實踐中有效，需要回答盈利問題：有多少并行通道提供最佳吞吐量？此問題的答案根據運行時的工作負載動態和資源可用性而變化。在本文中，我們提出了一種彈性自動并行化解決方案，可以動態調整用于實現高吞吐量的通道數，而不會浪費資源。最重要的是，我們的解決方案可以通過運行時狀態遷移處理分區有狀態運算符，這對應用程序開發人員完全透明。我們在工業級數據流處理平臺上提供系統的實施和評估，以驗證我們的解決方案。
1. Introduction
?????? 隨著世界變得更加互聯和儀表化，來自各種軟件和硬件傳感器的大量數據以連續流的形式出現?？梢栽诙鄠€領域找到示例，例如金融市場，電信，制造業和醫療保健。在所有這些領域中，越來越需要收集，處理和分析這些數據流以提取見解以及檢測新出現的模式和異常值。最重要的是，這種分析通常需要近乎實時地進行。世界變得更加互聯和儀表化，來自各種軟件和硬件傳感器的大量數據以連續流的形式出現?？梢栽诙鄠€領域找到示例，例如金融市場，電信，制造業和醫療保健。在所有這些領域中，越來越需要收集，處理和分析這些數據流以提取見解以及檢測新出現的模式和異常值。最重要的是，這種分析通常需要近乎實時地進行。
?????? 流計算是一種計算范例，能夠以高效且可擴展的方式執行分析任務。 通過將傳入的數據流通過放置在一組分布式主機上的Operator網絡，流計算提供了即時的處理模型。 由于數據不直接存儲在磁盤上，因此流計算避免了更傳統的數據管理存儲和處理模型所面臨的性能問題。 商業流處理系統的出現，如StreamBase [28]和InfoSphere Streams [16]，開源系統，如S4 [34]和Storm [27]，以及現有的學術系統，如STREAM [5]，Borealis [1]和System S [18]，是流計算范式未來增長和過去成功的證據。
?????? 在短時間內處理大量實時數據的頻繁需求是流處理應用的主要特征[26]。 因此，支持高吞吐量處理是流式系統的關鍵要求[14]。 它需要利用多臺主機來實現可擴展性[4]。 隨著可用于處理的不斷增加的實時數據量，這一要求將變得更加突出。 由于云計算和多核芯片設計的進步，分布式和并行計算的可承受性得到提高，這使得這個問題變得易于處理。 這產生了對語言和系統級技術的需求，這些技術可以有效地定位和有效地利用流處理應用程序中的并行化機會。 后一方面是本文的重點。
?????? 流應用程序被構造為有向無環圖，其中頂點是Operator，邊是數據流。 為了擴展此類應用程序，流處理系統可以自由決定應用程序圖將如何映射到可用主機集。 自動并行化[24]是一種有效的技術，可用于以透明的方式縮放流處理應用程序。 它涉及檢測應用程序圖中可以在多個主機上復制的parallel regions，這樣復制區域的每個實例（我們稱之為通道）處理數據流的子集以便增加吞吐量。 這種并行形式稱為數據并行性。 透明數據并行化涉及在沒有應用程序開發人員直接參與的情況下檢測parallel regions并應用運行時機制以確保安全性：并行化應用程序產生與順序應用程序相同的結果。
?????? 雖然安全性確保了正確性，但并不能確保提高性能。 提高性能的透明自動并行化必須具備一定的盈利機制。 在流數據parallel regions中，盈利能力涉及確定正確的并行度，這是要使用的并行通道的數量，而無需應用程序開發人員的明確參與。 彈性自動并行化通過使盈利性決策適應運行時動態（例如工作負載的變化和資源的可用性）而更進一步。 在本文中，我們提出了為流處理應用提供有效彈性自動并行化的新技術。
實現彈性自動并行化有兩個重要的要求。
（R1）存在有狀態運算符時的彈性需要狀態遷移。 這帶來了兩個主要挑戰。 首先，為了保持自動并行化的透明性，需要在存在但不干擾應用程序邏輯的情況下執行狀態遷移。 其次，我們需要盡量減少遷移狀態。 通過最小化遷移狀態，我們最小化可能干擾數據流的時間和空間開銷。 反過來，這將使更頻繁的適應。
（R2）存在運行時動態時的彈性需要控制算法。 這帶來了兩個主要挑戰。 首先，通用流處理應用程序包含大量用戶定義的Operator。 我們不能輕易地模擬這些Operator的反應。 應對這一挑戰需要利用運行時Metrics指標來指導控制系統，而不是依賴傳統的基于成本的優化。 其次，我們需要確保控制算法能夠提供SASO屬性[12]。 也就是說，它表現出穩定性（不會振蕩使用的通道數），達到良好的精度（找到最大化吞吐量的通道數），具有較短的穩定時間（快速達到穩定的通道數），最后避免 過沖（不使用超過必要的頻道）。
?????? 我們通過開發基于Key-Value存儲的狀態API來解決透明遷移的挑戰，該API旨在支持分區有狀態Operator的實現。 分區有狀態Operator為分區屬性[24]標識的每個子流存儲獨立狀態。 這些Operator在流處理應用程序中非常常見（由IP編號劃分的網絡跟蹤，由股票行情者劃分的財務流等）。 我們開發編譯時重寫技術，將高級用戶代碼轉換為使用狀態API的等效版本，以便保護應用程序開發人員免受狀態遷移的細節。
?????? 我們通過開發增量遷移協議和基于一致Hash散列的相關拆分策略來解決低成本遷移的挑戰[19]，它們共同最小化了遷移狀態的數量。
?????? 我們通過依賴于在splitter處計算的兩個本地Metrics來解決運行時控制的挑戰：congestion index（在Splitter處的Blocking時間的度量）和吞吐量。 splitter是一個運行時組件，與Operator共同生成要拆分的流以進行并行處理。 我們開發了一種在Splitter上工作的本地控制算法，并使用這些Metrics度量來調整用于處理流的信道數。
?????? 我們通過在控制算法中引入幾種技術來解決提供SASO屬性的挑戰。 這些措施包括根據觀察到的Metrics指標的變化，根據使用的Channel通道數量來上下調整，以解決準確性和超調問題; 記住過去在不同操作點取得的表現以解決穩定性問題; 并快速縮放以解決建立時間問題。
本文做出以下主要貢獻：
?????? 我們為實現彈性而引入的技術和算法，例如控制算法，狀態管理技術和遷移協議，都具有普遍適用性，并且可以在任何流處理系統中實現。我們使用IBM InfoSphere Streams的原型版本，簡稱Streams及其編程語言SPL [13]來舉例說明狀態管理API。
?????? 總之，本文展示了如何以透明和彈性的方式解決分布式有狀態流處理的盈利問題。本文的其余部分組織如下。第2節提供了Streams和SPL [13]的背景知識，并概述了基于以前工作的自動并行化的安全性方面[24]。第3節概述了我們的彈性自動并行化解決方案。第4節描述了控制算法及其如何實現SASO屬性。第5節描述了基于鍵值的狀態API和編譯時重寫技術。第6節詳細闡述了遷移協議。第7節報告了實驗結果。第8節討論了相關工作，第9節總結了這篇文章。
2. BACKGROUND
?????? 本節簡要討論SPL語言和Streams中間件，然后介紹自動并行化的安全性方面
2.1 SPL AND STREAMS
?????? SPL [13]是一種用于開發流處理應用程序的編程語言。 SPL應用程序由通過流連接相互連接的Operator實例組成。 Operator實例是應用程序數據流圖中的頂點。 Operator實例是Operator定義的實現。 例如，圖1中頂部圖的左側所示的運算符實例是TCPSource Operator的實例。 通常，Operator可以具有許多不同的實例，每個實例使用不同的流類型，參數或諸如窗口的其他配置。 Operator實例可以具有零個或多個輸入和輸出端口。 每個輸出端口生成一個唯一命名的流，它是一系列元組。 將輸出端口連接到運營商的輸入會建立流連接。 流連接是應用程序數據流圖中的邊緣。
?????? Operator直接在SPL（通過自定義Operator）或通用編程語言中實現。 在這兩種情況下，運算符實現依賴于事件驅動的接口，它們對到達Operator輸入端口的元組作出反應。 元組處理通常涉及更新某些操作符本地狀態并生成在輸出端口上發送的結果元組。
?????? Streams [16]是一個分布式流處理引擎，可以使用一組分布式主機執行SPL應用程序。 它執行各種運行時任務，例如數據傳輸，調度，容錯和安全性。
2.2 Auto-Parallelization
?????? 自動并行化是在應用程序的流程圖中自動發現數據parallel regions的過程，可以在運行時利用它。 除了發現這些parallel regions之外，編譯器還必須建立激活適當的運行時機制所需的某些屬性，以確保自動并行化的安全性。 例如，如果parallel regions是無狀態的，則要應用的運行時數據分割機制可以是循環的，而如果該區域是分區有狀態的，則必須使用基于Hash的方案來執行數據分割。
?????? 我們使用清單1中給出的SPL代碼示例說明了一個示例自動并行化過程。這里，我們看到一個名為OpMon的示例操作監視應用程序。 TCP Source運算符的實例用于接收包含有關不同應用程序的網絡使用情況的信息的流。 接下來是一個Aggregate運算符實例，它使用appId作為分區鍵計算每個應用程序的每分鐘數據使用信息。 聚合結果通過Filter運算符獲取，以保留網絡使用率高于閾值的應用程序。 最后，將結果結果發送到TCP Sink運算符實例。
?????? 圖1顯示了OpMon應用程序（頂部）的數據流圖的可視化，以及它的自動并行化版本（在底部）。 在此示例中，并行區域由Aggregate和Filter運算符組成。 它是一個分區的有狀態parallel regions，因為Aggregate運算符基于每個分區維護狀態。 Splitter駐留在parallel regions之前的Operator的輸出端口上，并負責將元組路由到并行通道。 一旦元組被路由到特定通道，那么與它共享appId屬性值的所有未來元組必須被路由到同一個通道。 這是通過在appId屬性上應用hash函數在Splitter上實現的。
?????? 在此示例中，在parallel regions（TCP Sink）之后還有一個附加Operator。 此外，沒有跡象表明該Operator可以容忍亂序結果。 因此，這個特定的parallel regions（需要在其輸出處維持元組的順序。 這是在合并時實現的，合并位于并行區域之后的運算符的輸入端口上。 合并使用在Splitter處分配并通過并行區域傳送的序列號執行重新排序操作。
?????? 最后，這個并行區域包含一個Filter運算符，可以刪除一些元組。 這導致選擇性值最多為1.因此，如果給定信道的元組碰巧以比其他信道更高的頻率丟棄，則合并可能長時間阻塞。 這是因為在沒有元組到達的時候，合并無法區分需要很長時間才能到達的元組和永遠不會到達（丟棄）的元組。 為了解決這個問題，這個特定的并行區域使用pules，pules是由Splitter周期性地發送并由合并器使用的特殊標記，以避免冗長的停頓。
?????? 有關自動并行化安全方面的完整詳細信息，請參見[24]。 總之，并行區域的以下屬性[33]在用于確保安全性的運行時機制中起著核心作用：
在本文的其余部分，我們將了解如何通過運行時自適應來解決自動并行化的盈利方面問題。
3. SOLUTION OVERVIEW
?????? 在本節中，我們將概述我們的解決方案，該解決方案基于運行時彈性。
?????? 我們的方法的關鍵思想是將盈利能力決策留給運行時，我們可以在其中推斷工作負載和資源可用性。 當應用程序開始執行時，并行通道的數量將設置為1. 放置在Splitter上的控制算法會根據其維護的本地運行時指標Metrics，定期重新評估要使用的通道數。 控制算法可以決定增加或減少使用的信道數量，或者在任何決策點不采取任何行動。 當要使用的通道數改變時，如果并行區域是有狀態的，則可能需要執行狀態遷移協議。
?????? 重要的是要注意，我們沒有解決這項工作中的放置問題。 特別是，當我們的算法請求新的并行通道時，我們假設它將被放置在系統中的可用主機/核心上。
?????? 對于分區有狀態的并行區域，改變并行通道的數量需要部分重新定位狀態。 例如，如果并行通道的數量增加，則一些分區的分配需要從現有的并行通道移動到新的并行通道。 每當在Splitter處發生這種分配的改變時，與移動的分區相關聯的狀態也必須被重新定位。 特別地，新添加的并行信道需要從現有并行信道收集分配給它們的分區的狀態。 類似地，當移除現有通道時，與其處理的分區相關聯的狀態必須重新分配到現有并行通道。
?????? 作為系統不變量，每個分區在任何給定時間點僅由單個并行通道擁有。 我們使用一致性hash執行分區到并行通道的分配，以最小化遷移期間移動的狀態量。
?????? 為了透明地執行運行時遷移，流處理中間件必須推斷Operator維護的狀態。 在通常使用用戶定義的Operator的通用流式傳輸系統中，這需要特殊的機器。 為了解決這個問題，我們的解決方案包括一個本地Key-Vaule存儲形式的狀態管理API。 SPL編譯器重寫Custom Operator中存在的代碼，以便將狀態轉換為使用此API，從而使運行時能夠推斷此狀態并執行透明遷移。
4. CONTROL ALGORITHM
定期運行控制算法以更新并行信道的數量。 它依賴于以下兩個本地計算的指標：
Congestion：表示Splitter在連接上發送元組時是否觀察到不適當的延遲。 它在兩個方面是一個有用的指標：1）阻塞的存在表明我們需要更多的信道來處理當前的負載，同樣缺乏阻塞表明我們可能使用的信道多于必要的信道。 2）阻塞值的時間變化可以指示工作負載可用性的變化。 我們通過對阻塞指數應用閾值來計算阻塞作為布爾值，阻塞指數是由于背壓而阻塞Splitter處的元組傳輸的時間分量的Metcis。
?????? 為了計算阻塞指數，我們使用非阻塞I / O來傳輸元組。 如果發送呼叫通知我們會發生阻塞，則我們阻塞直到可用空間并測量所涉及的阻塞量。 總的來說，阻塞指數衡量阻塞所花費的時間。 我們在所有Channel上平均這個值。 擁塞指數是范圍[0,1]中的值。 我們將在4.3節中進一步討論阻塞指數閾值。
Throughput: 是在上一個適應期間每秒處理的元組數。 吞吐量在兩個方面是有用的：1）當我們根據通道數量移動到新的操作點時，它告訴我們情況是否有所改善。畢竟，目標是優化吞吐量。 2）吞吐量的時間變化可以指示工作量的變化。 控制算法基于以下兩個基本原則運行：
（P1）Expand：如果出現擁堵，則上升（增加通道數），除非您以前曾在那里并且沒有觀察到提高的吞吐量。
（P2）Contract：如果沒有擁堵，則下降（減少通道數量），除非您曾經去過那里并觀察到擁堵。
?????? 這里，（P1）提供了SASO的準確性：我們獲得了良好的準確性，因為通道數量增加直到擁塞被消除。 （P2）提供SASO中的過度配置屬性：我們避免使用超過必要的更多信道，因為除非下面出現擁塞，否則信道數量會減少。 （P1）和（P2）中的“除非”條款在SASO中提供穩定性屬性：我們不會在操作點之間振蕩，因為過去發生的事情會被記住而不會重復。 但是，當工作量波動時，這兩個原則是不夠的。 當工作負載可用性發生變化時，我們需要忘記過去發生的部分事情。 因此，我們引入了以下調整以適應工作負載變化：
（P3）擁塞適應：如果在擁塞中觀察到工作量增加（減少）的變化，則忘記過去關于上升（下降）通道的觀察。
（P4）吞吐量適應：如果觀察到指示工作量增加（減少）的吞吐量的變化，則忘記過去關于上升（下降）信道的觀察。
?????? 這里，（P3）和（P4）使控制算法能夠適應工作負載變化。 注意，控制算法具有以下關鍵特征：它將在多個信道上建立，使得沒有擁塞，但是任何較少數量的信道將導致擁塞。 當處于這種穩定狀態時，如果工作量增加，它將開始觀察擁塞并上升（由于（P1））。 當工作量減少時，它將觀察到吞吐量減少并且忘記下面的一個信道導致擁塞（由于（P4））并且下降（由于（P2））的事實。
?????? 此版本的控制算法還有兩個小問題。 第一個是關于擁堵的性質。 該算法被設計為解釋擁塞的存在，作為需要更多信道來處理負載的指示。 在擁塞不是由于并行區域的成本而是由于并行區域下游的流量成本的情況下，增加通道數量不會導致任何改進，而是會導致過沖。 我們稱這種擁塞遠程擁塞，并使用以下附加原則避免潛在的陷阱：
（P5）遠程擁塞：如果在增加信道數量后擁塞繼續，但吞吐量沒有顯著增加，則下降。
?????? 這里，（P5）避免了由于持續存在擁塞而導致信道數量連續增加的情況，但吞吐量沒有提高。 沒有（P5），這可能發生在遠程擁塞的情況下。 值得注意的是，大多數流應用程序在通過并行化刪除其原始瓶頸時最終會達到可伸縮性限制。 這是因為瓶頸移動到應用程序的不可并行化部分，在大多數情況下，該部分是Source，Sink或某些有狀態操作符。 在并行區域下游的Operator成為瓶頸的所有情況下，將發生遠程擁塞。
?????? 第二個問題是，在可用資源（諸如主機和核心的執行上下文）和并行區域的成本都很高的情況下，最佳信道數也可以是高的。 因此，控制算法可能需要很長時間才能達到該數量。 這是由于算法的一次一個通道性質，并可能對SASO中的穩定時間屬性產生負面影響。 我們通過引入一個稱為快速縮放的算法選項來解決這個問題。 總結如下：
（P6）快速擴展：不是一次操作一個通道，而是一次操作一個級別，并在級別和通道數之間定義超線性映射。這里，（P6）通過仍然一步一步地改變操作點來保持算法的主要操作模式。 但是它不是直接使用通道數，而是使用一個級別，通過一個函數將其映射到通道數。 特別是，我們使用以下函數：
?????? 為了從0開始增加級別值，這導致以下一系列通道數：{1,2,3,4,6,8,11,16,23,32，...}。 根據最大通道數和建立時間要求，可以使用遵循更陡峭或更陡峭曲線的其他功能。
圖2給出了控制算法的高級描述，說明了原理P1到P6。
4.1 Algorithm Implementation
?????? 控制算法保留三個狀態變量。 第一個是當前的適應期，用P表示。第二個表示當前級別，用L表示。第三個是保存每個級別的以下信息的數組：算法所處的最后一個適應期 這個級別，用P i表示; 是否在最后一次算法處于此水平時觀察到擁塞，用C i表示; 上次算法處于此級別時觀察到的吞吐量，用T ai表示; 以及在最后一次算法在該水平上保持連續周期的第一個周期期間觀察到的吞吐量，由T i表示。 我們使用L *來表示最大級別數。
?????? 控制算法具有稱為變化靈敏度的全局參數，表示為 α，其確定重要變化意味著什么。 它取一個[0,1]范圍內的值。 值為1表示算法對吞吐量的微小變化非常敏感。 例如，如果靈敏度很高，則吞吐量的微小改善就足夠了。 吞吐量的所有變化都針對線性縮放系統中單個通道的理想吞吐量進行標準化。
?????? 算法1中的init（）程序提供狀態變量的初始化邏輯。該算法的核心在算法2提供的getNumberOfChannels（）例程中給出，該例程將當前吞吐量（由T表示）和當前擁塞狀態（由C表示）作為參數。作為第一步，應用原理（P3）和（P4）以查看負載是否有變化。如果負載增加（減少），則重置保持有關上述（下面）級別的信息。第二步更新保留的有關當前級別，上次吞吐量，上次擁塞狀態和第一次吞吐量的信息（除非算法最后一次處于此級別）。第三步調整當前級別。首先，應用原則（P5）來查看是否存在遠程擁塞。如果是這樣，我們會回到上一個級別。否則，應用原則（P1）：我們檢查是否存在擁塞，如果是，則上升一級除非算法之前存在但吞吐量更差。最后，應用原則（P2），即如果沒有擁塞，我們向下一級，除非算法之前已經存在并觀察到擁塞。一旦調整了當前電平，則應用原理（P6）以返回對應于當前電平的通道計數。
4.2 Detecting Workload Changes
?????? 算法3中給出了用于檢測工作負載變化的邏輯.checkLoadChangeViaCongestion（）例程使用擁塞狀態來檢測負載變化。如果當前級別和最后級別相同，但擁塞狀態已經改變，則將其視為負載變化的指示（如果當前存在擁塞則負載增加，否則負載減少）。如果當前級別低于最后一級，但擁塞已消失，則將其視為負載減少。最后，如果當前級別高于??最后一級，但是已經出現擁塞，則將其視為負載增加。 checkLoadChangeViaThroughput（）例程使用吞吐量來檢測負載變化。如果當前級別和最后級別相同，但吞吐量存在顯著變化，則將其視為負載變化的指示（如果當前吞吐量值較高則負載增加，否則負載減少）。變化靈敏度用于檢測相對于線性縮放系統中的理想變化的顯著變化。如果當前級別低于最后一級，但吞吐量增加，則將其視為負載增加。最后，如果當前級別高于??最后一級，但吞吐量已降低，則將其視為負載減少。
4.3 Discussion of Parameters
?????? 控制算法具有三個可配置參數。其中，擁塞指數閾值是唯一需要仔細調整的閾值。我們在實驗評估部分中根據經驗研究其設置，并顯示在[0.01,0.3]范圍內的任何閾值提供了穩健的設置。
?????? 快速縮放是一項可以打開以減少建立時間的功能。它調整了快速適應和微調并行通道數量的能力之間的權衡。
?????? 更改靈敏度可調整系統對工作負載變化的敏感度。在遷移成本較低的系統中，變化靈敏度參數的較小值（較高的靈敏度）是合適的。對于遷移成本高昂的系統，最好在采取適應步驟之前等待觀察到的吞吐量發生重大變化。例如，如果通道處理的吞吐量下降了10％，那么通過降低一級來對此做出反應對于具有高開銷遷移的系統來說可能過于激進。
?????? 即使用戶沒有調整快速縮放或改變選擇性，我們的算法也能滿足所有SASO屬性。但是，通過提供這些參數，我們使高級用戶可以根據需要調整SASO屬性之間的相對權衡。
5. STATE MANAGEMENT
?????? 參與并行區域的運營商要么是無狀態的，要么是分區有狀態的，如第2.2節所述。 分區有狀態運算符基于分區屬性在每個分區的基礎上維護獨立狀態。 這些操作員需要特殊的機器來支持透明的彈性平行化。 特別是，運行時系統需要遷移（跨主機）與分區子集關聯的狀態。 這要求運行時了解由分區有狀態運算符管理的狀態。
?????? 為了解決這個問題，我們開發了一個狀態管理API和一個相關的狀態管理服務。 此外，我們提供語言級機制，使新開發的運營商能夠利用托管狀態。 有關托管狀態API的詳細信息及其在SPL應用程序中的透明使用，請參閱附錄A.
6. STATE MIRGRATION
?????? 響應于控制算法在Splitter處做出的決定，對并行區域執行遷移協議。當控制算法更新通道數時，它還更新它用于在并行通道之間分配分區的數據分區功能并啟動遷移協議。僅在分區有狀態并行區域的情況下才需要遷移。
?????? 通過從Splitter向所有并行通道發送遷移脈沖來啟動遷移協議。當并行通道中的操作員接收到遷移脈沖時，它首先將脈沖向下游轉發，然后開始執行每個操作員的遷移協議。這使得在并行區域包含多于一個分區有狀態運算符的情況下，可以并行地在多個運算符的副本之間執行狀態遷移。
?????? 我們首先描述運算符的遷移協議，然后討論使用不同數據分區函數對系統性能的影響。
7. CONCLUSIONS
?????? 我們提出了一種自動并行化方案，可以為流處理應用程序提供彈性。它可以根據工作負載的可用性調整在運行時使用的并行通道數。最重要的是，通過依賴分區狀態的遷移，它能夠處理流處理應用程序中常見的分區有狀態運算符。我們提出了一種控制算法，該算法能夠實現良好的吞吐量，具有較短的建立時間，并避免振蕩和過沖。我們描述了狀態管理API和遷移協議，它們共同實現了對應用程序開發人員透明的彈性并行化。此外，彈性不會干擾安全性，并且在相同的輸入下，相同的輸出以相同的順序產生，而不管是否存在遷移。實驗結果說明了我們的解決方案在尋找平行區域的理想工作點并在工作負載動態存在的情況下調整這一點的有效性。
《新程序員》：云原生和全面數字化實踐50位技術專家共同創作，文字、視頻、音頻交互閱讀總結
以上是生活随笔為你收集整理的一周一论文（翻译）——[IEEE 14] Elastic scaling for data stream processing的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 一周一论文（翻译）——[PVLDB 17
- 下一篇： 一周一论文（翻译）——[SIGMOD 1