浙江移動基于Hadoop的詳單系統(tǒng)建設(shè)方案v1.97

浙江移動基于Hadoop的帳詳單查詢系統(tǒng)解決方案亞信聯(lián)創(chuàng)市場咨詢部2023年5月議題現(xiàn)存問題分析工程建設(shè)目標(biāo)工程方案介紹性能測試報(bào)告遷移方案簡介案例介紹浙江移動詳單查詢現(xiàn)存問題分析單次查詢話單量超過10000條時，由于加載數(shù)據(jù)量過大，查詢效勞無法返回，造成查詢失敗；詳單文件共享內(nèi)存13G導(dǎo)入中間文件詳單查詢加載落地讀取讀取1390571XXXX實(shí)時詳單查詢應(yīng)用通過訪問共享內(nèi)存和詳單文件系統(tǒng)，把二者數(shù)據(jù)組合生成查詢結(jié)果；詳單導(dǎo)入應(yīng)用處理中間文件后，先加載到共享內(nèi)存中，當(dāng)內(nèi)存數(shù)據(jù)到達(dá)5000萬條閥值時，集中將內(nèi)存數(shù)據(jù)寫入詳單文件中；問題一：大數(shù)據(jù)量詳單查詢成功率保障缺乏導(dǎo)入應(yīng)用和詳單查詢應(yīng)用通過共享內(nèi)存方式實(shí)現(xiàn)通信，當(dāng)導(dǎo)入應(yīng)用發(fā)生故障時，會造成詳單查詢應(yīng)用無法獲取內(nèi)存信號量，導(dǎo)致查詢效勞堵塞與積壓；問題二：應(yīng)用緊耦合查詢主機(jī)二(HPSD)查詢主機(jī)一(HPSD)實(shí)時詳單查詢實(shí)時詳單查詢實(shí)時詳單導(dǎo)入服務(wù)實(shí)時詳單導(dǎo)入服務(wù)實(shí)時詳單預(yù)處理實(shí)時詳單預(yù)處理歷史詳單查詢歷史詳單查詢歷史詳單導(dǎo)入歷史詳單預(yù)處理20.…..…..…..….10315實(shí)時詳單查詢服務(wù)實(shí)時詳單查詢服務(wù)歷史詳單查詢歷史詳單查詢歷史詳單導(dǎo)入歷史詳單預(yù)處理20.….…..….10部署現(xiàn)狀：

詳單查詢查詢主機(jī)采用兩臺HPSD，提供11+1月詳單數(shù)據(jù)主機(jī)一：實(shí)時詳單導(dǎo)入17個號段

歷史詳單導(dǎo)入11個號段主機(jī)二：實(shí)時詳單導(dǎo)入11個號段

歷史詳單導(dǎo)入17個號段主機(jī)負(fù)載情況：CPU忙時占用率50%，CPU閑時占用率22%，內(nèi)存占用率為55%；歷史詳單預(yù)處理每月24、28、30、1號從計(jì)費(fèi)數(shù)據(jù)庫讀取詳單文件生成cdr文件；歷史詳單導(dǎo)入每月1號11點(diǎn)按號段生成中間文件，2號凌晨處理完成，3號提供客戶查詢。詳單查詢、預(yù)處理，導(dǎo)入應(yīng)用部署在同一臺主機(jī)上，應(yīng)用之間相互影響較大。浙江移動詳單查詢現(xiàn)存問題分析〔續(xù)〕問題三：系統(tǒng)部署過于集中，主機(jī)資源競爭嚴(yán)重詳單處理應(yīng)用按業(yè)務(wù)和號段劃分，各進(jìn)程之間獨(dú)立運(yùn)行，無高可用保障措施。查詢效勞量過大時，缺乏過載保護(hù)機(jī)制。問題四：系統(tǒng)高可用保障能力缺乏實(shí)時詳單存儲歷史詳單存儲實(shí)時詳單文件

總存儲：10.2TB使用率：75%歷史詳單中間文件總存儲：4.1TB使用率：78%歷史詳單查詢文件總存儲：11.7TB使用率：34%實(shí)時詳單采用一個文件系統(tǒng)存儲數(shù)據(jù)，包括計(jì)費(fèi)原始詳單文件、中間過程詳單文件、以及最終查詢詳單文件；目前實(shí)時詳單文件系統(tǒng)已到達(dá)10.2T，使用率已經(jīng)到達(dá)75%；為了節(jié)省文件系統(tǒng)空間，保證最終查詢文件的存儲空間，計(jì)費(fèi)原始詳單與中間過程文件只保存3天數(shù)據(jù)，目前占用〔1.1+0.33=1.43〕T；最終查詢文件占用6.07T；目前單個文件系統(tǒng)的容量已經(jīng)過大，且隨著業(yè)務(wù)量的擴(kuò)展，詳單對存儲空間要求越來越大，存儲需要進(jìn)行重新規(guī)劃和調(diào)整。

歷史詳單采用兩個文件系統(tǒng)存儲數(shù)據(jù)，分別存儲歷史詳單的中間詳單文件和最終查詢文件;

目前歷史最終查詢詳單保存11個月，采用壓縮格式存儲，文件系統(tǒng)共11.7T，使用率34%；中間詳單文件系統(tǒng)4.1T，只保存一個月的中間處理文件，目前使用率78%；歷史詳單的處理每月導(dǎo)入一次，處理相對集成，文件碎片較小。浙江移動詳單查詢現(xiàn)存問題分析〔續(xù)〕問題五：文件系統(tǒng)劃分過于龐大，嚴(yán)重影響整體系統(tǒng)的穩(wěn)定性和讀寫效率按照效勞等級的區(qū)分，將詳單文件系統(tǒng)劃分實(shí)時詳單和歷史詳單；議題現(xiàn)存問題分析工程建設(shè)目標(biāo)工程方案介紹性能測試報(bào)告遷移方案簡介案例介紹工程建設(shè)目標(biāo)引入分布式數(shù)據(jù)庫，基于X86設(shè)備實(shí)現(xiàn)詳單處理的分布式架構(gòu)，提高系統(tǒng)的擴(kuò)展能力，降低系統(tǒng)整體建設(shè)本錢。采用分布式數(shù)據(jù)存儲技術(shù)，提高數(shù)據(jù)高可用，保障系統(tǒng)穩(wěn)定。引入分布式緩存機(jī)制，提高大數(shù)據(jù)量查詢效率。加強(qiáng)詳單稽核，提升故障快速定位能力。完成集團(tuán)公司〞基于云計(jì)算的詳單處理“建設(shè)試點(diǎn)工作，驗(yàn)證利用分布式技術(shù)對詳單進(jìn)行存儲、處理與查詢的技術(shù)方案，要求11月份完成試點(diǎn)工作。系統(tǒng)建設(shè)目標(biāo)滿足到2023年底支撐月詳單480億條，支持6+1月詳單存儲和查詢；詳單文件落地至處理完成時長不超過5分鐘，支持200以上的并發(fā)查詢，前臺查詢響應(yīng)時間小于10秒。議題現(xiàn)存問題分析工程建設(shè)目標(biāo)工程方案介紹性能測試報(bào)告遷移方案簡介案例介紹現(xiàn)有系統(tǒng)架構(gòu)統(tǒng)一門戶前臺功能接口服務(wù)器APP層EJB調(diào)用詳單查詢SOCKET服務(wù)歷史話單導(dǎo)出CDR文件實(shí)時話單導(dǎo)出R文件R文件導(dǎo)入QRY文件實(shí)時話單文件、歷史話單表FTP發(fā)送計(jì)費(fèi)系統(tǒng)綜合查詢詳單后臺CRM系統(tǒng)CDR文件導(dǎo)入QRY文件新系統(tǒng)總體架構(gòu)統(tǒng)一門戶前臺功能接口服務(wù)器詳單查詢HTTP協(xié)議（新）實(shí)時話單文件、歷史話單表FTP獲取計(jì)費(fèi)系統(tǒng)綜合查詢詳單后臺CRM系統(tǒng)話單預(yù)處理模塊OCNosql話單存儲詳單查詢效勞OCNosql詳單存儲計(jì)費(fèi)清單話單導(dǎo)入預(yù)處理備份與清理話單入庫緩存檢查話單查詢CRM查重匯總轉(zhuǎn)義分頁緩存查詢流程：加載流程：新系統(tǒng)總體流程詳單預(yù)處理詳單查詢效勞頁面組裝新系統(tǒng)數(shù)據(jù)模型原始話單存儲模型展示模型TRADEMARKDR_TYPESERVICE_IDUSER_NUMBERSTART_TIMEVC_NUMBERUSER_TYPETRADE_TYPEOPP_NUMBERTRADE_STATECARD_IDVC_TYPEHPLMN1HPLMN2VPLMN1VPLMN2CARD_HPLMN1CARD_HPLMN2CARD_CHARGESCP_IDVC_LOCATION用戶號碼業(yè)務(wù)類型字段1字段2字段3字段4字段5字段6字段7字段8字段9字段10字段11字段12字段13…字段32預(yù)留字段1預(yù)留字段2…預(yù)留字段18帳戶號開始時間時長批價(jià)時間呼叫類型漫游類型長途類型本地通話費(fèi)信息費(fèi)免費(fèi)資源1使用量免費(fèi)資源2使用量免費(fèi)資源1名稱免費(fèi)資源2名稱一級漫游地二級漫游地對端一級漫游地對端二級漫游地對端號碼服務(wù)商服務(wù)商產(chǎn)品預(yù)處理詳單查詢存儲需32個字段，現(xiàn)預(yù)留18個字段用于后續(xù)業(yè)務(wù)擴(kuò)展需要新系統(tǒng)介紹——模塊介紹新的詳單查詢系統(tǒng)，由如下三個模塊構(gòu)成：詳單預(yù)處理OCNoSql詳單存儲詳單查詢效勞數(shù)據(jù)預(yù)處理——功能架構(gòu)計(jì)費(fèi)話單數(shù)據(jù)并行計(jì)算數(shù)據(jù)操作HDFS文件系統(tǒng)調(diào)度引擎詳單預(yù)處理系統(tǒng)管理系統(tǒng)OCNOSQL存儲任務(wù)定義調(diào)度記錄流程任務(wù)數(shù)據(jù)入庫數(shù)據(jù)預(yù)處理——流程定義話單類型判斷結(jié)構(gòu)體映射話單過濾FTP話單傳輸多副本保存話單按號碼排序生成數(shù)據(jù)文件數(shù)據(jù)文件入庫將原始話單轉(zhuǎn)移目錄存儲刪除中間步驟生成的文件定義中間數(shù)據(jù)輸出目錄數(shù)據(jù)預(yù)處理——字段映射名稱列：統(tǒng)一結(jié)構(gòu)體字段名值：原始話單字段名或類似java語法的表達(dá)式，例如：if(VIDEO_TYPE==1)

{'VGSM';}elseif(OPP_NUMBER.substring(0,8)=='12590123’){'GSM_L';}elseif(OPP_NUMBER_TYPE.equals('77’))

{'YYZX';}elseif((OPP_NUMBER_TYPE>=1100&&OPP_NUMBER_TYPE<=2000)

||OPP_NUMBER_TYPE=='146')

{'YXHD';}elseif(OPP_NUMBER_TYPE.equals('63'))

{'GWBH';}elseif(OPP_NUMBER_TYPE>=10000&&OPP_NUMBER_TYPE<=28000)

{'SX';}elseif(((ROAM_TYPE==0)||(ROAM_TYPE==8))&&((CALL_TYPE==1)||(CALL_TYPE==0))&&(OPP_NUMBER_TYPE.equals('128')))

{'SX';}elseif((TOLL_TYPE==0)&&(ROAM_TYPE==0))

{'GSM_L';}elseif((CALL_TYPE==2)||(CALL_TYPE==3)){'GSM_HZ';}elseif(ROAM_TYPE==0){'GSM_T';}else{'GSM_R';}可以設(shè)定話單的過濾規(guī)那么，過濾掉不需要查詢的話單或者錯單詳單查詢效勞——功能架構(gòu)CRM接口機(jī)OCNosql存儲CRM-EJB效勞下沉業(yè)務(wù)邏輯與數(shù)據(jù)存儲完全解耦。引入緩存技術(shù)，優(yōu)化系統(tǒng)響應(yīng)速度。引入內(nèi)存數(shù)據(jù)庫，縮短字段轉(zhuǎn)義時間。支持多個數(shù)據(jù)源查詢詳單查詢接口效勞HTTP通訊接口封裝詳單查詢接口詳單模型詳單查詢處理邏輯字段轉(zhuǎn)義話單分頁話單匯總話單合并話單查重緩存REDIS內(nèi)存數(shù)據(jù)庫局?jǐn)?shù)據(jù)倒入工具詳單查詢數(shù)據(jù)接口OCNOSQL數(shù)據(jù)接口詳單查詢效勞——內(nèi)存數(shù)據(jù)庫的使用在詳單查詢效勞中引入內(nèi)存數(shù)據(jù)庫的作用：1、增加詳單結(jié)果分頁的功能查詢詳單時，以一個月詳單為例，一般查詢結(jié)果在300－1000條左右，返回全部數(shù)據(jù)對網(wǎng)絡(luò)IO開銷很大，尤其時并發(fā)數(shù)很大的時候使用內(nèi)存數(shù)據(jù)庫存儲詳單的全量數(shù)據(jù)，每次只返回20－100條詳單數(shù)據(jù)，可以大大提高詳單查詢的并發(fā)處理能力，同時還可以降低數(shù)據(jù)的重復(fù)查詢的壓力2、增加詳單結(jié)果中字段快速轉(zhuǎn)義的功能詳單中包含了大量的數(shù)字符號，例如：SP_CODE,SERVICE_CODE等等通常的處理方法是查詢數(shù)據(jù)庫轉(zhuǎn)義成為例如“中國移動〞“在線書城〞等結(jié)果在詳單查詢頂峰期對數(shù)據(jù)庫壓力很大，也影響詳單查詢的整體性能通過將局?jǐn)?shù)據(jù)等信息提前存入內(nèi)存數(shù)據(jù)庫，實(shí)現(xiàn)快速高并發(fā)查詢在上海移動的生產(chǎn)環(huán)境中，實(shí)際存入轉(zhuǎn)義數(shù)據(jù)300M左右，平均每次訪問減少數(shù)據(jù)庫查詢次數(shù)30－100次3、內(nèi)存數(shù)據(jù)庫的部署可以根據(jù)實(shí)際情況在轉(zhuǎn)義數(shù)據(jù)量不是很大的時候選擇多臺部署，防止單點(diǎn)故障。OCNoSql數(shù)據(jù)庫——功能架構(gòu)分布式數(shù)據(jù)庫數(shù)據(jù)加載工具數(shù)據(jù)索引存儲索引自動優(yōu)化分布式緩存高效能壓縮負(fù)載均衡管理數(shù)據(jù)加載規(guī)那么管理數(shù)據(jù)加載任務(wù)管理數(shù)據(jù)加載監(jiān)控管理二次開發(fā)接口對外接口JDBC、ODBC、WebService、RESTful…數(shù)據(jù)庫管理數(shù)據(jù)庫配置管理工具數(shù)據(jù)庫監(jiān)控管理工具數(shù)據(jù)庫備份恢復(fù)工具數(shù)據(jù)庫任務(wù)管理工具分布式文件系統(tǒng)DFSDFSDFS連接池管理權(quán)限管理線程管理OCNoSql數(shù)據(jù)庫——話單存儲OCNosql數(shù)據(jù)庫類似于行列混合模式，針對詳單查詢業(yè)務(wù)場景，它把行、列存儲的優(yōu)勢都發(fā)揮了出來，通過RowKey可迅速定位到行記錄，同時其對應(yīng)的列可隨時進(jìn)行擴(kuò)展,通過該方式，壓縮率可保證在10:1以上，同時大大降低了系統(tǒng)I/O。采用該方式提供詳單查詢效勞：入庫時無需先排序，詳單文件通過MapReduce并行計(jì)算框架可以高效的直接加載到分布式數(shù)據(jù)庫中；詳單數(shù)據(jù)入庫采用天建表策略，通過時間和號碼兩個維度迅速定位到數(shù)據(jù)文件。入庫時，針對詳單文件的特點(diǎn)，提供數(shù)據(jù)級別的壓縮功能，對于詳單中重復(fù)字段較多的場景，實(shí)現(xiàn)高壓縮比新詳單查詢系統(tǒng)——功能列表新詳單查詢系統(tǒng)完全繼承原有CRM側(cè)詳單查詢接口：實(shí)時詳單查詢歷史詳單查詢大數(shù)據(jù)詳單查詢新詳單查詢系統(tǒng)同時支持集團(tuán)類詳單的批量導(dǎo)出文件功能，包括：PBX詳單企業(yè)信息機(jī)詳單集團(tuán)400業(yè)務(wù)詳單新詳單查詢系統(tǒng)同時支持計(jì)費(fèi)側(cè)重批話單的導(dǎo)入和查詢對于重批話單，對其的導(dǎo)入完全等同于普通話單通過在查詢效勞模塊中的查重功能，實(shí)現(xiàn)對舊話單的過濾。新詳單查詢系統(tǒng)——維護(hù)功能入庫任務(wù)編排調(diào)度管理模塊：入庫任務(wù)調(diào)度頻度、啟動參數(shù)配置；任務(wù)流程可視化編排；任務(wù)流程調(diào)度引擎；任務(wù)流程監(jiān)控管理。錯單處理模塊：支持重批話單的導(dǎo)入。數(shù)據(jù)生命周期管理模塊：數(shù)據(jù)生命周期檢查規(guī)那么配置；數(shù)據(jù)生命周期檢查頻度配置；歷史數(shù)據(jù)刪除。維護(hù)類工具模塊：分布式文件系統(tǒng)備份分布細(xì)那么監(jiān)控；集群運(yùn)行情況監(jiān)控；人工刪除、補(bǔ)錄；維護(hù)類查詢。大數(shù)據(jù)量詳單內(nèi)存數(shù)據(jù)庫架構(gòu)優(yōu)化一：引入緩存處理，提高大數(shù)據(jù)量查詢效率目前狀況：分布式改造后：CRM…查詢代理查詢請求Hadoop分布式詳單數(shù)據(jù)庫查詢結(jié)果匯總查詢直接返回查詢分頁返回…分布式緩存自動索引分布式存儲詳單查詢接口效勞緩存技術(shù)分頁緩存單次查詢3000條以上記錄，經(jīng)常出現(xiàn)查詢失敗，查詢返回時間長。單次大數(shù)據(jù)量查詢，影響同時請求的小數(shù)據(jù)量查詢?；谖募到y(tǒng)的查詢，磁盤IO成為系統(tǒng)瓶頸，缺少緩存技術(shù)配合。文件生成分布式技術(shù)改造后：底層采用分布式數(shù)據(jù)庫技術(shù)，引入分布式緩存，通過緩存命中率，提高查詢效率。大數(shù)據(jù)查詢時，采用分頁返回策略，未返回的分頁數(shù)據(jù)在內(nèi)存數(shù)據(jù)庫中緩存。CRM需要做分頁顯示的改造，顯示下一頁需要通過從接口詳單查詢系統(tǒng)分頁緩存中取結(jié)果架構(gòu)優(yōu)化二：解耦應(yīng)用，防止故障影響擴(kuò)大目前狀況：分布式改造后：實(shí)時詳單查詢請求查詢內(nèi)存詳單詳單導(dǎo)入共享內(nèi)存查詢文件詳單詳單文件IPC詳單查詢流程從內(nèi)存和文件中獲取數(shù)據(jù)，組合生成詳單查詢數(shù)據(jù)為了獲取導(dǎo)入進(jìn)程內(nèi)存中的詳單數(shù)據(jù)，詳單查詢效勞通過共享內(nèi)存方式獲取內(nèi)存數(shù)據(jù)；當(dāng)導(dǎo)入應(yīng)用出現(xiàn)故障時，共享內(nèi)存信號無返回，造成查詢失敗中間文件加載導(dǎo)入分布式數(shù)據(jù)庫詳單查詢采用分布式數(shù)據(jù)庫后，無需再使用共享內(nèi)存的方式進(jìn)行詳單查詢，導(dǎo)入效勞和詳單查詢徹底別離開。因此無論導(dǎo)入效勞是否出現(xiàn)故障，查詢流程將直接讀取分布式數(shù)據(jù)庫中的詳單數(shù)據(jù)，再不會出現(xiàn)查詢失敗問題。架構(gòu)優(yōu)化三：分布式架構(gòu)讓系統(tǒng)無需集中部署目前狀況：詳單查詢、預(yù)處理，導(dǎo)入應(yīng)用部署在同一臺主機(jī)上，應(yīng)用之間相互影響較大分布式改造后：詳單查詢系統(tǒng)通過采用分布式數(shù)據(jù)庫后進(jìn)行分布式部署，通過該部署方式，讓應(yīng)用之間實(shí)現(xiàn)性能隔離，不會互相影響。Server1NoSQLMasterServer2NoSQLRegionServerServer3NoSQLRegionServerServerNNoSQLRegionServer…分布式數(shù)據(jù)庫集群：架構(gòu)優(yōu)化四：增強(qiáng)系統(tǒng)高可用保障能力及高可擴(kuò)展性詳單處理應(yīng)用按業(yè)務(wù)和號段劃分，各進(jìn)程之間獨(dú)立運(yùn)行，無高可用保障措施。查詢效勞量過大時，缺乏過載保護(hù)機(jī)制。目前狀況：分布式改造后：詳單查詢采用分布式數(shù)據(jù)庫：通過2份以上的副本與自動同步機(jī)制來保證數(shù)據(jù)的高可用性，實(shí)現(xiàn)自動容災(zāi)；其分布式架構(gòu)可滿足更高的吞吐量需求；自動索引及分布式緩存機(jī)制保障了詳單查詢效勞的高性能；在查詢效勞性能遇到瓶頸時，可通過橫向擴(kuò)展迅速提高效勞質(zhì)量。網(wǎng)廳、自助終端、……詳單查詢效勞流量控制CRM查詢效勞詳單查詢隊(duì)列流量控制模塊作為詳單查詢效勞的管理模塊，用于控制效勞調(diào)用；對于超出隊(duì)列閥值的調(diào)用，返回失敗消息。HTTPsocket內(nèi)部調(diào)用架構(gòu)優(yōu)化五：效勞流量控制數(shù)據(jù)節(jié)點(diǎn)1數(shù)據(jù)節(jié)點(diǎn)2…數(shù)據(jù)節(jié)點(diǎn)n主控節(jié)點(diǎn)Hadoop集群為了防止通過頻繁調(diào)用進(jìn)行的惡意攻擊，對于不同渠道、不同系統(tǒng)的接口進(jìn)行流量分配，對各渠道的單位時間調(diào)用次數(shù)和調(diào)用頻率進(jìn)行限制，超過調(diào)用閥值進(jìn)行告警，超過上限那么采取過載保護(hù)，進(jìn)行錯誤返回。架構(gòu)優(yōu)化六：加強(qiáng)詳單處理數(shù)據(jù)稽核話單導(dǎo)入話單預(yù)處理Hadoop用戶計(jì)費(fèi)系統(tǒng)查詢效勞歷史詳單實(shí)時詳單詳單查詢系統(tǒng)日志記錄在話單處理各個環(huán)節(jié)會對每個處理的話單記錄相應(yīng)的日志記錄，包括文件名、大小、開始結(jié)束時間、成功數(shù)、失敗數(shù)、耗時?；藞?bào)警當(dāng)出現(xiàn)文件名錯誤，文件大小錯誤，記錄總數(shù)錯誤，文件加載失敗，查詢失敗等，會向管理平臺告警?；它c(diǎn)架構(gòu)優(yōu)化七〔一〕：解決文件存儲問題目前狀況：文件系統(tǒng)劃分過于龐大，嚴(yán)重影響整體系統(tǒng)的穩(wěn)定性和讀寫效率分布式改造后：TBTBTBTBTBTBTBTBPB。。。。。。系統(tǒng)可直接在多臺x86化PCServer與刀片機(jī)的本地存儲及原有磁盤陣列上共同部署一套分布式文件系統(tǒng)來存放數(shù)據(jù)文件，支持PB級別存儲容量，因此不會再出現(xiàn)文件系統(tǒng)劃分過于龐大的問題高效的壓縮機(jī)制節(jié)省了更多的存儲空間，對于詳單這類列重復(fù)度較高的數(shù)據(jù)具有極高的壓縮比，壓縮狀態(tài)不影響數(shù)據(jù)讀寫性能，在啟動高級壓縮后，可以到1:10左右的綜合壓縮比數(shù)據(jù)庫容量與性能支持在線的彈性擴(kuò)展，為系統(tǒng)后期擴(kuò)容工作奠定了堅(jiān)實(shí)的根底架構(gòu)優(yōu)化七〔二〕：分布式存儲提高文件系統(tǒng)高可用性F1F5F3F0F5F1F2F0F1F2Master詳單查詢效勞…分布式存儲特性：數(shù)據(jù)多副本，建議1：2數(shù)據(jù)流與控制流別離寫文件采用追加寫刪除文件采用置失效方式，誤刪除可恢復(fù)機(jī)器宕機(jī)，或者永久損壞，Master節(jié)點(diǎn)可自動恢復(fù)在新節(jié)點(diǎn)。采用數(shù)據(jù)節(jié)點(diǎn)內(nèi)置硬盤或低端存儲存儲數(shù)據(jù)，高可用性通過Hadoop軟架構(gòu)實(shí)現(xiàn)，不依賴硬件性能。不需要做RAID，可使用裸盤。存儲擴(kuò)展可通過增加節(jié)點(diǎn)，由Hadoop自動分配完成。存儲的優(yōu)化依靠Hadoop的自動優(yōu)化管理，通過compact與split等動作完成，減少人工管理的時間。CRM議題現(xiàn)存問題分析工程建設(shè)目標(biāo)工程方案介紹性能測試報(bào)告遷移方案簡介案例介紹數(shù)據(jù)加載和查詢性能測試報(bào)告——硬件環(huán)境主機(jī)IP用戶名用途cpu/內(nèi)存/存儲pc-jfjwapp016etlcloud/etlcloudnamenodeschedual4cpu8core2.6GHz/32GB/2*300GB（raid1，僅有一塊可用硬盤）pc-jfjwapp027etlcloud/etlcloudDataNode4cpu8core2.6GHz/32GB/2*300GB（raid1，僅有一塊可用硬盤）pc-jfjwapp038etlcloud/etlcloudDataNode4cpu8core2.6GHz/32GB/2*300GB（raid1，僅有一塊可用硬盤）pc-jfjwapp049etlcloud/etlcloudDataNode4cpu8core2.6GHz/32GB/2*300GB（raid1，僅有一塊可用硬盤）pc-jfjwapp098etlcloud/etlcloudDataNode4cpu8core2.6GHz/32GB/2*300GB（raid1，僅有一塊可用硬盤）pc-jfjwapp109etlcloud/etlcloudDataNode4cpu8core2.6GHz/32GB/2*300GB（raid1，僅有一塊可用硬盤）pc-jfjwapp110etlcloud/etlcloudDataNode4cpu8core2.6GHz/32GB/2*300GB（raid1，僅有一塊可用硬盤）pc-jfjwapp121etlcloud/etlcloudDataNode4cpu8core2.6GHz/32GB/2*300GB（raid1，僅有一塊可用硬盤）

1expftp/expftp計(jì)費(fèi)話單主機(jī)

數(shù)據(jù)加載和查詢性能測試報(bào)告——測試目標(biāo)測試目標(biāo)本項(xiàng)測試的測試目標(biāo)為檢驗(yàn)話單從計(jì)費(fèi)主機(jī)經(jīng)過ftp，數(shù)據(jù)過濾，加載到OCNOSQL，清理全流程各個節(jié)點(diǎn)速度及系統(tǒng)資源占用情況。測試方法計(jì)費(fèi)話單從計(jì)費(fèi)主機(jī)經(jīng)過ftp，數(shù)據(jù)過濾，加載到OCNOSQL，記錄各個節(jié)點(diǎn)時間，資源占用率測試目標(biāo)本項(xiàng)測試的目標(biāo)為檢驗(yàn)OCNoSql的查詢性能。分別對按日分表的系統(tǒng)空閑時及系統(tǒng)忙時進(jìn)行查詢性能測試，并記錄查詢過程中主機(jī)的CPU，IO，MEM等各項(xiàng)資源占用情況。測試方法本次測試借助于Tomcat作為應(yīng)用服務(wù)器，在其上部署了調(diào)用分布式數(shù)據(jù)庫的查詢API的WebService；通過JMeter模擬多客戶端進(jìn)行不間斷查詢，并統(tǒng)計(jì)性能數(shù)據(jù)數(shù)據(jù)加載測試：數(shù)據(jù)查詢測試：數(shù)據(jù)加載性能數(shù)據(jù)量本次測試根據(jù)實(shí)際數(shù)據(jù)內(nèi)容和格式，模擬生成了GPRS詳單1天的數(shù)據(jù)，每天的詳單數(shù)據(jù)約為300G；存儲結(jié)構(gòu)為按日分表。數(shù)據(jù)加載和查詢性能測試報(bào)告——數(shù)據(jù)加載性能文件個數(shù)總文件大?。╧）總持續(xù)時間（秒）ftp耗時（秒）數(shù)據(jù)過濾耗時（秒）加載入庫耗時（秒）mapreduce啟動時間（秒）清理ftp過程吞吐量（M/S）數(shù)據(jù)過濾吞吐量（M/S）數(shù)據(jù)加載吞吐量（M/S）cpu利用率mem利用率DiskQueueLength100010301716704110288137907991.4634.9329.3736%30%1001008142562692548391273031.8116.578.1616%18%20數(shù)據(jù)加載和查詢性能測試報(bào)告——日表存儲查詢測試〔無數(shù)據(jù)加載〕抽樣數(shù)據(jù)并發(fā)數(shù)量循環(huán)次數(shù)平均處理時間(毫秒)最小處理時間（毫秒）最大數(shù)據(jù)響應(yīng)時間(毫秒)TPS(事務(wù)數(shù)/秒)TPS增長率Cpu利用率mem利用率DiskQueueLength1000005200001866510268-5%25%11000001020000196709448882%6%27%11000002020000236760382468%9%27%2100000502000028730061749112%16%20%1210000010020000334304118505%23%15%1610000020020000354912119063%25%20%30100000500200004971022119190.06%30%15%50數(shù)據(jù)加載和查詢性能測試報(bào)告——日表存儲加載與查詢并行測試抽樣數(shù)據(jù)并發(fā)數(shù)量循環(huán)次數(shù)平均處理時間(毫秒)最小處理時間（毫秒）最大數(shù)據(jù)響應(yīng)時間(毫秒)TPS(事務(wù)數(shù)/秒)Cpu利用率mem利用率DiskQueueLength100000100200004543177165230%25%120100000200100009357032189840%27%150100000100200003343041185023%15%30100000200200003549121190625%20%50紅色局部為日表閑時查詢測試用例測試結(jié)果數(shù)據(jù)數(shù)據(jù)加載和查詢性能測試報(bào)告——測試結(jié)論準(zhǔn)確性：話單數(shù)據(jù)通過預(yù)處理加載到OCNOSQL后，數(shù)據(jù)與原始話單一致。高可用性：集群中任意一臺數(shù)據(jù)節(jié)點(diǎn)宕掉后，OCNOSQL存儲的數(shù)據(jù)完整無喪失。擴(kuò)展性：通過5，6，7節(jié)點(diǎn)測試，整個詳單系統(tǒng)處理數(shù)據(jù)速度能隨著節(jié)點(diǎn)增加而增加。從5節(jié)點(diǎn)增加到6節(jié)點(diǎn)一塊磁盤，現(xiàn)規(guī)劃生產(chǎn)每臺主機(jī)有4塊磁盤，TPS隨查詢并發(fā)數(shù)提高還會有較大提高〕，數(shù)據(jù)過濾處理速度提高了18%，數(shù)據(jù)加載速度提高了26%。從6節(jié)點(diǎn)增加到7節(jié)點(diǎn)，數(shù)據(jù)過濾處理速度提高了13%，數(shù)據(jù)加載速度提高了25%。預(yù)處理加載性能：正常與積壓話單情況下處理速度滿足預(yù)處理加載性能指標(biāo)要求。正常業(yè)務(wù)量情況下4分29秒完成預(yù)處理加載，滿足5分鐘落地要求。話單積壓狀態(tài)下，一天話單在187分鐘處理完成。與現(xiàn)生產(chǎn)環(huán)境的處理效率比對，月歷史詳單導(dǎo)入速度可以提高40%。OCNOSQL查詢性能：5-500并發(fā)，平均響應(yīng)時間均小于100毫秒，并且隨著并發(fā)數(shù)提高，TPS也隨之提高?！矞y試環(huán)境每臺主機(jī)只有200并發(fā)閑時平均響應(yīng)時間35毫秒，忙時平均響應(yīng)時間93毫秒。壓縮比：正常業(yè)務(wù)量情況下，數(shù)據(jù)壓縮比為1:7，每天重處理前一天話單，壓縮比可到達(dá)1:10。議題現(xiàn)存問題分析工程建設(shè)目標(biāo)工程方案介紹性能測試報(bào)告遷移方案簡介案例介紹現(xiàn)有詳單查詢系統(tǒng)部署現(xiàn)狀分析查詢主機(jī)二(HPSD)查詢主機(jī)一(HPSD)實(shí)時詳單查詢實(shí)時詳單查詢實(shí)時詳單導(dǎo)入服務(wù)實(shí)時詳單導(dǎo)入服務(wù)實(shí)時詳單預(yù)處理實(shí)時詳單預(yù)處理歷史詳單查詢歷史詳單查詢歷史詳單導(dǎo)入歷史詳單預(yù)處理20.…..…..…..….10315實(shí)時詳單查詢服務(wù)實(shí)時詳單查詢服務(wù)歷史詳單查詢歷史詳單查詢歷史詳單導(dǎo)入歷史詳單預(yù)處理20.…..…..….10部署現(xiàn)狀：詳單查詢查詢主機(jī)采用兩臺HPSD，提供5+1月詳單數(shù)據(jù)操作系統(tǒng)：HP-UX操作系統(tǒng)發(fā)行版〔release〕的名稱：機(jī)型：ia64hpsuperdomeserverSD32B主機(jī)負(fù)載情況：CPU忙時占用率50%，CPU閑事占用率22%，內(nèi)存占用率為55%問題：數(shù)據(jù)量詳單查詢成功率保障缺乏應(yīng)用緊耦合系統(tǒng)部署過于集中，主機(jī)資源競爭嚴(yán)重系統(tǒng)高可用保障能力缺乏……基于Hadoop改造后的詳單查詢改變原有架構(gòu)，在進(jìn)行遷移時，采用的是兩對多的遷移方式硬件設(shè)備：以應(yīng)用性能指標(biāo)為標(biāo)準(zhǔn)，選取同等甚至超出原有系統(tǒng)處理能力的x86效勞器集群替代原小型機(jī)設(shè)備，并利用原小機(jī)設(shè)備作為詳單查詢效勞前臺支撐應(yīng)用軟件：選取基于Hadoop開發(fā)的可擴(kuò)展性高的x86集群應(yīng)用替代原有的Unix應(yīng)用兩對多的遷移基于Hadoop改變現(xiàn)有架構(gòu)，由X86效勞器集群替代詳單查詢后臺詳單查詢接口效勞新增兩臺刀片機(jī)作為詳單查詢接口效勞的效勞器基于X86架構(gòu)的詳單查詢整體部署方案集群共有4類節(jié)點(diǎn)：前臺應(yīng)用節(jié)點(diǎn)，主控節(jié)點(diǎn)，數(shù)據(jù)存儲節(jié)點(diǎn)及數(shù)據(jù)庫節(jié)點(diǎn)。前臺詳單查詢應(yīng)用節(jié)支撐詳單查詢效勞的前臺，主控節(jié)點(diǎn)需要使用兩臺效勞器互為熱備，進(jìn)行元數(shù)據(jù)管理并提供Hmaster效勞，同時還需要部署分布式數(shù)據(jù)庫配置管理效勞；數(shù)據(jù)庫節(jié)點(diǎn)負(fù)責(zé)索引管理及查詢訪問管理，由它來保證數(shù)據(jù)庫對高并發(fā)訪問的支持，并且可以保障查詢結(jié)果的快速響應(yīng)；數(shù)據(jù)存儲節(jié)點(diǎn)負(fù)責(zé)詳單數(shù)據(jù)的加載和存儲功能，由它來決定原始詳單數(shù)據(jù)入庫的效率，并且在存儲方面建議采用3份冗余策略來提高數(shù)據(jù)的可靠性及效勞的可用性。子節(jié)點(diǎn)1子節(jié)點(diǎn)2子節(jié)點(diǎn)3子節(jié)點(diǎn)4……NameNode主節(jié)點(diǎn)數(shù)據(jù)源數(shù)據(jù)源子節(jié)點(diǎn)N子節(jié)點(diǎn)NNameNode備節(jié)點(diǎn)詳單查詢效勞預(yù)處理Redis內(nèi)存數(shù)據(jù)庫預(yù)處理子系統(tǒng)調(diào)度JobTrackerStandByNameNode〔備〕主控節(jié)點(diǎn)實(shí)現(xiàn)HA高可用性——保證系統(tǒng)整體的高可用性NameNode節(jié)點(diǎn)只是管理文件系統(tǒng)的結(jié)構(gòu)與存儲位置，作為控制點(diǎn)，負(fù)載很低。發(fā)生故障的概率也不會太高。采用HA模式是ACTIVE-STANDBY。手工切換通過在備機(jī)手工啟動切換腳本，生效備機(jī)，使備機(jī)成為主機(jī)。必要的檢查確認(rèn)可以在2分鐘時間完成切換。風(fēng)險(xiǎn)點(diǎn)在于2分鐘之內(nèi)會有業(yè)務(wù)中斷現(xiàn)象。好處是數(shù)據(jù)完整性，正確性保證比較好。自動切換通過檢測網(wǎng)絡(luò)暢通情況，發(fā)現(xiàn)主機(jī)網(wǎng)絡(luò)超過規(guī)定時間內(nèi)無法接通，那么進(jìn)行自動切換。通?？梢栽趲酌胫型瓿汕袚Q。風(fēng)險(xiǎn)點(diǎn)在于網(wǎng)絡(luò)短時問題導(dǎo)致主機(jī)備機(jī)之間的不必要切換。好處是業(yè)務(wù)中斷時間短推薦根據(jù)浙江移動詳單查詢現(xiàn)狀，存儲能力評估算法如下：基于X86架構(gòu)的詳單查詢方案處理能力評估存儲需求：每天處理的詳單量約為0.7T；每半年數(shù)據(jù)增長率約為15%；字段使用率約為40%；詳單存儲時間為12個月，同時存放3天的話單原始數(shù)據(jù)，因此總存儲量應(yīng)該為12個月的數(shù)據(jù)+3天的原始數(shù)據(jù)；基于Hadoop詳單系統(tǒng)方案數(shù)據(jù)壓縮比為1:7.6，建議3份冗余。系統(tǒng)冗余率約為30%采用基于Hadoop的詳單查詢方案存儲空間評估：〔每天話單存儲*每月天數(shù)*半年月數(shù)*使用字段數(shù)百分比*〔〔1+半年增長率〕^2+〔1+半年增長率〕^3)/壓縮比)*存儲份數(shù)總存儲：85T根據(jù)浙江移動詳單查詢現(xiàn)狀，計(jì)算能力評估算法如下：基于X86架構(gòu)的詳單查詢方案處理能力評估〔續(xù)〕計(jì)算能力評估：6943403TPMC計(jì)算需求：在3天內(nèi)〔3號8點(diǎn)前〕從數(shù)據(jù)庫導(dǎo)入上個月的歷史詳單數(shù)據(jù)；每個月從數(shù)據(jù)庫中導(dǎo)出的詳單數(shù)據(jù)約為88T；每半年數(shù)據(jù)增長率約為15%；詳單數(shù)據(jù)實(shí)時入庫，即5分鐘內(nèi)可以提供查詢效勞；支持200個以上的并發(fā)查詢，同時響應(yīng)時間不超過10秒；集群CPU負(fù)荷在80%左右，內(nèi)存占用要在50%以下；Hadoop平臺在PB級數(shù)據(jù)以下處理能力保持線性增長；基于X86架構(gòu)的詳單查詢方案處理能力評估〔續(xù)〕根據(jù)前面的存儲和計(jì)算性能的需求評估需要存儲為85T,計(jì)算需求為694萬TPMC，綜合考慮，建議效勞器建議配置如下：詳單查詢后臺軟件環(huán)境：主機(jī)操作系統(tǒng)RedHatEnterpriseLinux5.6詳單查詢后臺硬件評估:數(shù)據(jù)庫軟件OCNOSQL割接方案——遷移風(fēng)險(xiǎn)分析及方案推薦并行方案一次全割詳單查詢接口路由老系統(tǒng)基于文件系統(tǒng)詳單查詢新系統(tǒng)基于Hadoop詳單查詢數(shù)據(jù)局部割接——將有最近歷史計(jì)費(fèi)詳單的數(shù)據(jù)〔5個月)通過數(shù)據(jù)割接轉(zhuǎn)換到Hadoop系統(tǒng)中來。查詢路由——需要單獨(dú)開發(fā)查詢路由模塊，進(jìn)行路由判斷，查5個月內(nèi)+當(dāng)前月的詳單，路由指向新系統(tǒng)，其他歷史月〔6-12個月〕詳單路由到老系統(tǒng)中。老系統(tǒng)逐步退出——當(dāng)新系統(tǒng)詳單存儲到達(dá)12月時，老系統(tǒng)完全退出。CRM新詳單查詢EJB最后上線——支持分頁返回，分批從新詳單系統(tǒng)中返回結(jié)果，延緩解決大數(shù)據(jù)量查詢問題。CRM新EJB老EJB并行期架構(gòu)12-n月數(shù)據(jù)n月數(shù)據(jù)n趨向于0總計(jì)12月的詳單數(shù)據(jù)過渡模塊數(shù)據(jù)全部割接——需要準(zhǔn)備額外的存儲，存儲12月計(jì)費(fèi)清單。Qry文件數(shù)據(jù)存在轉(zhuǎn)義，不適合割接使用。不需查詢路由——不需要單獨(dú)開發(fā)。老系統(tǒng)一次性退出——割接完成時，老系統(tǒng)就可以退出。割接完成，系統(tǒng)完成目標(biāo)架構(gòu)的構(gòu)建。CRM新詳單查詢EJB上線同時上線——CRM系統(tǒng)需要割接時，同時完成詳單查詢EJB改造上線。大數(shù)據(jù)量查詢問題一次性解決。優(yōu)點(diǎn)缺點(diǎn)并行方案上線周期短，靈活度高，割接日期，割接數(shù)據(jù)都變化。老系統(tǒng)可作為備用系統(tǒng)，降低割接風(fēng)險(xiǎn)。額外開發(fā)一些并行模塊。過渡期長，大數(shù)據(jù)量查詢問題延后解決。一次全割減少一定開發(fā)量大數(shù)據(jù)量查詢問題一次性解決割接風(fēng)險(xiǎn)高額外的存儲準(zhǔn)備期長，割接時間長推薦推薦采用并行的割接方案 ——綜合考慮上線周期，割接風(fēng)險(xiǎn)工程人員安排與資源投入工程進(jìn)度

WK月份7月（2012）W1W2W3W1W2W3W1W2W3工作內(nèi)容需求分析產(chǎn)品測試總設(shè)/概設(shè)編碼與單測外圍改造外圍聯(lián)調(diào)主機(jī)部署數(shù)據(jù)割接壓力測試容災(zāi)演練生產(chǎn)并行8月（2012）9月（2012）10月（2012）11月（2012）W1W2W3W1W2W3

需求分析與建設(shè)方案產(chǎn)品測試

總體設(shè)計(jì)、概要設(shè)計(jì)、需求功能矩陣

CRM、計(jì)費(fèi)、網(wǎng)廳、自主終端配合改造外圍接口聯(lián)調(diào)包括生產(chǎn)、測試主機(jī)集群硬件集成，軟件部署工作?；诟罱訑?shù)據(jù)進(jìn)行查詢壓力測試對5到9月歷史詳單進(jìn)行割接。歷史詳單割接 2023/10/10 2023/10/319月歷史詳單割接 2023/10/10 2023/10/188月歷史詳單割接 2023/10/19 2023/10/237、6、5月歷史詳單割接 2023/10/23 202