浙江移动基于Hadoop的详单系统建设方案v1.97

浙江移动基于Hadoop的帐详单查询系统解决方案亚信联创市场咨询部2023年5月议题现存问题分析工程建设目标工程方案介绍性能测试报告迁移方案简介案例介绍浙江移动详单查询现存问题分析单次查询话单量超过10000条时，由于加载数据量过大，查询效劳无法返回，造成查询失败；详单文件共享内存13G导入中间文件详单查询加载落地读取读取1390571XXXX实时详单查询应用通过访问共享内存和详单文件系统，把二者数据组合生成查询结果；详单导入应用处理中间文件后，先加载到共享内存中，当内存数据到达5000万条阀值时，集中将内存数据写入详单文件中；问题一：大数据量详单查询成功率保障缺乏导入应用和详单查询应用通过共享内存方式实现通信，当导入应用发生故障时，会造成详单查询应用无法获取内存信号量，导致查询效劳堵塞与积压；问题二：应用紧耦合查询主机二(HPSD)查询主机一(HPSD)实时详单查询实时详单查询实时详单导入服务实时详单导入服务实时详单预处理实时详单预处理历史详单查询历史详单查询历史详单导入历史详单预处理20.…..…..…..….10315实时详单查询服务实时详单查询服务历史详单查询历史详单查询历史详单导入历史详单预处理20.….…..….10部署现状：

详单查询查询主机采用两台HPSD，提供11+1月详单数据主机一：实时详单导入17个号段

历史详单导入11个号段主机二：实时详单导入11个号段

历史详单导入17个号段主机负载情况：CPU忙时占用率50%，CPU闲时占用率22%，内存占用率为55%；历史详单预处理每月24、28、30、1号从计费数据库读取详单文件生成cdr文件；历史详单导入每月1号11点按号段生成中间文件，2号凌晨处理完成，3号提供客户查询。详单查询、预处理，导入应用部署在同一台主机上，应用之间相互影响较大。浙江移动详单查询现存问题分析〔续〕问题三：系统部署过于集中，主机资源竞争严重详单处理应用按业务和号段划分，各进程之间独立运行，无高可用保障措施。查询效劳量过大时，缺乏过载保护机制。问题四：系统高可用保障能力缺乏实时详单存储历史详单存储实时详单文件

总存储：10.2TB使用率：75%历史详单中间文件总存储：4.1TB使用率：78%历史详单查询文件总存储：11.7TB使用率：34%实时详单采用一个文件系统存储数据，包括计费原始详单文件、中间过程详单文件、以及最终查询详单文件；目前实时详单文件系统已到达10.2T，使用率已经到达75%；为了节省文件系统空间，保证最终查询文件的存储空间，计费原始详单与中间过程文件只保存3天数据，目前占用〔1.1+0.33=1.43〕T；最终查询文件占用6.07T；目前单个文件系统的容量已经过大，且随着业务量的扩展，详单对存储空间要求越来越大，存储需要进行重新规划和调整。

历史详单采用两个文件系统存储数据，分别存储历史详单的中间详单文件和最终查询文件;

目前历史最终查询详单保存11个月，采用压缩格式存储，文件系统共11.7T，使用率34%；中间详单文件系统4.1T，只保存一个月的中间处理文件，目前使用率78%；历史详单的处理每月导入一次，处理相对集成，文件碎片较小。浙江移动详单查询现存问题分析〔续〕问题五：文件系统划分过于庞大，严重影响整体系统的稳定性和读写效率按照效劳等级的区分，将详单文件系统划分实时详单和历史详单；议题现存问题分析工程建设目标工程方案介绍性能测试报告迁移方案简介案例介绍工程建设目标引入分布式数据库，基于X86设备实现详单处理的分布式架构，提高系统的扩展能力，降低系统整体建设本钱。采用分布式数据存储技术，提高数据高可用，保障系统稳定。引入分布式缓存机制，提高大数据量查询效率。加强详单稽核，提升故障快速定位能力。完成集团公司〞基于云计算的详单处理“建设试点工作，验证利用分布式技术对详单进行存储、处理与查询的技术方案，要求11月份完成试点工作。系统建设目标满足到2023年底支撑月详单480亿条，支持6+1月详单存储和查询；详单文件落地至处理完成时长不超过5分钟，支持200以上的并发查询，前台查询响应时间小于10秒。议题现存问题分析工程建设目标工程方案介绍性能测试报告迁移方案简介案例介绍现有系统架构统一门户前台功能接口服务器APP层EJB调用详单查询SOCKET服务历史话单导出CDR文件实时话单导出R文件R文件导入QRY文件实时话单文件、历史话单表FTP发送计费系统综合查询详单后台CRM系统CDR文件导入QRY文件新系统总体架构统一门户前台功能接口服务器详单查询HTTP协议（新）实时话单文件、历史话单表FTP获取计费系统综合查询详单后台CRM系统话单预处理模块OCNosql话单存储详单查询效劳OCNosql详单存储计费清单话单导入预处理备份与清理话单入库缓存检查话单查询CRM查重汇总转义分页缓存查询流程：加载流程：新系统总体流程详单预处理详单查询效劳页面组装新系统数据模型原始话单存储模型展示模型TRADEMARKDR_TYPESERVICE_IDUSER_NUMBERSTART_TIMEVC_NUMBERUSER_TYPETRADE_TYPEOPP_NUMBERTRADE_STATECARD_IDVC_TYPEHPLMN1HPLMN2VPLMN1VPLMN2CARD_HPLMN1CARD_HPLMN2CARD_CHARGESCP_IDVC_LOCATION用户号码业务类型字段1字段2字段3字段4字段5字段6字段7字段8字段9字段10字段11字段12字段13…字段32预留字段1预留字段2…预留字段18帐户号开始时间时长批价时间呼叫类型漫游类型长途类型本地通话费信息费免费资源1使用量免费资源2使用量免费资源1名称免费资源2名称一级漫游地二级漫游地对端一级漫游地对端二级漫游地对端号码服务商服务商产品预处理详单查询存储需32个字段，现预留18个字段用于后续业务扩展需要新系统介绍——模块介绍新的详单查询系统，由如下三个模块构成：详单预处理OCNoSql详单存储详单查询效劳数据预处理——功能架构计费话单数据并行计算数据操作HDFS文件系统调度引擎详单预处理系统管理系统OCNOSQL存储任务定义调度记录流程任务数据入库数据预处理——流程定义话单类型判断结构体映射话单过滤FTP话单传输多副本保存话单按号码排序生成数据文件数据文件入库将原始话单转移目录存储删除中间步骤生成的文件定义中间数据输出目录数据预处理——字段映射名称列：统一结构体字段名值：原始话单字段名或类似java语法的表达式，例如：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';}可以设定话单的过滤规那么，过滤掉不需要查询的话单或者错单详单查询效劳——功能架构CRM接口机OCNosql存储CRM-EJB效劳下沉业务逻辑与数据存储完全解耦。引入缓存技术，优化系统响应速度。引入内存数据库，缩短字段转义时间。支持多个数据源查询详单查询接口效劳HTTP通讯接口封装详单查询接口详单模型详单查询处理逻辑字段转义话单分页话单汇总话单合并话单查重缓存REDIS内存数据库局数据倒入工具详单查询数据接口OCNOSQL数据接口详单查询效劳——内存数据库的使用在详单查询效劳中引入内存数据库的作用：1、增加详单结果分页的功能查询详单时，以一个月详单为例，一般查询结果在300－1000条左右，返回全部数据对网络IO开销很大，尤其时并发数很大的时候使用内存数据库存储详单的全量数据，每次只返回20－100条详单数据，可以大大提高详单查询的并发处理能力，同时还可以降低数据的重复查询的压力2、增加详单结果中字段快速转义的功能详单中包含了大量的数字符号，例如：SP_CODE,SERVICE_CODE等等通常的处理方法是查询数据库转义成为例如“中国移动〞“在线书城〞等结果在详单查询顶峰期对数据库压力很大，也影响详单查询的整体性能通过将局数据等信息提前存入内存数据库，实现快速高并发查询在上海移动的生产环境中，实际存入转义数据300M左右，平均每次访问减少数据库查询次数30－100次3、内存数据库的部署可以根据实际情况在转义数据量不是很大的时候选择多台部署，防止单点故障。OCNoSql数据库——功能架构分布式数据库数据加载工具数据索引存储索引自动优化分布式缓存高效能压缩负载均衡管理数据加载规那么管理数据加载任务管理数据加载监控管理二次开发接口对外接口JDBC、ODBC、WebService、RESTful…数据库管理数据库配置管理工具数据库监控管理工具数据库备份恢复工具数据库任务管理工具分布式文件系统DFSDFSDFS连接池管理权限管理线程管理OCNoSql数据库——话单存储OCNosql数据库类似于行列混合模式，针对详单查询业务场景，它把行、列存储的优势都发挥了出来，通过RowKey可迅速定位到行记录，同时其对应的列可随时进行扩展,通过该方式，压缩率可保证在10:1以上，同时大大降低了系统I/O。采用该方式提供详单查询效劳：入库时无需先排序，详单文件通过MapReduce并行计算框架可以高效的直接加载到分布式数据库中；详单数据入库采用天建表策略，通过时间和号码两个维度迅速定位到数据文件。入库时，针对详单文件的特点，提供数据级别的压缩功能，对于详单中重复字段较多的场景，实现高压缩比新详单查询系统——功能列表新详单查询系统完全继承原有CRM侧详单查询接口：实时详单查询历史详单查询大数据详单查询新详单查询系统同时支持集团类详单的批量导出文件功能，包括：PBX详单企业信息机详单集团400业务详单新详单查询系统同时支持计费侧重批话单的导入和查询对于重批话单，对其的导入完全等同于普通话单通过在查询效劳模块中的查重功能，实现对旧话单的过滤。新详单查询系统——维护功能入库任务编排调度管理模块：入库任务调度频度、启动参数配置；任务流程可视化编排；任务流程调度引擎；任务流程监控管理。错单处理模块：支持重批话单的导入。数据生命周期管理模块：数据生命周期检查规那么配置；数据生命周期检查频度配置；历史数据删除。维护类工具模块：分布式文件系统备份分布细那么监控；集群运行情况监控；人工删除、补录；维护类查询。大数据量详单内存数据库架构优化一：引入缓存处理，提高大数据量查询效率目前状况：分布式改造后：CRM…查询代理查询请求Hadoop分布式详单数据库查询结果汇总查询直接返回查询分页返回…分布式缓存自动索引分布式存储详单查询接口效劳缓存技术分页缓存单次查询3000条以上记录，经常出现查询失败，查询返回时间长。单次大数据量查询，影响同时请求的小数据量查询。基于文件系统的查询，磁盘IO成为系统瓶颈，缺少缓存技术配合。文件生成分布式技术改造后：底层采用分布式数据库技术，引入分布式缓存，通过缓存命中率，提高查询效率。大数据查询时，采用分页返回策略，未返回的分页数据在内存数据库中缓存。CRM需要做分页显示的改造，显示下一页需要通过从接口详单查询系统分页缓存中取结果架构优化二：解耦应用，防止故障影响扩大目前状况：分布式改造后：实时详单查询请求查询内存详单详单导入共享内存查询文件详单详单文件IPC详单查询流程从内存和文件中获取数据，组合生成详单查询数据为了获取导入进程内存中的详单数据，详单查询效劳通过共享内存方式获取内存数据；当导入应用出现故障时，共享内存信号无返回，造成查询失败中间文件加载导入分布式数据库详单查询采用分布式数据库后，无需再使用共享内存的方式进行详单查询，导入效劳和详单查询彻底别离开。因此无论导入效劳是否出现故障，查询流程将直接读取分布式数据库中的详单数据，再不会出现查询失败问题。架构优化三：分布式架构让系统无需集中部署目前状况：详单查询、预处理，导入应用部署在同一台主机上，应用之间相互影响较大分布式改造后：详单查询系统通过采用分布式数据库后进行分布式部署，通过该部署方式，让应用之间实现性能隔离，不会互相影响。Server1NoSQLMasterServer2NoSQLRegionServerServer3NoSQLRegionServerServerNNoSQLRegionServer…分布式数据库集群：架构优化四：增强系统高可用保障能力及高可扩展性详单处理应用按业务和号段划分，各进程之间独立运行，无高可用保障措施。查询效劳量过大时，缺乏过载保护机制。目前状况：分布式改造后：详单查询采用分布式数据库：通过2份以上的副本与自动同步机制来保证数据的高可用性，实现自动容灾；其分布式架构可满足更高的吞吐量需求；自动索引及分布式缓存机制保障了详单查询效劳的高性能；在查询效劳性能遇到瓶颈时，可通过横向扩展迅速提高效劳质量。网厅、自助终端、……详单查询效劳流量控制CRM查询效劳详单查询队列流量控制模块作为详单查询效劳的管理模块，用于控制效劳调用；对于超出队列阀值的调用，返回失败消息。HTTPsocket内部调用架构优化五：效劳流量控制数据节点1数据节点2…数据节点n主控节点Hadoop集群为了防止通过频繁调用进行的恶意攻击，对于不同渠道、不同系统的接口进行流量分配，对各渠道的单位时间调用次数和调用频率进行限制，超过调用阀值进行告警，超过上限那么采取过载保护，进行错误返回。架构优化六：加强详单处理数据稽核话单导入话单预处理Hadoop用户计费系统查询效劳历史详单实时详单详单查询系统日志记录在话单处理各个环节会对每个处理的话单记录相应的日志记录，包括文件名、大小、开始结束时间、成功数、失败数、耗时。稽核报警当出现文件名错误，文件大小错误，记录总数错误，文件加载失败，查询失败等，会向管理平台告警。稽核点架构优化七〔一〕：解决文件存储问题目前状况：文件系统划分过于庞大，严重影响整体系统的稳定性和读写效率分布式改造后：TBTBTBTBTBTBTBTBPB。。。。。。系统可直接在多台x86化PCServer与刀片机的本地存储及原有磁盘阵列上共同部署一套分布式文件系统来存放数据文件，支持PB级别存储容量，因此不会再出现文件系统划分过于庞大的问题高效的压缩机制节省了更多的存储空间，对于详单这类列重复度较高的数据具有极高的压缩比，压缩状态不影响数据读写性能，在启动高级压缩后，可以到1:10左右的综合压缩比数据库容量与性能支持在线的弹性扩展，为系统后期扩容工作奠定了坚实的根底架构优化七〔二〕：分布式存储提高文件系统高可用性F1F5F3F0F5F1F2F0F1F2Master详单查询效劳…分布式存储特性：数据多副本，建议1：2数据流与控制流别离写文件采用追加写删除文件采用置失效方式，误删除可恢复机器宕机，或者永久损坏，Master节点可自动恢复在新节点。采用数据节点内置硬盘或低端存储存储数据，高可用性通过Hadoop软架构实现，不依赖硬件性能。不需要做RAID，可使用裸盘。存储扩展可通过增加节点，由Hadoop自动分配完成。存储的优化依靠Hadoop的自动优化管理，通过compact与split等动作完成，减少人工管理的时间。CRM议题现存问题分析工程建设目标工程方案介绍性能测试报告迁移方案简介案例介绍数据加载和查询性能测试报告——硬件环境主机IP用户名用途cpu/内存/存储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计费话单主机

数据加载和查询性能测试报告——测试目标测试目标本项测试的测试目标为检验话单从计费主机经过ftp，数据过滤，加载到OCNOSQL，清理全流程各个节点速度及系统资源占用情况。测试方法计费话单从计费主机经过ftp，数据过滤，加载到OCNOSQL，记录各个节点时间，资源占用率测试目标本项测试的目标为检验OCNoSql的查询性能。分别对按日分表的系统空闲时及系统忙时进行查询性能测试，并记录查询过程中主机的CPU，IO，MEM等各项资源占用情况。测试方法本次测试借助于Tomcat作为应用服务器，在其上部署了调用分布式数据库的查询API的WebService；通过JMeter模拟多客户端进行不间断查询，并统计性能数据数据加载测试：数据查询测试：数据加载性能数据量本次测试根据实际数据内容和格式，模拟生成了GPRS详单1天的数据，每天的详单数据约为300G；存储结构为按日分表。数据加载和查询性能测试报告——数据加载性能文件个数总文件大小（k）总持续时间（秒）ftp耗时（秒）数据过滤耗时（秒）加载入库耗时（秒）mapreduce启动时间（秒）清理ftp过程吞吐量（M/S）数据过滤吞吐量（M/S）数据加载吞吐量（M/S）cpu利用率mem利用率DiskQueueLength100010301716704110288137907991.4634.9329.3736%30%1001008142562692548391273031.8116.578.1616%18%20数据加载和查询性能测试报告——日表存储查询测试〔无数据加载〕抽样数据并发数量循环次数平均处理时间(毫秒)最小处理时间（毫秒）最大数据响应时间(毫秒)TPS(事务数/秒)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数据加载和查询性能测试报告——日表存储加载与查询并行测试抽样数据并发数量循环次数平均处理时间(毫秒)最小处理时间（毫秒）最大数据响应时间(毫秒)TPS(事务数/秒)Cpu利用率mem利用率DiskQueueLength100000100200004543177165230%25%120100000200100009357032189840%27%150100000100200003343041185023%15%30100000200200003549121190625%20%50红色局部为日表闲时查询测试用例测试结果数据数据加载和查询性能测试报告——测试结论准确性：话单数据通过预处理加载到OCNOSQL后，数据与原始话单一致。高可用性：集群中任意一台数据节点宕掉后，OCNOSQL存储的数据完整无丧失。扩展性：通过5，6，7节点测试，整个详单系统处理数据速度能随着节点增加而增加。从5节点增加到6节点一块磁盘，现规划生产每台主机有4块磁盘，TPS随查询并发数提高还会有较大提高〕，数据过滤处理速度提高了18%，数据加载速度提高了26%。从6节点增加到7节点，数据过滤处理速度提高了13%，数据加载速度提高了25%。预处理加载性能：正常与积压话单情况下处理速度满足预处理加载性能指标要求。正常业务量情况下4分29秒完成预处理加载，满足5分钟落地要求。话单积压状态下，一天话单在187分钟处理完成。与现生产环境的处理效率比对，月历史详单导入速度可以提高40%。OCNOSQL查询性能：5-500并发，平均响应时间均小于100毫秒，并且随着并发数提高，TPS也随之提高。〔测试环境每台主机只有200并发闲时平均响应时间35毫秒，忙时平均响应时间93毫秒。压缩比：正常业务量情况下，数据压缩比为1:7，每天重处理前一天话单，压缩比可到达1:10。议题现存问题分析工程建设目标工程方案介绍性能测试报告迁移方案简介案例介绍现有详单查询系统部署现状分析查询主机二(HPSD)查询主机一(HPSD)实时详单查询实时详单查询实时详单导入服务实时详单导入服务实时详单预处理实时详单预处理历史详单查询历史详单查询历史详单导入历史详单预处理20.…..…..…..….10315实时详单查询服务实时详单查询服务历史详单查询历史详单查询历史详单导入历史详单预处理20.…..…..….10部署现状：详单查询查询主机采用两台HPSD，提供5+1月详单数据操作系统：HP-UX操作系统发行版〔release〕的名称：机型：ia64hpsuperdomeserverSD32B主机负载情况：CPU忙时占用率50%，CPU闲事占用率22%，内存占用率为55%问题：数据量详单查询成功率保障缺乏应用紧耦合系统部署过于集中，主机资源竞争严重系统高可用保障能力缺乏……基于Hadoop改造后的详单查询改变原有架构，在进行迁移时，采用的是两对多的迁移方式硬件设备：以应用性能指标为标准，选取同等甚至超出原有系统处理能力的x86效劳器集群替代原小型机设备，并利用原小机设备作为详单查询效劳前台支撑应用软件：选取基于Hadoop开发的可扩展性高的x86集群应用替代原有的Unix应用两对多的迁移基于Hadoop改变现有架构，由X86效劳器集群替代详单查询后台详单查询接口效劳新增两台刀片机作为详单查询接口效劳的效劳器基于X86架构的详单查询整体部署方案集群共有4类节点：前台应用节点，主控节点，数据存储节点及数据库节点。前台详单查询应用节支撑详单查询效劳的前台，主控节点需要使用两台效劳器互为热备，进行元数据管理并提供Hmaster效劳，同时还需要部署分布式数据库配置管理效劳；数据库节点负责索引管理及查询访问管理，由它来保证数据库对高并发访问的支持，并且可以保障查询结果的快速响应；数据存储节点负责详单数据的加载和存储功能，由它来决定原始详单数据入库的效率，并且在存储方面建议采用3份冗余策略来提高数据的可靠性及效劳的可用性。子节点1子节点2子节点3子节点4……NameNode主节点数据源数据源子节点N子节点NNameNode备节点详单查询效劳预处理Redis内存数据库预处理子系统调度JobTrackerStandByNameNode〔备〕主控节点实现HA高可用性——保证系统整体的高可用性NameNode节点只是管理文件系统的结构与存储位置，作为控制点，负载很低。发生故障的概率也不会太高。采用HA模式是ACTIVE-STANDBY。手工切换通过在备机手工启动切换脚本，生效备机，使备机成为主机。必要的检查确认可以在2分钟时间完成切换。风险点在于2分钟之内会有业务中断现象。好处是数据完整性，正确性保证比较好。自动切换通过检测网络畅通情况，发现主机网络超过规定时间内无法接通，那么进行自动切换。通常可以在几秒中完成切换。风险点在于网络短时问题导致主机备机之间的不必要切换。好处是业务中断时间短推荐根据浙江移动详单查询现状，存储能力评估算法如下：基于X86架构的详单查询方案处理能力评估存储需求：每天处理的详单量约为0.7T；每半年数据增长率约为15%；字段使用率约为40%；详单存储时间为12个月，同时存放3天的话单原始数据，因此总存储量应该为12个月的数据+3天的原始数据；基于Hadoop详单系统方案数据压缩比为1:7.6，建议3份冗余。系统冗余率约为30%采用基于Hadoop的详单查询方案存储空间评估：〔每天话单存储*每月天数*半年月数*使用字段数百分比*〔〔1+半年增长率〕^2+〔1+半年增长率〕^3)/压缩比)*存储份数总存储：85T根据浙江移动详单查询现状，计算能力评估算法如下：基于X86架构的详单查询方案处理能力评估〔续〕计算能力评估：6943403TPMC计算需求：在3天内〔3号8点前〕从数据库导入上个月的历史详单数据；每个月从数据库中导出的详单数据约为88T；每半年数据增长率约为15%；详单数据实时入库，即5分钟内可以提供查询效劳；支持200个以上的并发查询，同时响应时间不超过10秒；集群CPU负荷在80%左右，内存占用要在50%以下；Hadoop平台在PB级数据以下处理能力保持线性增长；基于X86架构的详单查询方案处理能力评估〔续〕根据前面的存储和计算性能的需求评估需要存储为85T,计算需求为694万TPMC，综合考虑，建议效劳器建议配置如下：详单查询后台软件环境：主机操作系统RedHatEnterpriseLinux5.6详单查询后台硬件评估:数据库软件OCNOSQL割接方案——迁移风险分析及方案推荐并行方案一次全割详单查询接口路由老系统基于文件系统详单查询新系统基于Hadoop详单查询数据局部割接——将有最近历史计费详单的数据〔5个月)通过数据割接转换到Hadoop系统中来。查询路由——需要单独开发查询路由模块，进行路由判断，查5个月内+当前月的详单，路由指向新系统，其他历史月〔6-12个月〕详单路由到老系统中。老系统逐步退出——当新系统详单存储到达12月时，老系统完全退出。CRM新详单查询EJB最后上线——支持分页返回，分批从新详单系统中返回结果，延缓解决大数据量查询问题。CRM新EJB老EJB并行期架构12-n月数据n月数据n趋向于0总计12月的详单数据过渡模块数据全部割接——需要准备额外的存储，存储12月计费清单。Qry文件数据存在转义，不适合割接使用。不需查询路由——不需要单独开发。老系统一次性退出——割接完成时，老系统就可以退出。割接完成，系统完成目标架构的构建。CRM新详单查询EJB上线同时上线——CRM系统需要割接时，同时完成详单查询EJB改造上线。大数据量查询问题一次性解决。优点缺点并行方案上线周期短，灵活度高，割接日期，割接数据都变化。老系统可作为备用系统，降低割接风险。额外开发一些并行模块。过渡期长，大数据量查询问题延后解决。一次全割减少一定开发量大数据量查询问题一次性解决割接风险高额外的存储准备期长，割接时间长推荐推荐采用并行的割接方案 ——综合考虑上线周期，割接风险工程人员安排与资源投入工程进度

WK月份7月（2012）W1W2W3W1W2W3W1W2W3工作内容需求分析产品测试总设/概设编码与单测外围改造外围联调主机部署数据割接压力测试容灾演练生产并行8月（2012）9月（2012）10月（2012）11月（2012）W1W2W3W1W2W3

需求分析与建设方案产品测试

总体设计、概要设计、需求功能矩阵

CRM、计费、网厅、自主终端配合改造外围接口联调包括生产、测试主机集群硬件集成，软件部署工作。基于割接数据进行查询压力测试对5到9月历史详单进行割接。历史详单割接 2023/10/10 2023/10/319月历史详单割接 2023/10/10 2023/10/188月历史详单割接 2023/10/19 2023/10/237、6、5月历史详单割接 2023/10/23 202