
业务需求
为缓解原数据集群的压力,提高支持决策部门的业务数据报表生成效率,该厂商将核心业务数据从庞大繁杂的数据库集群当中抽离出来,组建了独立的企业大数据平台,用于汇聚企业各个数字化平台所产生的核心数据以支持决策分析。目前,平台接入了企业内部在各地区的数字化报表、研发数据、质量控制、审计信息、工厂信息、人脸识别与人员权限、客户档案管理、运输管理、业务流程管控、售后等核心业务及产研系统,并为各类报表生成提供统一接口,该大数据平台已经成为企业内部经营管理信息获取的最重要的系统之一。
近年来,随着业务的扩张,不断有新业务被迁移到系统当中,数据体量和并发数不断增多,且时刻有大量的核心数据输入,这对数据库的写入和查询性能提出了更高的要求;而原有 Greenplum 集群性能有限,随着数据和业务的增长,原有数据查询时的执行明显变慢,甚至有偶发的报表无法查看的情况,已经严重影响到企业的正常运营。
因此,该企业亟需将原大数据平台升级,将 Greenplum 更换为性能更高的数据库产品,从而提高生成各类数据报表的效率,更好的为决策层提供实时的数据支撑。除此之外,企业希望在更换数据库提高性能表现的同时,尽可能避免过大的系统改动和重构,从而降低数据库迁移所带来的业务影响。因此,另一大需求是沿用原有技术栈和应用,减少下层数据入库和上层应用的逻辑改动,实现业务侧和技术侧的平稳过渡。

数据库选型

核心业务数据的迁移过程

首先,将生产环境中的数据进行备份,梳理出详细的 DDL 脚本并实现脚本化,做好应急预案,确保迁移失败时可快速还原,提前应对数据库迁移对业务所带来的风险;
其次,准备好目标集群的软件环境,如安装 YMatrix 数据库,安装 Grafana 等必备监控软件等;
同时,做好和业务的实施前沟通,规范迁移期间的注意事项,避免在迁移实施期间业务侧执行任何 DDL,包括创建对象、修改对象、添加字段、删除字段等操作,严格禁止执行 CREATE、ALTER、TRUNCATE、DROP 动作;
随后,根据既定方案,将库中原有的两张大表改变两张 3 个月周期的分区表并进行核对,再将表中数据全量同步到数据湖集群上进行备份;
最后,停止全部在平台上所运行的非关键业务。
2. 执行迁移
迁移过程中,最新开发的数据迁移工具 MatrixShift 发挥了重要作用。
在迁移完成后,修改 YMatrix 集群端口,确保与原 Greenplum 的端口一致以保障原有应用无缝切换,接着恢复业务访问并观察业务运行情况。持续跟踪 30 分钟,确认数据库日志和业务侧均无异常,逐步恢复数据写入业务,并持续跟踪数小时,确保数据库的稳定运行,最终完成将该大数据平台的核心数据由 Greenplum 到 YMatrix 的迁移任务。

最终收益
1. 打造以 YMatrix 为核心的业务集群

2. 无感扩容
3. 性能优越

总结
一条有爱的分割线
感谢你的阅读,YMatrix 期待与志同道合的你一起同行。








