BI主仓MPP分布式数据库迁移改造实战分享

发布时间：2021-01-11 08:03 所属栏目：[大数据] 来源：网络整理

导读：点击上方蓝色字体关注我们汤人杰 ? ? ? ? ? 资深大数据架构师骆似骏 ? ? ? ? ? 项目经理刘刚 ? ? ? ? ? ? ?大数据工程师徐彬馨 ? ? ? ? ? 大数据工程师刘文兵 ? ? ? ? ? 大数据工程师一、背景分析 DB2作为IBM公司开发的一套关系型数据库管理系统，被

点击上方蓝色字体关注我们

汤人杰 ? ? ? ? ? 资深大数据架构师

骆似骏 ? ? ? ? ? 项目经理

刘刚 ? ? ? ? ? ? ?大数据工程师

徐彬馨 ? ? ? ? ? 大数据工程师

刘文兵 ? ? ? ? ? 大数据工程师

一、背景分析

DB2作为IBM公司开发的一套关系型数据库管理系统，被广泛应用于大型数据仓库项目中。浙江移动自2003年构建经营分析系统以来，采用DB2数据库搭建BI主仓达10多年之久，聚焦于B域数据分析，支撑内部管理决策、营销推广和客户服务等工作。

大数据在带来全新商业模式和业务增长的同时，给IT支撑工作提出了更高的挑战，对现有技术架构体系也提出了全新的要求，其中自然包括数据仓库支撑能力。在业务需求快速变化的今天，传统数据库软件显得捉襟见肘，存在较多的不足，主要包括：

（一）技术支撑较为薄弱，响应较慢

DB2 作为IBM成熟的商业软件，不仅所需的硬件设备售价格高，而且原厂的维保费用也很高，很多疑难问题的定位，都要中转反馈到IBM美国总部工程师处解决，响应及时性得不到保障，影响工作的正常运行。

（二）扩展性不足，无法支持平滑扩展

但传统DB2扩容只能Scale-up(纵向扩展)，以增加处理器、高端存储容量等资源进行升级以获得对应用性能的要求，但是更大更强的服务器同时也是昂贵的，扩容完还需要进行数据的balance操作，甚至需要进行停库操作，直接会对生产造成影响。

（三）产品高可用性较差

数据库配置文件及逻辑节点的元数据有1份副本，但系统默认在同一目录，且不可更改，不可再备份，其安全性非常低。

（四）?软硬件投资成本高

DB2的主机需要用IBM的小机，存储用的是EMC的裸设备，这些设备的价格动辄数百万；同时DB2软件的lisence也非常昂贵。而在人员的开支上， DB2数据库管理员的价格远远高于其他数据库管理员。

因此，如何引入大数据新技术来满足当前业务的需求，如何克服新技术障碍、人员储备不足等问题，是三墩IT人必须尽快克服的重要挑战。

二、方案选型

综上，考虑到分布式数据库支持基于X86的部署方式，而X86大量取代传统小机已经成为趋势，具有成本低、扩展性好等优势，传统数据库依赖小机升级的扩容模式走到了尽头等原因，决定引入分布式数据库取代现有DB2数据库。在核心数据仓库完成数据建模，之后同步到数据分析集市，同时数据分析集市作为大数据集市承载目前所有的基于数据库标准SQL开发的应用。

经过详细的选型分析，最终选择GBase 8a MPP Cluster作为本次目标产品，选型的详细分析这里略过，有兴趣的可以线下联系。

三、建设方案

2015年10月，正式启动经分系统DB2数据库往目标分布式数据库的迁移工作，整体工作分成环境部署、应用迁移和系统优化三个阶段。

环境部署

在容灾方面，同城异地的主备两个数据库集群间以表为单元进行增量同步，数据的同步过程基于Rsync数据同步工具实现。

在备份方面，该产品提供专用的备份恢复工具，可以方便地对整个集群中的数据实现全量、增量、热备、冷备等各种形式的备份。支持数据并行备份和并行恢复，备份文件可以分布在不同的备份存储领域上，并可以按照安全组单位，配置不同数量的备份恢复节点。

此次环境部署主要解决如下几个问题：数据库与操作系统兼容性、X86服务器本地存储高效使用、数据库数据安全问题、装载节点高效数据处理等。

为解决如上问题我们设计平台架构如下：

（1）功能架构

MPP资源池集群建设，主要分为两个独立的MPP数据库建设，分别是核心数据仓库和数据集市。

BI主仓MPP分布式数据库迁移改造实战分享

（2）平台架构

集群共xx节点，每个安全组3个节点，即每组做3份冗余数据，每个安全组成员均部署在不同机架中；批量数据交换节点由xx台服务器组成，主要实现从云化ETL平台加载或导出数据。

BI主仓MPP分布式数据库迁移改造实战分享

每台计算节点操作系统盘由2块盘做raid1实现热备，数据盘由21块600GB盘组成，每7块做1组Raid5,3组Raid5再做Raid0合成1个数据盘，提高存储读写性能，并兼顾数据安全性。

采用万兆业务网络、千兆管理网络，计算节点采用2万兆绑定网络，解决批量数据处理可能存在的网络瓶颈问题。

BI主仓MPP分布式数据库迁移改造实战分享

应用迁移

为了减少省经与一经的相互影响，实现一经与省经解耦，把现有DB2上除一经外的仓库模型、片区化应用、手机经分等省经应用全部迁移到MPP平台上。

本次迁移改造采取按应用逐步实施的策略，遵循如下步骤：

（1）把DB2上执行程序代码直接搬迁到MPP上执行，根据错误调整相应的语法，通过批量调整的模式，保证所有程序能正常执行。

（2）导入数据源后运行程序，将MPP上的结果数据与DB2进行比对，发现差异数据后找到问题并解决，确保两边数据一致。

（3）优化程序（如小表建复制表，大表分区键是否合理）并保证生成数据的时间不晚于DB2生成的时间。

（4）在程序稳定运行半个月后，切换对外接口数据源，最终实现平稳迁移。

系统优化

随着省经业务应用逐步往GBASE上迁移上线，业务数据量出现了超预期的增长，出现了性能下降和容量不足等情况，经过整理，共两大类计10个问题。

（1）装载问题，包括：装载机网络不稳定、装载效率低、稳定性差、装载超时、装载数据质量问题，以及装载文件字段与表结构不一致等问题；

（2）性能问题，包括：数据库运行一段时间后出现性能下降、查询插入语句执行效率慢、垃圾SQL耗尽数据库临时空间、建表不合理、大量失效视图和过期表未及时清理等问题。

上述问题既有平台侧问题，也有业务侧（SQL质量和开发规范）问题，为此，三墩IT人从系统参数、数据库源码级、应用层等方面对系统进行了专项优化。

（1）系统参数优化

网络优化4项：升级网卡驱动，修改网卡模式，调整交换机哈希算法完成数据流量的负载均衡，调整TCP相关内核参数，增大内核套接字接收缓存区的大小。改进后网卡流量可稳定2万兆运行，网卡效率与稳定性出现显著提升，丢包和重传现象基本消失。

数据库优化9项：优化控制文件参数、优化加载并行度、增加预读缓存、优化CPU线程数量、增大装载服务端与客户端之间的通信延时参数、优化装载超时参数，装载失败率由30%左右下降到低于0.5%；优化insert控制参数，相同SQL的执行时间由60s左右提升到22s，性能提升64%；优化数据库内存参数，提高了系统稳定性。

（2）数据库源码级算法优化

SQL的哈希拆分、压缩和发送算法优化：原有的SQL在处理多表关联过程时，对哈希分布不合理的表需要建临时表，进行哈希重分布处理，期间每个节点执行SQL的哈希拆分、压缩和发送过程均为串行，如此耗时较多；在进行算法优化后，实现了该过程的并行处理，从而提升处理效率，降低耗时，最终提高SQL执行性能。

BI主仓MPP分布式数据库迁移改造实战分享

会话释放锁资源算法优化：集群各节点在做完节点间数据传输后，将会话链接断开，此时需要释放当前会话打开的相关表锁。之前版本采用遍历链表的方式查找并释放表锁，当集群中打开表逐渐增多时，此方法耗时增长，表现为SQL执行性能下降。新版本优化了会话链接断开的逻辑，可直接关闭已打开的表锁，使该操作的耗时大大降低，外部表现SQL执行性能明显提升。

BI主仓MPP分布式数据库迁移改造实战分享

（3）业务层优化

因平台应用开发人员对新产品不够熟悉，部分SQL质量较差（如没加nolock，hash键选取不合理、复制或分布表属性选择不合理等）、执行性能差（多余子查询、笛卡尔积、关联字段不合理），对这些问题分别进行了调整优化。

与此同时，还进行了产品培训及使用指导，发布并持续更新多版MPP数据库开发规范，帮助应用开发者更好地使用MPP平台。目前99%以上的SQL运行正常，个别SQL耗时较长的及新开发的SQL还需要继续针对性优化。

四、经验总结

经过200多个日日夜夜的奋斗，本次项目取得了圆满的成功。在大量技术难题面前，三墩IT人勇于实践、敢于踩坑、善于总结，征服了前进道路上一座又一座的大山，最终将国产MPP数据库应用于BI主库建设。这一实践成果在集团内部乃至国内其他行业来看，都属于比较领先的。

引入MPP之后，在数据库软硬件投资方面，为公司节约了的成本相当可观。升级到MPP后，存储容量增加1倍，相当于传统小机+存储架构的1.7倍的能力，仅这一项节约投资xxxx万。

此外，通过本次项目的实践，我们锤炼了一批技术人员，积累了宝贵的大数据技术实战经验，实现了核心能力的自我掌控。在国产数据库的应用上，以一丝不苟的精神追求系统不断优化，最终大幅的提升了MPP数据库集群的性能和稳定性，实现了大数据平台的“去IOE”。

MPP技术也在不断升级更新中，后续新版本可支持多管理节点的联邦架构，能够支持300+节点的集群规模。我们期待新的技术演进。

BI主仓MPP分布式数据库迁移改造实战分享

【免责声明】本站内容转载自互联网，其相关言论仅代表作者个人观点绝非权威，不代表本站立场。如您发现内容存在版权问题，请提交相关链接至邮箱：bqsm@foxmail.com，我们将及时予以处理。