一種云原生數據智能服務生產平臺設計與實現

王浩田,鄂海紅,王 勇,宋美娜

(1.北京郵電大學 計算機學院(國家示范性軟件學院),北京 100876;2.聯洋國融(北京)科技有限公司,北京 100088)

0 引 言

隨著數字技術革新與發展,數字化轉型已成為企業轉型升級的必由之路[1]。數據智能業務通過“記錄—統計—分析—預測-決策”的方式為企業在不同場景的運營與發展提供了核心資料支撐,是企業實現數字化轉型的重要目標之一。傳統企業的數據智能業務發展對于當前過載的互聯網、大數據環境顯得力不從心,數據說話、精準定位、快捷響應已經成為現階段的基本訴求。

雖然國內外研究人員在大數據計算平臺、AI訓練平臺以及服務開發平臺[2-7]等方面都進行了大量的研究和實踐,但是都集中在以DevOps或MLOps的軟件生命周期方法單一地對大數據處理流程和AI訓練流程進行優化,仍無法滿足數據智能業務快捷開發的需求,存在以下問題和挑戰:

(1)海量多源異構數據集中管理與利用的問題。數據智能業務所需要的數據來源廣且量大,不同的數據源所屬領域不同,它們提供的數據呈分散、異構的特點,缺乏了統一的數據資源組織管理[8-11]。

(2)服務開發過程依舊繁瑣、開發周期依舊長的問題。數據智能業務的落地需要經過大數據存儲與處理、模型設計與訓練、模型性能評估、應用部署運維等過程,需要投入大量的人力分工協作,且不同工作間具有依賴性,對后期發現問題的返工修正的不斷更新,導致更高的時間和經濟成本[12-13]。另一方面,前期研發所形成的算法資產,對于新的數據和特定的場景,都有持續訓練、集成和部署的需求[14]。

(3)服務之間的可重復利用問題。在數據智能場景的服務開發中,復用多個已構建數據智能服務的原子能力形成新的服務,是一種提高生產力的有效方式[15]。但服務之間的依賴關系、重復調用導致了更長的響應時間和系統資源占用量,如何設計出高效的組合服務顯得格外重要。

因此,該文旨在設計并開發一個云原生數據智能服務開發平臺,實現從多源異構數據的統一組織管理,到數據智能服務自動化生產線的構建,再到高性能數據智能服務引擎的搭建,提高從數據資產到模型資產的價值轉變能力,模型資產到服務資產的持續訓練、集成和部署的自動化能力,以及服務資產之間的可重復利用能力,使相關人員能夠通過該平臺快速完成數據智能服務的開發與管理。

1 研究內容

針對以上問題與挑戰,該文重點圍繞數據智能服務自動化生產線和高性能分布式數據智能服務引擎兩個方面進行研究與分析,并完成了一個云原生數據智能服務生產平臺(見圖1)。主要研究內容有以下三項:

圖1 關鍵問題與研究內容

(1)設計并實現了數據智能服務自動化生產線。該生產線實現了從多源異構的海量數據資產存儲與管理,到大數據驅動的多版本AI模型資產的生產與管理,再到高性能數據智能服務資產的部署與管理的自動化生產流程,有效縮減了數據智能服務的開發周期,減少了人力投入,實現了降本增效的目的。

(2)設計并實現了高性能分布式數據智能服務引擎。一方面,引擎實現了數據智能服務實例根據負載狀況自動擴縮容,提高服務的穩定性和響應速度;另一方面,引擎以表達式即服務的方式,實現了對數據智能服務原子能力的復用,并對表達式的構建與調用進行了優化,解決了服務編排時服務依賴問題帶來的響應時間過長和服務重復調用導致的系統資源浪費的問題。

(3)設計并實現了云原生數據智能服務生產平臺。在產品設計方面,該平臺將算法與業務分離,使算法工程師更多地聚焦于算法的深度和廣度并承接更多場景的算法設計,使模型運營專注于數據集構建和模型訓練并快速達到業務指標。在系統功能方面,該平臺提供了多源異構數據統一管理、融合多種異構數據的數據集構建與管理、算子在線開發與版本管理、圖像化工作流拖拽開發與版本管理、模型評估部署與版本管理、服務健康監測、表達式服務在線編輯與測試功能。通過產品層面的解耦合與功能層面的自動化生產能力,大大提高了相關人員開發數據智能服務的效率。

2 數據智能服務自動化生產線

數據智能服務自動化生產線實現了從數據資產到模型資產再到服務資產的全方位管理與生產,以過程自動化的方式提高數據智能服務的生產效率,降低人力成本的投入。

圖2是數據智能服務生產流水線的架構,流水線的運轉依賴下層的基礎服務層和基礎設施層,并支撐了上層的系統應用層和場景應用。基礎設施層在物理機集群上搭建了Kubernetes容器云,提供了容器運行的基本環境。以容器應用作為承載平臺計算任務的基本單元,可以實現運維的自動化和彈性伸縮等功能并最大限度地發揮物理機群的性能和資源規模調度的效率優勢。基礎服務層以容器應用的方式封裝了Spark、MapReduce等計算服務,HDFS、Hive、Mysql、Minio等存儲服務,Docker Image、Docker Container等虛擬化服務,Grafana、Prometheus等監控服務,為流水線的核心功能層提供了基本服務。核心功能層實現了數據管理、自動化模型生產與管理、服務引擎等流水線的核心功能。系統應用層對流水線的功能進行了封裝,實現了數據管理與標注、算法模型研發、模型批量生產和數智服務管理等應用模塊,為多場景數據智能服務的生產做支撐。

圖2 數據智能服務生產流水線的架構

數據智能服務生產流水線為大屏可視化、智能客服、畫像構建、推薦系統等多個場景應用的構建提供了智能服務支持。

2.1 數據管理

數據智能服務的落地需要海量不同來源的數據作支撐,這些數據呈分散、異構的特點,因此,亟需一個統一的數據資源倉庫實現對數據的統一管理。

圖3是該文設計的數據資源倉庫,實現了對海量多源異構數據的存儲與管理。當用戶提交數據文件或數據源信息后,數據倉庫通過四個過程將其進行存儲:(1)將數據文件或數據源信息上傳到HDFS中并根據配置信息創建一個文件導入任務;(2)任務分類會將任務放入不同的管道中排隊;(3)空閑的解析器會在創建區根據它的類型裝載不同的文件導入任務;(4)裝載完畢后,在運行區解析文件并將數據插入到Hive倉庫中。其中任務解析器是一個Job類型的Pod,當解析器運行失敗Kubernetes會自動重啟該任務,直到解析器運行成功。當讀取數據的時候,可以執行相應的Hive SQL,并且可以實現多源異構數據的關聯讀取。通過編寫不同的文件解析器,將文件從HDFS轉存到Hive中,可以實現多源異構數據的統一管理。

圖3 數據資源倉庫

圖3中的HDFS和Hive是基于Kubernetes平臺實現的大數據集群提供的存儲服務,采用這種方式部署大數據集群解決了傳統的大數據集群參數配置復雜、運維難度大、缺乏自動修復能力、彈性擴縮容緩慢且無法及時隨業務量變化等問題。

2.2 自動化模型生產與管理

數據智能服務開發過程多且復雜,過程與過程之間具有依賴性,后期的返工修復會導致更多的時間和經濟成本,以及在特定的場景和新數據的情況下,都有服務持續生產的需求。因此,該文在流水線中設計了自動化模型生產工作流和模型倉庫,實現了模型的自動生產與管理。

(1)工作流基本運算單元——算子。工作流中的節點也稱為算子,它是工作流運行的基本單元,對應Kubernetes中的Pod。算子由代碼文件夾(包含一個啟動腳本和相關的程序代碼)、運行鏡像、運行參數等元素組成。

(2)工作流調度引擎。將多個算子按照一定的依賴關系進行拼裝組合,就可以形成一個自動化工作流。工作流調度引擎將會按照依賴關系,依次運行每一個工作流節點。已創建工作流資源可以輸入不同的數據和設置不同的配置參數多次運行,生產出不同的模型或服務,實現算法資產的可持續集成、訓練和部署。

圖4是工作流調度引擎的執行過程,Web端構造的工作流圖會放入管道中排隊,空閑的工作流處理器依次讀取管道中的工作流圖進行解析與調度。工作流處理器維護一個集合,對工作流圖進行層序遍歷。每當運行完一個工作流節點,如果該工作流節點的后置節點不在集合中就將其加入集合,并對集合進行檢查,將所有前置依賴運行完的工作流節點取出并將其作為Job Pod放入Kubernetes中運行,重復進行此操作,直到集合為空,工作流運行成功。對于工作流中的一個節點,會存在兩次調度:一是等待全部依賴節點運行完成,才能夠調度該節點運行;二是將節點調度到Kubernetes集群的節點運行,實現資源的負載均衡。

圖4 工作流調度引擎的工作過程

(3)模型倉庫。工作流中的模型注冊算子會將訓練完的模型存入到模型倉庫,模型倉庫會將實現模型資產的統一管理。

圖5是模型倉庫的架構,注冊算子注入的模型首先經過模型轉換模塊轉換為ONNX模型,然后存入到模型庫。模型庫本質是一張Sql表,表中記錄了模型的基本信息和模型所在HDFS中的路徑。此外,模型倉庫還提供了模型評估和模型部署的功能,模型評估通過在評估腳本模板中加載ONNX模型和測試數據集并與作為運行環境的鏡像一起以Pod的形式在Kubernetes中運行,實現模型性能指標評估的計算。模型部署通過在推理腳本模板中加載ONNX模型并與作為運行環境的鏡像一起部署為多個Kubernetes的Pod實例實現服務的多實例部署與注冊。

圖5 模型倉庫功能與架構

2.3 服務引擎

模型倉庫中創建成功的模型部署會將部署信息作為服務信息注冊到服務引擎,服務引擎實現了對服務資產的統一管理。

圖6是服務引擎的架構,單個服務是由一個負載均衡器、一個ReplicaSet控制器和多個實例組成。服務列表綁定了每個負載均衡器的地址,通過服務列表可以查找到已經注冊的全部服務。底層的Prometheus監控著實例的CPU、內存等資源的利用率。伸縮控制控制器通過讀取實例的指標進行判斷,當某一指標超過設定的最大閾值后,開始控制ReplicaSet控制器進行實例橫向擴容;當所有指標均低于設定的最低閾值后,開始控制ReplicaSet進行實例縮容。通過這樣的結構和工作過程,提高了服務在峰值時的穩定性以及減少了在低谷時的資源利用。

圖6 服務引擎架構

3 高性能分布式數據智能服務引擎

高性能分布式數據智能服務引擎以表達式即服務方式實現了對數據智能服務原子能力的細粒度復用,并對表達式服務的構建、調用等方面進行了優化,有效提高了服務開發效率以及服務響應速度和系統資源利用率。

數據智能服務引擎是三層結構(見圖7):原子服務層、引擎中控層和應用層,底下兩層采用了分布式的結構。核心層是引擎中控層,它采用Leader-Worker的結構保證中控層的高可用性和一致性,單節點的內部由功能決策、緩存、歸并優化器、狀態控制器、邏輯運算器、排序模塊、存儲服務、溢寫模塊等模塊組成,實現了表達式的優化和表達式服務調用的優化。底層是原子服務層,它實現了AI模型的推理能力,由負載均衡器和多個服務實例組成。最上層是應用層,提供了表達式構建、表達式準確率在線測試和服務管理的功能。

表1 引擎結構的主要模塊

圖7 數據智能服務引擎的三層結構

3.1 表達式服務

數據智能服務本質上是一種數據驅動的人工智能服務,不同類型的服務由多種原子能力組成,如文本多標簽分類服務是由多種單標簽分類原子能力組成,命名實體識別服務是由多種單實體識別原子能力組成。針對數據智能服務的這種特點,該文將多種不同服務的原子能力組合成邏輯表達式,以表達式即服務的方式實現了新服務的快速開發。

3.2 表達式服務的創建

圖8展示了表達式服務創建的過程。功能決策模塊首先會根據請求的Type字段判斷請求為服務創建類型,然后請求轉發給歸并優化器。歸并優化器會提取共有的原子服務進行聚合,示例中的表達式有三個數據智能服務項(也叫做原子服務項),共兩類atom_A和atom_B。具體歸并聚合例子為:[CallTC(atom_A,text, ‘見面問候’) ‖ CallTC(atom_A, text, ‘離別問候’) ‖ CallTC(atom_B, text,‘問候語’) ‖ InRegex(‘你好’,…,‘再見’)] &&NotInRegex (‘我生氣’,…,‘不開心’),通過提取項中的原子服務,得到atom_A,atom_A和atom_B,然后進行歸并得到atom_A和Atom_B,對原表達式進行改寫,得到:(atom_A_Res==‘見面問候’‖atom_A_Res==‘離別問候’‖Atom_B_Res==‘問候語’‖InList[‘你好’,…,‘再見’])&&NotInList(‘我生氣’,…,‘不開心’),該樣例表達式在AI服務引擎中會將原來的3次服務調用優化為2次。最后歸并優化器會將得到的優化結果以配置文件的形式存儲到存儲服務中,完成表達式服務的創建過程。

圖8 表達式服務創建過程

3.3 表達式服務的調用

圖9展示了表達式服務的調用過程。功能決策模塊首先會根據請求的Type字段判斷請求為服務調用類型,然后根據(ServiceId,Text)查找緩存中是否命中,如果命中直接返回結果,否則轉發請求到狀態控制器。狀態控制器根據ServiceId從存儲服務中找到表達式服務的配置文件,然后根據CallService中原子服務的數量,創建等量的線程,并行調用原子服務,直到全部的原子服務返回結果,將結果傳入到邏輯運算器。邏輯運算器根據原子服務的調用結果和正則列表,計算真值,將計算結果寫入到溢寫模塊并返回給客戶端。

圖9 表達式服務的調用過程

3.4 緩存的更新

引擎中的溢寫模塊記錄了所有請求與表達式服務的運算結果,當記錄存儲大小接近存儲系統的文件塊時,溢寫模塊會將這些記錄寫入到存儲服務中。引擎中的排序模塊會定期拉取歷史請求記錄以(ServiceId,Text)為Key進行聚合并降序排列,將結果的前N個寫入到緩存中。

4 云原生數據智能服務生產平臺

在數據智能服務自動化生產線和高性能數據智能服務引擎的基礎上,該文設計并實現了云原生數據智能服務開發平臺。一方面,該平臺實現了數據資產到模型資產持續訓練和集成的價值轉變能力,模型資產到服務資產持續部署的自動化能力,以及服務資產之間的可重復利用能力。另一方面,該平臺將算法與業務分離,使算法工程師更多地聚焦于算法的深度和廣度并承接更多場景的算法設計,使模型運營專注于數據集構建和模型訓練并快速達到業務指標。

4.1 平臺的功能架構

圖10是數據智能服務開發平臺功能結構,該平臺提供了數據管理、算子構建、模型開發、服務管理和復合服務5個模塊,實現了對15種資產或資源的生產與管理。

圖10 平臺功能結構

數據管理模塊實現了對多種數據源和數據集的統一管理,其中數據集通過導入數據源并進行標注生產而來。算子構建模塊實現了Job、Task、Run、鏡像、算子等資源的生產與管理,其中算子是一個Run的實例,Run是Task通過輸入運行參數運行的實例,Task由鏡像和項目腳本組成,Job則是一系列Task的集合。模型開發模塊實現了工作流、工作流運行歷史、模型、模型評估、模型部署等資源的生產與管理,其中工作流是對一系列算子編排而來,工作流運行歷史是工作流運行的實例,模型則是通過工作流運行生產而來,模型評估是通過輸入測試集對模型性能進行評估的實例,模型部署是將模型發布成服務的實例。服務管理實現了對服務實例的管理和監控,其中服務實例是模型部署后產生的。復合服務實現了對正則組、表達式服務等資源的管理,表達式服務由一系列正則組合和一系列服務實例通過邏輯運算組合而來。

表2 數據智能服務開發平臺的生產或管理的資產與資源

4.2 平臺的技術架構

圖11是平臺的技術架構,共分為5層:基礎設計層實現對CPU服務器、GPU服務器等物理設備的統一管理;虛擬化層利用Docker Engine和Kubernetes實現容器云,用于分配、調度和管理CPU計算資源、異構GPU計算資源、存儲資源、網絡資源,為上層設施提供基本計算能力和基本存儲能力的支持。基礎服務層提供AI訓練服務、大數據服務和通用數據存儲服務:AI訓練服務利用Pytorch、TensorFlow、ONNX等框架實現了AI模型的搭建、訓練和部署等能力;大數據服務利用HDFS、Hive實現大數據存儲能力,利用Spark實現大數據計算能力;通用存儲服務利用Mysql實現關系數據存儲,利用Minio實現對象存儲,搭建鏡像存儲服務器實現對鏡像的存儲。業務邏輯層將下層服務封裝成功能接口供前端調用,后端系統整體基礎架構采用Spring Boot開發,持久層框架采用MyBatis,實現對后端數據庫進行CRUD操作,前端與后端采用Restful API的方式進行通信。頁面展示層使用Vue.js前端開發框架進行開發,配合Element-UI樣式組件庫實現前端頁面展示效果。同時通過axios異步調用的方式訪問后端接口。

圖11 平臺技術架構

5 結束語

傳統企業的數據智能業務發展對于當前過載的互聯網、大數據環境顯得力不從心。針對海量多源異構數據集中管理與利用的問題、服務開發過程依舊繁瑣、開發周期依舊長的問題和服務之間的可重復利用問題,設計并實現了一個云原生數據智能服務開發平臺,提高了從數據資產到模型資產持續訓練和集成的價值轉變能力,模型資產到服務資產持續部署的自動化能力,以及服務資產的一站式運維能力和服務資產之間的可重復利用能力,使相關人員能夠通過該平臺快速完成數據智能服務的開發與管理。研發的平臺支撐了國家自然科學基金醫學認知圖譜復雜知識結構表示研究項目。