影刀RPA进阶教程：千万级数据采集的分批策略与内存控制

影刀RPA进阶教程：千万级数据采集的分批策略与内存控制

小批量采集谁都会做，机器人一口气采五千条，Excel随便写。可当任务是采几百万、上千万条数据时，同一套流程跑到半夜就崩了：电脑内存被吃光、Excel打开就卡死、机器人运行十几个小时后越来越慢，最后不报错但也不动弹，像死机一样。

我把一个全量商品库采集项目从三十万条做到累计上千万条，中间经历的三次崩溃教会我一件事：大数据量采集不是"流程写得对"就行，内存管理和分批策略才是项目能不能活下来的关键。这篇就把影刀RPA做大体量采集的分批方案完整拆开讲。

先给一个总原则：数据永远不在内存里攒着，来一批、写一批、丢一批。后面所有的技巧都是围绕这句话展开的。

先看内存是怎么被吃光的

想治内存，先知道内存去哪了。官方文档对大文件操作引发的内存不足问题列过三个典型现象，我照着踩过一遍：

1. 拷贝、粘贴较大的sheet页内容，内存瞬间拉满
2. 循环Excel内容并打印日志，越跑越慢
3. 各类读写操作指令处理大表时卡住

除了这三个，采集场景还有两个隐形大户：把整页抓取结果存成一个巨大的列表变量，存到最后几百MB；列表套字典的结果集在循环里只增不减，机器人跑十小时，变量涨十小时。变量面板里能看到这些变量的实时大小，调试大数据流程时盯一眼，你会被吓到。

内存被吃光的表现不只是报错，更多时候是"假死"：流程还在跑，但每条指令的执行时间从0.1秒变成10秒，一晚上其实没采多少数据。看到越跑越慢，先怀疑内存，再去查别的。

分批策略一：按页切，用游标记录进度

最自然的分批单位是页。翻页采集本来就是一个页面一个页面拿数据，要做的是给这个天然批次加上"进度记录"，让千万级任务能拆成无数个小段接力跑。

实现方式就是断点游标：每采完一页，把页码写进本地文件；流程启动时先读游标，从上次的页码继续。这样任务随时可以中断——电脑要干别的、网络断了、机器人需要重启——恢复运行后接着上次的页码走，不用从头来。

游标文件建议同时记三样东西：当前页码、最后一条已采数据的ID、当天日期。日期字段是为了配合按天分片（后面讲），ID是为了配合去重。游标写入用最普通的文本写入指令就行，别把它也存进那个巨大的结果列表里，游标要的是落盘，一个几KB的txt最可靠。

按页切分的一个配套技巧：每页采完立刻写入存储，然后清空当页的临时列表变量再进下一页。千万别天真地想"我最后统一写"，千万级数据统一写入的那一天就是流程死亡的那一天。

分批策略二：按日期或ID区间切大任务

页游标解决"接力跑"，但一个千万级任务往往还需要按业务维度切片，把大任务分解成一批独立小任务。我常用的两种切法。

按日期切：目标站的数据有发布时间或更新时间的，按天切任务，每天跑一个日期分片。好处是天然可并行、可补采，某一天的数据有问题，单独重跑那一片就行，完全不碰其他数据。

按ID区间切：接口采集时URL里常带分页参数或ID参数，按ID区间每十万个一段，写个循环自动生成任务清单。接口类采集这么做效率极高，官方文档里讲批量数据抓取时提过抓取页数可以由变量控制，把页数参数变量化，配合外层循环就是自动分片。

三种切法可以叠加用：外层按天，内层按页，最里面按ID。层次多了流程别写成一锅粥，每层切片用一个子流程封装，这正是下一节的内容。

工程化：一个调度器加三个子流程

千万级项目的流程结构必须分层，我的标准结构是一个调度主流程加三个子流程，运行了半年没有再重构过。

调度主流程负责读任务清单（今天要跑哪些日期分片）、逐个调用子流程、记录每个分片的成败状态。它自己不碰数据，只管排队叫号。

三个子流程各管一段：open初始化负责开浏览器、验证登录态、加载游标；collect采集负责单分片内的翻页循环抓取，每页写入后更新游标；save入库负责清洗和写入目标存储。子流程之间用参数传递分片信息，输入输出在子流程属性面板配置。

调试这种分层结构有一个巨大好处：可以在调度器里只挑一个小分片单独跑，几分钟就能验证全链路，不用为了改一行代码重跑三小时。配合断点调试逐行排查，问题定位永远在分钟级。

命名规范在这里不再是洁癖而是刚需：几十个指令的流程里，“01_初始化”、“02_单分片采集”、"03_入库"这样的编号命名，是半年后还能看懂流程的唯一保证。

数据处理：写入端的三种存储选型

采集的数据往哪写，直接决定内存压力。三种方案我都长期用过，按数据量级给个选型参考。

Excel是新手默认选项，但它恰是大体量场景的第一杀手。用影刀操作大Excel时，读取区域、写入区域的范围尽量精确，别动不动全表读写。追加写入时起始行号、起始列名这些参数用变量控制，让每批数据写到正确的位置。还有个隐蔽坑：写入带括号的数字会被自动转成负数，采集数据里出现"(100)"这种文本时先处理再写入。

量级上去后坚定换数据库。连接、执行SQL、关闭连接三件套配分批提交，每批一千条左右commit一次，写入又快又稳。批量插入遇到Duplicate entry唯一值冲突，是重复数据触发主键冲突，写入前查重或改用容错写法。

飞书多维表格适合"边采边让人看"的场景，多维表格读写指令按行写入，注意别触发频率限制，写入间隔留一点余量。

Pandas分块：Excel大表的救命稻草

存量的大Excel怎么办？比如前期不懂分批，已经攒出一个几十万行的表格，现在要清洗合并。直接用表格指令循环处理，内存大概率扛不住，官方文档给的解法之一就是用pandas处理大数据量的Excel。

pandas在影刀的Python节点里直接可用，分块读取是关键：

# 用pandas分块读取大Excel，每次只装10万行进内存importpandasaspddefmain(args):chunks=[]# chunksize=100000：每次读10万行，内存占用可控reader=pd.read_excel('big_table.xlsx',chunksize=100000)forchunkinreader:chunk=chunk.drop_duplicates()# 每块单独去重chunks.append(chunk)result=pd.concat(chunks,ignore_index=True)result.to_excel('cleaned.xlsx',index=False)returnlen(result)# 返回处理后的总行数

去重、格式转换、字段筛选这类清洗操作在pandas里都是一行代码的事，比在RPA循环里逐行处理快一个数量级。我的分工原则：抓取用RPA，清洗用pandas，各干各的强项。之前有个同行非要在影刀循环里对百万行数据逐条字符串处理，跑一夜没跑完，换pandas三分钟完事。

Python协同再进一步，把清洗逻辑封装成def函数、存成独立模块，跨流程调用，清洗规则改一处全流程生效，这是把项目做大的必经之路。

变量管理的瘦身清单

内存控制很大一部分是变量纪律。把我压箱底的瘦身清单列出来。

1. 结果集不攒批：循环里每页写入后清空临时列表，重新赋值一个空列表
2. 大字符串不进日志：打印日志有长度截断，整页HTML源码这种东西写文件，别塞日志
3. 网页对象及时关：分片跑完就关闭网页，几十个标签页开着也吃内存
4. 字典按需建：不要为了"以后可能用到"把整条数据的所有属性都塞进字典，用到的字段才留
5. 中间结果落盘：两阶段处理（先抓后洗）之间，中间数据写csv文件过渡，别用变量接力

变量面板是你观察内存的窗口，长跑任务每隔一小时看一眼变量大小，有异常增长的立刻找源头。这个习惯让我提前发现了两个内存泄漏点，都是某个子流程里列表忘了清空。

网页端的加载控制：懒加载与滚动判断

大体量采集跑得久，页面加载策略的每个细节都会被量级放大。翻页类列表最省资源，按页拿数据、写完就走。瀑布流懒加载页面最费资源，滚动加载无上限，必须自己设批次边界。

懒加载页面的标准控制流：滚动一次→等待加载→对比滚动前后元素数量→数量不变说明到底了→退出循环。每一轮滚动只抓新增的部分，用index切片从元素列表里拿新出现的那些条目，抓完清空临时列表再滚下一轮。千万别把整页几百个元素列表一直留着反复抓。

页面本身的渲染负担也要考虑：滚动循环里每次滚动后给足等待，等待时间不足会导致元素没加载完就去抓，抓到空值，后面清洗时一堆"–"要补采，反而更耗时。快和稳在大体量场景里，稳永远是第一优先级。

平台实战：千万级采集的两个真实场景

说两个量级较大的实战场景怎么套这套框架。全站商品库采集（淘宝类）：外层按店铺ID分片，每个店铺内按页翻，商品链接ID做去重键，入库用MySQL，每店铺一个commit批次。跑了一个季度累计千万行，数据库毫无压力，压力全在采集端的频率控制上——大任务跑得越久越容易被平台盯上，每页之间加随机延迟，宁可多跑两天。

历史评价类采集（天猫评价这种）：评价有翻页和全量两种模式，全量走接口按页拉，分批更彻底；页面采集则按商品ID分片，每个商品一个采集子任务。评价里的日期常是"三个月前"这种相对时间，解析不了就原样存，别在采集环节卡格式。

平台共性的一条经验：大体量任务的采集频率控制不是可选项。全量任务动辄连跑几天，频率过高轻则弹验证重则封IP，一天的采集量安排出十几天的耐心，才是大体量玩家的正常心态。

系统联动：让大任务可观测

千万级任务一跑好几天，人不可能一直盯着，观测体系要建起来。我的做法是三层汇报。

调度器每完成一个分片，往飞书多维表格写一行状态：分片日期、采集条数、耗时、成败。这个多维表格就是任务看板，手机随时能看进度。每天固定时间汇总当日总量，推一条飞书消息。异常退出时，Catch里的告警消息带上最后游标位置，恢复时直接照着断点续跑。

邮件通知可以补一条日报，把每日采集量做成简单汇总发到自己邮箱，历史数据翻邮件就能查。这些联动指令都不难，难的是养成"长跑任务必须可观测"的意识——没有观测的大任务，崩了你都不知道它是什么时候崩的。

版本与性能：64位和机器配置

最后补几条硬件和版本层面的实操建议。官方文档对Excel内存不足给的第一个解法就是安装64位版本，32位进程内存有上限，大数据量场景64位是标配，装之前先确认自己装的是哪个版本。

机器内存16GB起步，32GB更从容；跑大任务时把无关软件关掉，浏览器只留机器人用的那一个窗口。多任务并行要多台机器或机器人多开时，每台机器上分摊的分片量按内存余力算，别把一台机器当三台用。

时间成本也要算清楚：千万级任务即使流程全优化好，也要按周计。提前把分片计划排出来，每天推进多少、什么时候跑完，写进任务清单，比闷头跑科学得多。

易错速查：大数据量采集故障对照表

千万级项目踩过的坑，浓缩成一张表。

学习资源

本文的调度器加三子流程结构、游标管理、pandas分块清洗，完整流程源码我放在代码仓库 home.linyan.cloud，可以直接参考改造，把里面的分片参数换成你的目标站就能跑。官方帮助中心建议精读"Excel运行时内存不足"和"批量数据抓取"两篇，前者是内存问题的诊断依据，后者是多页抓取参数化控制的正源。

#影刀RPA #RPA自动化 #数据采集 #分批处理 #Excel

作者：林焱