做量化这件事，很多人一开始把精力全压在策略上：均线、因子、机器学习、网格交易，看起来每一步都很有成就感。但真正跑过一段时间的人都会承认，最先暴露问题的往往不是策略，而是数据。数据源这个环节看起来只是“找个接口把K线拿下来”，实际上从选型、清洗、拼接、时区到增量更新，每一个细节都可能让回测结果失真，甚至让实盘下单直接停摆。
我见过不止一个项目，策略逻辑本身没什么问题，最后排查了半天，发现是数据源在某个除权日之后价格断了一截，或者把夜盘时间归属到了错误的交易日期，又或者多数据源切换时连接串配错，服务根本起不来。这篇文章想认真聊一聊量化软件获取数据源时常见的5个坑。这5个坑不解决，后面加再多花哨的功能，都是在沙地上盖楼。
先给一个贯穿全文的判断：量化数据源真正难的从来不是“找得到数据”，而是拿到稳定、准确、可复用的数据流。找数据只是一个动作，稳定获取和持续维护才是一个工程问题。
1. 第一个坑：数据源来源太杂，接口差异被低估
1.1 免费接口、爬虫和商业数据源，根本不是一类东西
做量化的人手里通常不会只有一个数据来源。常见的情况是：日线用某个免费开源接口，财务数据用另一个，复权因子从第三处找，盘中行情可能还要靠爬虫去抓网页接口。
这些来源之间的差异，远远不止“一个免费、一个付费”。同一个股票，有的接口返回的字段叫close，有的叫收盘价，有的叫price；有的返回的是字符串，有的返回浮点数，有的把价格四舍五入到分，有的保留原始精度；同样是日线，有的默认前复权，有的返回不复权，有的需要你再单独调一个参数。
如果只是人眼在客户端里看，这些差异还能容忍。问题在于，策略代码是按统一逻辑处理的。当回测脚本从A源拿日线、从B源拿财务数据、从C源拿复权因子，而三份数据的字段口径不一致时，对齐错误是隐性的。它通常不会让程序报错，而是让算出来的指标悄悄偏掉。
最典型的例子是：A源的日线是不复权的，C源的复权因子是后复权口径，两边没有做任何转换，回测一旦遇到除权除息日，价格断档就会被当成真实的涨跌幅，一个本来不该开仓的信号，就变成了开仓信号。
1.2 先把字段口径统一，再谈后续所有事儿
所以数据源落地，第一步不是“接数据”，而是先定义一套自己系统的标准表结构。
我建议在数据接入层加一个适配层，也就是 adapter。每一个外部数据源都写一段独立的适配代码，把它的字段、类型、时间格式、复权状态全部映射成系统内部的统一格式。这样策略层永远只认同一套 schema，换数据源时只需要替换适配层，策略代码一行都不用改。
这套标准结构至少要包含这几类信息：
- 标的标识：代码、交易所、市场类别
- 时间信息：日期、时间戳、时区、交易日
- 行情信息：开高低收、成交量、成交额
- 复权信息：复权类型、复权因子
- 来源信息：数据源标识、抓取时间
其中来源信息最容易被忽略。很多人的表里没有source字段，等数据出了问题，根本不知道这条记录是谁提供的，也没法追溯。
1.3 最小可执行的统一 schema
下面是一个比较通用的日线表结构示例，真实项目可以按需调整：
CREATE TABLE bar_daily ( symbol VARCHAR(20) NOT NULL, exchange VARCHAR(10) NOT NULL, trade_date DATE NOT NULL, open DECIMAL(20,4), high DECIMAL(20,4), low DECIMAL(20,4), close DECIMAL(20,4), volume BIGINT, amount DECIMAL(24,4), adj_status VARCHAR(10), -- NONE / PRE / POST source VARCHAR(50), created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (symbol, exchange, trade_date, adj_status, source) );需要注意，如果不复权、前复权、后复权数据都要保留，建议加adj_status字段，而不是混在一起。不同复权口径的数据混在一个表里，是做策略时最容易埋雷的操作。
适配层写完之后，要跑一个最小验证：拿一只近期除权过的股票，从不同数据源取同一段数据，对比开高低收和成交量。如果这层对齐了，后续所有策略计算才有一点可信度。
2. 第二个坑：K线拼接与复权因子，回测失真多半在这里
2.1 不复权、前复权、后复权到底怎么选
先看一个很常见的现象：某只股票昨天收盘10块，今天除息，每10股派5元，今天开盘价直接变到9.5附近。如果不做任何处理，K线上会出现一个向下的跳空缺口。这个缺口不是市场真实下跌，而是分红除息造成的价格调整。
很多人的回测脚本拿到什么数据就用什么数据。如果用的是不复权数据，那么在除权除息当天，策略会认为价格“跌”了5%，如果刚好仓位规则是跌破某个均线就卖出，这里就会触发一次错误交易。
前复权是以当前价格为基准，把历史价格向下调整。它的好处是图上看不出历史缺口，缺点是每次更新到今天的最新行情，之前所有历史价格都会被重新计算一遍。这意味着，今天回测得到的结果，和明天再跑一遍同一区间，数值可能会变。对于需要复现的研究场景，这一点非常难受。
后复权以上市首日为基准，把后续价格向上调整。它不会因为新数据加入而改变历史价格，更适合回测和长期收益统计。
我的建议是：展示用前复权，回测和因子计算用后复权或自行维护复权因子，计算真实收益率时必须把分红、送股反映进去。很多免费接口默认返回前复权，你需要在接入时就明确指定口径，不要等到回测结果对不上再去猜。
2.2 分钟线拼接不是简单 concat
分钟线是另一个重灾区。很多数据源提供的分钟线不是连续的，可能某天缺了一根，也可能时间戳对不齐。最常见的几个问题：
- 不同数据源之间的分钟数据片段时间戳不连续，有的缺09:31，有的盘中缺一分钟；
- 跨日拼接时，把昨天14:59和今天15:00连在一起算一分钟涨跌幅，得出一个夸张的错误信号；
- 集合竞价数据归属不统一，有的数据源把9:25的集合竞价价格放在9:30这一根K线里，有的单独放；
- 期货夜盘和日盘拼接时，没有明确交易时段，把21:00的夜盘数据直接排在第二天15:00之后。
正确做法是：拼接之前先按交易日分组，每个交易日内再按时间戳排序。跨日边界处不要做连续性假设，集合竞价、开盘、午休、收盘这几个边界点要单独核对。
验证方法也很简单：随便抽一只股票的普通交易日，检查第一根分钟K线的时间戳是不是开盘时间，最后一根是不是收盘时间；再抽一只除权除息日的分钟线，确认是否存在异常跳空。
2.3 复权因子表的数据模型
我建议在系统里单独维护一张复权因子表，而不是每次都依赖数据源返回的“已复权价格”。
CREATE TABLE adjust_factor ( symbol VARCHAR(20) NOT NULL, exchange VARCHAR(10) NOT NULL, ex_date DATE NOT NULL, dividend_cash DECIMAL(20,6), bonus_share DECIMAL(20,6), placement_share DECIMAL(20,6), factor DECIMAL(30,10), source VARCHAR(50), PRIMARY KEY (symbol, exchange, ex_date, source) );这张表记录每个除权除息日的分红、送股、配股等信息，然后通过日期向前或向后累乘得到任意一天的复权因子。如果数据源能直接提供复权因子，优先使用；如果只给分红送股公告，就需要自己维护计算逻辑。
注意：不要在你的基础行情表里直接修改原始价格字段来“做复权”。一旦发现复权计算有误，你很难把原始价格恢复回来。保留原始价格，单独维护复权信息，才是最可控的做法。
3. 第三个坑：时间与时区，看起来小但最伤人
3.1 一个交易时刻在三个时区里长着三张脸
说一个特别容易踩的场景。你在国内开发，数据库安装在云服务器上，默认时区是 UTC，数据源返回的时间是北京时间。日K线还好说，日期基本一致。一旦到分钟级数据，问题就来了。
同样是北京时间下午15:00，存进数据库时如果你没做时区转换，存进去的可能是 UTC 时间 07:00。查询时界面又按本地时区把这条记录显示成 15:00，看起来一切正常。但如果你用 SQL 去做时间窗口计算，比如“过去30分钟的最高价”，时区错位会直接导致窗口切错，数据匹配不上。
做期货、期权、美股、港股的时候更明显。期货夜盘21:00开始，如果数据源存的是 UTC 13:00，你只看自然日就会把夜盘记录归到前一天。等第二天早上做数据统计，怎么都查不到夜盘那几根K线，实际上数据就在表里，只是日期分错了。
3.2 日线归属和夜盘日切
很多时候，不同数据源对“这根K线属于哪个交易日”的定义不一样。股票日线通常以交易所交易日为准，但集合竞价的记录、盘后数据、盘前数据的日期归属，不同数据源可能有差异。
期货的日切就更复杂。夜盘交易时段从今晚21:00开始，但它在交易逻辑里属于下一个交易日。如果你按自然日分组，今晚21:00的成交会被归到今天，而正确的做法是归到明天。
所以，一张完整的行情表里，除了标准时间戳，还应该单独维护一个“交易日”字段，并且用交易所交易日历计算，而不是用自然日截断。交易日历看起来是个简单的东西，实际上每个交易所的节假日、周末、临时休市都不一样，建议单独建一张日历表维护，不要在代码里写死。
3.3 锚定时区比“看着对”更重要
统一的建议是：存储层尽量用标准时区（UTC）存时间戳，查询展示时再转成你需要的时区。同时额外保留一个“交易日”字段，用交易所本地日期表示。
下面只是示意写法，具体实现取决于你使用的语言和库：
# 统一用 UTC 时间戳存储，交易日单独一列 row["ts_utc"] = source_ts.astimezone(timezone.utc) row["trade_day"] = get_trade_day(source_ts, exchange="SH")这里的重点不是某个具体的API，而是两条原则：时间戳语义要统一，交易日归属要单独存。不要依赖数据库当前的时区参数，因为换一台服务器、改一个全局配置，所有时间都可能变掉。
4. 第四个坑：多数据源切换和连接配置，软件直接在启动这步挂掉
4.1 ODBC 数据源找不到，先别急着重装驱动
很多量化软件在 Windows 环境里跑，数据会存入 SQL Server、MySQL 或 PostgreSQL。连接数据库时经常会遇到一个典型报错：
[IM002] [Microsoft][ODBC 驱动程序管理器] 未发现数据源名称并且未指定默认驱动第一次遇到这个错的人，第一反应通常是重新安装数据库驱动，装完发现还是报错，于是开始怀疑系统问题。实际上，这个问题大多出在“应用看到的ODBC环境和驱动环境不一致”上。
常见原因有这几类：
- 驱动确实没装，或者安装的是另一版本的驱动；
- 应用是32位，但安装的是64位ODBC驱动，或者反过来；
- 连接串里写了 DSN 名称，但该 DSN 只定义在用户DSN里，服务以系统身份运行时看不到；
- 连接串里只给了 DSN，没有同时指定 Driver，而 DSN 本身又没找到。
排查顺序建议是这样：
- 先确认应用是 x86 还是 x64，然后打开对应版本的 ODBC 数据源管理器。32位和64位的 odbcad32.exe 是两个不同入口，别只看名字相同；
- 在数据源管理器确认 DSN 是否存在，并且记住它是在“用户DSN”还是“系统DSN”；
- 检查连接串写法，有些场景下最省事的方式是不依赖 DSN，直接写 Driver、Server、Database；
- 如果软件是作为 Windows 服务运行的，还要确认服务账号有没有权限访问这个 DSN。
一个更稳妥的写法是在连接串里同时指定 Driver 和服务器地址，而不是只写 DSN：
Driver={ODBC Driver 17 for SQL Server};Server=127.0.0.1;Database=quant;Trusted_Connection=no;UID=quant_user;PWD=******4.2 多数据源切换的事务边界
量化软件有一个天然的多数据源场景：一边连行情数据库，一边连自己的策略运行库，实盘时还要连券商交易接口。这几个数据源往往不在同一个数据库实例里，甚至不是同一个数据库产品。
最常见的坑是，一个业务方法里先从A库读数据，处理后写入B库。如果不做任何处理，这两个库的操作都放在同一个本地事务里，一旦B库写入失败，A库的读取连接也会因为事务状态混乱而报错。
更麻烦的是动态数据源切换。很多框架支持“运行时切换数据源”，但如果事务已经在某个数据源上开启了，连接就已经绑定到那个数据源，此时再切数据源是无效的。你看起来调用了切库方法，实际写的还是原来那个库。
我的建议是：
- 读和写分离，事务尽量只放在写库一侧；
- 多个数据库之间的操作不要用同一个本地事务，除非你愿意引入分布式事务。但对量化系统里的大部分数据导入任务来说，分布式事务的成本远大于收益；
- 数据源切换要在事务开始之前完成，不要在Service方法内部穿插切换。
4.3 MyBatis 多数据源常见的配置事故
在网上搜“多数据源”相关的问题，经常能看到 MyBatis 批量操作写错库的讨论。典型场景大致是：
- 动态数据源切换之后，SqlSession 还是上一个数据源的连接，导致批处理写到旧库；
- 事务开了之后才切数据源，切换不生效；
- 主库和从库的表结构不一致，批量 saveOrUpdate 时字段对不上；
- 数据库驱动版本太老，连不上新版本数据库。
处理思路其实很固定：
- 先确认切换数据源的调用点是否在事务开始之前；
- 批量操作前打印当前连接对应的库名，确认物理连接真的切过去了；
- 主从库表结构用脚本统一管理，不要在手上去改其中一个库；
- 批量操作建议按批次提交，不要一次攒几万条再刷，一旦失败回滚成本很高。
注意：多数据源配置类问题，报错信息往往不会直接说“你连错库了”，而是表现为更新后数据没生效、批量操作部分成功部分失败。排查时要先确认当前线程绑定的是哪个连接，再往下查SQL。
5. 第五个坑：数据完整性、缺失值与增量更新，不做校验等于白存
5.1 停牌、新股、涨跌停、异常值：四种容易让策略误判的情况
即使数据源稳定，行情数据本身也有大量“特殊状态”。最常见的有四类：
停牌：股票停牌期间没有交易，数据源可能返回空、返回上一交易日收盘价、甚至不返回该股票。如果你的策略拿到空记录后直接跳过，或者拿到重复价格后继续计算指标，都可能在回测中产生虚假交易。
新股：上市初期价格波动大，且没有足够历史数据。很多策略会用到60日均线、120日均线，新股上市前几十天的指标是NaN。如果代码没有做过滤，NaN会顺着计算链传播，最后所有因子都变成空值。
涨跌停：股票在涨跌停一字板时，价格被限制在涨跌幅范围内，成交量很小，不代表真实买卖意愿。使用一字板的价格和成交量计算动量、波动率，会把市场状态判断错。
异常值：数据源可能存在个别错误成交记录，导致最高价或最低价远超合理范围。这类异常值应该结合涨跌停幅度和近期波动率过滤。
5.2 缺失值处理：填充之前先搞清楚为什么缺失
很多人一看到缺失值就想着前向填充、插值、删除。但在量化数据里，缺失的原因比缺失本身更重要。
同样是某一天缺失K线，如果是停牌导致的，前向填充价格可能是合理的，但成交量应该视为0或NaN，不能把停牌日当作正常交易日计算收益率；如果是数据源漏采，那应该去回补，而不是直接填充；如果那本来就不是交易日，那根本不算缺失，不需要处理。
所以我建议先维护一张交易日历表，用交易日历判断某一天到底该不该有数据。凡是交易日历上存在、但数据表里缺失的日期，才需要进一步处理。
5.3 增量更新和日终对账
增量更新最核心的要求是幂等。同一个交易日的数据，同一批数据源重复导入多次，结果必须是一致的，不能因为重复导入就出现重复记录或者重复复权。
实现方式很简单：在表结构上建立唯一键，比如symbol + exchange + trade_date + adj_status + source，然后使用 UPSERT 语义写入。每次导入前先删除同批次的旧数据，或者使用数据库的 ON DUPLICATE KEY UPDATE / MERGE 语法。
除了写入机制，还要做日终对账。每天收盘后至少检查这几项：
| 检查项 | 方法 |
|---|---|
| 数据数量 | 当天应有N条记录，实际有M条，N-M为缺失数 |
| 时间完整性 | 最后一根K线时间戳是否等于交易所收盘时间 |
| 价格合理性 | 判断 high 是否大于等于 open 和 close，low 是否小于等于 open 和 close |
| 复权一致性 | 除权除息日前后价格是否出现不合理跳空 |
| 交易日归属 | 夜盘记录是否归属到了正确交易日 |
这个对账清单看起来简单，但能拦住绝大多数数据问题。很多线上事故，都是因为缺少这一步，坏数据进入库后一直没人发现，等到策略跑偏才回头查。
6. 一条能长期跑的数据链路怎么搭
6.1 分成五层，每层只干一件事
聊完5个坑，最后给一套可以复用的落地框架。我不建议一上来就设计一个大而全的数据平台，但至少要按层划分职责，这样出问题时能快速定位。
- 采集层：对接外部数据源，把原始数据拉取下来。这一层只负责“拿到”，不负责清洗；
- 标准化层：完成字段映射、类型转换、时区归一、复权因子计算。这一层解决“口径统一”；
- 存储层：存储标准化之后的数据，包括行情表、交易日历表、复权因子表、数据源日志表；
- 校验层：同步检查数量、时间、价格、复权一致性，发现异常立即告警；
- 服务层：为策略端提供查询接口或数据文件。
每层之间不要跳过。比如采集层和存储层直接连，虽然写起来快，但后续任何口径变化都要改所有调用方，维护成本非常高。
6.2 先最小闭环，再逐步加工程化能力
很多新手拿到数据源之后，第一反应是把能下载的历史数据全部拉下来，然后开始写策略。这个顺序不太好。
我更建议先跑一个最小闭环：
- 手动导入3天到一周的数据到标准表；
- 写一行很简单的查询，比如算5日均线，人工核对结果；
- 拿一只自己很熟悉的股票，对比同一数据源在第三方终端里的K线数值；
- 跑一个最简单的均线策略回测，确认交易信号落在正确的日期上。
这个最小闭环通过之后，再考虑全量数据导入、增量更新、定时调度、监控告警。
数据接入的完整路径可以按“单次跑通 → 批量化 → 工程化”三步走。单次跑通只验证流程没断，批量化解决成本和效率，工程化才是解决长期稳定性的关键。
6.3 边界：什么数据源方案适合什么人群
最后把场景边界说清楚。不存在“所有情况下都最好”的数据源方案，适合自己的就是当前阶段最好的。
| 使用者 | 建议方案 | 注意点 |
|---|---|---|
| 新手学策略 | 免费标准库日线数据 | 只用于学习和验证流程，不要直接用来实盘回测 |
| 个人量化实盘 | 商业数据源 + 本地数据库 + 每日增量 | 必须做对账和完整性校验 |
| 团队产品化 | 多源备份 + 主备切换 + 全量监控 | 配置、版本、权限、告警都要纳入管理 |
免费数据源适合学习和小规模实验，但稳定性和准确性都不能和商业数据源相比。商业数据源也不是万能，字段定义、复权规则、时间归属都需要自己核对。券商柜台数据最权威，但并不是所有量化场景都能方便获取。
数据源这个环节，做的时候不显眼，但它就是整个量化系统最底层的地基。这5个坑不是一次性踩完就过去了，只要系统还在运行，数据源的问题就会反复出现。最好的应对方式不是“出问题再修”，而是从一开始就把数据源当成一个独立的工程模块来对待：先定标准，再做适配，最后持续校验。希望你能少走一段弯路，把精力留给真正有价值的策略研究。
