計算密集型大流量數據的接力計算與動態分流處理

廖 佳，陳 揚，包秋蘭，廖雪花，朱洲森*

（1.四川師范大學物理與電子工程學院，成都 610101；2.四川師范大學計算機科學學院，成都 610101）

（*通信作者電子郵箱992827658@qq.com）

0 引言

隨著社會的數字化轉型、互聯網的蓬勃發展以及國民經濟的快速崛起，世界各個領域的數據呈爆炸式增長，大流量數據的處理問題引起了世界各國專家的廣泛關注［1-2］。數據作為信息的載體，已經成為包括互聯網經濟、交通物流和社會生活等各個領域中最核心的資源［3］。在這些領域中，高效的計算能力是必不可少的條件之一。

我國在大數據計算應用領域發展迅速，主要集中在I/O密集型［4］和計算密集型［5］。目前I/O 密集型數據處理在我國應用領域先進而成熟，典型應用場景如春運期間搶購火車票、購物網站的“雙十一”搶購商品、電商平臺的秒殺搶購等。對于這些I/O 密集型應用，通過技術的不斷革新和架構的不斷優化，得到了進一步的提升和完善。但是計算密集型數據處理仍然處在發展階段，對于大型應用的開發存在困難，主要集中在大型科學計算、省市級的社保醫保數據的計算與服務、稅務數據的計算與優化等方面。

對于計算密集型的應用，國內外學者在任務調度、資源分配等方面有一些相關研究。張楠等［6］提出了一種面向計算密集型任務的分布式任務調度平臺，有效地提高了系統的資源利用率和穩定性。楊志豪等［7］研究了一種面向數據和計算雙重密集型任務的私有云計算系統實現方案，通過對文件和并行處理模塊的簡化和優化，使得系統結構變得簡單且方便使用。郝永生等［8］分析研究了計算密集型和數據密集型混合作業情況下的調度問題，對傳統的網格作業調度算法進行了擴展，提出了三種調度算法：Emin-min、Ebest、Esufferage。Kolici等［9］從高計算需求的角度出發，介紹了利用現代高性能體系結構模擬調度和資源分配的計算密集型應用的一些研究成果。

對于計算密集型的應用，在我國目前還處于發展階段。因此，本文提出一套計算密集型大流量數據的接力計算與動態分流處理模型。通過內存型數據存儲模塊中預存儲信息確定計算任務的復雜等級，同時利用接力計算模塊中計算節點的資源能力作為排序標準，將計算任務動態分配至指定接力計算節點并行處理，最終在數據分流模塊整合計算結果，返回客戶端展示，有效減輕了單服務器端的計算壓力。

本文主要工作：1）采用內存型數據庫預存計算參量，減少數據庫對頻繁使用參量的讀寫成本，同時內存數據庫動態記錄計算量與復雜度，供動態計算調節器使用；2）調節器動態調用數據存儲資源（分布式數據庫），將大流量的計算任務拆解為若干小任務由存儲資源并行運算，并將并行運算的初步結果送往下一級處理層；3）后續兩級到三級的接力處理層將復雜的計算任務并行地分層處理，將最后的計算結果以數據流的方式合并輸出。

1 關鍵技術

1.1 微服務架構

微服務架構［10］是一種體系結構模式，它采用一組服務來構建一個應用程序，服務獨立地部署在不同的進程中，可獨立擴展伸縮，并且每個服務可采用不同的編程語言來實現。相較于傳統的單體應用架構，微服務架構具有以下優勢：

①獨立部署。

由于微服務具有獨立的運行進程，所以每個微服務可以獨立進行部署。當某個微服務發生變化時，不需要重新編譯和部署整個應用程序，大大縮短了應用的交付周期。

②降低復雜度。

微服務架構將單個模塊應用程序分解為多個微服務，同時保持總體功能不變。每個服務都集中在一個單一的功能上，并通過接口清楚地表示服務邊界。由于功能單一、復雜度低，小規模開發團隊可以充分掌握，易于維護，開發效率高。

③技術選型多元化。

在微服務架構下，應用程序的技術選擇是去中心化的，各個開發團隊可以根據自身應用的業務需求開發，選擇合適的架構和技術。

④容錯性。

在微服務架構中，由于微服務之間彼此獨立的特點，故障被隔離在單個服務中，系統的其他微服務模塊可以通過重試、降級等機制在應用層實現容錯，從而提高系統應用的容錯性。

⑤可擴展性。

微服務架構中的每一個服務可以根據實際需要獨立地進行擴展［11］，充分體現了微服務架構的靈活性。

本文采用微服務架構搭建接力計算與動態分流處理模型。

1.2 非阻塞客戶端WebClient

WebClient 是一個非阻塞、響應式的HTTP（HyperText Transfer Protocol）客戶端工具，它以響應式流、背壓的方式執行HTTP 請求。對于高并發的情況，可以利用非阻塞和響應式的特性使用少量的線程數進行處理［12］。本文利用這兩個特性處理微服務各模塊之間通信的問題。

采用微服務架構搭建整體框架，各個微服務模塊之間如何遠程進行訪問服務資源是需要考慮的問題。目前，一般微服務中各個模塊之間的調用有兩種方式：RestTemplate 和Feign，都是采用HTTP 協議調取Restful API 的方式。但這兩種方式都具有阻塞的缺點，當系統應用收到大量請求時，會造成請求堆積，響應時長增加。非阻塞客戶端WebClient 的出現，可以完美解決上述問題。

本文在接力計算和數據同步過程中，各層接力計算節點利用WebClient 的非阻塞特性進行通信，傳遞計算和同步任務，獲取處理結果。接力計算節點調用圖如圖1所示。

2 接力計算與動態分流處理模型

為解決現有大流量數據計算緩慢、響應時間長等問題，本文研究了一種計算密集型大流量數據的接力計算與動態分流處理模型，具有響應迅速、計算效率高、可擴展性好等優點。整個模型主要由數據分流模塊、內存型數據存儲模塊、接力計算模塊和數據存儲模塊四部分組成，模型圖如圖2所示。

圖2 計算密集型大流量數據處理模型Fig.2 Computing-intensive large flow data processing model

2.1 接力計算與動態分流處理運行流程

由圖2 可知，接力計算與動態分流處理模型通過四大模塊之間的相互配合，共同完成大流量數據的快速計算。該模型的具體運行流程與各大模塊的功能如下：

1）數據分流模塊實現大流量數據的動態分流與合并。

該模塊主要利用均衡算法將大流量數據均分至多個計算節點同時進行計算，計算完成后，將結果進行整合，返回至客戶端進行展示。

2）接力計算模塊完成大部分計算任務。

接力計算模塊根據計算任務的分解方式，確定接力層數以及各層的節點數，通過各層各節點之間相互配合，完成大部分的計算任務。

3）內存型數據存儲模塊：微計算處理單元。

內存型數據存儲模塊具有讀寫速度快、性能好、易于擴展等優點［13］，本文將具有使用頻率較高、相對固定不變、已進行簡單計算等特點的數據預存儲在內存型數據存儲模塊中，方便其余三大模塊在計算過程中快速讀取所需數據。

4）數據存儲模塊：讀寫分離。

數據存儲模塊是克隆數據存儲集群，采用讀寫分離，能有效減輕數據存儲模塊的負載壓力［14］。其中，讀取數據集中在（N-1）個數據存儲端，而寫入數據在N個數據存儲端中并行執行。當寫入數據出現錯誤時，進行回滾，保證存儲端集群中的數據一致。

2.2 接力計算與動態分流處理模型優勢

傳統的大流量計算模式多為增加或升級硬件資源，譬如大型互聯網企業雙十一期間需要增加幾千或上萬臺服務器，或人為拆解大流量為若干小任務，需要較長的時間完成大量的計算任務。

相較于傳統大流量數據的計算方式，本文所提出的接力計算與動態分流處理模型有以下優勢：

1）緩解硬件資源節點的計算壓力。數據分流模塊通過內存型存儲模塊中的數據快速確定計算任務的復雜等級X，利用均衡算法將計算任務分配至X個接力計算節點完成，有效緩解單一架構的計算壓力。

2）易于擴展。本文的接力計算模塊為集群式，體現為多層接力節點共同參與任務計算。上層接力節點的計算結果傳遞到下層接力節點繼續參與計算。大流量數據的復雜運算可以利用多層接力節點異步處理計算任務，減輕傳統單服務器端的計算壓力。

3）數據同步。數據存儲端集群采用讀寫分離的方式存儲數據，有效減輕存儲模塊的負載壓力；并且，通過執行SQL 捕獲器的結果和引發錯誤后回滾的方式保證數據同步。

4）讀寫快速。利用內存型數據存儲模塊中讀寫數據快速的優點，將使用頻率較高的數據預存儲在內存型數據存儲端中。

3 接力計算與動態分流處理模型設計與實現

根據接力計算與動態分流處理模型的說明，可以得到接力計算與動態分流處理模型的總體運行流程如圖3所示。

圖3 接力計算與動態分流處理模型流程Fig.3 Flowchart of relay computation and dynamic diversion processing model

具體技術實現闡述如下：

1）數據分流模塊對數據進行動態分流。

數據分流模塊接收客戶端原始任務請求，利用SQL 捕獲器的結果判斷任務類型。其中，增加、刪除和更新操作屬于數據同步任務，而讀取操作屬于計算任務。

SQL 捕獲器的結果判定是計算任務時，先確定計算任務的復雜等級。本文將第一次請求數據的時間Tm預存儲在內存型數據存儲模塊中，后續計算請求任務將Tm與自定義閾值時間T作對比，得到計算任務的復雜等級X：

其中：N為數據存儲端的個數；Tm表示第一次請求數據時間；T表示自定義閾值時間；X表示參與計算節點數和計算任務的復雜等級；［］表示取整。

當Tm/T≤1 時，表示接力計算模塊中的1 個接力計算節點得到全部計算任務Y。當Tm/T∈(1，N-2]時，使用式（2）計算每個接力計算節點獲取的計算任務量R：

其中：n代表計算節點的編號；Y表示計算任務量。

當Tm/T>N-2，并且Y%X=0 時，使用式（3）計算每個接力計算節點獲取的計算任務量R：

當Tm/T>N-2，并且Y%X≠0 時，使用式（4）計算每個接力計算節點獲取的計算任務量R：

接力計算節點完成計算任務的分配時，需要先對接力計算節點進行編號。利用微服務架構中的服務發現功能獲取第一層接力計算節點所在服務器端的IP 地址，通過IP 地址讀取CPU 和內存使用率等信息，對節點資源能力按照從低到高進行排序，對各個節點進行編號（編號值n：1 →N-1）。每個接力計算節點分配的計算任務量R由式（2）～（4）可得。

SQL 捕獲器結果判斷是數據同步任務時，將SQL 捕獲器結果和任務標識作為請求參數，直接轉發到接力計算模塊進一步處理。

2）數據存儲模塊實現數據提取、簡單運算和數據同步的功能。

數據存儲模塊根據任務標識執行不同的任務，分別為計算任務和數據同步任務，以下將分為兩方面進行介紹。

①計算任務。

數據存儲模塊執行計算任務時，將數據提取和簡單運算放在該模塊完成，例如查詢計算人員的姓名、年齡等基本信息，可以從數據存儲模塊提取多位人員姓名、出生日期基本信息，通過編寫的數據庫函數實時計算年齡等信息。而在X個數據存儲端完成計算任務時，先判斷內存型數據存儲模塊是否存有當前所需數據，如果未保存，將數據寫入內存型數據存儲模塊，方便后續請求從內存型數據存儲模塊中直接提取。計算完成后將半成品結果返回至接力計算模塊進一步處理。

②數據同步任務。

數據存儲模塊執行數據同步任務時，N個數據存儲端執行SQL 捕獲器的結果（增加、刪除和更新），N個接力計算節點記錄執行情況并使用WebClient 相互通信。如果當前數據存儲端執行成功，同時收到其余（N-1）個數據存儲端執行成功的信息，接力計算節點向上一層接力處理模塊返回執行成功的信息。

如果N個數據存儲端中出現執行失敗的情況，出錯的接力計算節點使用WebClient向其余節點發送執行失敗的信息，利用數據庫ACID 特性［15］的原子性（ACID特性即原子性Atomic、一致性Consistency、隔離性Isolation和持久性Durability），對執行成功的模塊進行事務回滾，恢復至執行前的數據狀態，同時接力計算節點向上一層計算終端返回執行失敗的信息，這樣可以保證N個數據存儲端中的數據完全相同。數據存儲模塊功能流程如圖4所示。

圖4 數據存儲模塊功能流程Fig.4 Function flowchart of data storage module

3）接力計算模塊完成數據的大部分計算。

接力計算模塊主要完成大部分的計算任務，可以自定義接力計算層數F，其中每層接力節點數m需要大于等于數據存儲端數量N。

本文在確定最佳接力計算層數F時，需要對復雜計算任務完成分解。任務分解的思想在于將一個復雜計算任務通過某種方式分解為多個不同的、簡單的子任務，可以將這些分解后的子任務交給多個接力計算模塊完成，最終將多個模塊計算完成的結果返回數據分流模塊，進行整合規范。

本文在完成計算任務分解時，需先測量單機完成該任務所花費的時長。接著，將任務分解為多個無關聯的計算子任務，分配至多層接力計算節點完成，記錄任務完成時間。同時，考慮各模塊的關聯和依賴作用，將多個計算子任務合并在同一個接力節點完成，記錄最終任務的完成時間。比較多種任務分解方式，得出最合理的任務分解方式，計算完成所花費的時間最短。

本文使用3層接力節點，每層接力節點包含3個接力計算節點，3 個數據存儲端為例進行具體詳述。接力計算模塊結構如圖5所示。

圖5 接力計算模塊結構圖Fig.5 Structure diagram of relay computation module

數據分流模塊對數據進行分流，根據式（1）確定復雜等級X的值，比如計算完成X的值為2，代表將計算任務分配至兩個接力計算節點同時完成。將計算任務量劃分成2 份，對第一層接力節點中3 個計算節點資源能力從高到低進行排序編號，將計算任務分配至編號1 和2 的接力計算節點完成，根據式（3）或式（4）得到每個接力計算節點分配的計算任務量R。節點資源能力計算公式如下：

其中：NodeAbility代表計算節點的資源能力；Rate代表CPU 剩余利用率；idle_cores代表空閑CPU 核數；MainFrequency代表CPU主頻。

處理數據完成后，對第二層接力計算節點資源能力按照式（5）計算后進行排序編號，轉發對應編號節點的計算任務請求，比如第一層接力節點編號為1 的計算節點向第二層接力節點中編號為1 的計算節點轉發請求，以此類推，第二層接力節點向第三層節點請求轉發的規則也相同。節點計算結構如圖6所示。

圖6 節點計算結構圖Fig.6 Node computation structure diagram

如上所述，請求到達第三層接力節點時，數據提取和簡單運算放在數據存儲模塊完成，每個接力計算節點對應一個數據存儲端，在計算過程中可以直接獲取內存型數據存儲模塊中所需數據，計算完成的半成品結果在第三層、第二層和第一層接力節點中特制的計算模塊進行進一步處理。第一層接力節點得到最終計算結果后，返回到數據分流模塊，進行合并2個接力節點的計算結果，轉換為客戶端能夠解析的數據類型，將整合規范后的結果返回客戶端展示。接力計算模塊中的各層節點之間的通信采用異步非阻塞的WebClient方式，不會阻塞后續程序運行。

接力計算模塊處理數據同步任務時，計算結構圖和處理計算任務時相同，如圖6所示。

數據分流模塊將SQL捕獲器的結果和數據同步任務標識作為請求參數，轉發至第一層接力節點中資源能力按照式（5）計算后進行排序編號為1 的計算節點，在解析請求參數中任務標識為數據同步任務時，將請求直接轉發至第二層接力節點中資源能力也按照式（5）計算后進行排序編號為1 的計算節點，該節點接收請求后，轉發至第三層中所有計算節點，在數據存儲模塊中并行執行SQL 捕獲器結果。如前面所述，出現執行失敗的情況時，3 個接力計算節點使用WebClient 相互通信，數據存儲模塊進行事務回滾，恢復至未執行前的數據狀態。3 個接力計算節點將執行失敗情況原路返回，在數據分流模塊對執行情況進行整合，最終將任務完成情況返回給客戶端。數據同步失敗結構如圖7所示。

圖7 數據同步失敗結構圖Fig.7 Data synchronization failure structure diagram

4 測試與結果分析

本文通過計算保存在數據存儲模塊中的學生成績數據，獲取指定數據量的計算任務，完成對應學生總分、平均分等計算。將第一次多個計算節點請求數據的響應時間小于單個計算節點時的數據量預存儲在內存型數據存儲模塊，后續請求數據量與內存型數據存儲模塊中作對比：如果超過該數據量，對數據進行分流；如果未超過該數據量，由單個計算節點完成，利用當前節點的資源能力判斷任務分配至各層節點計算。

本文測試計算中，主要使用單個計算節點和兩個計算節點（2 層接力節點，每層接力節點包含2 個接力計算節點和2個數據存儲端）進行測試。模擬接力計算時，為簡單處理只將提取學生成績放在數據存儲端完成，平均分放在第一層節點，總分放在第二層節點計算。

客戶端將計算任務分配至數據分流模塊，通過內存型數據存儲模塊中的數據判斷是否進行分流，將分流請求數據量傳送至第二層計算節點，提取學生多門成績放在數據存儲模塊完成，將半成品計算結果以流的形式返回接力計算模塊，分別計算學生的總分和平均分。計算完成，將結果返回數據分流模塊進行整合，最終在客戶端展示。每次客戶端發送計算請求時，記錄每次請求完成的響應時間。

需要說明的是，為了測試的真實性，測試在正式的生產環境進行，所以沒有讓計算進行同步回寫存儲，但不影響對模型與框架的驗證與相應結論。

4.1 測試的物理環境

本文使用的物理環境包括如下：

數據分流模塊運行環境：1 臺Linux 服務器，操作系統CentOS-7.6 64 bit，運行內存8 GB，帶寬10 Mb/s，Java 開發工具包jdk-1.8.0_181。

接力計算模塊運行環境：2 臺Linux 服務器，操作系統CentOS 7.6 64 bit，運行內存8 GB，帶寬5 Mb/s，Java 開發工具包jdk-1.8.0_181。

數據存儲模塊運行環境：1 臺Linux 服務器，關系型數據庫管理系統MySQL 8.0.20，操作系統CentOS 7.6 64 bit，運行內存16 GB，帶寬5 Mb/s，Java 開發工具包jdk-1.8.0_181。

4.2 測試結果和分析

4.2.1 運行結果

通過對不同數量級數據的多次測試，去除波動較大的測試結果后取平均值。學生成績在單個節點和多個節點的計算完成時間的對比測試結果如表1所示。

表1 單個節點與兩個節點耗時對比Tab.1 Time consumption comparison between single node and two nodes

表2～3 展示的當計算請求數據量較大（30 000 條）和較小（100條）時，數據分流模塊接收10次計算請求后，每次單個節點和多個節點分別從請求開始到返回計算結果的完成時間對比。需要注意的是，由于實驗中服務器存在實時網絡狀態不同等原因，每次計算請求的完成時間是不相同的，所以表2～3展示的數據中，后續請求的完成時間可能會小于開始請求的完成時間。

表2 請求數據量大（30 000條）時的完成時間對比Tab.2 Comparison of completion time for requests with large amount of data（30 000 items）

表3 請求數據量小（100條）時的完成時間對比Tab.3 Comparison of completion time for requests with small amount of data（100 items）

4.2.2 運行結果分析

根據運行的結果，分析表1～3 可知：在計算請求數據量較小的情況下，單個計算節點完成相同計算任務的時間會小于多個計算節點的完成時間；而計算請求數據量較大的情況，則剛好相反。這說明該模型的計算調節器可以通過判斷請求數據量的大小來決定是否進行分流，避免在計算過程中過多資源的浪費。對于大流量數據的密集計算使用該模型可以降低運行時間，并且隨著計算請求數據量的增大和計算復雜度的增加，模型的優勢就越明顯。并且，該模型通過三層（內存型數據存儲模塊、接力計算模塊和數據存儲模塊）的接力計算，可以解決一般數據計算軟件可能出現的運算速度緩慢、計算阻塞堆積等問題，也大幅減少了其中一層的運算和處理接近滿負荷或積壓，而另外兩層出現等待或閑置的狀況。通過不同數量級計算數據的測試，記錄了單個節點和多個節點計算完成時間等指標，對指標數據的整理分析，說明了該模型能夠顯著提升數據計算的效率，對超高并發數據的處理、計算密集性數據的計算方法及類似應用場景，具有借鑒與參考性的價值。

5 結語

本文構建一種利用內存式數據存儲技術為過渡，通過預存儲、一體化轉換、讀寫分離等構架與算法，探索快速處理存儲模塊數據的模型與構架，并著眼于通過內存式數據存儲技術為樞紐，將大流量數據的計算任務，通過預加載、解耦、緩存機制等，銜接來自于動態分流進一步處理的數據，完成大流量數據的快速計算。該模型及其實現已經在實際的密集計算型的應用場景得到運用，在計算速度和資源成本方面都取得理想的結果［16］。該方案和相關技術對于計算密集型的應用領域和相關研究，都具有建設性的意義，也可降低信息化系統建設成本，實現資源充分利用。