做量化这件事很多人一开始把精力全压在策略上均线、因子、机器学习、网格交易看起来每一步都很有成就感。但真正跑过一段时间的人都会承认最先暴露问题的往往不是策略而是数据。数据源这个环节看起来只是“找个接口把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, exchangeSH)这里的重点不是某个具体的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 和服务器地址而不是只写 DSNDriver{ODBC Driver 17 for SQL Server};Server127.0.0.1;Databasequant;Trusted_Connectionno;UIDquant_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 和 closelow 是否小于等于 open 和 close复权一致性除权除息日前后价格是否出现不合理跳空交易日归属夜盘记录是否归属到了正确交易日这个对账清单看起来简单但能拦住绝大多数数据问题。很多线上事故都是因为缺少这一步坏数据进入库后一直没人发现等到策略跑偏才回头查。6. 一条能长期跑的数据链路怎么搭6.1 分成五层每层只干一件事聊完5个坑最后给一套可以复用的落地框架。我不建议一上来就设计一个大而全的数据平台但至少要按层划分职责这样出问题时能快速定位。采集层对接外部数据源把原始数据拉取下来。这一层只负责“拿到”不负责清洗标准化层完成字段映射、类型转换、时区归一、复权因子计算。这一层解决“口径统一”存储层存储标准化之后的数据包括行情表、交易日历表、复权因子表、数据源日志表校验层同步检查数量、时间、价格、复权一致性发现异常立即告警服务层为策略端提供查询接口或数据文件。每层之间不要跳过。比如采集层和存储层直接连虽然写起来快但后续任何口径变化都要改所有调用方维护成本非常高。6.2 先最小闭环再逐步加工程化能力很多新手拿到数据源之后第一反应是把能下载的历史数据全部拉下来然后开始写策略。这个顺序不太好。我更建议先跑一个最小闭环手动导入3天到一周的数据到标准表写一行很简单的查询比如算5日均线人工核对结果拿一只自己很熟悉的股票对比同一数据源在第三方终端里的K线数值跑一个最简单的均线策略回测确认交易信号落在正确的日期上。这个最小闭环通过之后再考虑全量数据导入、增量更新、定时调度、监控告警。数据接入的完整路径可以按“单次跑通 → 批量化 → 工程化”三步走。单次跑通只验证流程没断批量化解决成本和效率工程化才是解决长期稳定性的关键。6.3 边界什么数据源方案适合什么人群最后把场景边界说清楚。不存在“所有情况下都最好”的数据源方案适合自己的就是当前阶段最好的。使用者建议方案注意点新手学策略免费标准库日线数据只用于学习和验证流程不要直接用来实盘回测个人量化实盘商业数据源 本地数据库 每日增量必须做对账和完整性校验团队产品化多源备份 主备切换 全量监控配置、版本、权限、告警都要纳入管理免费数据源适合学习和小规模实验但稳定性和准确性都不能和商业数据源相比。商业数据源也不是万能字段定义、复权规则、时间归属都需要自己核对。券商柜台数据最权威但并不是所有量化场景都能方便获取。数据源这个环节做的时候不显眼但它就是整个量化系统最底层的地基。这5个坑不是一次性踩完就过去了只要系统还在运行数据源的问题就会反复出现。最好的应对方式不是“出问题再修”而是从一开始就把数据源当成一个独立的工程模块来对待先定标准再做适配最后持续校验。希望你能少走一段弯路把精力留给真正有价值的策略研究。
做量化这件事很多人一开始把精力全压在策略上均线、因子、机器学习、网格交易看起来每一步都很有成就感。但真正跑过一段时间的人都会承认最先暴露问题的往往不是策略而是数据。数据源这个环节看起来只是“找个接口把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, exchangeSH)这里的重点不是某个具体的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 和服务器地址而不是只写 DSNDriver{ODBC Driver 17 for SQL Server};Server127.0.0.1;Databasequant;Trusted_Connectionno;UIDquant_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 和 closelow 是否小于等于 open 和 close复权一致性除权除息日前后价格是否出现不合理跳空交易日归属夜盘记录是否归属到了正确交易日这个对账清单看起来简单但能拦住绝大多数数据问题。很多线上事故都是因为缺少这一步坏数据进入库后一直没人发现等到策略跑偏才回头查。6. 一条能长期跑的数据链路怎么搭6.1 分成五层每层只干一件事聊完5个坑最后给一套可以复用的落地框架。我不建议一上来就设计一个大而全的数据平台但至少要按层划分职责这样出问题时能快速定位。采集层对接外部数据源把原始数据拉取下来。这一层只负责“拿到”不负责清洗标准化层完成字段映射、类型转换、时区归一、复权因子计算。这一层解决“口径统一”存储层存储标准化之后的数据包括行情表、交易日历表、复权因子表、数据源日志表校验层同步检查数量、时间、价格、复权一致性发现异常立即告警服务层为策略端提供查询接口或数据文件。每层之间不要跳过。比如采集层和存储层直接连虽然写起来快但后续任何口径变化都要改所有调用方维护成本非常高。6.2 先最小闭环再逐步加工程化能力很多新手拿到数据源之后第一反应是把能下载的历史数据全部拉下来然后开始写策略。这个顺序不太好。我更建议先跑一个最小闭环手动导入3天到一周的数据到标准表写一行很简单的查询比如算5日均线人工核对结果拿一只自己很熟悉的股票对比同一数据源在第三方终端里的K线数值跑一个最简单的均线策略回测确认交易信号落在正确的日期上。这个最小闭环通过之后再考虑全量数据导入、增量更新、定时调度、监控告警。数据接入的完整路径可以按“单次跑通 → 批量化 → 工程化”三步走。单次跑通只验证流程没断批量化解决成本和效率工程化才是解决长期稳定性的关键。6.3 边界什么数据源方案适合什么人群最后把场景边界说清楚。不存在“所有情况下都最好”的数据源方案适合自己的就是当前阶段最好的。使用者建议方案注意点新手学策略免费标准库日线数据只用于学习和验证流程不要直接用来实盘回测个人量化实盘商业数据源 本地数据库 每日增量必须做对账和完整性校验团队产品化多源备份 主备切换 全量监控配置、版本、权限、告警都要纳入管理免费数据源适合学习和小规模实验但稳定性和准确性都不能和商业数据源相比。商业数据源也不是万能字段定义、复权规则、时间归属都需要自己核对。券商柜台数据最权威但并不是所有量化场景都能方便获取。数据源这个环节做的时候不显眼但它就是整个量化系统最底层的地基。这5个坑不是一次性踩完就过去了只要系统还在运行数据源的问题就会反复出现。最好的应对方式不是“出问题再修”而是从一开始就把数据源当成一个独立的工程模块来对待先定标准再做适配最后持续校验。希望你能少走一段弯路把精力留给真正有价值的策略研究。
