分布式数据库在传统车联网厂商的应用实践 | OceanBase案例

本文作者：慧视通科技，梁君

传统车联网厂商运维百亿级数据的痛点与难点

深圳慧视通科技（简称慧视通）作为专业的位置数据综合运营服务提供商，一直深耕智能交通领域，依托车联网、云计算、大数据处理、无线通信和北斗/GPS全球定位技术为核心，为巡游、物流、网约出租车、两客一危、前装新能源、驾驶培训、汽车租赁、试乘试驾等行业，量身打造符合其实际需求的产品和解决方案。

慧视通的主要业务是以车联网为主体，比如大家经常乘坐的出租车、网约车等，很多都装载着慧视通的定位设备解决方案。那么，对于数量庞大的定位设备所产生的海量数据，我们后续又是如何进行处理及存储的呢？

当车辆通过终端定位设备产生相关数据时，数据会经过我们的慧视通云平台进行数据清洗、流转和分发，并通过微服务提供给各个子系统，例如慧视通车辆监控系统（SAAS平台），客服中心、大数据中心等，以及乘客、司机的终端和APP等。同时，数据会传输到政府的监管平台、运营中心、行业协会等。因此，对于如此复杂和庞大的业务会涉及数据处理和存储的各种难点和痛点。

1. 海量数据存取。作为车联网行业，业务数据爆发式增长，每天的增量数据上亿条，数据库处理峰值记录每秒上万次。面对业务数据量庞大、使用部门人员众多、数据分析统计需求多样的需求，数据处理和分析是一大难点。
2. 存储和运维成本。庞大的增量数据和上千亿的存量数据，使我们不得不重视存储成本与运维成本，因此，我们非常看重数据库解决方案的数据压缩率、存储空间占用等因素。
3. 数据的挖掘和分析能力。随着数据量的快速增长，挖掘和分析它的数据链路越来越长，有时候可能跑了几个小时甚至跑一天。对于数据挖掘能力及AP能力，我们需要选择一套系统同时支撑海量交易、海量分析，并且一份数据同时支持TP、AP负载的产品。
4. 国产信创要求。我们服务的客户对象基本以央企、国企或政府单位为主，近几年来国家要求国央企落实信息化系统升级，国产软件务求稳定，降低信息化风险，让升级的系统能够被业主单位真正接纳。面对几乎100%的升级率，我们需要选择一款完全自研、稳定、完全的国产数据库。

传统厂商转型国产分布式数据库的选型考虑

我们是一个传统的技术企业，整套系统都采用了微软的全家桶，其中数据库主要采用SQLServer，部分边缘业务采用其它数据库例如MySQL等。因此，我们替换数据库的成本要比其他企业高得多，而我们需要将迁移和改造成本降到最低，在选型时就会主要考虑以下三个因素。

第一，技术架构的先进性。比如支持云原生、分布式，具备高可扩展性、高稳定性和高性能等，能够满足大规模数据处理以及交易和分析的复杂业务需求。

第二，迁移和改造成本。确保新系统能够与现有系统和未来业务发展相匹配，能够降低迁移改造和未来升级扩展的难度。

第三、社区成熟。由于我们要选择一款具有成熟社区支持和被广泛应用的国产信创产品，确保顺利转型并快速掌握新产品的开发和维护技术，因此社区成熟度与活跃度是选型的重要指标之一。如果社区支持不够，那么在使用过程中遇到问题或知识盲点靠自己摸索解决方案是非常浪费时间的。

基于上述因素，我们考虑自研分布式中间件或替换为蚂蚁自研的原生分布式数据库OceanBase。

对比自研分布式中间件方案与OceanBase原生分布式方案

目前，自研分布式中间件方案的业务处理数据链路是：终端设备的海量数据传输到数据中心，通过一系列操作进行数据清洗、筛选后发送到位于深圳、哈尔滨、淄博的三个数据中心。每个数据中心都有很多实例，每个实例都以分库分表的形式存储数据。这些数据在经过汇聚聚合，形成最终用户使用的数据。

那目前这样的一个架构有什么优点和缺点呢？优点方面，自研分布式中间件方案属于完全自主研发，有一定的研发可控性，比较灵活，能够符合客户对软件著作权的要求。缺点方面，自研的复杂度高，根据慧视通云平台系统的研发经验，需历经多年分多阶段才能开发完善，自研分布式中间件的性能方面也不容忽视，并且如何保证高可用和数据一致性也是需要考虑的问题。

如果采用OceanBase原生分布式方案，就基本能避免以上问题，不存在研发难度和复杂度的问题了。OceanBase支持云原生，具有单机分布式一体化架构和HTAP能力，在产品特性和产品能力方面完全符合我们的选型要求。但我们也不得不考虑学习成本，比如多租户等新概念的引入，以及需要沉淀运维经验，才能确保数据安全、稳定运营、极端场景应急处理等。当然，这是引入新技术栈必然会面临的问题。

实践方案：原有代码以最低成本进行迁移改造

最终，我们选择了OceanBase作为我们数据库方案，经过实践验证后，我们总结了从SQLServer微软全家桶迁移到OceanBase的经验，希望可以帮到有相同业务需求的朋友。

首先，设计整体架构改造方案。需要评估替换底层数据库对业务及整体技术架构的影响，在时间成本、人力成本方面是否可接受。并进行代码梳理和分析，比较代码结构、评估改造代码量。我们原本以为SQLServer替换为OceanBase的改造成本很高，但经过梳理后，找到了低成本改造的解决方案。

其次，选择迁移工具和方案。目前市面上没有SQLServer相关代码、存储过程完美迁移到OceanBase的工具，因此，我们采用ORM将原来的存储过程、业务代码全部改造，进行存储过程代码化，这时业务层面既兼容SQLServer又兼容MySQL，还能兼容OceanBase。从业务持续可控的角度来讲，替换数据库不可能一键全部替换，需要慢慢过渡。我们采用ORM可以稳定实现过渡，同时能够将过去业务中大量的存储过程全部代码化。

最后，保留原有部分系统架构，由于迁移可能需要全面改造原来的系统架构和设计方案，这会导致非常长时间的改造而延误客户需求。因此，我们在设计时并没有将全部业务架构迁移，而是保留原来的部分技术和业务，为整体迁移的过程争取了一定的时间。假如客户两个月后就要上线一套技术可靠的系统，能不能提供出来？完全改造是改造不过来的，所以采用部分技术方案保留，我们只要先替换应用的数据库，后续逐渐改造，最终完成整体迁移过程。

此次迁移历经10个月的时间。彻底将SQLServer替换为OceanBase。我们也总结了从初次接触OceanBase到目前接入线上系统正式使用，我们遇到的问题和解决方案。：

• 初期接触时，OceanBase作为一款技术先进、架构完善的新型分布式产品，需要我们了解和学习的概念较多、加上生态工具较多、整体让我们感到相对复杂，有一定的学习成本，但后续在使用中还是很便捷的。
• 业务兼容性大致满足，包括多数据中心、多地域，这是OceanBase原生支持的。我们在测试过程中发现的某些特殊需求，OceanBase社区也会迅速迭代支持。
• 遇到BLOB数据时性能有影响，OceanBase社区人员直接跟我们一对一地沟通问题，最后在新版本中快速迭代解决了，响应非常快速。
• 我们在迁移的过程中，发现 SQL Server迁移时遇到自增主键无法迁移，通过第三方工具以及代码脚本解决。

整体来讲，我们的迁移过程有一些困难，但相对顺利，特别是在OceanBase社区的工作人员和技术支持的情况下。