一、应用案例背景

        随着企业数据量的迅速增长和业务需求的不断演变，传统的数据仓库技术面临性能瓶颈和扩展性限制。为了应对这些挑战，企业启动了梧桐数据库迁移项目，旨在使梧桐数据库助力现网业务蓬勃发展，并评估梧桐数据库的性能、扩展性、兼容性和总体拥有成本。

        当前资产中心现网环境有4个oracle集群，支撑含日报、快报等B域大部分业务，资产中心数仓当前存在业务支撑方面存在性能瓶颈（过亿级表、多表关联时延达小时级）、硬件扩容困难（不支持按需扩展存算资源、不支持在线扩容）、集群间数据共享低效（集群间数据拷贝、dblink传输效率低）、以及产品建设成本高、非自主可控等问题。

        从数仓技术架构演进和实现降本增效的需求出发，故开展本次“梧桐”国产数仓产品，验证的目的是通过B域内的典型应用场景（资产中心）验证该产品能否支撑实际生产业务开展，同时与现有资产中心在用数据库的使用进行对比，为数据库选型提供依据。

注：当前资产中心业务一小时并发峰值存过达到300个，相对于标签生成客户群业务、位置实时处理业务，资产中心业务的作业并发度、任务数、单个作业处理逻辑复杂度（多表关联处理）更高，能够充分检验数据库系统能力。

二、应用案例目标

• 解决现网性能瓶颈。
• 节约硬件成本。
• 提升整体生态扩、缩容的在线处理能力，降低对生产使用的影响。
• 提升集群间数据共享效益。

三、应用案例实施步骤

3.1环境搭建与数据迁移：在指定的硬件环境中部署梧桐数据库，并配置所需的网络和存储资源。

总体规模：梧桐数据库本期规划36节点，其中计算 节点23台, 存储节点 4台，管理节点9台。

计算节点：计算节点主要承载大量的数据计算任务， 包括业务汇总、关联计算，属于高CPU、高内存业务处理，规划优先选用C3型主机。

管理节点：管理节点主要用作数据库会话的连接和 元数据的存储，不进行大量的计算任务，所以采用 B1性主机。

存储节点：主要用于存储数据，由于联创数据库采 用分布式共享存储架构，所以采用大存储，低计算 B2型主机。

注：因资源池暂时只有B2服务器，当前集群全部基于B2服务器搭建，后期资源池资源充足，可将计算节点换成C3或者B1服务器。

3.2 功能验证：对梧桐数据库的基础功能进行测试，包括数据查询、数据更新、事务处理等。

1、函数支持

• 支持窗口函数、复杂函数等常用函数；
• 支持自定义函数，可以在数据库直接创建，不需要java或者C编译；
• 兼容常用测试sql。

2、分区支持

• 在国产数仓中存储Oracle抽取过来的多个分区的数据，能够满足对所有分区的查询性能不降低。

3、易用性支持

• 图形化客户端；
• 如PL/SQL一样，方便开发人员使用。

4、锁机制

• Oracle为行级锁，不同分区并发不会产生锁等待，验证国产数仓对同一个表执行多个sql是否支持分区锁。

3.3 性能测试：模拟实际业务场景，对梧桐数据库进行压力测试和性能评估。

1、数据抽取

• 测试场景：测试国产数仓的数据抽取效率，并与Oracle做对比；
• 数据量：万级、百万级、千万级、亿级、十亿级。

2、数据加载

• 测试场景：测试国产数仓的数据加载效率，并与Oracle做对比；
• 数据量：万级、百万级、千万级、亿级、十亿级。

3、数据处理

• 测试场景：测试区分数据转换、单表汇总、两表关联、三表关联等不同场景下国产数仓的数据处理效率，并与Oracle做对比；
• 数据量：万级、十万级、百万级、千万级、亿级、十亿级。
• 注：由于Oracle对百亿数据量无法支持，故此量级不做比对。

4、实时写入

• 测试场景：通过Flink将数据实时写入国产数仓，记录执行时间，观察CPU/IO等资源消耗，并和Ignite进行对比；
• 数据量：千万级、亿级、十亿级、百亿。
• 注：由于Oracle对百亿数据量无法支持，故此量级不做比对；从位置中心实时抽取数据至Ignite支撑网格通业务。

5、实时读取

测试场景：实时读取数据，验证连接数使用（N多并发是否会把连接数占满），单表、多表关联等场景数据读取效率，并和Starrocks进行对比；

• 数据量：千万级、亿级、十亿级、百亿。

注：从话单、位置集群实时抽取数据至Starrocks，支撑行程码明细归集查询。

6、批量业务场景

• 测试场景：进行生产实际运行业务的批量验证；
• 作业量：本次进行典型存过的验证，并确保任务定周期运行。

3.4 扩展性测试：验证梧桐数据库的存储和计算资源能否按需进行扩展。

• 存储资源、计算资源分别扩容的情况下，是否需要停机操作，对已部署流程执行效率的影响；

四、应用案例成果

• 梧桐数据库在处理大规模数据集时表现出良好的性能，响应速度快，满足业务需求。
• 存算分离架构有效提升了系统的扩展性和资源利用效率。
• 数据迁移过程顺利，数据完整性和一致性得到保障。

五、应用案例结论

结论一 ：经验证，梧桐数据库在功能特性方面满足使用需求，对比Oracle在性能、拓展性、架构等方面具备更优的特性，但在实时入库能力、复杂函数兼容性、易用性等方面存在优化空间。

结论二：基于Gbase现场使用反馈，梧桐数据库功能架构更优，迁移改造工作量对比GBase8a数据库手工改造有所降低。

结论三：满足存算分离使用场景，极大提升在线扩容能力，解决性能瓶颈问题。

结论四：节点数越多，节约成本越多，本次降低硬件成本30%。

注：本次验证因B1、B3服务器资源有限，无法部署Gbase数据库。

六、后续建议

• 基于试点验证的结果，建议在更多业务场景中推广梧桐数据库的应用。
• 继续与梧桐数据库团队合作，针对发现的问题进行优化和改进。
• 定期评估梧桐数据库的版本更新，确保系统功能与业务需求保持同步。