量化因子库收官：从数据流到可复用因子库的工程化实践

量化金融里最难的不是把一个因子算出来，而是让因子从原始行情数据一路走到因子库之后，还能被信任、被复用、被持续更新。这篇是“365天量化金融”因子阶段的收官内容，核心就两个字：数据流。很多人做量化做了几个月，因子能算、回测能跑，但换一个数据源、换一段历史区间、换一台机器，结果就对不上了。问题不出在策略代码，而出在数据流和因子库没有真正建立起来。

适合谁看？适合正在自建量化研究和交易系统的开发者，尤其是已经能拿到行情数据、能写出因子公式，但还没有把因子管道化、工程化、可复用化的人。最值得关注的不是某一个因子的具体计算，而是从“有数据”到“有因子库”之间，究竟要完成哪些步骤、有哪些检查点、有哪些坑。

1. 先搞清楚“因子阶段收官”到底在收什么

因子研究做到一定程度，容易产生一种“什么都跑过、什么都存了，但用的时候找不到”的状态。今天说的收官，不是指把所有因子计算收尾，而是把因子从零散的脚本和临时文件里收口，变成一套有目录、有命名、有元数据、有校验的因子库。

先给三个判断标准。如果都满足，说明因子阶段可以收官：

• 新增一段行情数据之后，增量更新因子是自动的，不需要手工重跑全部脚本。
• 任何一个因子，外部的人看命名和元数据，就能说出它是什么周期、什么标的范围、什么计算参数。
• 回测或策略代码读取因子时，不依赖某个人的剪贴板、临时 Excel 或某个特定目录的绝对路径。

这三条看起来简单，但很多独立做量化的人一条都做不到。常见的情况是：因子计算脚本散落在.py和.ipynb文件里，同一个因子有多个版本，数据更新之后旧结果没有清理，最终策略里到底加载的是哪个文件，只有当时写代码的人自己能推断。

所以，因子阶段收官，收的不是“因子数量”，而是“数据流和因子库工程化”。

1.1 因子研究的最终交付物不是因子，而是可复用的因子库

因子本身是一种中间产物。你在研究阶段算出一个动量因子、一个波动率因子、一个量价相关性因子，它们解决的是策略信号问题。但如果你想做多因子组合、因子轮动、因子衰减分析，就必须把因子当作数据资产管理。

这意味着每个因子至少要有：

• 唯一标识：字段名，比如mom_20d_close，不能叫factor1。
• 含义说明：因子定义、输入字段、计算逻辑。
• 参数记录：窗口大小、是否截尾、是否中性化、中性化方式。
• 数据版本：基于哪个数据源、哪个复权方式、哪个截至日期。

这些内容统一放到元数据表里，比因子数据本身还重要。因为因子算错一次，以后所有基于它的回测、组合、信号都可能是错的；而解决这个问题的关键，就是能追溯“这个因子是用什么数据算出来的”。

1.2 数据流和因子库是两件事，但它们必须连起来看

数据流指的是从原始数据采集，到清洗、对齐、计算、存储、读取的完整管道。因子库只是这条管道的终点之一。

如果只管理因子库，不管理数据流，那么因子库会迅速变成一次性的产物。数据源一换就废，日期范围一变就断，字段风格一改就乱。反过来，如果只关注数据采集和清洗，没有把它接到因子库上，那么数据质量做得再好，也无法反馈到策略中。

所以“从数据流到因子库”并不是两个独立阶段，而是先有稳定的数据流，才能有可信的因子库。下面按落地顺序拆开讲。

2. 从数据流到因子库：整体数据链路的 5 个层次

一次完整的量化数据链路，我个人习惯分成 5 层。分层的目的是把不同职责切开，避免一锅烩。

层次	主要任务	典型存储形式	最容易出现的问题
数据源层	获取原始行情、财务、指数、行业等数据	外部数据接口、第三方文件	字段格式不统一、缺失、单位不一致
原始数据层	原样落盘，不做任何修改	Parquet、CSV、HDF5 按日或按标的拆分	重复下载、没有校验、无法回溯
清洗层	去重、补全、异常识别、类型转换	清洗后的标准目录	把“缺失”直接填 0，引入错误
因子计算层	根据原始字段计算时间序列特征	中间特征表或内存计算	参数没记录、版本混乱、重算成本高
因子库层	存储最终因子、元数据、校验记录	Parquet + 元数据表	没有目录规范、无增量逻辑、无监控

每一层之间用一个明确的任务边界隔开。原始数据层只能做“原样落地”，清洗层才允许改值，因子计算层不允许直接读取外部数据源。这样可以防止有人在某个因子里直接接了原始数据接口，导致因子和清洗逻辑耦合。

2.1 五层数据链路的划分

把数据链路拆成 5 层，最大的好处是排查问题时有明确的入口。

• 如果因子值异常，先看因子计算层参数和输入。
• 如果输入看起来不对，再往下看清洗层。
• 如果清洗层也不对，再往下看原始数据层，看看原始文件是否完整。
• 如果原始文件都丢了，那就直接定位到数据源层，重新增量拉取。

我见过很多人做量化时跳过清洗层，直接在原始数据上算因子。短期没问题，时间一长，原始数据里的单位、复权方式、停牌标记、缺失值规则一旦变化，所有因子全部要重算。建立清洗层的意义，就是把这些规则固定下来，不让它们影响因子计算。

2.2 每层最容易出问题的地方

数据源层最典型的坑是复权方式不统一。有的数据源默认向前复权，有的默认向后复权，有的需要单独下载复权因子。如果因子计算层没有固定统一成一种复权口径，回测结果就会受除权除息影响，尤其做长期动量因子时非常明显。

原始数据层最容易出现的是“以为下载成功，实际文件只有一部分”。所以要给每个数据文件加一个完整性检查，例如记录文件行数、日期范围、最后更新时间，并在写入时生成一个校验标记。

清洗层最容易出问题的是把缺失值和 0 值混为一谈。财务因子比较常遇到：停牌期间成交量为 0 是正常的，利润数据缺失则不能直接填 0。正确的做法是保留缺失，并在因子计算时区分“停牌无交易”和“数据缺失”。

3. 数据流落地的关键环节：采集、清洗、对齐、复权

说了分层，接下来讲每个环节的具体操作。这些环节是数据流到因子库之间最影响结果的部分，比因子公式本身更需要花时间。

3.1 采集：先按源和粒度组织目录

采集阶段的目标不是把数据全部下载下来，而是让后续每个环节都知道“数据在哪、是什么版本”。我建议按“数据源 / 市场 / 数据类型 / 时间粒度”组织目录。

例如：

data/ raw/ source_a/ china_stock/ daily/ 2024-01-01.parquet 2024-01-02.parquet minute/ 2024-01-01.parquet source_b/ financials/ quarterly/ 2024Q1.parquet

这样做的原因是：增量更新时只需要扫描缺失日期，不需要对整个目录重新遍历。如果某个数据源字段对齐有问题，也只需要重拉这一层，不影响其他层。

采集过程中要记录两个时间：数据日期和采集日期。数据日期是数据本身对应的交易日，采集日期是这个文件什么时候被拉下来。这两个字段在后续排查“为什么某一天数据不完整”时非常有用。

3.2 清洗：不要只做缺失值填充

清洗层要有顺序，顺序错了结果就会偏。我的顺序通常是：

1. 去重：同一交易标的同一交易日出现两次的，只保留一条，并记录 Duplicate。
2. 格式统一：日期转成统一格式，代码统一成 6 位，浮点数和整数分开处理。
3. 缺失标记：区分 NaN、0、None、停牌、未上市、已退市。
4. 异常识别：价格、成交量、收益率出现极端值或负值时，给出异常标记而不是直接改值。
5. 复权处理：如果后续因子需要，按统一口径计算复权价。

清洗层不负责“把它改成我们认为正确的值”，只负责“把它标记出来”。把异常值直接改掉，会让后续所有分析失去对数据真实性的信任。正确方式是保留原始值，加上一个异常标志列，让因子计算层决定是否剔除。

3.3 对齐与复权：因子计算前的最后一道关卡

“对齐”这个词在量化里包含两层意思。

第一层是交易日历对齐。不同数据源的交易日历可能不同，有的数据源 9 月 30 日有数据，有的没有。因子计算前必须统一使用同一个交易日历，避免某个因子在 9 月 30 日算出的收益率是过去两天或三天的混合。

第二层是财务数据的时间对齐。财务数据不能按财报期直接对齐到当前日期，必须按“实际披露日期”对齐，否则就用了未来数据。这里的常见做法是维护一个财报披露日期表，在因子计算时只取披露日期之前的数据。

复权处理则要根据因子类型选择。做短期量价因子，通常用前复权价；做长期动量因子，要特别小心复权方式对收益率的扭曲。比较稳妥的方式是原始数据保留不复权价，同时单独保存复权因子表，计算时再根据因子需求决定是否复权。这样最灵活，也最容易排查。

4. 因子计算阶段：命名、参数、版本和增量计算

数据流稳定之后，才进入因子计算。但因子计算阶段真正难的不是数学公式，而是管理。

4.1 因子命名规范：字段名就是因子在数据库里的身份证

我给所有因子命名都会遵守同一套规则：

类型_窗口_标的字段_处理方式

例如：

• mom_20d_close_ret：20 日收益率动量因子。
• vol_60d_ret_std：60 日收益率标准差因子。
• turn_5d_amount_avg：5 日成交额均值因子。

这套命名方式看起来啰嗦，但读代码时非常直观。数据库字段、因子文件列名、元数据里的因子名必须完全一致，否则策略代码里很容易出现“读错列”这种低级错误。

不建议使用factor_01、alpha_007这种名字。因为 007 是什么逻辑，一年后自己也想不起来。

4.2 参数记录与版本控制

因子计算一般都有窗口、阈值、中性化、去极值等参数。这些参数必须记录，且最好记录成结构化格式。

例如，一个 20 日动量因子的元数据可以这样存：

{ "factor_name": "mom_20d_close_ret", "definition": "20 个交易日前收盘价到当前收盘价的收益率", "input_fields": ["close"], "window": 20, "fillna": false, "winsorize": { "method": "mad", "n": 3 }, "neutralize": null, "data_version": "2024-06-30", "created_by": "factor_pipeline_v1" }

参数版本同样重要。同一个因子，如果后来把 window 从 20 改成 30，那么它应该是一个新因子，或者在元数据里明确标识版本号。不建议直接覆盖旧文件，否则回测时无法复现历史结果。

4.3 增量计算与重复计算

因子计算的常规流程是先确认数据日期范围，再计算缺失日期，最后更新元数据。

增量计算的核心逻辑是：

1. 读取因子库已有日期范围。
2. 计算已覆盖日期和最新数据日期之间的差集。
3. 只对差集部分重新计算。
4. 追加写入并重写索引或分区元数据。

注意：不要每次新增一天数据就全量重算所有因子。全量重算在股票数量少、窗口短、因子少的时候能接受，一旦标的扩展到全市场几千只，窗口拉到 250 日，因子扩充到几十个，全量重算的时间会成倍增加。

另外，增量计算时要小心“窗口依赖”。20 日动量因子如果要算第 T 天的值，依赖 T-20 到 T 的收盘价。因此增量计算不能只从新增日期开始，而要从新增日期往前回退足够的窗口长度。这个细节很容易漏，一漏就会导致增量结果和全量结果不一致。

5. 因子库存储与目录设计

因子算完之后，需要有一个统一入口读取。这就是因子库。因子库不一定要用重型数据库，很多独立量化者用文件系统就能完成，但目录和格式要规范。

5.1 先讲目录，再讲格式

一个简单的因子库目录结构可以这样：

factor_library/ factors/ mom_20d_close_ret/ 2024-01-01_2024-06-30.parquet vol_60d_ret_std/ 2024-01-01_2024-06-30.parquet meta/ factor_meta.json data_version.json checks/ missing_rate_2024-06-30.json

这样做有几点好处：

• 单个因子一个目录，方便单独更新。
• 数据按日期范围切分，可以只增量追加新文件，不覆盖旧文件。
• meta 目录集中管理元数据和数据版本，不跟随数据文件散落。
• checks 目录放质量检查结果，方便排查时回溯哪一天做过校验。

5.2 parquet、hdf5、csv、数据库怎么选

不同格式适合不同场景：

格式	优点	缺点	适用场景
Parquet	列式存储，读取快，支持压缩	单个文件不方便手工查看	因子库主力格式
HDF5	单文件多数据集，读写灵活	文件损坏时恢复困难，并发写容易出现锁问题	小规模原型或研究过程中的中间存储
CSV	可直接用 Excel 打开	体积大，读取慢，无 schema 校验	临时调试、导出给同事
DuckDB / SQLite	支持 SQL 查询，方便按条件过滤	需要额外依赖，SQLite 并发较弱	因子查询、跨因子筛选、多条件下钻

我自己的组合是：因子主存储用 Parquet 文件，按日期分区；元数据用 JSON 或 SQLite；临时查询工具用 DuckDB。这个组合在个人量化和小团队中够用，而且不引入额外服务。

如果团队规模变大、需要多人同时读因子库，再考虑把因子数据迁移到 ClickHouse 或 PostgreSQL 等集中式存储。迁移的关键是保留字段命名和元数据，不要改因子名。

6. 因子库质量校验：哪些指标必须盯

因子库能不能被信任，靠的不是感觉，而是校验。以下是我每次更新因子库后都会检查的指标。

6.1 数据质量指标：缺失率、覆盖率、方差、极值

缺失率不只是看整体缺失比例，还要看缺失是否集中在特定股票、特定时间段。比如一个波动率因子在今年 3 月到 5 月缺失率突然升高，很可能是这段时间的数据源出了断更问题，而不只是因子本身无值。

覆盖率的判断标准是：因子有效值数量 / 当日全市场可交易股票数量。覆盖率明显下降时，要检查是不是停牌股票过多、新股不足窗口期、或者财务数据未及时更新。

方差和极值检查方面，最有效的是看因子值分布。因子值出现大量极值，或者某一天的标准差突然飙升，大概率是输入数据有问题。可以先不急着改因子，而是回看清洗层的异常标记。

6.2 计算正确性校验：增量对比、逻辑回归、样本外检查

一个很实用的校验方法：每次增量计算后，取最近一个已经覆盖的日期，用增量结果和旧结果对比，值应该完全一致。如果不一致，说明增量逻辑里窗口依赖处理错了。

另一个方法是做逻辑回归或 IC 分析。因子和未来收益率之间的 IC 在合理范围内有波动是正常的，但如果一个因子突然变得特别显著或者完全不显著，先确认是不是数据口径变化，比如换成了后复权、换了财务数据源。

样本外检查适合定期做。把数据分成两段，前段做因子筛选，后段做验证。这个阶段不追求绝对收益，追求的是因子在样本外的稳定性。如果样本内很好、样本外失效，很可能是因子过拟合了参数。

6.3 监控与告警：长期可维护性

因子库不是一次建完就完事。数据每天更新，因子每天更新，质量也要每天检查。最简单的做法是每天跑一个检查脚本，把缺失率、覆盖率、更新延迟、新增因子数量写入一个 JSON 文件，再让调度工具读它。

这些告警不一定非要接入复杂的监控平台，可以先从一个简单的状态文件开始，再做定时邮件或消息通知。关键是把“检查”固化到流程里，否则因子库过一个月就变成没人知道里面有什么的旧仓库。

7. 从学习到生产：排查链路和个人建议

最后一段是实战里容易遇到的排查顺序，以及我自己的落地建议。

7.1 排查链路

当发现某个因子的值异常、覆盖不全、或者回测结果和预期严重不符时，我建议按照下面顺序排查：

1. 先看因子本身：字段名、参数、版本号是否被策略代码正确引用。
2. 再看因子计算输入：用的是清洗层数据还是原始数据，复权方式是否符合因子定义。
3. 然后看清洗层：缺失值、异常值、停牌标记有没有被错误处理。
4. 继续看原始数据：文件是否完整，日期范围是否符合预期，数据源有没有字段变更。
5. 最后看数据源：复权因子、更新延迟、字段单位是否有变化。

这个顺序的核心思路是从“离现象最近的地方”开始，逐渐往源头排查。大多数人喜欢一上来就检查数据源，但很多时候问题出在策略代码引用了旧文件和旧参数，和数据源根本无关。

7.2 个人建议

如果做量化还没有到大规模生产阶段，不建议一开始就设计一个巨大的分布式数据平台。先把单机文件系统 + Parquet + 元数据 JSON 这套最小结构跑稳，再逐步加索引、加 SQL 查询、加调度。

我更建议先跑通一个完整闭环：日线数据 → 清洗 → 计算 3 到 5 个因子 → 存入因子库 → 做一次简单回测。这个闭环能跑通，后面扩展数据源、扩展因子数量、接入实时数据就会顺畅很多。

量化金融里的数据流建设，本质不是技术炫技，而是让每一份数据都来源清晰、口径统一、可回溯。因子库做得越稳，后面的组合优化和策略研究就越省心。建议在因子阶段收官的节点上，把数据链路完整走一遍，而不是继续堆因子数量。