如何快速構建基于PG的全云化大數據應用-數據庫管理、開發實踐專場（30頁）.pdf

1、單擊此處編輯母版標題樣式單擊此處編輯母版標題樣式如何快速構建基于PG的全云化大數據應用2019.11.30-一種大規模的計算集群解決方案3一、背景介紹二、原型方案三、PG in cloud目錄4為實現大數據敏捷開發，基于云原生方案打造了一套高可用的數據中心方案。1、背景概述前期完成了全省的PM數據接入，近期為了進行5G規劃，以MDT數據（一種采樣點級）數據進行空間聚類分析。5 52、分布方式多機處理方案大數據處理的關鍵以opdata為例，實現省OMC的采集分布到多套服務器上快速處理：流程說明：Beat定時觸發gettergetter任務觸發handlerhandler任務觸發loaderMes

2、sage queue:作為任務件調度的消息載體一種強大而簡單的結構6 63、CI/CD 方案DEVOPS的基石在本期項目中，完全采用GitLab CI/CD Pipeline實現持續集成的方案。gitlab-ci運行流程：提交代碼到gitlab會觸發CI/CD流程流程交給gitlab-runner運行gitlab-runner加載.gitlab-ci.yml中的自動化定義gitlab-runner依次執行stage(實現自動化)7MDT數據基于用戶上報的測量數據實現無線網絡：4、MDT應用問題分析1，數據量大：全省每小時產生80萬個壓縮文件。2，空間計算復雜：根據用戶位置實現用柵格定位。3，數

3、據聚合復雜：負責應用中有多維度報表的需求。MDT 處理的主要難點處理的主要難點8 8 5、主要的挑戰在前期方案，處理MDT數據難點微服務清單及功能描述見下表：用例領域用例領域功能描述功能描述微服務命名微服務命名微服務管理容器倉庫registry代碼管理gitlabgitlab CI自動化集成gitlab-runner任務管理rabbitmqrabbitpm/nrm定時器beatpg定時器pg_beat數據轉換管理pm下載pm_getterpm處理pm_handlerpm入庫pm_loadernrm下載nrm_getternrm處理nrm_handlernrm入庫pm_loaderDB管理pg相

4、關任務pg_task監控管理celery任務監控可視化flower容器監控可視化visualizercelery任務監控taskMonitor主機/容器狀態監控promethus將promethues數據寫到pg的適配器prometheus-postgresql-adapter主機狀態收集器node_exporter容器狀態收集器cAdvisor_exporter可視化管理react_jsreact_jsDjango_restful_apiDjango_restful_api目前微服務主要分為微服務管理，任務管理，數據轉換，DB管理，監控管理，可視化管理六大模塊：主要挑戰：1）適配多種格式的文

5、件2）容器規模增加到400個3）ETL需要復雜空間運算9一、背景介紹二、原型方案三、PG in cloud目錄10MDT分析主要是實現柵格級的FDD/NB覆蓋效果評估。1、用例模型主要的用例：1）管理MDT采集任務2）更新工參配置3）天粒度數據匯總11111-2采集方案與領域對象模型由于MDT是一種采樣點級的數據，1個小時全省的文件量為 80W個。根據廠家不同，有小包壓縮文件，和大包壓縮文件兩種。分廠家的文件格式分廠家的文件格式一個小時的文件量一個小時的文件量12針對MDT文件進行實時處理，生成小區柵格級統計分析應用數據。2、數據處理pipeline-MDT柵格定位1313p流轉換層：負責將數

6、據從外部的FTP服務器，提取到應用服務器，經過一系列的轉換，輸入的數據庫當中進行持久化。p異步服務層：負責提供整體的一步異步服務調用。p定制服務層：負責提供一些專有的解析，和計數功能。3、分析模型（Analysis model）核心解碼模塊的微服務拆分的框架如下圖，整個微服務劃分為三層：14144 微服務方案 主要挑戰不同的微服務之間需要協作，而這個協作的橋梁就是分布方式的隊列（QUEUE）方案，前期框架設計的是4個任務隊列：queue最大優先級最大優先級priority正常處理正常處理priority補采補采prioritybeat/mdt_getter221mdt_handler221md

7、t_loader221nrm_getter221nrm_handler221nrm_loader221由于每小時產生的文件為80萬。Getter完成采集以后，將在1瞬間產生80萬的task：主要問題1、快生產、慢消費2、隊列數據積壓3、重運算數據困難15154-2 微服務方案Refine 優化思路將getter和handler之間完全解耦，引入一個jobhandler處理層：其它定時任務統計表：16164-3 微服務方案 任務調度時序解耦思路：1、getter只負責采集文件，生成filelist2、jobhandler負責將未處理的文件，智能分組，生成任務3、handler 只負責處理任務17

8、5、Call-stack（）編排方案為了解除微服務之間的調用關系，引入微服務編排組件實現調用關系的集中管理。以本項目為例，使用chain原語實現三個微服務的順序調用。微服務的調用關系利用回調關系隱式表達?；卣{機制是一種完全異步的非阻塞方式。18187 微服務方案 效果驗證解耦思路：1、新方案的1小時消息量，舊方案的1小時消息量舊方案消息量：160萬條（80萬*2）新方案消息量：1.6萬條（160萬/100）2、分組調度的策略說明3、實時+批處理的優點解耦getter與handler關系預防getter消息量突增可通重復發送任務批量處理，減少IO操作提升CPU利用率DIY Bigdata APP

9、19198、集群的CPU利用率pcpu資源利用率本項目分配了200個CPU,CPU24小時平均利用率保持在80%以上，充分利用機器資源。Bigdata via Small hardware20一、背景介紹二、原型方案三、PG in cloud目錄21211、從PG并行到“并行PG”Q：如果數據規模超過300T，可以使用PG數據庫嗎。A：DIY一個調度器整合多套PG數據庫?；赾allStack整合方案22222、云原生環境組件棧（DIY Bigdata APP）PostgreSOL：1、數據持久化。2、熱共享數據 3、微服務編排支撐（callstack）23233、ETL海量采集文件管理（熱共

10、享數據）PostgreSOL：1、file_list表進行了天粒度分片。Python：2、引入內存數據庫，批量更新，避免多節點沖突。以mdt為例，每小時采集70-80萬文件，存入file_list表，多進程下要避免鎖表操作的發生。24244-1、寫操作調優（數據持久化）PostgreSOL：1、配置參數調優。Python：2、copy方式入庫。以pm為例,要完成小時粒度數據的實時粒度入庫表名8時9時10時1天table11091萬1078萬1105萬2.5億table232萬31萬33萬770萬table3124萬121萬128萬3千萬table41814萬1814萬1814萬4.35億tab

11、le55410萬5410萬5410萬13億table645萬45萬46萬1.1千萬table7137萬137萬138萬3.3千萬table877萬75萬77萬1.9千萬table977萬75萬77萬1.8千萬table1030萬30萬33萬720萬table116.4萬6.4萬7.1萬150萬table1219萬19萬21萬465萬25254-2、面向海量數據加載的pg12調優PostgreSOL：1、配置參數調優。Python：2、copy方式入庫。以pg12為例,采用以下配置可實現數據的實時入庫寫操作參數調優項：shared_buffers=128MB#min 128kB 建議調大到 10

12、24MBmaintenance_work_mem=64MB#min 1MB 建議調整到 4096MBsynchronous_commit=on#建議調整成 offcheckpoint_timeout=5min#建議調整成 30 minwal_keep_segments=0#建議調整成 204826265、微服務task監控利用pg12實現task結果的收集，是callstack（）的核心組件。在多處理機的環境下需要集中管理微服務結果。（借助DB）基于pg12實現27274-2、云化環境中task轉態集中收集利用pg12收集task狀態由于task狀態表需要頻繁讀寫，數據庫的隔離性能就很關鍵。PG12具有良好的表現28285、時序數據庫擴展助力-云監控利用調度器控制task數量prometheus+timescaleDB監控云平臺的狀態。29296、PG12在大數據stack的戰略定位云原生stacK更加依賴高可用RDBMS。1.低成本2.高可用3.支撐好30