采用基于Hadoop的详单查询方案存储空间评估

1 .浙江移动 基于 Hadoop 的帐详单查询系统 解决方案 亚信联创市场咨询部 2012 年 5 月

2 .议题 现存问题分析 项目建设目标 项目方案介绍 性能测试报告 迁移方案简介 案例介绍

3 .浙江移动详单查询现存问题分析 单次查询话单量超过 10000 条时，由于加载数据量过大，查询服务无法返回，造成查询失败； 详单文件 共享内存 13G 导入 中间文件 详单查询 加载 落地 读取 读取 1390571XXXX 实时详单查询应用通过访问共享内存和详单文件系统，把二者数据组合 生成查询结果； 详单导入应用处理中间文件后，先加载到共享内存中，当内存数据达到 5000 万条阀值时，集中将内存数据写入详单文件中； 问题一：大数据量详单查询成功率保障不足 导入应用和详单查询应用通过共享内存方式实现通信，当导入应用发生故障时，会造成详单查询应用无法获取内存信号量，导致查询服务堵塞与积压； 问题二：应用紧耦合

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

5 .实时详单存储 历史详单存储 实时详单文件 总存储： 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% ； 历史详单的处理每月导入一次，处理相对集成，文件碎片较小。 浙江移动详单查询现存问题分析（续） 问题五：文件系统划分过于庞大，严重影响整体系统的稳定性和读写效率 按照服务等级的区分，将详单文件系统划分实时详单和历史详单；

6 .实时详单存储 历史详单存储 实时详单文件 总存储： 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% ； 历史详单的处理每月导入一次，处理相对集成，文件碎片较小。 浙江移动详单查询现存问题分析（续） 问题五：文件系统划分过于庞大，严重影响整体系统的稳定性和读写效率 按照服务等级的区分，将详单文件系统划分实时详单和历史详单；

7 .项目建设目标 引入 分布式数据库，基于 X86 设备实现详单处理的分布式架构，提高系统的扩展能力，降低系统整体建设 成本。 采用分布式数据存储技术，提高数据高可用，保障系统 稳定。 引入分布式缓存机制，提高大数据量查询 效率。 加强详单稽核，提升故障快速定位 能力。 完成集团公司”基于云计算的详单处理“建设试点工作，验证利用分布式技术对详单进行存储、处理与查询的技术方案，要求 11 月份完成试点工作 。 系统建设目标满足到 2013 年底支撑月详单 480 亿条，支持 6+1 月详单存储和查询；详单文件落地至处理完成时长不超过 5 分钟，支持 200 以上的并发查询，前台查询响应时间小于 10 秒 。

8 .项目建设目标 引入 分布式数据库，基于 X86 设备实现详单处理的分布式架构，提高系统的扩展能力，降低系统整体建设 成本。 采用分布式数据存储技术，提高数据高可用，保障系统 稳定。 引入分布式缓存机制，提高大数据量查询 效率。 加强详单稽核，提升故障快速定位 能力。 完成集团公司”基于云计算的详单处理“建设试点工作，验证利用分布式技术对详单进行存储、处理与查询的技术方案，要求 11 月份完成试点工作 。 系统建设目标满足到 2013 年底支撑月详单 480 亿条，支持 6+1 月详单存储和查询；详单文件落地至处理完成时长不超过 5 分钟，支持 200 以上的并发查询，前台查询响应时间小于 10 秒 。

9 .现有系统架构 统一门户前台 功能 接口服务器 APP 层 EJB 调用 详单查询 SOCKET 服务 历史话单导出 CDR 文件 实时话单导出 R 文件 R 文件导入 QRY 文件 实时 话单文件、历史话单表 FTP 发送 计费系统 综合查询详单后台 CRM 系统 CDR 文件导入 QRY 文件

10 .新系统总体 架构 统一门户前台 功能 接口服务器 详单查询 HTTP 协议（新） 实时 话单文件、历史话单表 FTP 获取 计费系统 综合查询详单后台 CRM 系统 话单预处理模块 OCNosql 话单存储 详单查询服务

11 .OCNosql 详单存储 计费清单 话单导入 预处理 备份与清理 话单入库 缓存检查 话单查询 CRM 查重 汇总 转义 分页缓存 查询流程： 加载流程： 新系统总体流程 详单预处理 详单查询服务 页面组装

12 .新系统数据模型 原始话单 存储模型 展示模型 TRADEMARK DR_TYPE SERVICE_ID USER_NUMBER START_TIME VC_NUMBER USER_TYPE TRADE_TYPE OPP_NUMBER TRADE_STATE CARD_ID VC_TYPE HPLMN1 HPLMN2 VPLMN1 VPLMN2 CARD_HPLMN1 CARD_HPLMN2 CARD_CHARGE SCP_ID VC_LOCATION 用户号码 业务类型 字段 1 字段 2 字段 3 字段 4 字段 5 字段 6 字段 7 字段 8 字段 9 字段 10 字段 11 字段 12 字段 13 … 字段 32 预留字段 1 预留字段 2 … 预留字段 18 帐户号 开始时间 时长 批价时间 呼叫类型 漫游类型 长途类型 本地通话费 信息费 免费资源 1 使用量 免费资源 2 使用量 免费资源 1 名称 免费资源 2 名称 一级漫游地 二级漫游地 对端一级漫游地 对端二级漫游地 对端号码 服务商 服务商产品 预处理 详单查询 存储需 32 个字段，现预留 18 个字段用于后续业务扩展 需要

13 .新系统介绍 —— 模块介绍 新的详单查询系统，由如下三个模块构成： 详单预处理 OCNoSql 详单存储 详单查询服务

14 .数据预处理 —— 功能架构 计费话单 数据并行计算 数据操作 HDFS 文件系统 调度引擎 详单预处理系统 管理系统 OC NO SQL 存储 任务定义调度记录 流程 任务 数据入库

15 .数据预处理 —— 流程定义 话单类型判断 结构体映射 话单过滤 FTP 话单传输 多副本保存话单 按号码排序 生成数据文件 数据文件入库 将原始话单转移目录存储 删除中间步骤生成的文件 定义中间数据输出目录

16 .数据预处理 —— 流程定义 话单类型判断 结构体映射 话单过滤 FTP 话单传输 多副本保存话单 按号码排序 生成数据文件 数据文件入库 将原始话单转移目录存储 删除中间步骤生成的文件 定义中间数据输出目录

17 .详单查询服务 —— 功能 架构 CRM 接口机 OCNosql 存储 CRM-EJB 服务下沉 业务逻辑与数据存储完全解耦。 引入缓存技术，优化系统响应速度。 引入内存数据库，缩短字段转义时间。 支持多个数据源查询 详单查询接口服务 HTTP 通讯接口封装 详单查询接口 详单模型 详单查询处理逻辑 字段转义 话单分页 话单汇总 话单合并 话单查重 缓存 REDIS 内存数据库 局数据倒入工具 详单查询数据接口 OCNOSQL 数据接口

18 .详单查询服务 —— 内存数据库的使用 在详单查询服务中引入内存数据库的作用： 1 、增加详单结果分页的功能 查询详单时，以一个月详单为例，一般查询结果在 300 － 1000 条左右，返回全部数据 对网络 IO 开销很大，尤其时并发数很大的时候 使用内存数据库存储详单的全量数据，每次只返回 20 － 100 条详单数据，可以大大提 高详单查询的并发处理能力，同时还可以降低数据的重复查询的压力 2 、增加详单结果中字段快速转义的功能 详单中包含了大量的数字符号，例如： SP_CODE,SERVICE_CODE 等等 通常的处理办法是查询数据库转义成为例如“中国移动”“在线书城”等结果 在详单查询高峰期对数据库压力很大，也影响详单查询的整体性能 通过将局数据等信息提前存入内存数据库，实现快速高并发查询 在上海移动的生产环境中，实际存入转义数据 300M 左右，平均每次访问减少数据库 查询次数 30 － 100 次 3 、内存数据库的部署 可以根据实际情况在转义数据量不是很大的时候选择多台部署，避免单点 故障。

19 .OCNoSql 数据库 —— 功能架构 分布式数据库 数据加载工具 数据索引存储 索引自动优化 分布式缓存 高效能压缩 负载均衡管理 数据加载规则管理 数据加载任务管理 数据加载监控管理 二次开发接口 对外接口 JDBC 、 ODBC 、 WebService 、 RESTful … 数据库管理 数据库配置管理工具 数据库监控管理工具 数据库备份恢复工具 数据库任务管理工具 分布式文件系统 DFS DFS DFS 连接池管理 权限管理 线程管理

20 .OCNoSql 数据库 —— 话单存储 OCNosql 数据库类似于行列混合模式 ，针对详单查询业务场景，它把行、列存储的优势都发挥了出来，通过 RowKey 可迅速定位到行记录，同时其对应的列可随时进行扩展 , 通过该方式，压缩率可保证在 10:1 以上，同时大大降低了系统 I/O 。 采用 该方式 提供详单查询服务 ： 入库时无需先排序，详单文件 通过 MapReduce 并行计算框架可以高效的直接 加载到 分布式 数据库中 ； 详单数据 入库采用 天 建表策略 ，通过时间和手机号码两个维度迅速定位到数据文件。 入库时，针对详单文件的特点，提供数据级别的压缩功能，对于详单中重复字段较多的场景，实现高压缩比

21 .新详单查询系统 —— 功能列表 新详单查询系统完全继承原有 CRM 侧详单查询接口： 实时详单查询 历史详单查询 大数据详单查询 新详单查询系统同时支持集团类详单的批量导出文件功能，包括： PBX 详单 企业信息机详单 集团 400 业务详单 新详单查询系统同时支持计费侧重批话单的导入和查询 对于重批话单，对其的导入完全等同于普通话单 通过在查询服务模块中的查重功能，实现对旧话单的过滤。

22 .新详单查询系统 — — 维护功能 入库任务编排调度管理模块： 入库任务调度频度、启动参数配置； 任务流程可视化编排； 任务流程调度引擎； 任务流程监控管理。 错单处理模块： 支持重批话单的导入 。 数据生命周期管理模块： 数据生命周期检查规则配置； 数据生命周期检查频度配置； 历史数据删除。 维护类工具模块： 分布式文件系统备份分布细则监控； 集群运行情况监控； 人工删除、补录； 维护类查询。

23 .大数据量详单内存数据库 架构优化一：引入缓存处理，提高大数据量查询效率 目前状况： 分布式改造后： CRM … 查询代理 查询请求 Hadoop 分布式详单数据库 查询结果 汇总 查询直接返回 查询分页返回 … 分布式缓存 自动索引 分布式存储 详单查询接口服务 缓存技术 分页缓存 单次查询 3000 条以上记录，经常出现查询失败，查询返回时间长。 单次大数据量查询，影响同时请求的小数据量查询。 基于文件系统的查询，磁盘 IO 成为系统瓶颈，缺少缓存技术配合。 文件生成 分布式技术改造后： 底层采用分布式数据库技术，引入分布式缓存，通过缓存命中率，提高查询效率。 大数据查询时，采用分页返回策略，未返回的分页数据在内存数据库中缓存。 CRM 需要做分页显示的改造，显示下一页需要通过从接口详单查询系统分页缓存中取结果

24 .架构优化二：解耦应用，避免故障影响扩大 目前状况： 分布式改造后： 实时详单查询请求 查询内存详单 详单导入 共享内存 查询文件详单 详单文件 IPC 详单查询流程从内存和文件中获取数据，组合生成详单查询数据 为了获取导入进程内存中的详单数据，详单查询服务通过共享内存方式获取内存数据；当导入应用出现故障时，共享内存信号无返回，造成查询失败 中间文件 加 载 导入 分布式数据库 详单查询 采用分布式数据库后，无需再使用共享内存的方式进行详单查询，导入服务和详单查询彻底分离开。 因此无论导入服务是否出现故障，查询流程将直接读取分布式数据库中的详单数据，再不会出现查询失败问题。

25 .架构优化三：分布式架构让系统无需集中部署 目前状况： 详单查询、预处理，导入应用部署在同一台主机上，应用之间相互影响较大 分布式改造后： 详单查询系统通过采用分布式数据库后进行分布式部署，通过该部署方式，让应用之间实现性能隔离，不会互相影响。 Server1 NoSQL Master Server2 NoSQL RegionServer Server3 NoSQL RegionServer ServerN NoSQL RegionServer … 分布式数据库集群：

26 .架构优化四：增强系统高可用保障能力及高可扩展性 详单处理应用按业务和号段划分，各进程之间独立运行，无高可用保障措施。 查询服务量过大时，缺乏过载保护机制。 目前状况： 分布式改造后： 详单查询采用分布式数据库： 通过 2 份以上的副本与自动同步机制来保证数据的高可用性，实现自动容灾； 其分布式架构可满足更高的吞吐量需求； 自动索引及分布式缓存机制保障了详单查询服务的高性能； 在查询服务性能遇到瓶颈时，可通过横向扩展迅速提高服务质量。

27 .网厅、自助终端、 …… 详单 查 询服务 流量控制 CRM 查询服务 详单查询队列 流量控制模块作为详单查询服务的管理模块，用于控制服务调用； 对于超出队列阀值的调用，返回失败消息。 HTTP socket 内部调用 架构优化五：服务流量控制 数据节点 1 数据节点 2 … 数据节点 n 主控 节点 Hadoop 集群 为了避免通过频繁调用进行的恶意攻击，对于不同渠道、不同系统的接口进行流量分配，对各渠道的单位时间调用次数和调用频率进行限制，超过调用阀值进行告警，超过上限则采取过载保护，进行错误返回。

28 .架构优化六：加强详单处理数据稽核 话单导入 话单预处理 Hadoop 用户 计费系统 查询服务 历史详单 实时详单 详单查询系统 日志记录 在 话单处理 各个 环节会对每个处理的话单记录相应的日志 记录， 包括文件名、大小、开始结束时间、成功数、失败数、耗时 。 稽核报警 当出现文件名错误，文件大小错误，记录总数错误，文件加载失败，查询失败等，会向管理平台告警。 稽核点

29 .架构优化七（一）：解决文件存储问题 目前状况： 文件系统划分过于庞大，严重影响整体系统的稳定性和读写效率 分布式改造后： TB TB TB TB TB TB TB TB PB 。。。 。。。 系统可直接在多台 x86 化 PC Server 与刀片机的本地存储及原有磁盘阵列上共同部署一套分布式文件系统来存放数据文件，支持 PB 级别存储容量，因此不会再出现文件系统划分过于庞大的问题 高效的压缩机制节省了更多的存储空间，对于详单这类列重复度较高的数据具有极高的压缩比，压缩状态不影响数据读写性能，在启动高级压缩后，可以到 1:10 左右的综合压缩比 数据库容量与性能支持在线的弹性扩展，为系统后期扩容工作奠定了坚实的基础