《如何快速构建基于PG的全云化大数据应用-数据库管理、开发实践专场（30页）.pdf》由会员分享，可在线阅读，更多相关《如何快速构建基于PG的全云化大数据应用-数据库管理、开发实践专场（30页）.pdf（30页珍藏版）》请在三个皮匠报告上搜索。

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数据库。基于callStack整合方案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