做量化开发的谁没被数据接口按在地上摩擦过我前后折腾了不下五个数据源中间有三次踩坑踩到怀疑人生最后才拼出一套能长期跑的数据方案。今天把这三次坑和最终方案一次性说清楚希望能给正在选数据源、写入库脚本的朋友们省点时间。先交代背景我是个人量化开发者主要做 A 股日线级别的策略回测和模拟盘。量化这行数据就是血液数据接口就是输血管。没有稳定干净的数据策略再漂亮也是空中楼阁。但个人开发者既没有机构级的数据渠道也买不起几十万的终端服务只能在各种免费或半免费接口之间反复横跳。这篇分享的“本命工具”不是某一个接口而是一套组合方案稳定数据源 Python 脚本 本地数据库 自动化更新。适合正在被接口稳定性、数据质量、入库效率折磨的朋友参考。1. 量化开发的第一步就卡在数据接口上很多刚入门的量化小白会把大部分精力花在策略因子上觉得只要代码写得足够花哨就能赚钱。但真正开始跑回测之后就会发现你六十行代码还没写先得解决“数据从哪来”的问题。行情数据、财务数据、资金流向、行业板块、指数成分每一个策略都需要对应的数据切片而这些数据接口的稳定性、完整度和及时性直接决定了你的策略结果可不可信。以日线回测为例你需要至少保证每个交易日每只股票的开高低收、成交量、成交额、复权因子、涨跌停标记、停牌状态。注意复权因子和停牌状态是最容易被忽略、但影响最大的字段。如果接口里没有复权数据遇到高送转或者大比例分红价格会出现跳空回测曲线直接失真。如果不知道停牌日你会把一只停牌一整个月的股票当成可以随时买卖的标的成交信号就会完全错误。个人开发者的困境还在于机构数据源比如 Wind 的 Python 接口、聚宽的底层数据确实好用但门槛高、价格贵个人玩家很难长期承担。而免费接口看似很多实际上每个都有脾气。我用过的接口里有的突然停止更新有的字段悄悄改名有的单位一会儿元一会儿万元有的接口干脆返回空数据。这些细节在刚开始接触时往往注意不到等策略跑出离谱曲线再回头查数据时间已经搭进去了。所以我个人建议在正式开始量化开发之前先把数据层当成一个正式项目来做。不要急着写策略先花几天时间把数据源选型、数据库表结构、增量更新机制这三件事想清楚。磨刀不误砍柴工这条经验是我用无数次熬夜换来的。2. 三次被坑实录每一步都是血泪2.1 第一次坑免费接口说挂就挂数据质量也一言难尽最开始我没有太多想法直接在 GitHub 上找了个免费金融数据接口用 Python 拉日线行情。刚开始觉得挺好requests 一调JSON 一解析pandas 一装数据就能用了。但很快问题就来了每个交易日收盘后接口经常延迟遇到行情活跃的日子直接超时然后返回空数组。一开始我以为是网络问题重试几次还能拿到数据但次数多了以后发现接口方开始限流同一 IP 短暂时间内调太多次会被封掉。更头痛的是数据质量。有一次我做除权除息回测发现某只股票在权益登记日之后价格断崖式下跌但我的策略竟然完美躲过了下跌收益曲线异常漂亮。我当时还高兴了一会儿后来查了下数据发现接口返回的是不复权价格我没有做复权处理导致除权日的跳空被误判成真实亏损。回测结果完全失真等于白跑。还有一次做财务因子策略需要读取资产负债表的净利润字段发现某接口返回的单位是“元”另一个接口返回的是“万元”还有的接口在盈余公积这种大数字上直接给了四舍五入后的值。我因为没有统一单位导致构建的因子排序乱成一团。所以免费接口适合快速验证想法但直接拿来做严肃的量化回测风险非常高。2.2 第二次坑抓包走了一条更偏的路第一次被免费接口坑了以后我一度非常激进想着“既然接口不给力那我直接去抓行情软件的包行不行”。有人给我提过一套思路在电脑端微信里打开某小程序配合 Fiddler Everywhere 抓取小程序发出的接口请求能拿到 JSON 行情数据和 K 线图片。我当时还真去试了也确实抓到过数据。但这条路走不通。第一小程序接口基本都有签名校验没过几天就要重新逆向算法维护成本极高。第二对方服务端有 IP 和频率限制抓几次之后请求就失败。第三涉及数据版权和平台服务条款问题个人开发者去抓别人平台的接口本身就有合规风险。我后来想通了这是一条更偏的死胡同。如果你也只是想调试自己开发的程序Fiddler Everywhere 这类抓包工具是很好的助手但如果想靠它建立自己的量化数据管线那大概率是捡芝麻丢西瓜。当时我甚至怀疑过是不是自己电脑网络环境出了问题连“rmii接口网卡接收数据错误”这种底层网卡日志都去查过折腾半天最后发现数据缺失压根不是本地网络问题而是上游接口不稳定。这个教训让我彻底断了抓包的念头决定回归正规数据源。2.3 第三次坑数据库表设计随便弄数据存进去却读不出来好不容易找到能用的数据源我又栽在了存储环节。一开始偷懒每次拉完数据直接存成 CSV 文件文件名带日期文件夹里堆了几百个文件。等我想跨越多个日期做统计时发现自己要写一堆文件遍历代码而且 CSV 没有约束重复数据、缺失字段到处都是更不用说磁盘占用和读取速度了。后来决定换到数据库选了 SQLite以为只是换个存储介质。结果因为表结构没有认真设计字段类型不统一时间列一会儿是字符串一会儿是日期主键也没设置导致插入重复数据后查询结果出现大量重复记录。尤其是一轮回测需要读取三年日线数据时SQL 查询慢得像蜗牛爬。我意识到数据管道设计比接口本身更重要如果入库前不做规划后面每一个策略迭代都会被数据问题拖累。3. 我的“本命工具”长什么样稳定数据源 Python 入库 自动化更新三次坑踩完我总结出一个公式稳定的数据源 规范的数据库表结构 可重跑的增量更新脚本才是量化开发最靠谱的数据底座。下面说说我最终选型和落地的方法。3.1 数据源选型为什么选择 Tushare Pro 和 AkShare 组合我用过的数据源里如果机构预算充足Wind 的 Python 接口体验最好字段文档规范服务稳定但个人用户很难开通费用也高。退而求其次我选了两个免费/低成本数据源组合使用主数据源Tushare Pro。它的优势是数据规范化做得不错接口字段有完整文档很多字段直接给出中文注释积分机制虽然让人头疼但基础积分足够拿到日线行情、财务数据、交易日历等核心内容。我用它做全市场日线行情、复权因子、财务数据的主来源。补充数据源AkShare。它覆盖面更广包括一些 Tushare 积分门槛较高的数据、行业板块、概念板块、期货期权数据等。虽然文档和稳定性不如 Tushare但作为备胎非常合适。需要冷门数据时先从 AkShare 取然后统一落库。对比项Tushare ProAkShareWind Python 接口数据稳定性较稳定有积分限制接口较多偶尔变动非常稳定文档完整度完整字段注释清楚部分接口文档较简略完整服务好费用/门槛积分制基础免费免费商业授权贵数据覆盖面股票/基金/期货/宏观/财务更广包含另类数据全但需权限适合人群个人/小团队个人快速验证机构/专业团队选型逻辑很简单一个主源保证核心数据稳定一个备源覆盖补充数据两者都通过 Python 入库避免单点依赖。如果你学校的机构账号能开 Wind那当然优先用 Wind 的 Python 接口省去不少麻烦但如果和我一样是个人玩家Tushare Pro AkShare 的组合已经足够应付大部分场景。3.2 用 Python 把接口数据批量写入数据库我最终的技术栈是Python pandas SQLAlchemy PostgreSQL。为什么用 PostgreSQL因为它对数值类型、时间索引、JSON 字段的支持都比 SQLite 强而且支持并发写入配合 pandas 的to_sql非常顺手。如果你不想装数据库用 MySQL 也一样SQLAlchemy 帮你隔离了数据库差异。入库不要一条条 insert而是把接口返回的数据整理成 DataFrame然后一次性批量写库。核心代码大概长这样import pandas as pd from sqlalchemy import create_engine # 连接本地 PostgreSQL engine create_engine(postgresql://quant_user:passwordlocalhost:5432/quant) # 调用 Tushare Pro 接口获取日线数据 import tushare as ts pro ts.pro_api(your_token_here) df pro.daily(ts_code000001.SZ, start_date20240101, end_date20240131) # 基础清洗统一字段类型、删除重复记录 df[trade_date] pd.to_datetime(df[trade_date]) df df.drop_duplicates(subset[ts_code, trade_date]) # 批量写入数据库主键由 ts_code trade_date 组成 df.to_sql(daily_bar, engine, if_existsappend, indexFalse, chunksize5000)这里有两个细节特别重要第一if_existsappend表示追加写入适合增量更新但如果当天重复运行会写入重复数据所以最好先按主键去重第二chunksize不要设太大我试过 5000 行一批比较稳妥太大容易长时间占用数据库连接太小则会显著降低导入速度。如果你需要更精细的控制可以使用 SQLAlchemy 的Table对象做 upsert但日常用to_sql 去重就足够了。重点是把表结构先建好主键必须是“代码 交易日”的联合主键这样查询某个股票的时间序列时才能走索引不会全表扫描。3.3 自动化更新的定时任务设计数据接口只是第一步数据每天都要更新尤其 A 股交易日每天收盘后是数据更新的黄金时间。我写了一个 Python 脚本用系统 cronLinux/macOS或计划任务Windows每天 18:00 执行一次。增量更新机制很关键。不要在每次运行时都把全市场从 2010 年到现在拉一遍既慢又容易触发限频。我的做法是维护一张update_log表记录每个接口最近成功更新的日期。任务启动后先读这张表确定本次要拉取的日期范围再调用接口增量拉取最后更新update_log。核心伪代码如下def get_last_update_date(source_name): # 从 update_log 表读取 source_name 对应的最近日期 ... def daily_update(): last_date get_last_update_date(tushare_daily) end_date today() # 若今天不是交易日则取上一个交易日 df pro.daily(trade_date_range[last_date, end_date]) # 清洗、入库 # 更新 last_date 为 end_date为了避免触发接口频率限制在每次请求之间加time.sleep(0.5)如果调用的是高频接口也可以把 sleep 拉到 1 秒。稳定比速度重要。另外建议在脚本里加上重试逻辑网络超时或者接口返回异常时最多重试 3 次退避时间递增。这样即使偶发故障也能自动恢复。4. 关键细节与避坑清单能让你少走三年弯路4.1 复权因子与除权除息回测中最重要的数据预处理我在第一次坑里已经吃过不复权的亏了这里详细说下正确做法。日线行情接口返回的close通常是不复权价格但 Tushare 单独提供adj_factor复权因子接口。计算后复权价格时把复权因子序列做归一化处理然后乘到原始价格上。adj pro.adj_factor(ts_code000001.SZ, start_date20200101, end_date20240201) df df.merge(adj[[ts_code, trade_date, adj_factor]], on[ts_code, trade_date]) # 后复权以最新一日复权因子为基准归一化 base_factor adj[adj_factor].iloc[-1] df[adj_close] df[close] * df[adj_factor] / base_factor回测和选股建议使用后复权价格因为前复权价格会随最新价格变化而动历史数据会不断“重写”导致同一段历史在不同时间的回测结果不一致。后复权价格的缺点是当前价格与市场价格有差异但这只影响绝对值不影响收益率计算和排序。4.2 字段规范与单位统一不同数据源的字段名和单位差异很大必须做统一映射。我的做法是在数据库里建一张标准字段对照表把ts_code、trade_date、open、high、low、close、vol、amount这些字段固定下来任何来源的数据都先映射成这套标准再入库。单位方面金额统一用元成交量统一用“股”或“手”财务数据如果接口是万元入库前先乘以 10000。用生活里的话说这就像把所有快递盒都拆开把里面的东西分门别类放进同样的收纳箱。接口经常换但你自己的表结构轻易不要变否则下游策略代码会跟着遭殃。4.3 时区、交易日历与停牌处理数据库中的日期字段建议统一用 date 类型行情时间统一按北京时间处理。尤其在跨市场对比时时区混乱会导致日期错位比如美股和 A 股的自然日相同但交易日不同。A 股交易日历直接用 Tushare 的trade_cal接口不要自己硬编码节假日因为每年国庆、春节的休市安排都可能调整。停牌股的处理容易被忽略。停牌的股票在日线接口里根本没有记录回测时如果简单地按自然日 reindex停牌日会被当成“可交易但无行情”从而出现用停牌日之前的价格成交的假信号。正确的做法是显式标注停牌日回测框架遇到停牌日不能产生交易信号。4.4 数据库索引与查询性能数据表建好之后一定要加索引。我最常用的查询就是“某只股票某段时间的日线序列”所以联合索引(ts_code, trade_date)必不可少。没有索引的时候全市场三年数据查询是秒级响应加了索引基本毫秒级。入库效率方面建议把全市场日线数据按交易日批量拉取每批 5000 行左右提交避免单条 insert 造成的性能灾难。如果你的数据量达到几千万行可以考虑按月份做分区表但个人开发者的数据量一般不需要。先把索引和写入逻辑做好已经能覆盖 90% 的需求。5. 常见问题快查手册接口报错、数据对不上、入库失败这里整理一个我用这半年里最常遇到的排查清单基本覆盖数据管线的常见故障。现象可能原因解决办法接口报“权限不足”Tushare 积分不够升级积分或者改用 AkShare 对应接口接口请求超时网络波动或接口限频加指数退避重试请求间隔 sleep 0.5-1 秒数据量和预期不符停牌、新股上市日期、退市股票核对交易日历和上市状态不要只看自然日财务数字多几个零接口单位是万元先看接口文档统一转换为元再入库数据库主键冲突重复运行了入库脚本先按主键去重再 append或者使用 upsert写入 DataFrame 报 NaN 错误PostgreSQL 不接受 NaN入库前用df.where(pd.notnull(df), None)转换查询速度慢缺索引或全表扫描建立(ts_code, trade_date)联合索引增量更新漏数据上次任务失败但 update_log 没回退事务机制先插入数据成功后再更新日志表再补充一个我特别想强调的入库脚本一定要是可重跑的。意思是同一段日期无论跑多少次结果都应该一致不会因为重复写入而导致脏数据。我在实际开发中就把“幂等性”作为入库脚本的第一原则每次写脚本前先想想如果这次任务被中断下次重跑能不能自动修复如果不能那脚本还需要再设计。6. 个人体验这套方案已经稳定运行大半年从我把整套数据管道搭起来之后已经稳定运行八个多月了。每天收盘后自动拉取全市场日线行情和复权因子增量写进 PostgreSQL再通过几条简单的 SQL 视图给策略回测提供数据。这期间除了偶尔网络波动导致任务重跑几乎没有因为数据本身出过问题。我个人的体会是量化开发中的“本命工具”不是越贵越好也不是功能越多越好而是能在长期运行中持续提供干净、稳定、可复现的数据。免费接口固然方便但如果你要做严肃的策略研究请一定把数据源选型和入库流程当回事。Wind 的 Python 接口确实香但个人玩家用 Tushare Pro AkShare 的组合已经能跑通绝大部分场景。最后再分享一个我自己的小习惯每次跑完回测我会随机抽查十只股票的 K 线确认除权除息日没有跳空确认停牌日没有成交记录确认财务数据的数量级正确。这个习惯看起来笨但确实帮我提前发现了好几次数据问题。数据稳了策略研究才能真正开始。