Python高效下载处理1GB级LDA API捐款数据库技术咨询

规模判定与测算合理性 #

• 你的两套测算逻辑都站得住脚，最终1GB左右、约140万行的量级属于数据处理的常规规模，普通消费级笔记本跑全流程毫无压力，完全不会出现设备崩溃、内存溢出的问题。
• 两种测算方式的结果误差来自分页JSON的结构冗余、不同申报记录的字段长度差异，最终实际数据量浮动不会超过20%，提前按2GB预留磁盘空间足够。

具体疑问解答 #

• 全量下载耗时问题：按普通家用宽带10MB/s的平均速率，纯数据传输仅需2分钟左右；考虑到接口限流控制（建议单请求间隔100-300ms，并发数不超过3）、数据解析落盘的开销，全量拉取总耗时可以控制在20分钟以内，不存在耗时过长的问题。参议院的LDA公开接口限流规则很宽松，只要不恶意高并发爬取不会被封禁。
• 全量遍历匹配性能问题：140万行级别的结构化数据，纯Python逐行跑正则匹配总耗时在10秒以内；做模糊匹配时不要用原生fuzzywuzzy，换接口完全兼容的rapidfuzz，速度可以提升10-100倍，全量匹配总耗时可以控制在1分钟级别，完全不会出现运行卡顿的问题。
• iJson适用性问题：非常适合。不管是边拉取边解析分页响应，还是后续离线解析本地存储的JSON文件，iJson的流式解析逻辑都可以避免把整段/整个文件加载到内存，把解析环节的内存开销控制在KB级别，哪怕开多协程拉取也不会占用过多内存。
• 存储格式选择问题：CSV不是最优选项，优先选SQLite：
  • CSV没有类型约束、不支持索引，后续做筛选、关联查询的效率远低于数据库，还容易出现特殊字符转义错误、编码错乱的问题
  • SQLite是单文件嵌入式数据库，不需要额外部署服务，140万行数据写入后总文件体积和CSV基本持平，给姓名字段加索引后，筛选查询速度可以从秒级降到毫秒级
  • 后续做清洗、匹配迭代时，SQLite的读写灵活性远高于CSV，还能很方便地保留原始数据做回溯

落地执行最优流程 #

• 拉取环节：
  1. 先请求第一页数据确认总页数、分页参数规则，用aiohttp开2-3个协程异步拉取，每个请求加随机延时避免触发限流
  2. 用iJson流式解析每一页的响应内容，解析出单条捐款记录后直接批量写入SQLite，不要把整页甚至全量数据缓存在内存里
  3. 加简单的断点续传逻辑：每成功写入10页数据就记录当前页码，程序中断重启后从上次记录的位置继续拉取，不用重复请求已下载的数据
• 存储环节：
  1. 提前建原始数据表，给后续需要匹配的受捐人姓名、游说机构字段建普通索引，不要等全量数据写完再建索引，减少锁表等待时间
  2. 所有原始接口返回的字段完整存在原始表中，不要提前裁剪字段；后续清洗、匹配生成的结果单独存结果表，不要修改原始数据方便回溯校验
• 清洗匹配环节：
  1. 正则匹配可以直接用SQLite内置的正则函数执行，比把数据拉到Python内存里逐行匹配快3-5倍
  2. 模糊匹配前先对所有姓名做标准化处理：统一转小写、去掉标点符号、剔除多余空格，再用rapidfuzz计算匹配度，设置合理阈值过滤误匹配结果即可

内容的提问来源于stack exchange，提问作者Jack