百万级别数据 Excel 导出优化
前提
这篇文章不是标题党,下文会通过一个仿真例子分析如何优化百万级别数据Excel
导出。
笔者负责维护的一个数据查询和数据导出服务是一个相对远古的单点应用,在上一次云迁移之后扩展为双节点部署,但是发现了服务经常因为大数据量的数据导出频繁Full GC
,导致应用假死无法响应外部的请求。因为某些原因,该服务只能够「分配2GB
的最大堆内存」,下面的优化都是以这个堆内存极限为前提。通过查看服务配置、日志和APM
定位到两个问题:
启动脚本中添加了
CMS
参数,采用了CMS
收集器,该收集算法对内存的敏感度比较高,大批量数据导出容易瞬间打满老年代导致Full GC
频繁发生。数据导出的时候采用了一次性把目标数据全部查询出来再写到流中的方式,大量被查询的对象驻留在堆内存中,直接打满整个堆。
对于问题1咨询过身边的大牛朋友,直接把所有CMS
相关的所有参数去掉,由于生产环境使用了JDK1.8
,相当于直接使用默认的GC
收集器参数-XX:+UseParallelGC
,也就是Parallel Scavenge + Parallel Old
的组合然后重启服务。观察APM
工具发现Full GC
的频率是有所下降,但是一旦某个时刻导出的数据量十分巨大(例如查询的结果超过一百万个对象,超越可用的最大堆内存),还是会陷入无尽的Full GC
,也就是修改了JVM
参数只起到了治标不治本的作用。所以下文会针对这个问题(也就是问题2),通过一个仿真案例来分析一下如何进行优化。
一些基本原理
如果使用Java
(或者说依赖于JVM
的语言)开发数据导出的模块,下面的伪代码是通用的:
一个例子如下:
针对不同的OutputStream
实现,最终可以把数据导出到不同类型的目标中,例如对于FileOutputStream
而言相当于把数据导出到文件中,而对于SocketOutputStream
而言相当于把数据导出到网络流中(客户端可以读取该流实现文件下载)。目前B
端应用比较常见的文件导出都是使用后一种实现,基本的交互流程如下:
为了节省服务器的内存,这里的返回数据和数据传输部分可以设计为分段处理,也就是查询的时候考虑把查询全量的结果这个思路改变为每次只查询部分数据,直到得到全量的数据,每批次查询的结果数据都写进去OutputStream
中。
这里以MySQL
为例,可以使用类似于分页查询的思路,但是鉴于LIMIT offset,size
的效率太低,结合之前的一些实践,采用了一种「改良的"滚动翻页"的实现方式」(这个方式是前公司的某个架构小组给出来的思路,后面广泛应用于各种批量查询、数据同步、数据导出以及数据迁移等等场景,这个思路肯定不是首创的,但是实用性十分高),注意这个方案要求表中包含一个有自增趋势的主键,单条查询SQL
如下:
把上面的SQL
放进去前一个例子中,并且假设订单表使用了自增长整型主键id
,那么上面的代码改造如下:
「上面这个示例就是百万级别数据Excel
导出优化的核心思路」。查询和写入输出流的逻辑编写在一个死循环中,因为查询结果是使用了自增主键排序的,而属性lastBatchMaxId
则存放了本次查询结果集中的最大id
,同时它也是下一批查询的起始id
,这样相当于基于id
和查询条件向前滚动,直到查询条件不命中任何记录返回了空列表就会退出死循环。而limit
字段则用于控制每批查询的记录数,可以按照应用实际分配的内存和每批次查询的数据量考量设计一个合理的值,这样就能让单个请求下常驻内存的对象数量控制在limit
个从而使应用的内存使用更加可控,避免因为并发导出导致堆内存瞬间被打满。
❝
这里的滚动翻页方案远比LIMIT offset,size效率高,因为此方案每次查询都是最终的结果集,而一般的分页方案使用的LIMIT offset,size需要先查询,后截断。
❞
仿真案例
某个应用提供了查询订单和导出记录的功能,表设计如下:
现在要基于支付时间段导出一批订单数据,先基于此需求编写一个简单的SpringBoot
应用,这里的Excel
处理工具选用Alibaba
出品的EsayExcel
,主要依赖如下:
模拟写入200W
条数据,生成数据的测试类如下:
基于JdbcTemplate
编写DAO
类OrderDao
:
编写服务类OrderService
:
最后编写控制器OrderController
:
这里为了方便,把一部分业务逻辑代码放在控制器层编写,实际上这是不规范的编码习惯,这一点不要效仿。添加配置和启动类之后,通过请求http://localhost:10086/order/export?paymentDateTimeStart=2020-07-01 00:00:00&paymentDateTimeEnd=2020-07-16 00:00:00
测试导出接口,某次导出操作后台输出日志如下:
导出成功后得到一个文件(连同表头一共1031540
行):
小结
这篇文章详细地分析大数据量导出的性能优化,最要侧重于内存优化。该方案实现了在尽可能少占用内存的前提下,在效率可以接受的范围内进行大批量的数据导出。这是一个可复用的方案,类似的设计思路也可以应用于其他领域或者场景,不局限于数据导出。
文中demo
项目的仓库地址是:
Github
:https://github.com/zjcscut/spring-boot-guide/tree/master/ch10086-excel-export
(本文完 c-2-d e-a-20200711 20:27 PM)
技术公众号《Throwable文摘》(id:throwable-doge),不定期推送笔者原创技术文章(绝不抄袭或者转载):
本文使用 mdnice 排版
版权声明: 本文为 InfoQ 作者【Throwable】的原创文章。
原文链接:【http://xie.infoq.cn/article/1e3f564c3765834f039473a2e】。文章转载请联系作者。
评论