随着充电桩业务的逐年快速铺开，数据量呈现出爆炸性的增长态势。在业务初期，项目团队采用MongoDB和PolarDB这种事务性数据库来支撑业务运行。然而，随着数据量的急剧增加，这些数据库在处理百万级、千亿级数据量的分析、聚合任务时已无法满足业务对数据处理速度和准确性的高要求。
为了应对这一挑战，项目团队采用专门的分析型数据架构，它专注于处理非事务性质的任务，如数据分析和聚合，能够更高效地处理大规模数据，为业务提供更加准确、及时的数据支持。
本文重点介绍充电桩项目的亿级数据处理和分析，并详细阐述从关系型数据库到分析型数据库的整个演进过程。
01 数据下载优化
充电桩项目初期下载时序图
在充电桩项目初期，项目团队采用MongoDB作为主要数据库。在该架构下，前端调用下载接口请求数据，后端服务会立即访问MongoDB或PolarDB，检索并返回所有相关数据。前端接收到这些数据后，会负责执行Excel写入操作以及数据压缩处理，最终生成一个可供用户直接下载的文件。然而，这种操作方式在实际应用过程中面临以下挑战：
- 数据传输时间过长：由于下载的数据量大，可能会超出F5负载均衡器设定的常规连接时间限制（2分钟），导致连接中断；
- 服务资源占用过高：大规模数据的处理会占用服务器的CPU和内存资源，可能会影响其他业务的正常运行；
- 数据库性能压力大：频繁的大规模数据检索会增加数据库的负担，可能会导致其性能下降。
服务器和数据库
因此，项目团队对当前的数据处理和传输流程分阶段进行优化，以提升服务的整体性能和稳定性。
阶段一 分片压缩下载
分片压缩下载逻辑时序图
项目团队主要聚焦以下三个核心进行优化：一是实施数据分片读取与逐步写入Excel的策略，旨在以最低内存消耗完成数据处理；二是设定合理的单个Excel文件数据容量上限，确保文件的快速可访问性；三是将多个Excel文件整合至单一Zip压缩包中，以缩减用户下载所需时间。优化后，数据库CPU和内存的使用率得到显著下降，具体见下表所示：
阶段二 异步OSS下载
异步OSS下载逻辑时序图
为了提升数据下载效率，减轻服务压力，项目团队实施异步下载策略，有效缩减了接口请求时间并增加了数据下载量。同时，采用OSS作为文件存储，减少服务端口流量占用，降低服务CPU和内存使用率。经过优化调整，在500万数据量场景下，服务CPU使用率下降10%，而数据库CPU则保持稳定状态，具体见下表所示：
阶段三 基于分析型数据库下载
基于分析型数据库下载逻辑时序图
阶段三时，项目团队将下载功能转到下载中心服务，业务数据进入数据湖后再进行流转清洗，然后使用多线程分片下载方式，将数据写入文件并进行压缩，最后上传到OSS存储。经过优化调整，在500万数据量场景下，服务CPU、服务内存、数据库CPU及数据库内存均得到显著下降，具体见下表所示：
02 数据查询优化
数据查询优化逻辑时序图
在充电桩项目初期进行数据查询时，常常会遇到以下情况：
- 历史数据与实时数据混合，未能得到有效分离；
- 在MongoDB中进行复杂条件查询时，或因索引选择不当或查询条件过于复杂，导致最优索引失效。这种情况下，数据库会进行全表扫描，延长查询时间并消耗大量CPU资源，直接影响业务数据处理。
具体见下表所示：
为了更有效地解决数据查询问题，项目团队制定了分阶段的优化策略，具体分以下两个阶段实施。
阶段一 查询业务逻辑分离
查询分离逻辑时序图
在阶段一，项目团队将总数查询与分页查询的逻辑明确分开，通过单独执行总数查询来减少数据库在分页查询时的额外计算负担，从而降低CPU损耗。
在分页查询时，系统默认只查询前5000条热点数据。对于特殊需求，如需要查询超出前5000条的冷数据，则单独处理这些查询，以确保不会影响到热点数据的查询效率。
经过上述优化措施的实施，在5000万数据量场景下，数据库CPU及数据库内存均得到明显改善，具体见下表所示：
阶段二 历史查询和实时数据查询分开
历史查询和实时数据查询逻辑时序图
在阶段二的优化过程中，项目团队通过将热点数据和非热点数据进行有效分离，以减少关系型数据库对CPU的消耗。项目团队还利用Redis缓存加速查询，必要时回退到关系型数据库（如MongoDB或PolarDB）进行查询。对于历史数据的查询，则采用了Hadoop、Spark等处理技术，实现了千亿级数据量的高效分页查询，显著提升了查询性能。具体见下表所示：
03 项目总结
经过多阶段的持续努力与优化，充电桩项目成功解决了亿级数据下载与查询中的性能瓶颈和资源消耗难题。项目团队从最基础的下载与查询逻辑出发，逐步引入分片压缩下载、异步OSS下载、下载中心服务等高效策略，显著提升了系统的整体性能与稳定性。
在优化过程中，项目团队采取多项关键措施，大幅降低服务与数据库资源消耗，显著加快下载与查询速度：
- 数据库分片读取有效降低了单次查询的负载；
- 合理限制Excel数据量避免了资源过度消耗；
- 下载任务异步处理提升了用户响应速度；
- OSS存储的应用实现了数据的高效存储与访问；
- OLTP与OLAP数据分离，满足不同业务场景下的数据需求。
分析型数据架构在百亿级数据查询中展现出的卓越性能，有效减轻了业务数据库的负担。同时，OLAP数据下载服务凭借数仓的强大支持，不仅提高了查询效率，还确保了数据的一致性和完整性。
未来，项目团队将持续关注系统性能与稳定性，灵活调整并持续优化策略，以稳健的姿态迎接业务增长带来的全新挑战。
本文作者
王志坚：碧桂园服务JAVA开发专家
指导人：
毛卓：碧桂园服务技术总监
刘刚：碧桂园服务架构师
