上海移动CRM历史库去”O”经验分享

原作者：亚信姜明俊(2018.5)

项目概况

为真正推进数据库去“O”工作，自2016年开始，上海移动开始考察、比对和测试各类分布式数据库，计划选择一个容量大、访问量高、影响可控的Oracle数据库割接替换为分布式数据库，重点考察分布式数据库的分布式查询处理、海量数据访问、在线水平扩展性、自动故障恢复等特性，积累分布式数据库实施和运维经验，验证去“O”难度，为后续CRM库、BOSS库等主库去“O”探路。

鉴于现网CRM数据库存储压力大亟需瘦身的需求，最终选择了历史库进行试点，2017年上海移动正式启动CRM库瘦身&历史库去“O”试点项目，改造前上海移动历史库存储了自2002年以来所有的3个月以前的用户操作记录、订单记录、账单等数据，存储了海量数据，同时数据访问量巨大，本次CRM库瘦身&历史库去“O”试点项目，除了将ORACLE历史库割接为X86架构的分布式数据库，还需将CRM库自2013年1月上线以来，所有的失效的订购实例数据搬迁到历史库上，以达到现网CRM库瘦身的目标，进一步增加了数据库的数据量和访问量。

方案选择

“原生分布式数据库”VS“数据库分库分表+分布式中间件”。分布式数据库目前处于快速发展中，各大一线互联网厂商内部多开发了适用于自身业务特色的方案，但关键模块均未对外开源。分库分表+中间件的方案和原生分布式数据库都可以达到分布式处理的效果。亚信AntDB与腾讯的PGXZ（未开源）数据库均基于PGXC开源的原生分布式数据库方案，PGXZ目前已全面支持微信电商业务。亚信AntDB在PGXC的基础上进行了大量稳定性优化并增加了Oracle语法支持、并行查询、在线扩展，以及大量自动化运维功能。

AntDB是亚信中台CRM与平台数据库团队在理论和实践相结合的基础上深耕多年打造的一款产品。AntDB的理念是做一个可扩展、多租户、高可用、高性能、低成本且对业务透明的原生分布式数据库。为达到这些目标，AntDB分布式数据库基于PostgreSQL进行了组件化改造，组件包括Coordinator、DataNode、GTM、MGR Server和MGR Client组成。GTM负责分布式事务管理，DataNode负责实际存储数据，Coordinator负责对数据进行分发、聚合等操作，Coordinator本身不负责保存业务数据。Coordinator通过将分布Key上值进行Hash路由到各个DataNode（子集群）上。GTM与DataNode都可以分为Master节点与Slave节点，通过Master与Slave主备复制，提供高可用和读写分离。集群的软件分发、安装、配置和运行监控由MGR Client和MGR Server共同完成，MGR Server存储相应的配置信息，MGR Client安装在每个节点，接收MGR Server请求，完成实际的安装、配置与监控。MGR Client通过多次确认监控到节点异常后，会通知MGR Server进行集群自动高可用切换，对上层应用透明。

图1：AntDB系统架构图

通过对比测试，发现AntDB对应用几乎零改造，所以最终确定使用AntDB作为上海移动历史库为去“O”试点改造的数据库。

表1：某开源知名产品 VS AntDB产品

方案实施

系统部署

上海移动AntDB历史库采用8台X86机器。使用一主两从的部署架构，数据被分到8个DataNode子集群，每个子集群包含一个Master和2个Slave，确保了数据库服务高可用、零丢失。 8个Coordinator对外提供数据访问。 GTM和MGR Server采用一主一备方式部署。

图2：AntDB分布式历史库部署图

迁移改造

一键化Oracle数据迁移工具，大幅降低割接难度。上海移动CRM库瘦身&历史库去“O”试点项目，需要完成当前Oracle历史库数据搬迁到AntDB历史库，同时还需完成现网CRM库失效实例数据搬迁至AntDB历史库。总共涉及7000张表，20T数据。若手工完成数据对象的创建，字段类型转换，分片规则的定义等等，工作量会非常的巨大。AntDB提供了数据迁移工具，实现了一键化数据从Oracle历史库到AntDB历史库的所有对象和数据的全部转换和抽取，抽取过程数据文件自动切片，利用管道技术对切片文件并行导入，导入过程数据自动分片，并支持过程跟踪，断点续抽，数据迁移完整性稽核。数据迁移过程无需人工干预，大大节约了DBA或交付工程师的工作量。100G的数据平均8-10分钟抽取完成。
高度支持Oracle语法，应用几乎“零”改造。目前上海移动历史数据查询，CRM侧的历史数据主要通过HisQuery服务查询，BOSS的历史账单数据通过帐管系统查询，本次历史库AntDB改造，主要改造数据库连接池，和数据库访问开关控制。涉及到数据库访问逻辑，几乎没有调整。数据访问相关的应用逻辑改造成本几乎为零

系统扩容

通过一致性Hash+Map算法，支持在线快速扩容。AntDB历史库初期只提供了4台x86服务器进行一主两从部署，但随着每晚平均50G数据量的导入，经过几个月的运行验证，4台机器无法满足应用需求。项目组进行了一次在线扩容，在线增加了4台机器。本次使用了AntDB提供的一致性Hash+Map算法实现在线扩容能力。2小时5分钟完成了从4节点到8节点的数据同步，路由切换仅用了18秒。也就是说，扩容过程对业务完全透明，只有18秒的针对新进连接请求业务阻塞感知。为确保业务不停以及数据一致性，AntDB的整个迁移过程采用移存量数据、迁移增量数据、数据检验、再追增量、切换路由、清理 六个步骤循环迭代进行

表2：上海移动CRM历史库在线扩容操作用时记录

数据备份

使用AntDB的Guardian对数据进行全量和增量备份存储在NFS上，结合AntDB创新的栅栏技术实现了上海移动AntDB历史库面对高并发场景下全局数据的事务强一致性备份和基于时间点（PITR）的恢复。 经过技术对比其他分布式数据库暂还无法提供类似功能。

AntDB提供的和Oracle数据库间的异步复制模式为上线初期AntDB和Oracle并行运行实现异构数据库的容灾提供了保障，在Oracle中又实现了一份完整的数据备份。

使用效果

目前AntDB历史库已经承载了原Oracle历史库的CRM过程数据和CRM库瘦身到历史库的失效实例数据，并且AntDB历史库已经代替Oracle历史库，完全承载了113个渠道的CRM历史数据访问服务。系统自上线以来运行平稳，未发生影响面较大的故障。

该项目使用了10台总价在80万元的x86服务器，使用AntDB分布式架构部署，承载了自2002年至3个月前的过程数据及1年前的失效实例数据，总计20T的数据，算上历史主库数据乘上2副本的冗余数据，一共60T的数据。数据库端并发连接在300个左右，平均每秒60个并发查询SQL，平均耗时40毫秒，CPU的使用率在10%-15%之间。用极低的成本达到了巨大的经济效益，和原Oracle需要运行在IOE架构上所要的投入相比，为客户节约了60%以上的成本。

图3：上海移动CRM历史库2017年4月13号大屏监控截图

图4：上海移动CRM历史库2017年4月13号大屏监控截图

红线为响应延时告警阀值，蓝色线为系统运行的业务总的毫秒响应时间，绿色柱状图为外部系统对历史库平台2分钟内总的调用量。2018年11月相比2017年4月份，业务调用量增长了近20倍，但响应延时依然毫秒级。

4月13号CRM三个渠道历史数据查询运行指标：

每分钟SQL执行量：

SQL执行平均耗时：

主机CPU使用率：

(4月13号06点到08点运行task任务进行数据搬迁和数据稽核操作(count(*))，此时三个渠道的业务量还未大量过来，所以图表显示这段时间整体调用量低，平均耗时却高些。)

经验总结

本次项目是初次使用分布式数据库，在割接上线正式使用的过程中,也因经验不足遇到了一些问题，积累了一些宝贵的实施经验，预估不足也导致了些问题，比如出现了CPU使用率和IO过高导致历史数据查询效率慢的问题。出现问题的主要原因如下：

• 分片键设置不合理，造成查询效率低，CPU使用率过高问题

在割接表的过程中，未对各表具体查询条件进行分析，使用了默认主键分片的模式，但是实际使用过程中，近70%的数据库访问走不是主键，而是其他索引，导致SQL执行过程无法根据分片键精准操作，而是全节点并发访问，造成主机CPU忙。

针对该问题，我们通过分析查询语句命中率，快速调整了分片键，保证绝大部分的查询能够走到分片键。同时AntDB还引入了索引辅助表，解决了分片键依赖问题，实现了走任何索引都可以精准查询数据。

• GTM(全局事务管理器)未单独部署，造成相互影响

GTM(全局事务管理器)是个耗CPU的组件(20%)，最初同某个数据节点部署在一台主机上，在访问量大的时候，相互影响，易出现木桶效应
针对该问题，我们及时对GTM进行了单独部署，调整后CPU使用率高的问题得到了明显的改善。

本次是上海移动和亚信科技公司在去IOE背景下的一次全新的尝试和合作。在国产自主，安全可控的大背景下积极响应国家号召开展的一次有效证明。通过本次的实施，为上海移动探索出了宝贵的去‘O’经验并验证了可行性。为后续在上海移动的核心业务系统上开展更加深入的合作奠定了坚实的基础。