1 摘要  

        運(yùn)營(yíng)商經(jīng)過(guò)多年的系統(tǒng)建設(shè)和演進(jìn)，內(nèi)部系統(tǒng)間存在一些壁壘，通過(guò)在運(yùn)營(yíng)商的各個(gè)內(nèi)部系統(tǒng),如經(jīng)分、VGOP、大數(shù)據(jù)平臺(tái)、集團(tuán)集市等中構(gòu)建基于ESB 的能力開(kāi)放平臺(tái),解決了系統(tǒng)間調(diào)度、封閉式開(kāi)發(fā)、數(shù)據(jù)孤島等系統(tǒng)問(wèn)題，使得運(yùn)營(yíng)商營(yíng)銷(xiāo)能力和效率大大提高。 

        2 問(wèn)題分析 

        2.1 背景分析 

        隨著市場(chǎng)發(fā)展，傳統(tǒng)的開(kāi)發(fā)模式已經(jīng)無(wú)法滿(mǎn)足業(yè)務(wù)開(kāi)發(fā)敏捷性的要求。2014 年以來(lái)，某省運(yùn)營(yíng)商經(jīng)營(yíng)分析需求量激增，開(kāi)發(fā)時(shí)限要求縮短，業(yè)務(wù)迭代優(yōu)化需求頻繁，原有的“工單-開(kāi)發(fā)”模式平均開(kāi)發(fā)周期為4.5 天，支撐負(fù)荷已達(dá)到極限。能力開(kāi)放使業(yè)務(wù)人員可以更便捷的接觸和使用到數(shù)據(jù)，釋放業(yè)務(wù)部門(mén)的開(kāi)發(fā)能力。 

        由于歷史原因，業(yè)務(wù)支撐系統(tǒng)存在經(jīng)分、VGOP、大數(shù)據(jù)平臺(tái)、集團(tuán)集市等多套獨(dú)立的運(yùn)維系統(tǒng)，缺乏統(tǒng)一的運(yùn)維管理，造成系統(tǒng)與系統(tǒng)之間的數(shù)據(jù)交付復(fù)雜，無(wú)法最大化的利用系統(tǒng)資源。統(tǒng)一調(diào)度的出現(xiàn)能夠充分整合現(xiàn)有調(diào)度系統(tǒng)，減少運(yùn)維工作量，提升維護(hù)質(zhì)量。 

        驅(qū)動(dòng)力一:程序調(diào)度管理混亂，系統(tǒng)資源使用不充分經(jīng)分、大數(shù)據(jù)平臺(tái)、GOP、集團(tuán)集市平臺(tái)各自擁有獨(dú)立的調(diào)度管理，平臺(tái)內(nèi)程序基本是串行執(zhí)行，以經(jīng)分日處理為例，每日運(yùn)行時(shí)間為20 個(gè)小時(shí)，已經(jīng)嚴(yán)重影響到了指標(biāo)的匯總展示。 

        驅(qū)動(dòng)力二:傳統(tǒng)開(kāi)發(fā)模式響應(yīng)慢，不能滿(mǎn)足敏捷開(kāi)發(fā)需求 

        大數(shù)據(jù)平臺(tái)已成為一個(gè)數(shù)據(jù)寶庫(kù)，已有趨勢(shì)表明，只依賴(lài)集成商與業(yè)務(wù)支撐人員的傳統(tǒng)開(kāi)發(fā)模式已經(jīng)無(wú)法快速響應(yīng)業(yè)務(wù)部門(mén)需求，提升數(shù)據(jù)價(jià)值。 

        驅(qū)動(dòng)力三:大數(shù)據(jù)平臺(tái)豐富了經(jīng)分的數(shù)據(jù)源，業(yè)務(wù)部門(mén)急待數(shù)據(jù)開(kāi)放某省運(yùn)營(yíng)商建立了面向企業(yè)內(nèi)部所有部門(mén)的大數(shù)據(jù)平臺(tái)，大數(shù)據(jù)平臺(tái)整合了接入B域、O 域、互聯(lián)網(wǎng)域數(shù)據(jù)，近100 余個(gè)數(shù)據(jù)接口，共計(jì)820T 的數(shù)據(jù)逐步投入生產(chǎn)。大數(shù)據(jù)平臺(tái)增強(qiáng)了傳統(tǒng)經(jīng)分的數(shù)據(jù)處理的能力，成為公司重要的資產(chǎn)，但是傳統(tǒng)經(jīng)分?jǐn)?shù)據(jù)倉(cāng)庫(kù)的用戶(hù)主要面向業(yè)支內(nèi)部人員，限制了數(shù)據(jù)的使用人員范圍和數(shù)據(jù)的使用頻度，已經(jīng)無(wú)法滿(mǎn)足公司日益發(fā)展的業(yè)務(wù)需求，數(shù)據(jù)的開(kāi)放迫在眉睫。 

        2.2 問(wèn)題詳解 

        基于背景情況分析，我們認(rèn)為主要問(wèn)題有三個(gè): 

        1、 缺乏統(tǒng)一的調(diào)度管理，維護(hù)效率低下 

        目前經(jīng)分系統(tǒng)的日處理一般是使用SHELL 腳本開(kāi)發(fā)的，按照串行調(diào)度的思路執(zhí)行。進(jìn)行能力開(kāi)放后，目前的系統(tǒng)架構(gòu)無(wú)法滿(mǎn)足開(kāi)發(fā)者提交的大量程序執(zhí)行調(diào)度的運(yùn)維需求。如果采用統(tǒng)一調(diào)度的設(shè)計(jì)思路則基于任務(wù)的數(shù)據(jù)表依賴(lài)進(jìn)行任務(wù)解耦及調(diào)度，將大大簡(jiǎn)化調(diào)度配置工作和提高系統(tǒng)的并發(fā)度; 

        2、 需求周期長(zhǎng)，導(dǎo)致開(kāi)發(fā)周期長(zhǎng) 

        現(xiàn)行的開(kāi)發(fā)模式是由業(yè)務(wù)部門(mén)提出需求，業(yè)務(wù)支撐中心進(jìn)行需求分析，然后再轉(zhuǎn)派給開(kāi)發(fā)廠商。廠商除了需要與業(yè)支溝通需求以外，有時(shí)候還需要與業(yè)務(wù)部門(mén)進(jìn)行二次溝通，最終才能明確需求，開(kāi)發(fā)周期比較長(zhǎng); 

        3、 數(shù)據(jù)管理分散，存在數(shù)據(jù)冗余，營(yíng)銷(xiāo)效果欠佳經(jīng)分系統(tǒng)對(duì)外提供數(shù)據(jù)，目前采用的是傳統(tǒng)的文件接口形式，這樣會(huì)造成經(jīng)分和外圍系統(tǒng)存在至少2 份的數(shù)據(jù)，隨著經(jīng)分的按天支撐模式，造成傳統(tǒng)的營(yíng)銷(xiāo)效果欠佳，外圍系統(tǒng)的存儲(chǔ)浪費(fèi)。 

        3 解決方案介紹 

        3.1 業(yè)務(wù)目標(biāo) 

        將大數(shù)據(jù)平臺(tái)及經(jīng)分?jǐn)?shù)據(jù)倉(cāng)庫(kù)平臺(tái)的數(shù)據(jù)和系統(tǒng)處理能力進(jìn)行標(biāo)準(zhǔn)化封裝，按需進(jìn)行開(kāi)放，滿(mǎn)足各業(yè)務(wù)部門(mén)數(shù)據(jù)使用的需求，并在經(jīng)驗(yàn)成熟的情況下逐漸開(kāi)放給外部眾多的合作伙伴使用。 

        統(tǒng)一調(diào)度:作為大數(shù)據(jù)開(kāi)放基礎(chǔ)平臺(tái)，通過(guò)消息總線將大數(shù)據(jù)平臺(tái)、經(jīng)分、集市、VGOP、業(yè)務(wù)部門(mén)的應(yīng)用進(jìn)行統(tǒng)一的系統(tǒng)調(diào)度管控，提供跨平臺(tái)調(diào)度、分發(fā)、解析等基礎(chǔ)功能，實(shí)現(xiàn)大數(shù)據(jù)平臺(tái)、經(jīng)分?jǐn)?shù)據(jù)倉(cāng)庫(kù)等多類(lèi)型底層平臺(tái)的能力互補(bǔ)，形成融合平臺(tái)的協(xié)作效應(yīng);通過(guò)多租戶(hù)技術(shù)，解決生產(chǎn)任務(wù)與數(shù)據(jù)開(kāi)放能力爭(zhēng)用的問(wèn)題，實(shí)現(xiàn)系統(tǒng)資源對(duì)生產(chǎn)任務(wù)與臨時(shí)任務(wù)的合理分配及高效調(diào)度。 

        統(tǒng)一開(kāi)發(fā):集成圖形化的開(kāi)發(fā)界面，通過(guò)統(tǒng)一封裝的函數(shù)庫(kù)提供類(lèi)SQL 的開(kāi)發(fā)語(yǔ)言，以屏蔽底層平臺(tái)差異，降低業(yè)務(wù)人員的開(kāi)發(fā)門(mén)檻，實(shí)現(xiàn)快速的業(yè)務(wù)開(kāi)發(fā)及數(shù)據(jù)測(cè)試。通過(guò)元數(shù)據(jù)的數(shù)據(jù)模型抽象，逐步將Hadoop、DB2 的后臺(tái)數(shù)據(jù)資源高、安全并可控可管的開(kāi)放給前端進(jìn)行訪問(wèn)。 

        數(shù)據(jù)共享:大數(shù)據(jù)平臺(tái)將用戶(hù)標(biāo)簽、營(yíng)銷(xiāo)目標(biāo)、用戶(hù)套餐剩余量等信息通過(guò)統(tǒng)一的數(shù)據(jù)服務(wù)方式開(kāi)放給其他系統(tǒng)或者在線使用，確保數(shù)據(jù)的唯一性和數(shù)據(jù)響應(yīng)的及時(shí)性。 

        3.2 方案內(nèi)容及亮點(diǎn) 

        圖為基于大數(shù)據(jù)的能力開(kāi)放體系架構(gòu)，我們?cè)谠写髷?shù)據(jù)平臺(tái)上進(jìn)行整合，使得大數(shù)據(jù)的成果能夠有效的被外部系統(tǒng)調(diào)用，并具備標(biāo)準(zhǔn)的服務(wù)能力供后續(xù)的系統(tǒng)對(duì)接。 能力開(kāi)放平臺(tái)由統(tǒng)一調(diào)度、統(tǒng)一開(kāi)發(fā)、數(shù)據(jù)共享三大平臺(tái)組成: 統(tǒng)一調(diào)度平臺(tái)將原大數(shù)據(jù)平臺(tái)、經(jīng)分?jǐn)?shù)據(jù)倉(cāng)庫(kù)、VGOP 平臺(tái)等關(guān)聯(lián)度高的獨(dú)立應(yīng)用系統(tǒng)的任務(wù)進(jìn)行統(tǒng)一管理、執(zhí)行調(diào)度及監(jiān)控，提升整體的執(zhí)行效率并簡(jiǎn)化運(yùn)維。 

        統(tǒng)一開(kāi)發(fā)平臺(tái)搭建于統(tǒng)一調(diào)度的基礎(chǔ)之上，開(kāi)發(fā)者可以通過(guò)IDE 使用封裝后的函數(shù)，以SQL 腳本進(jìn)行圖形化的數(shù)據(jù)處理程序設(shè)計(jì)及開(kāi)發(fā)。通過(guò)多租戶(hù)的方式，對(duì)開(kāi)發(fā)者分配獨(dú)立的大數(shù)據(jù)平臺(tái)及數(shù)據(jù)倉(cāng)庫(kù)的存儲(chǔ)、計(jì)算資源，確保開(kāi)發(fā)者在共享數(shù)據(jù)、系統(tǒng)能力的同時(shí)，不影響生產(chǎn)系統(tǒng)的正常運(yùn)行。 

        數(shù)據(jù)共享平臺(tái)提供標(biāo)準(zhǔn)API 封裝，提供給外部系統(tǒng)進(jìn)行數(shù)據(jù)查詢(xún)和調(diào)用，實(shí)現(xiàn)經(jīng)分系統(tǒng)對(duì)外數(shù)據(jù)服務(wù)標(biāo)準(zhǔn)化，同時(shí)保障數(shù)據(jù)安全性并降低外部系統(tǒng)數(shù)據(jù)存儲(chǔ)壓力。 

        3.2.1 統(tǒng)一調(diào)度 

        統(tǒng)一調(diào)度由控制中心和AGENT 兩部分組成，如下圖所示: 

        (1)控制中心: 控制中心接收來(lái)自?xún)?nèi)部的消息，通過(guò)規(guī)則引擎判斷任務(wù)是否滿(mǎn)足觸發(fā)條件并分發(fā)給Agent 進(jìn)行處理，并對(duì)任務(wù)執(zhí)行情況進(jìn)行監(jiān)控及消息生成。消息接收:支持各種事件觸發(fā)消息，如文件到達(dá)、接口裝載、表生成; 規(guī)則引擎:根據(jù)人工定義、系統(tǒng)資源情況、租戶(hù)定義等設(shè)置制定任務(wù)的執(zhí)行條件及前后依賴(lài)關(guān)系;任務(wù)觸發(fā):根據(jù)消息總線傳遞的消息，判斷任務(wù)是否具備執(zhí)行條件，并將滿(mǎn)足觸發(fā)條件的任務(wù)分發(fā)至各平臺(tái)Agent 端執(zhí)行;