2. 数据基础设施搭建:数据源选择、数据库设计与数据清洗对齐

数据基础设施是因子库的“地基”。数据源的质量、数据库的读写性能以及数据清洗对齐的严谨程度,直接决定了后续因子计算与IC分析的可靠性。本章从三个核心环节展开:数据源选型、数据库设计、数据清洗与对齐流程。

2.1 数据源选择:Wind、Tushare、聚宽等对比

国内量化领域主流数据源可分为三类:商业终端、开源社区平台、量化SaaS平台。下表从数据覆盖、更新频率、成本、API易用性四个维度进行对比。

数据源 数据覆盖 更新频率 成本 API易用性 典型场景
Wind A股/港股/期货/债券/宏观 盘中实时+盘后 高(年费数万) Python/C++/Excel插件 机构投研、高频回测
Tushare A股/基金/指数/期货 日频为主,部分分钟 低(积分制,基础免费) HTTP RESTful API 个人研究、因子初筛
聚宽(JoinQuant) A股/期货/基金 日频+分钟 中(付费套餐) Python SDK,本地+云端 策略回测、因子平台
RiceQuant A股/期货 日频+分钟 中 Python SDK 策略回测、因子研究
AkShare A股/期货/宏观/另类 日频为主 免费 Python requests 另类数据、快速原型
选型建议:机构团队建议以Wind为主数据源,Tushare或聚宽作为补充(如因子数据缺失时的备选通道)。个人研究者可从Tushare或AkShare起步,成本低且社区活跃。

2.2 数据库设计:MySQL vs ClickHouse

因子库对数据库的核心要求是:列式存储(便于按因子字段批量读取)、时间分区(按交易日快速过滤)、高压缩比(降低存储成本)。MySQL与ClickHouse是两种典型选型。

2.2.1 数据库选型对比

特性 MySQL ClickHouse
存储引擎 行式存储(InnoDB) 列式存储(MergeTree)
查询性能(宽表) 慢(全表扫描) 快(列裁剪+向量化)
压缩比 低(约1:2) 高(约1:5~1:10)
时间分区 需手动分区表 内置分区+TTL
并发写入 支持(行锁) 批量写入(建议每秒一批)
运维复杂度 低 中(需关注MergeTree合并)
适用规模 因子数<200,日频 因子数>500,高频/分钟级
推荐方案:中小团队(因子数<200,日频)使用MySQL + 按交易日分区;大规模因子库(因子数>500,分钟级)使用ClickHouse + MergeTree引擎 + 按月分区。

2.2.2 数据库表结构设计(以MySQL为例)

因子库核心表设计遵循“宽表+分区”原则。以下为因子日频数据表结构示例:

CREATE TABLE factor_daily (
    trade_date DATE NOT NULL,
    stock_code VARCHAR(10) NOT NULL,
    factor_pe_ttm DECIMAL(20,4),
    factor_pb DECIMAL(20,4),
    factor_mom_20d DECIMAL(20,4),
    factor_vol_20d DECIMAL(20,4),
    factor_turnover_5d DECIMAL(20,4),
    factor_roe_ttm DECIMAL(20,4),
    -- 更多因子字段...
    update_time DATETIME DEFAULT CURRENT_TIMESTAMP,
    PRIMARY KEY (trade_date, stock_code),
    INDEX idx_stock (stock_code),
    INDEX idx_date (trade_date)
) ENGINE=InnoDB
PARTITION BY RANGE (YEAR(trade_date)) (
    PARTITION p2020 VALUES LESS THAN (2021),
    PARTITION p2021 VALUES LESS THAN (2022),
    PARTITION p2022 VALUES LESS THAN (2023),
    PARTITION p2023 VALUES LESS THAN (2024),
    PARTITION p2024 VALUES LESS THAN (2025),
    PARTITION p_future VALUES LESS THAN MAXVALUE
);
避坑提示:不要使用“股票代码+日期”作为唯一索引时忽略复权因子变化。同一股票同一日期可能因复权调整产生多行数据,建议在ETL阶段做去重或使用版本号字段。

2.3 数据清洗与对齐流程

数据清洗与对齐是因子库搭建中最耗时、最易出错的环节。核心流程包括:缺失值处理、异常值检测、复权对齐、交易日历对齐、截面对齐。

2.3.1 清洗对齐流程步骤

  1. 缺失值处理:对因子列按股票分组,前向填充(ffill)最多N个交易日,超出则置为NaN。
  2. 异常值检测:使用MAD(中位数绝对偏差)或3σ方法,将超出阈值的值替换为边界值(winsorize)。
  3. 复权对齐:统一使用后复权价格计算因子,避免前复权带来的未来信息泄露。
  4. 交易日历对齐:以交易所交易日历为基准,剔除非交易日数据,确保所有股票在同一日期有相同的时间戳。
  5. 截面对齐:在每个交易日,确保所有股票因子值在同一时间截面(如收盘后)计算,避免日内时序错位。
对齐黄金法则:因子计算时使用的价格、财务数据、成交量必须来自同一时间戳(如同一个收盘时刻)。任何跨日或跨时段的混用都会导致IC分析出现虚假相关性。

2.3.2 数据清洗对齐流程SVG

下图展示了从原始数据到因子库的完整清洗对齐流水线:

数据清洗对齐流程 数据清洗与对齐流水线 原始数据 缺失值处理 异常值检测 复权对齐 交易日历对齐 截面对齐 因子库 关键原则:每一步都需记录清洗日志(缺失率、异常值数量、对齐前后行数),便于回溯排查。

2.4 数据对齐的常见陷阱与解决方案

陷阱 表现 解决方案
未来信息泄露 使用前复权价格计算因子,导致当日因子包含未来除权信息 统一使用后复权价格,或使用未复权价格+复权因子自行计算
停牌日数据污染 停牌日价格不变,导致因子值异常(如波动率骤降) 停牌日因子值置为NaN,或使用停牌前最后有效值
财报发布日错位 使用最新财报数据时,未考虑实际发布日期与财报截止日的差异 建立财报发布日期表,因子计算时使用“截至当前日已发布的最新财报”
不同数据源时间戳不一致 Wind与Tushare同一股票同一日期的收盘时间相差数秒 统一以交易所收盘时间(15:00)为基准,对分钟数据做快照对齐

2.5 数据基础设施架构总览

下图展示了从数据源到因子库的完整数据流架构:

数据基础设施架构 数据基础设施架构总览 Wind Tushare 聚宽 AkShare 数据源层 ETL 清洗对齐引擎 处理层 MySQL ClickHouse 存储层 因子计算 & IC分析 应用层
架构要点:数据源层支持多源接入,ETL层统一清洗对齐,存储层根据规模选择MySQL或ClickHouse,应用层直接读取清洗后的因子数据。每一层之间通过标准接口(如DataFrame或Parquet文件)解耦,便于后续扩展。