一、现状及需求痛点
当前地市统一支撑平台是为地市租户提供全方位业务支持的核心系统，以满足地市级用户在业务处理、数据分析、用户服务及内部管理等多方面的需求。主要承载业务系统的联机事务处理（OLTP）与联机分析处理（OLAP）两类数据处理需求。
1.2 平台现状概述
1）集群资源概况：
当前平台由Oracle RAC集群组成，一体设备共计17个节点，x86设备工具24个节点，集群资源使用情况如下：
2）集群业务承载：
联机事务处理（OLTP）：支撑地市日常运行及工作流程管理，平台支撑多类业务系统，有大量的在线事务操作。这些事务通常具有短小、快速的特点，对响应时间和并发事务能力有较高要求。
根据反馈的调研信息，四个地市用户规模总计为80万，并发峰值28000。全网业务总量按照已调研规模的2.5倍预估，全部用户规模可达200万，并发峰值7万。
联机分析处理（OLAP）：平台还作为经营分析和报表加工等支撑平台，以支持指标计算、决策辅助和数据上报等需求。这些场景多为离线处理和在线查询等业务，具备大数据量和低延时的需求特点，对海量数据下复杂计算和并发查询能力有较高要求。
根据反馈的调研信息，四个地市租户批处理作业规模8500个左右，数据增量0.8TB/天。全网业务总量按照已调研规模的2.5倍预估，全部租户调度作业可达2万个，查询并发用户数约2000，增量数据2TB/天，数据超过生命周期后会定期删除，数据年增量约30TB/年。
1.3 平台痛点问题
Ø 资源抢占问题
1）多个地市租户共享同一个集群，租户之间存在资源抢占现象，作业需要排队执行，批处理时间长业务受阻。
2）联机分析处理（OLAP）与联机事务处理（OLTP）业务运行于同一个集群，批处理时间跨度大（0点-24点），白天业务峰值时对资源占用比重高，影响OLTP业务应用。
Ø 非自主可控问题
1）目前集群为国外品牌产品Oracle，不符合自主可控和自主创新能力要求，存在安全隐患和license风险。
二、技术方案规划
2.1 平台建设目标
本项目从平台演进和业务支撑需求出发，对地市统一支撑平台进行架构规划，以期适应主流的技术趋势和长期业务发展需要。
平台建设需要满足如下目标：
1.基于自主可控数据库技术实现平台架构升，建议选用中国移动自研产品或国内自主可控产品。
2.围绕业务使用核心功能需求，新建平台能够支撑Oracle数据库迁移以及应用生态适配。
3.建设地市租户资源隔离能力，实现租户间计算负载有效隔离，数据高效共享，业务运行互不干扰。
4.具备高安全性和权限管控机制，可对关键数据进行脱敏、加密以及权限配置。
5.平台具备高性能处理能力，可满足在线并发事务处理和海量数据低延时处理分析。
6.平台具备高可用性和高扩展性，满足业务增长需求。
2.3 技术选型分析
当前地市统一支撑平台由Oracle数据库支撑，可满足业务系统的联机事务处理（OLTP）与联机分析处理（OLAP）两类数据处理需求。从业务时效性角度看，场景分布如下：
因此平台数据库技术选型考虑两种方式选择对比：
1.基于HTAP数据库构建混合负载支撑平台
混合事务与分析处理（Hybrid Transactional Analytical Processing, HTAP）技术是一种基于一站式架构同时处理事务请求与查询分析请求的技术。HTAP技术不仅消除了从关系型事务数据库到数据仓库的数据抽取、转换和加载过程,还支持实时地分析最新事务数据。然而,为了同时处理OLTP与OLAP，HTAP系统也需要在系统性能与数据分析新鲜度之间做出取舍，这主要是因为高并发、短时延的OLTP与带宽密集型、高时延的OLAP访问模式不同且互相干扰。目前主流的HTAP数据库主要以行列共存的方式来支持混合事务与分析处理，但由于此类数据库面向不同的业务场景，所以它们的存储架构与处理技术各有不同。
图---传统OLTP/OLAP分离架构与一站式HTAP架构对比
图---HTAP数据库的四类存储架构图
图---HTAP数据库的四类存储架构对比
分析结论：经技术分析和市场应用调研，HTAP数据库通常在TP 和AP领域各有侧重，还无法做到同时支持TP +完全的AP场景**，目前HTAP数据库主要用于交易处理和实时查询混合负载的场景，无法高效满足离线批处理，尤其是涉及超大规模数据复杂多表关联场景，目前还是大数据平台和MPP类数据库来支撑。针对地市统一支撑平台应用场景涉及联机事务处理、实时查询和离线批处理三类典型场景，单一的HTAP数据库难以高效满足这三种场景的混合负载。对此建议在平台设计上可将非实时的海量、复杂、多维度数据加工场景，即重型批量处理操作放到MPP类、AP类或者大数据平台实施；而对联机高并发、有实时聚合分析和轻量批量加工的场景则用HTAP来支撑。
2.基于OLTP库+OLAP库构建混合负载支撑平台
事务型数据库主要用于OLTP场景，在数据库国产化的大趋势下，涌现出很多优秀的国产品牌事务性数据库产品，如OceanBase、TiDB、GaussDB等。因此可基于移动生态内成熟稳定的国产品牌的事务型数据库支撑地市统一支撑平台建设需求。
Hadoop大数据平台和MPP数据库主要用于OLAP场景，目前移动体系内部已规模化应用。考虑到地市平台建设需要满足Oracle数据库迁移需求，建议选用MPP数据库类产品搭建非事务型场景下的数据处理和计算业务支撑。
***分析结论：OLTP+OLAP混搭的架构是目前数据平台建设主流成熟的架构体系，***现网很多业务支撑平台也延续该架构在运行，尤其是核心系统或规模化系统，OLTP和OLAP都是独立系统支撑。因此可基于移动生态内成熟稳定的国产品牌的事务型数据库+MPP类分析型数据库混合架构支撑地市统一支撑平台建设需求。
图---技术路线业务支撑对比
2.3 产品选型建议
OLTP数据库选型建议：
OceanBase 数据库是一款完全自研的国产企业级原生分布式数据库，具有云原生、强一致性、高度兼容 Oracle/MySQL等特性。自2010年开始完全自主研发，代码级可控，自研单机分布式一体化架构，连续多年通过大规模金融核心场景的可靠性验证；完备的角色权限管理体系，数据存储和通信全链路透明加密，支持国密算法，通过等保三级专项合规检测。建议选择该款数据库支撑事务型业务处理。
OLAP数据库选型建议：
当前在移动产品生态体系中，有两款OLAP数据库可供选型：
Gbase 8a：南大通用公司产品，基于列存储的完全并行的MPP+Shared Nothing的架构，采用多活管理节点（Master）、数据（计算）节点的两级部署结构，所有节点无共享，具有对等计算能力。功能、性能、安全性、稳定性符合建设要求，有大规模应用先例。
梧桐云原生数据库：中国移动自有品牌产品***，存算分离架构的***云原生数据库，采用多活管理节点（Master）、无状态计算节点、分布式存储节点的三级部署结构，原生支持Hadoop和云生态，具备弹性计算能力，可超大规模部署。功能、性能、安全性、稳定性符合建设要求，架构上相对MPP数据库更符合技术演进趋势，目前集团公司正全网推广该产品规模化应用。
图---Gbase 8a与梧桐数据库的技术对比
产品选型场景对比：
2.4 平台架构规划
三、问题和风险
1.当前架构下除了新增数据库软件订购成本，还存在业务迁移、调度工具建设、CDC采集同步工具建设成本和方案选型。
2.本地化部署目前梧桐数据库省内自采尚未有明确的政策落地和明确价格。
3.如果基于边缘节点资源池部署，按照以往项目经验，前期申请机器等环境准备预期至少2个月，建议省内自搭环境部署。
4.当前尚未明确迁移开发工作由谁承担，相关工作成本无法评估。
四、结论及建议
根据业务需求和以上分析过程，建议本次地市统一支撑平台采用独立OLTP+OLAP数据库的建设方案，一方面可以满足迁移Oracle数据库实现国产化替代的需求，另一方面该架构是目前企业数据中心中型以上系统的主流架构，性能和资源隔离可以得到保障，符合本期和远期的使用规划。