在实际量化研究项目中数据存储方案的选择往往比策略模型本身更早地决定了一个项目的天花板。很多个人研究者在初期会习惯性地使用 CSV 或 Excel 文件但随着数据量增长、因子维度增加以及回测频率提升文件读写慢、内存溢出、数据一致性差等问题会迅速成为瓶颈。此时选择一个合适的数据库不仅能解决存储问题更能为后续的数据清洗、因子计算、回测引擎乃至实盘对接提供一个稳定、高效、可扩展的基础设施。本文面向的是具备一定 Python 编程和量化基础的个人研究者或小型团队。我们将从量化数据的典型特征如时间序列、高维度、高频读写出发系统性地对比几种主流数据库方案包括关系型数据库如 PostgreSQL、时序数据库如 InfluxDB、列式存储如 Apache Parquet DuckDB以及内存数据库如 Redis。文章不会停留在理论对比而是会给出具体的技术选型决策树、环境搭建步骤、数据入库与查询的代码示例并重点分析在回测、因子计算等典型场景下的性能表现和常见陷阱。读完本文你将能够根据自己当前的数据规模、硬件条件和研究阶段做出一个清晰、可落地的数据库选型决策。1. 量化数据特征与数据库选型核心维度在讨论具体数据库之前必须明确量化研究数据的特点这直接决定了数据库需要具备哪些能力。1.1 量化数据的典型特征强时间序列属性所有行情数据tick、分钟线、日线、因子数据、信号数据都严格依赖时间戳。查询模式高度集中于时间范围查询如WHERE date BETWEEN 2023-01-01 AND 2023-12-31和按时间排序。多维度、宽表结构单个标的股票、期货等在某个时间点上的状态可能由数百个因子技术指标、基本面数据、另类数据共同描述形成非常“宽”的表结构。高吞吐的写入与读取在数据预处理和因子计算阶段需要批量写入海量历史数据在回测阶段则需要按照时间顺序高速、顺序或随机读取大量标的的数据。以分析型查询为主与交易系统不同研究环境的查询多为复杂的分析型查询OLAP例如跨标的多因子回归、截面排名、分组统计等涉及大量的聚合SUM, AVG、连接JOIN和窗口函数Window Function操作。数据局部更新频繁因子值可能随着计算逻辑的调整而重新计算需要更新特定时间段、特定标的的数据而非全表覆盖。1.2 数据库选型的四个核心评估维度基于以上特征我们可以从四个维度评估一个数据库是否适合量化研究场景维度说明对量化研究的重要性时序优化原生支持时间序列数据模型对时间戳建立高效索引优化时间范围查询。高。直接决定行情和因子数据查询效率。列式存储按列而非按行存储数据。当查询只涉及少数列如只查收盘价和成交量时可以极大减少 I/O。高。因子表通常很宽但每次计算可能只用到其中几列。分析性能对聚合查询、复杂 JOIN、窗口函数等 OLAP 操作有良好支持和高性能引擎。高。因子计算和归因分析依赖此类操作。易用性与生态安装部署的复杂度、与 Python 生态pandas, numpy的集成度、社区活跃度和学习成本。中高。个人研究者需要快速上手避免在基础设施上耗费过多精力。2. 主流方案深度对比与适用场景下面我们将几种常见方案放入上述评估框架中进行对比。2.1 通用关系型数据库PostgreSQL / MySQL这是最容易被首先想到的方案利用其成熟的 SQL 引擎和事务支持。PostgreSQL 示例创建行情数据表CREATE TABLE market_data ( symbol VARCHAR(20) NOT NULL, trade_date DATE NOT NULL, open_price DECIMAL(12, 4), high_price DECIMAL(12, 4), low_price DECIMAL(12, 4), close_price DECIMAL(12, 4), volume BIGINT, turnover DECIMAL(20, 4), PRIMARY KEY (symbol, trade_date) ); CREATE INDEX idx_market_data_date ON market_data(trade_date);优点功能全面完整的 SQL 支持事务 ACID 特性适合需要强一致性的场景。生态强大连接工具如 DBeaver, Navicat、ORM 框架SQLAlchemy支持完善。扩展性好PostgreSQL 的 TimescaleDB 插件可使其变身专业的时序数据库MySQL 也有其适用场景。缺点时序查询非原生优化即使对时间戳建索引在超大规模单时间点查询例如查询全市场3000只股票某一天的数据时性能可能不如专业时序库。行式存储对于宽表的列式查询效率较低I/O 压力大。分析性能一般对于复杂的多标的多因子聚合分析性能可能成为瓶颈。适用场景数据量不大例如仅 A 股日线数据十年数据量约 700 万行。查询模式相对简单不涉及极其复杂的分析。项目初期追求快速验证想法且团队对 SQL 非常熟悉。需要与现有系统如 Web 服务共享数据库。2.2 专业时序数据库InfluxDB / TimescaleDB专为时间序列数据设计在写入、压缩和时间窗口查询上具有天然优势。InfluxDB 示例写入行情数据使用 InfluxDB 2.x Python Clientfrom influxdb_client import InfluxDBClient, Point, WritePrecision from influxdb_client.client.write_api import SYNCHRONOUS client InfluxDBClient(urlhttp://localhost:8086, tokenyour-token, orgyour-org) write_api client.write_api(write_optionsSYNCHRONOUS) point Point(market_data) \ .tag(symbol, 000001.SZ) \ .field(open, 12.50) \ .field(high, 12.80) \ .field(low, 12.40) \ .field(close, 12.75) \ .field(volume, 1000000) \ .time(2023-10-27T15:00:00Z, WritePrecision.NS) write_api.write(bucketquant_bucket, recordpoint)优点极高的时序写入和查询性能数据模型和存储引擎为时间戳优化压缩率高。内置时间窗口函数轻松进行按日、周、月的聚合统计。生态针对监控和指标与 Grafana 等看板工具集成极佳。缺点SQL 支持有限或语法特殊InfluxDB 使用 Flux 或类 SQL复杂分析能力不如标准 SQL 强大。TimescaleDB基于 PostgreSQL则兼容标准 SQL。非标准关系模型多表关联查询JOIN能力较弱不适合需要频繁跨表关联的复杂因子计算。学习成本需要理解其独特的数据模型Measurement, Tag, Field。适用场景存储高频 tick 数据、分钟线数据查询模式主要是按标的和时间的单维度查询。对写入速度和存储压缩比有极高要求。分析查询相对简单不涉及复杂跨表关联。2.3 列式存储 分析引擎Apache Parquet DuckDB这是一种新兴的、备受数据科学社区青睐的架构。将数据以列式格式Parquet存储在文件系统如本地 SSD 或对象存储 S3使用 DuckDB 进行内存分析。操作示例将 pandas DataFrame 保存为 Parquet并用 DuckDB 查询import pandas as pd import duckdb # 1. 模拟一个因子宽表 DataFrame df pd.DataFrame({ date: pd.date_range(2023-01-01, periods100, freqD), symbol: [STOCK_A] * 100, factor_ma5: np.random.randn(100), factor_ma20: np.random.randn(100), factor_rsi: np.random.randn(100), # ... 更多因子列 }) # 2. 保存为 Parquet 文件列式存储 df.to_parquet(factor_data.parquet) # 3. 使用 DuckDB 直接查询 Parquet 文件无需导入数据库 conn duckdb.connect() result conn.execute( SELECT symbol, AVG(factor_ma5) as avg_ma5, STDDEV(factor_rsi) as std_rsi FROM read_parquet(factor_data.parquet) WHERE date 2023-02-01 GROUP BY symbol ).fetchdf() print(result)优点极致分析性能DuckDB 是为 OLAP 设计的进程内数据库无需服务端直接在内存中执行对复杂 SQL 查询速度极快。完美的 Python 生态集成与 pandas DataFrame 可以零成本转换查询结果直接是 DataFrame。存储与计算分离Parquet 文件是静态的易于备份、共享和版本管理。计算资源按需使用。成本极低完全免费部署简单适合个人研究者。缺点并发写入能力弱DuckDB 更适合“一次写入多次读取”的分析场景高并发写入不是其强项。数据需完全载入内存虽然 DuckDB 会优化但处理远超内存大小的数据时仍需技巧如分区。无服务端对于需要多进程/多机器共享同一实时数据库的场景不适用。适用场景个人量化研究的首选方案。数据量在单机内存可处理范围内数十GB。研究流程以“数据准备 - 批量因子计算 - 回测”为主中间结果可以物化为文件。需要频繁进行探索性数据分析EDA和复杂 SQL 查询。2.4 内存数据库Redis严格来说Redis 并非用于持久化存储和分析但其在量化系统中扮演着重要角色。适用场景缓存中间结果将计算耗时的因子值、预处理后的数据缓存起来加速回测迭代。存储实时信号在实盘系统中作为高速通道存储最新的交易信号、风控状态。发布/订阅用于不同模块数据抓取、因子计算、风控、交易之间的消息通信。不适用场景作为主要的、持久化的历史数据存储和分析引擎。3. 决策树与混合架构实践面对众多选择个人研究者可以遵循以下决策路径graph TD A[开始选型] -- B{数据量 查询复杂度}; B -- 数据量小br查询简单 -- C[使用 PostgreSQL]; B -- 数据量大br以时序点查询为主 -- D[使用时序数据库 InfluxDB/TimescaleDB]; B -- 数据量大br以复杂分析查询为主 -- E{是否需要多进程/服务共享}; E -- 是 -- F[考虑 PostgreSQL 或 ClickHouse]; E -- 否 -- G[强烈推荐 Parquet DuckDB]; G -- H[完成]; C -- H; D -- H; F -- H;在实际项目中混合使用多种存储方案往往是更优解。一个典型的混合架构如下原始数据层将清洗后的基础数据日线、分钟线以Parquet格式存储在硬盘或对象存储上。这是你的“数据湖”成本低易管理。因子计算与中间存储使用DuckDB从 Parquet 文件中读取数据执行复杂的因子计算 SQL。将计算结果因子宽表再次输出为新的 Parquet 文件集。回测引擎数据源回测时回测引擎如 Backtrader, Qlib直接读取因子 Parquet 文件或通过 DuckDB 接口查询实现高速数据供给。缓存与实时层可选对于需要极低延迟访问的中间数据或参数使用Redis进行缓存。元数据与结果管理使用轻量级的SQLite或PostgreSQL存储回测结果、策略参数、实验记录等结构化元数据。4. 实战基于 Parquet DuckDB 搭建研究数据栈下面我们以一个具体的例子展示如何用 Parquet 和 DuckDB 构建一个可用的量化研究数据环境。4.1 环境准备与数据准备首先安装必要的 Python 库pip install pandas numpy duckdb pyarrow假设我们已有 CSV 格式的日线数据stock_daily.csv包含symbol,date,open,high,low,close,volume字段。4.2 步骤一将原始数据转换为 Parquet将不同数据源统一转换为 Parquet这是构建高效数据栈的第一步。import pandas as pd import os # 读取 CSV df pd.read_csv(stock_daily.csv, parse_dates[date]) # 按标的和日期排序这对后续查询性能有帮助 df df.sort_values([symbol, date]).reset_index(dropTrue) # 保存为 Parquet。使用 snappy 压缩以平衡速度与体积。 df.to_parquet(stock_daily.parquet, enginepyarrow, compressionsnappy) # 对于超大数据可以按日期或标的进行分区存储DuckDB 能高效读取分区数据。 # 例如按年份分区 os.makedirs(stock_daily_partitioned, exist_okTrue) for year, group in df.groupby(df[date].dt.year): group.to_parquet(fstock_daily_partitioned/year{year}/data.parquet, enginepyarrow)4.3 步骤二使用 DuckDB 进行探索性分析现在我们可以不将数据导入任何数据库服务直接进行查询。import duckdb conn duckdb.connect() # 查询某只股票2023年的所有数据 query1 SELECT * FROM read_parquet(stock_daily.parquet) WHERE symbol 000001.SZ AND date BETWEEN 2023-01-01 AND 2023-12-31 ORDER BY date df_000001 conn.execute(query1).fetchdf() print(df_000001.head()) # 复杂的分析查询计算所有股票2023年的年化收益率和波动率 query2 WITH daily_returns AS ( SELECT symbol, date, close, LN(close / LAG(close) OVER (PARTITION BY symbol ORDER BY date)) AS daily_log_return FROM read_parquet(stock_daily.parquet) WHERE date 2023-01-01 ) SELECT symbol, COUNT(*) as trading_days, AVG(daily_log_return) * 252 as annualized_return, STDDEV(daily_log_return) * SQRT(252) as annualized_volatility FROM daily_returns WHERE daily_log_return IS NOT NULL GROUP BY symbol HAVING COUNT(*) 100 -- 过滤掉交易天数过少的股票 ORDER BY annualized_return DESC factor_df conn.execute(query2).fetchdf() print(factor_df.head())4.4 步骤三将 DuckDB 查询集成到因子计算流程你可以将复杂的因子计算逻辑编写成 SQL 视图或 CTE公用表表达式让 DuckDB 高效执行。# 定义一个计算移动平均因子的函数 def calculate_ma_factors(parquet_path, ma_windows[5, 10, 20]): conn duckdb.connect() # 动态生成 SQL计算多个移动平均 ma_columns [] for w in ma_windows: ma_columns.append(fAVG(close) OVER (PARTITION BY symbol ORDER BY date ROWS BETWEEN {w-1} PRECEDING AND CURRENT ROW) AS ma_{w}) ma_columns_sql , .join(ma_columns) query f SELECT symbol, date, close, {ma_columns_sql} FROM read_parquet({parquet_path}) result_df conn.execute(query).fetchdf() # 将结果保存为新的因子 Parquet 文件 result_df.to_parquet(factor_ma.parquet, enginepyarrow) return result_df factor_df calculate_ma_factors(stock_daily.parquet)4.5 步骤四在回测中读取因子数据在回测框架中此处以伪代码示意可以直接读取 Parquet 文件或通过 DuckDB 查询。# 伪代码以 Backtrader 为例 import backtrader as bt import pandas as pd class MyStrategy(bt.Strategy): params ((ma_period, 20),) def __init__(self): # 在初始化时一次性读取该股票的所有因子数据到内存字典中 self.factor_data {} # 假设 factor_ma.parquet 已经包含所有股票的 MA 因子 all_factor_df pd.read_parquet(factor_ma.parquet) for symbol, group in all_factor_df.groupby(symbol): self.factor_data[symbol] group.set_index(date) def next(self): # 在每一个 bar获取当前标的当前日期的因子值 current_date self.datas[0].datetime.date(0) symbol self.datas[0]._name # 从字典中快速定位因子值 ma20 self.factor_data[symbol].loc[current_date, ma_20] # ... 基于因子值做交易逻辑5. 性能调优与常见问题排查即使选择了合适的方案不当的使用也会导致性能低下。以下是一些关键调优点和排查思路。5.1 Parquet DuckDB 性能调优分区如果数据量很大按日期year2023/month10或标的首字母进行分区能极大提升查询性能。DuckDB 的read_parquet支持通配符可以读取整个目录。-- 查询2023年10月所有数据 SELECT * FROM read_parquet(stock_daily_partitioned/year2023/month10/*.parquet);使用合适的压缩格式snappy压缩速度快gzip压缩率高。对于需要频繁读取的分析数据snappy是更好的选择。利用 DuckDB 持久化连接与视图对于重复使用的复杂查询可以创建视图或将中间表持久化到 DuckDB 的本地数据库文件.db格式中避免每次重复解析 SQL 和 Parquet 文件。conn duckdb.connect(my_research.db) # 连接到持久化数据库文件 conn.execute(CREATE VIEW factor_view AS SELECT * FROM read_parquet(factor_ma.parquet)) # 后续查询直接使用 view更快 result conn.execute(SELECT * FROM factor_view WHERE symbol000001.SZ).fetchdf()5.2 常见问题与解决方案问题现象可能原因检查与解决方案查询速度突然变慢1. 未对常用过滤字段如date,symbol进行排序。2. Parquet 文件过大未分区。3. 内存不足。1. 在生成 Parquet 前按[symbol, date]排序。2. 将大文件拆分为按日期或标的分区的多个小文件。3. 监控内存使用考虑使用 DuckDB 的外部聚合功能或升级硬件。DuckDB 内存占用过高1. 单次查询数据量过大。2. 同时打开了多个连接或进行了大量中间计算。1. 使用LIMIT采样或分区查询避免全表加载。2. 及时关闭连接 (conn.close())对于复杂管道考虑分步将中间结果写入 Parquet 释放内存。因子计算逻辑更改后历史数据需全部重算原始架构设计为全量覆盖未考虑增量更新。设计数据版本管理。将原始数据与因子计算分离。因子表按计算日期分区。重算时只更新受影响的分区。使用 DVCData Version Control等工具管理 Parquet 文件版本。多进程回测时数据读取冲突多个进程同时读取/写入同一个 Parquet 文件。Parquet 文件是只读的天然支持多进程读取。确保写入操作如保存回测结果写入不同的文件或数据库。对于需要共享的状态使用 Redis 或数据库。6. 从研究到生产的考量个人研究者的项目也可能逐步成长需要提前考虑生产化要素。数据版本化使用dvc或git-lfs管理 Parquet 数据文件确保每次实验的数据可复现。计算流水线化使用pipeline工具如Prefect或Airflow将数据下载、清洗、因子计算、回测等步骤组织成可调度、可监控的工作流。元数据管理使用一个轻量级 SQL 数据库如 SQLite记录每次回测的参数、绩效指标、使用的数据版本便于横向对比。监控与日志在关键步骤如数据更新、因子计算加入日志记录开始结束时间、处理行数、错误信息。对于个人研究者而言技术选型的核心是在简洁性与扩展性之间找到平衡点。初期过度设计会拖慢研究进度而完全不考虑架构则会在数据量增长后被迫重构。以Parquet DuckDB为核心辅以SQLite管理元数据是一个在相当长时间内都能保持高效和简洁的黄金组合。当数据规模真正超越单机能力时再考虑迁移到分布式数据库如 ClickHouse或专业的数仓方案届时你积累的数据处理流程和 SQL 经验也将平滑过渡。