徐亞軍

（ 蘇州百智通信息技術(shù)有限公司，江蘇 蘇州215000）

智能化機(jī)器學(xué)習(xí)技術(shù)成為現(xiàn)代公司追求的發(fā)展方向，普遍應(yīng)用于豐富的業(yè)務(wù)開發(fā)以及業(yè)務(wù)場(chǎng)景中，滿足一項(xiàng)業(yè)務(wù)需求，需要涉及整個(gè)數(shù)據(jù)收集以及機(jī)器學(xué)習(xí)模型線一體化算法流程，不同業(yè)務(wù)場(chǎng)景需要耗費(fèi)大量的成本做重復(fù)性開發(fā)工作，同時(shí)還需要融合原有軟件開發(fā)體系與模型開發(fā)流程，在這過(guò)程中容易造成代碼入侵問(wèn)題。

本文當(dāng)中所設(shè)計(jì)的一站式服務(wù)機(jī)器學(xué)習(xí)算法系統(tǒng)，可以完成從最初的數(shù)據(jù)采集存儲(chǔ)，到最后的模型線上化的計(jì)算過(guò)程。初級(jí)學(xué)習(xí)者也可以根據(jù)業(yè)務(wù)需求制作簡(jiǎn)單的機(jī)器學(xué)習(xí)模型，同時(shí)專業(yè)的工程師也可以借助該機(jī)器學(xué)習(xí)算法系統(tǒng)，開發(fā)更加復(fù)雜的模型平臺(tái)，減免了修改原有業(yè)務(wù)系統(tǒng)代碼過(guò)程。融合機(jī)器學(xué)習(xí)算法模型以及原有的業(yè)務(wù)生態(tài)系統(tǒng)，提升可擴(kuò)展性，同時(shí)降低維護(hù)和開發(fā)成本。

1 系統(tǒng)總體架構(gòu)設(shè)計(jì)

該機(jī)器學(xué)習(xí)算法系統(tǒng)，主要是面向?qū)嶓w用戶和虛擬用戶開放業(yè)務(wù)系統(tǒng)。系統(tǒng)對(duì)外接口不僅可以獲取用戶輸入信息，同時(shí)也可以將結(jié)果反饋給用戶。一般來(lái)說(shuō)實(shí)體用戶主要有圖形化以及終端命令輸入兩種輸入方式，而虛擬用戶主要運(yùn)用的是RPC 傳輸方式。

1.1 數(shù)據(jù)服務(wù)部分

數(shù)據(jù)采集服務(wù)位于整個(gè)服務(wù)層的外側(cè)，所有數(shù)據(jù)的存儲(chǔ)和交互都需要經(jīng)過(guò)數(shù)據(jù)服務(wù)層入口。資源的獲取以及讀取方式、上層數(shù)據(jù)的來(lái)源均需要依靠數(shù)據(jù)采集服務(wù)[1]。

1.2 數(shù)據(jù)清洗和數(shù)據(jù)標(biāo)準(zhǔn)化服務(wù)

清理臟亂數(shù)據(jù)、加工源數(shù)據(jù)以及賦予文字值數(shù)據(jù)化屬性，都需要在這兩個(gè)服務(wù)當(dāng)中進(jìn)行。特征工程服務(wù)位于服務(wù)最底端，其主要作用是提取精細(xì)化和標(biāo)準(zhǔn)化的數(shù)據(jù)特征，進(jìn)行特征降維操作等（圖1）。

1.3 算法模型層

1.3.1 模型解析

模型解析的主要工作是解析，有關(guān)計(jì)算圖的描述信息。然后將模型放在內(nèi)存當(dāng)中，依靠算法庫(kù)中的通用算法庫(kù)、自定義復(fù)雜算法庫(kù)以及通用場(chǎng)景庫(kù)做訓(xùn)練、評(píng)估和上線。

1.3.2 計(jì)算層

圖1 面向服務(wù)的一站式機(jī)器學(xué)習(xí)算法系統(tǒng)整體架構(gòu)圖

計(jì)算層不僅能夠支撐算法模型層，同時(shí)也能夠?qū)崿F(xiàn)算法的多樣化計(jì)算。計(jì)算層主要分為三類，分別為spark 大規(guī)模數(shù)據(jù)批處理和流處理框架、Tensorflow為代表的分布式深度學(xué)習(xí)框架以及MPI 并行計(jì)算技術(shù)。

2 面向服務(wù)的一站式機(jī)器學(xué)習(xí)算法系統(tǒng)的詳細(xì)設(shè)計(jì)與實(shí)現(xiàn)

2.1 數(shù)據(jù)采集存儲(chǔ)模塊

系統(tǒng)數(shù)據(jù)層的出入口，存在于數(shù)據(jù)采集存儲(chǔ)模塊中。該模塊可以將不同的數(shù)據(jù)源交互方式，轉(zhuǎn)變成單一的黑盒模式，借助API，使上層模塊，能夠操作不同數(shù)據(jù)源。與此同時(shí)，該模塊借助多線程并行方式，解決了數(shù)據(jù)存儲(chǔ)介質(zhì)交互過(guò)程中磁盤l/0 以及網(wǎng)絡(luò)l/O 所造成的等待時(shí)間過(guò)長(zhǎng)問(wèn)題，從而提升模塊的存儲(chǔ)性和讀取性能[2]。

選擇1#樣品韻達(dá)公司快遞包裹袋，剪取面積為0.5 cm×0.5 cm，利用反射法，在相同檢測(cè)條件下重復(fù)測(cè)定5次。

2.1.1 數(shù)據(jù)采集存儲(chǔ)模塊的詳細(xì)設(shè)計(jì)

關(guān)于數(shù)據(jù)采集存儲(chǔ)模塊的設(shè)計(jì)，不同的屬性對(duì)應(yīng)不同的數(shù)據(jù)源信息。數(shù)據(jù)源的IP 地址source IP 端口地址對(duì)應(yīng)sourceport，數(shù)據(jù)源類型對(duì)應(yīng)sourceType，數(shù)據(jù)源擴(kuò)展字段的json 格式對(duì)應(yīng)featureStr，例如mysql 的庫(kù)名等。為提升讀取便利性，feature 所對(duì)應(yīng)的map 形式，是由數(shù)據(jù)源拓展字段演變而來(lái)。

AbstractDataSource 是不同數(shù)據(jù)源交互方式的抽象父類，shardPolicy 類型是其重要成員。該種類型可以從DataSourceBean的feature 中獲得用戶分片信息，并根據(jù)行列或者文件名進(jìn)行讀取。其中，DataSourcePool 類型主要負(fù)責(zé)連接數(shù)據(jù)源，充當(dāng)有限大小連接池，定義其核心的為po olsize 定義。resize 方法，可以擴(kuò)充連接池容量，F(xiàn)ree 方法，可以銷毀并且回收連接池資源。

該模塊主要采取的設(shè)計(jì)思想為Pro actro 模式，從而提升數(shù)據(jù)讀取和存儲(chǔ)效率，所使用方法為startTask 方法以及checkDoneQueue 方法，前者主要是用來(lái)創(chuàng)建和分發(fā)任務(wù)；后者主要負(fù)責(zé)嗅探工作，TaskEventQueue 是任務(wù)隊(duì)列的集合類，一旦發(fā)現(xiàn)隊(duì)列中存在任務(wù)，便可完成自動(dòng)讀取任務(wù)獲取信息。其中，DataSourceTask 是任務(wù)載體類別，taskType, taskStatus 以及taskResult 分別對(duì)應(yīng)的是任務(wù)類型、狀態(tài)和結(jié)果[3]。

2.1.2 數(shù)據(jù)采集存儲(chǔ)模塊的實(shí)現(xiàn)

數(shù)據(jù)任務(wù)的執(zhí)行、調(diào)度以及數(shù)據(jù)源連接資源的分配，是數(shù)據(jù)采集模塊當(dāng)中較為重要的部分、為實(shí)現(xiàn)數(shù)據(jù)任務(wù)的調(diào)度控制，需 要 借 助 DataSourceController DataSource' Task 以 及TaskEventQueue 三大類來(lái)實(shí)現(xiàn)。

第二類，可以有效封裝，所有數(shù)據(jù)任務(wù)操作控制數(shù)據(jù)任務(wù)狀態(tài)變化，同時(shí)運(yùn)用call,wait,wake 三種方法，執(zhí)行task 的任務(wù)，可轉(zhuǎn)化系統(tǒng)狀態(tài)。其中call 方法主要作用是獲取數(shù)據(jù)源鏈接，如果獲取失敗，則可以運(yùn)用task 以及wake 方法，喚醒沉睡的線程。

第三類，作為任務(wù)隊(duì)列數(shù)據(jù)結(jié)構(gòu)，包括任務(wù)結(jié)果隊(duì)列、等待資源任務(wù)隊(duì)列以及空閑任務(wù)隊(duì)列、正在運(yùn)行任務(wù)隊(duì)列。第三類是單例，一般不會(huì)用在多個(gè)線程中，如果是4 個(gè)數(shù)據(jù)結(jié)構(gòu)需要運(yùn)用線程.ConcurrentHashMap 類和LinkedBlockingQueue 類[4]。

2.2 算法服務(wù)模塊

2.2.1 算法服務(wù)模塊的詳細(xì)設(shè)計(jì)

Pro cess 方法是ServiceBroker 類用來(lái)接收消息，開啟算法服務(wù)模塊流程的關(guān)鍵。ServiceBuilder 類用于創(chuàng)建服務(wù)的任務(wù)類，其中jobld 指的是模型編號(hào)，fileur，指的是模型持久化文件儲(chǔ)存位置。

ModelService 類是存在大量實(shí)體的外供系統(tǒng)模型服務(wù)，主要運(yùn)用的方法為predict 在線預(yù)測(cè)服務(wù)方法，通過(guò)byte 數(shù)組以及models 關(guān)于jobld 的PredictModel 對(duì)象，完成模型預(yù)測(cè)。其中包含存儲(chǔ)模型mpa，即models；檢測(cè)存儲(chǔ)器正確性的mpa，即monitors（圖2）。

關(guān)于算法服務(wù)模塊建立算法服務(wù)的關(guān)鍵流程節(jié)點(diǎn)具體如下：

首先，可靠消息隊(duì)列會(huì)收到來(lái)自算法引擎模塊的文件儲(chǔ)存位置、模型文件大小等模型信息；然后，通過(guò)cosumer 位置，借助Process 方法，傳送至ServiceBroker 服務(wù)器；內(nèi)存放模型建立單線程ServiceBuilder 任務(wù)，將執(zhí)行模型重放至predictModel 載體類中，在model service 節(jié)點(diǎn)機(jī)器上添置模型。

圖2 算法引擎模塊類關(guān)鍵類類型

2.2.2 算法服務(wù)模塊的實(shí)現(xiàn)

算法服務(wù)模塊的方法包含： ServiceBroker 的process 方法、ServiceBuilder 的run 方法以及ModelService 的addModel 方法。其中，第1 種方法，主要作用是接收消息并判斷類型，該方法處理心跳類型的消息便是直接回應(yīng)消息給對(duì)方。而第2 種方法，具有較強(qiáng)的處理邏輯。根據(jù)所對(duì)應(yīng)的HDFS 存儲(chǔ)位置尋找適宜的HDFS 服務(wù)器，讀取形式為byte 數(shù)組的數(shù)據(jù)流文件，將其轉(zhuǎn)化為PredictModel 對(duì)象，并與manager 節(jié)點(diǎn)建立關(guān)聯(lián)，獲取modelService 的節(jié)點(diǎn)信息，從而選擇模型服務(wù)節(jié)點(diǎn)與業(yè)務(wù)節(jié)點(diǎn)之間的距離作為最合適的節(jié)點(diǎn)，部署系統(tǒng)模型，于兩個(gè)節(jié)點(diǎn)之上，用來(lái)提供服務(wù)和服務(wù)備份工作[5]。

3 結(jié)論

綜上所述，面向服務(wù)的一站式機(jī)器學(xué)習(xí)算法系統(tǒng)，可以融合機(jī)器學(xué)習(xí)模型以及傳統(tǒng)軟件系統(tǒng)，拓展了系統(tǒng)的可修改性，精細(xì)優(yōu)化線程模型。通過(guò)設(shè)計(jì)和實(shí)現(xiàn)可算法模型以及數(shù)據(jù)采集模型，解決代碼入侵問(wèn)題，從而借助偽代碼和原生代碼，使系統(tǒng)的設(shè)計(jì)得以實(shí)現(xiàn)。