本發(fā)明涉及計算機技術(shù)領(lǐng)域，具體涉及一種基于插裝機制的APP任務執(zhí)行方法及系統(tǒng)。

背景技術(shù)：

隨著大數(shù)據(jù)時代的來臨，數(shù)據(jù)的處理框架層出不窮，其中，Spark作為全棧式的大數(shù)據(jù)處理框擁有Hadoop MapReduce所具有的優(yōu)點；但不同于MapReduce的是任務中間輸出結(jié)果可以保存在內(nèi)存中，從而不再需要讀寫HDFS，因此Spark能更好地適用于數(shù)據(jù)挖掘與機器學習等需要迭代的MapReduce的算法。因此，基于Spark的APP的開發(fā)及測試被廣泛的應用。

然而，目前Spark App的提交和執(zhí)行，大都采用手工調(diào)用spark-submit腳本的方式。這種方式對Spark App的提交執(zhí)行人員提出了要求，需要了解Shell命令(大部分Spark Client部署在Linux、Unix等非Windows操作系統(tǒng)下)；需要了解spark-submit參數(shù)對應的含義；需要能根據(jù)spark-submit腳本錯誤，分析spark-submit執(zhí)行命令的語法。如果由安全分析人員負責測試及執(zhí)行Spark App，他們關(guān)心的只是App計算的結(jié)果，并不關(guān)心App執(zhí)行過程以及過程中的錯誤，以上要求無疑提高了安全人員的使用成本和負擔。

因此，如何使安全分析人員能夠方便的對APP進行測試及執(zhí)行，是計算機技術(shù)領(lǐng)域亟待解決的問題。

技術(shù)實現(xiàn)要素：

本發(fā)明所要解決的技術(shù)問題是針對現(xiàn)有技術(shù)中所存在的上述缺陷，提供一種基于插裝機制的APP任務執(zhí)行方法及系統(tǒng)，用以解決現(xiàn)有技術(shù)中存在的基于SPARK的APP開發(fā)及測試執(zhí)行不能分離，導致基于SPARK的APP的測試及執(zhí)行復雜的問題。

為實現(xiàn)上述目的，本發(fā)明提供一種基于插裝機制的APP任務執(zhí)行方法，所述方法包括如下步驟：

獲取APP信息，并根據(jù)所述APP信息在插件表中注冊生成APP插件記錄；

根據(jù)所述APP插件記錄生成初始APP任務；

對所述初始APP任務進行參數(shù)配置，并執(zhí)行參數(shù)配置后的APP任務。

優(yōu)選的，所述APP信息包括APP算法信息，則在所述獲取APP信息的步驟之后，根據(jù)所述APP信息在插件表中注冊生成APP插件記錄的步驟之前，所述方法還包括：判斷是否支持所述APP算法信息中的算法，若不支持，則在預設(shè)的算法表中增加所述APP信息中的算法。

優(yōu)選的，所述在預設(shè)的算法信息表中增加所述APP信息中的算法，包括：在預設(shè)的算法表中創(chuàng)建所述APP信息中的APP算法記錄，以及在預設(shè)的插件算法關(guān)聯(lián)表中創(chuàng)建APP插件算法關(guān)聯(lián)記錄。

優(yōu)選的，所述參數(shù)包括算法參數(shù)和執(zhí)行參數(shù)；所述對所述初始APP任務進行參數(shù)配置，具體包括：對所述初始APP任務在預設(shè)的算法參數(shù)表中創(chuàng)建APP算法參數(shù)記錄，并在預設(shè)的任務參數(shù)賦值表中創(chuàng)建APP執(zhí)行參數(shù)賦值記錄。

本發(fā)明還提供一種基于插裝機制的APP任務執(zhí)行系統(tǒng)，包括：

獲取模塊，用于獲取APP信息；

插件管理模塊，用于根據(jù)所述APP信息在插件表中注冊生成APP插件記錄；

任務管理模塊，用于根據(jù)所述APP插件記錄生成初始APP任務；

參數(shù)配置模塊，用于對所述初始APP任務進行參數(shù)配置；

任務執(zhí)行模塊，用于執(zhí)行參數(shù)配置后的APP任務。

優(yōu)選的，所述獲取模塊，具體用于獲取所述APP信息，所述APP信息包括APP算法信息，則所述系統(tǒng)還包括:判斷模塊和算法管理模塊；所述判斷模塊，用于在所述獲取模塊獲取APP信息之后，在所述插件管理模塊根據(jù)所述APP信息在插件表中注冊生成APP插件記錄之前，判斷是否支持所述APP算法信息中的算法，若不支持，則指示所述算法管理模塊，用于在預設(shè)的算法表中增加所述APP信息中的算法。

優(yōu)選的，所述算法管理模塊，具體用于在預設(shè)的算法表中創(chuàng)建所述APP信息中的APP算法記錄，以及在預設(shè)的插件算法關(guān)聯(lián)表中創(chuàng)建APP插件算法關(guān)聯(lián)記錄。

優(yōu)選的，所述參數(shù)包括算法參數(shù)和執(zhí)行參數(shù)；所述參數(shù)配置模塊，具體用于對所述初始APP任務在預設(shè)的算法參數(shù)表中創(chuàng)建APP算法參數(shù)記錄，并在預設(shè)的任務參數(shù)賦值表中創(chuàng)建APP執(zhí)行參數(shù)賦值記錄。

本發(fā)明所提供基于插裝機制的APP任務執(zhí)行方法及系統(tǒng)，能夠?qū)PP的開發(fā)工作及測試執(zhí)行工作相分離，開發(fā)人員注重APP的功能開發(fā)，測試執(zhí)行人員可以在只具備相對簡單的技術(shù)背景，及掌握相對簡單的測試技能的前提下，便能很好的完成APP的測試執(zhí)行任務，使得APP的開發(fā)及測試執(zhí)行工作分工更加明確，流程更加簡單，人力成本也相對下降，并能減少SPARK APP調(diào)用SPARK-SUBMIT腳本提交和執(zhí)行過程中的人為因素導致的異常和錯誤。

附圖說明

為了更清楚的說明本發(fā)明實施例中的技術(shù)方案，下面將對實施例描述中所需要使用的附圖做簡單地介紹，顯而易見地，下面描述中的附圖是本發(fā)明的一些實施例，對于本領(lǐng)域普通技術(shù)人員來講，在不付出創(chuàng)造性勞動的前提下，還可以根據(jù)這些附圖獲得其他附圖。

圖1為本發(fā)明提供的一種基于插裝機制的APP任務執(zhí)行方法的流程示意圖；

圖2為本發(fā)明提供的一種基于插裝機制的APP任務執(zhí)行系統(tǒng)功能模塊結(jié)構(gòu)示意圖；

圖3為本發(fā)明提供的一種基于插裝機制的APP任務執(zhí)行系統(tǒng)的實現(xiàn)結(jié)構(gòu)示意圖；

圖4為本發(fā)明提供的一種基于插裝機制的APP任務執(zhí)行系統(tǒng)的數(shù)據(jù)庫設(shè)計圖；

圖5為本發(fā)明提供的一種基于插裝機制的APP任務執(zhí)行系統(tǒng)的插件生成輸入界面；

圖6為本發(fā)明提供的一種基于插裝機制的APP任務執(zhí)行系統(tǒng)的任務生成輸入界面；

圖7為本發(fā)明提供的一種基于插裝機制的APP任務執(zhí)行系統(tǒng)的任務管理界面；

圖8為本發(fā)明提供的一種基于插裝機制的APP任務執(zhí)行系統(tǒng)的任務結(jié)果展示界面。

具體實施方式

為使本領(lǐng)域技術(shù)人員更好地理解本發(fā)明的技術(shù)方案，下面結(jié)合附圖和實施例對本發(fā)明作進一步詳細描述。顯然，所描述的實施例是本發(fā)明一部分實施例，而不是全部的實施例?；诒景l(fā)明中的實施例，本領(lǐng)域普通技術(shù)人員在沒有做出創(chuàng)造性勞動前提下所獲得的所有其他實施例，都屬于本發(fā)明保護的范圍。

圖1為本發(fā)明提供的一基于插裝機制的APP任務執(zhí)行方法的流程示意圖，圖1所示的一種基于插裝機制的APP任務執(zhí)行方法的流程包括：

步驟S101,獲取APP信息，并根據(jù)所述APP信息在插件表中注冊生成APP插件記錄。

具體的，在對APP進行測試執(zhí)行之前，需要獲知的APP的信息包括，APP需要調(diào)用的算法，APP在數(shù)據(jù)庫中的數(shù)據(jù)包路徑，APP的運行類入口，即APP的運行類信息，以便進行插件的注冊。

本發(fā)明提供一種優(yōu)選的方式，為適應APP的多樣性，在獲取APP信息步驟之后，所述方法還包括：判斷是否支持所述APP算法信息中的算法，若不支持，則在預設(shè)的算法表中增加所述APP信息中的算法。

由于APP的多樣性，導致APP需要調(diào)用的算法，不一定是插件表中已經(jīng)具備的算法，為保證插件的順利注冊及任務的順利生成，實現(xiàn)檢查APP需要的算法是否具備，是本發(fā)明提供的一項優(yōu)選的步驟。

其中，在所述算法信息表中增加所述APP信息中的算法，包括：在預設(shè)的算法表中創(chuàng)建所述APP信息中的APP算法記錄，以及在預設(shè)的插件算法關(guān)聯(lián)表中創(chuàng)建APP插件算法關(guān)聯(lián)記錄。

所述APP算法表包括算法名稱，算法描述，狀態(tài)，樂觀鎖，創(chuàng)建人，創(chuàng)建時間，所述APP插件算法關(guān)聯(lián)記表包括插件名稱和算法名稱。通過建立新的算法記錄，并與插件表進行關(guān)聯(lián)后，APP需要調(diào)用的算法便具備了被調(diào)用的基礎(chǔ)。

上述的插件表、算法表及插件算法關(guān)聯(lián)表，其數(shù)據(jù)庫的具體實現(xiàn)方式，如圖4所示。

根據(jù)所述APP信息在插件表中注冊生成APP插件記錄，所述APP插件記錄包括插件名稱，插件編碼，APP信息，插件狀態(tài)，樂觀鎖，創(chuàng)建人，創(chuàng)建時間。生成APP插件記錄后，形成了一個基于插裝機制的APP執(zhí)行插件，通過調(diào)用相應的算法，便可以發(fā)送給系統(tǒng)中的APP管理模塊生成APP執(zhí)行任務，實現(xiàn)開發(fā)及測試執(zhí)行分離的APP管理流程。

本發(fā)明還提供圖形化的人機交互界面，方便用戶的使用和操作，其中圖5為插件生成輸入界面，通過頁面顯示可以看出，生成APP插件記錄的必須項，主要涉及到使用的算法及插件的類型。

步驟S102,根據(jù)所述APP插件記錄生成初始APP任務。

具體的，根據(jù)APP插件記錄生成后，結(jié)合APP運行需要的業(yè)務場景生成初始APP任務。

由于APP的多樣性，所述APP運行所需要的業(yè)務場景也是非常多樣的，所述初始APP任務，包括：在任務表中創(chuàng)建初始APP任務記錄，所述初始APP任務記錄包括插件名稱，算法名稱，業(yè)務參數(shù)，SPARK運行參數(shù)，任務調(diào)度參數(shù)，任務開始時間，任務結(jié)束時間，任務失敗異常，任務狀態(tài)，任務類型，樂觀鎖，創(chuàng)建人，創(chuàng)建時間。同樣，所述初始任務所對應的任務表如圖4的任務表所示。

步驟S103,對所述初始APP任務進行參數(shù)配置，并執(zhí)行參數(shù)配置后的APP任務。

具體的，所述參數(shù)包括算法參數(shù)和執(zhí)行參數(shù)；所述對所述初始APP任務進行參數(shù)配置，具體包括：對所述初始APP任務在預設(shè)的算法參數(shù)表中創(chuàng)建APP算法參數(shù)記錄，并在預設(shè)的任務參數(shù)賦值表中創(chuàng)建APP執(zhí)行參數(shù)賦值記錄。

初始APP任務需要進行算法參數(shù)及執(zhí)行參數(shù)的完善，生成完整的APP任務。由于APP任務是APP插件負責具體生成的，其涉及的算法及執(zhí)行的信息等，需要本發(fā)明提供的APP插件管理模塊進行具體設(shè)置。圖6為本發(fā)明提供的人機交互界面中的任務生成界面，由于一個APP插件可對應多個APP任務，不同的APP任務都有獨立的任務名稱及相應的設(shè)置。

所述任務配置包括算法參數(shù)配置和執(zhí)行參數(shù)配置，其中：所述算法參數(shù)配置包括在算法參數(shù)表中創(chuàng)建APP算法參數(shù)記錄，所述APP算法參數(shù)記錄包括算法名稱，參數(shù)類型，參數(shù)描述，所述執(zhí)行參數(shù)配置包括在任務參數(shù)賦值表中創(chuàng)建APP執(zhí)行參數(shù)賦值記錄，所述APP執(zhí)行參數(shù)賦值記錄包括任務名稱，算法參數(shù)名稱和參數(shù)值。

對APP任務進行了算法參數(shù)配置及執(zhí)行參數(shù)配置以后，便生成了完整的基于插裝機制的APP執(zhí)行方法的任務，可以發(fā)送給APP任務執(zhí)行模塊，其中一個APP插件可以對應多個APP任務。本領(lǐng)域技術(shù)人員很容易理解的是，在進行任務的配置時，進行定時任務的配置，或進行人為設(shè)定執(zhí)行的配置，均是任務執(zhí)行配置中的常規(guī)選擇，本發(fā)明亦可使用這兩種配置，此處不再進行詳述。

本發(fā)明還提供一種優(yōu)選的方法，在任務執(zhí)行管理模塊執(zhí)行參數(shù)配置后的APP任務后，所述方法還包括：輸出所述APP計算結(jié)果。

即，本發(fā)明可以對APP的計算結(jié)果進行提取和展示，并提供圖形化的人機友好界面，在圖5至圖8中，對本發(fā)明提供的基于插裝機制的APP執(zhí)行方法中，重要的人機交互頁面進行了展示。在人機交互界面中，此步驟涉及的主要有兩個界面，如圖7為任務管理界面，圖8為任務結(jié)果展示界面。通過任務管理界面可對任務的執(zhí)行情況進行監(jiān)控，通過任務結(jié)果展示界面，可以對多個APP任務進行統(tǒng)計和分析。

本發(fā)明提供的基于插裝機制的APP任務執(zhí)行方法，通過創(chuàng)建APP插件并生成相應的APP任務的方法，使得APP的開發(fā)工作及測試執(zhí)行工作分工明確，整個APP的生成流程清晰，并能減少APP測試執(zhí)行人員的人為失誤，降低人力成本。

圖2為本發(fā)明提供的一種基于插裝機制的APP任務執(zhí)行系統(tǒng)功能模塊結(jié)構(gòu)示意圖，如圖2所示的一種基于插裝機制的APP任務執(zhí)行系統(tǒng)功能模塊包括：

獲取模塊201，用于獲取APP信息，具體用于獲取所述APP信息，所述APP信息包括APP算法信息。

插件管理模塊202，用于根據(jù)所述APP信息在插件表中注冊生成APP插件記錄。

任務管理模塊203，用于根據(jù)所述APP插件記錄生成初始APP任務。

參數(shù)配置模塊204，用于對所述初始APP任務進行參數(shù)配置，具體用于對所述初始APP任務在預設(shè)的算法參數(shù)表中創(chuàng)建APP算法參數(shù)記錄，并在預設(shè)的任務參數(shù)賦值表中創(chuàng)建APP執(zhí)行參數(shù)賦值記錄。

任務執(zhí)行模塊205，用于執(zhí)行參數(shù)配置后的APP任務。

判斷模塊206，用于在所述獲取模塊獲取APP信息之后，在所述插件管理模塊根據(jù)所述APP信息在插件表中注冊生成APP插件記錄之前，判斷是否支持所述APP算法信息中的算法，若不支持，則指示算法管理模塊207在預設(shè)的算法表中增加所述APP信息中的算法。

算法管理模塊207，具體用于在預設(shè)的算法表中創(chuàng)建所述APP信息中的APP算法記錄，以及在預設(shè)的插件算法關(guān)聯(lián)表中創(chuàng)建APP插件算法關(guān)聯(lián)記錄。

本發(fā)明所提供的基于插裝機制的APP任務執(zhí)行系統(tǒng)，將APP開發(fā)功能及測試執(zhí)行功能分別在不同的模塊執(zhí)行，使得測試執(zhí)行人員只需輸入較少的運行參數(shù)及算法參數(shù)等，便可以順利的完成測試執(zhí)行的整個流程，使得整個APP的開發(fā)及測試執(zhí)行過程流程清晰，人為失誤大大降低。

為更好的對本發(fā)明所提供的方法及系統(tǒng)進行說明，下面結(jié)合圖3對本發(fā)明在實際系統(tǒng)中的實現(xiàn)進行進一步的說明。

圖3為本發(fā)明提供的一種基于插裝機制的APP任務執(zhí)行系統(tǒng)的實現(xiàn)結(jié)構(gòu)示意圖，如圖3所示的一種基于插裝機制的APP任務執(zhí)行系統(tǒng)的實現(xiàn)結(jié)構(gòu)包括：

平臺服務器301，主要用于承載插件管理模塊202，算法管理模塊207，和任務管理模塊203，是本發(fā)明所提供的基于插裝機制的APP任務執(zhí)行系統(tǒng)的核心平臺。

插件服務器302，主要用于與平臺服務器301，用于生成初步APP任務。

ZOOKEEPER集群303，主要用于整個APP任務執(zhí)行系統(tǒng)的狀態(tài)監(jiān)控。

MYSQL304，主要用于存儲插件APP的數(shù)據(jù)。

HDFS305，主要用于存儲插件APP數(shù)據(jù)，以及執(zhí)行APP任務。

appMgr306,主要用于APP任務的調(diào)度和APP任務的下發(fā)執(zhí)行。

Spark集群307，主要用于執(zhí)行APP任務。

存儲308，主要用于APP數(shù)據(jù)的存儲。

基于圖3的具體實現(xiàn)方式可以看出，本發(fā)明所提供的基于插裝機制的APP任務執(zhí)行方法及系統(tǒng)，充分利用了大數(shù)據(jù)平臺中的各項資源，實現(xiàn)了APP開發(fā)及測試執(zhí)行流程的清晰管理。

在本申請所提供的實施例中，應該理解到，所揭露的方法、設(shè)備和系統(tǒng)，可以通過其它的方式實現(xiàn)。例如，以上所描述的設(shè)備實施例僅是是示意性的，所述功能模塊的劃分，僅為一種邏輯功能的劃分，實際實現(xiàn)時可以有另外的劃分方式，例如多個模塊可以結(jié)合或者可以集成到另一個系統(tǒng)，或者一些特征可以忽略，或不執(zhí)行。

最后應說明的是：以上實施例僅用以說明本發(fā)明的技術(shù)方案，而非對其限制；盡管參照前述實施例對本發(fā)明進行了詳細的說明，本領(lǐng)域的普通技術(shù)人員應當理解：其依然可以對前述各實施例所記載的技術(shù)方案進行修改，或者對其中部分技術(shù)特征進行等同替換；而這些修改或者替換，并不使相應技術(shù)方案的本質(zhì)脫離本發(fā)明各實施例技術(shù)方案的精神和范圍。