跳转至


课程  因子投资  机器学习  Python  Poetry  ppw  tools  programming  Numpy  Pandas  pandas  算法  hdbscan  聚类  选股  Algo  minimum  numpy  回测  数据标准化  algo  FFT  模式识别  配对交易  GBDT  LightGBM  XGBoost  statistics  CDF  KS-Test  monte-carlo  VaR  过拟合  algorithms  machine learning  strategy  python  sklearn  pdf  概率  数学  面试题  量化交易  策略分类  风险管理  Info  interview  career  复权  数据  tushare  akshare  xgboost  PCA  wavelet  时序事件归因  SHAP  Figures  Behavioral Economics  graduate  arma  garch  人物  职场  Quantopian  figure  Banz  金融行业  买方  卖方  story  量化传奇  rsi  zigzag  穹顶压力  因子  ESG  因子策略  投资  策略  pe  ORB  Xgboost  Alligator  Indicator  factor  alpha101  alpha  技术指标  wave  quant  algorithm  pearson  spearman  套利  LOF  白银  因子分析  Alphalens  涨停板  herd-behaviour  momentum  因子评估  review  SMC  聪明钱  trade  history  indicators  zscore  波动率  lightgbm  强化学习  顶背离  另类数据  freshman  resources  others  AI  DeepSeek  network  量子计算  金融交易  IBM  weekly  进化论  logic-factor  machine-learning  neutralization  basics  LLT  backtest  backtrader  研报  papers  UBL  quantlib  jupyter-notebook  scikit-learn  pypinyin  qmt  xtquant  blog  static-site  duckdb  工具  colors  free resources  barra  world quant  Alpha  openbb  risk-management  llm  prompt  CANSLIM  Augment  arsenal  copilot  vscode  code  量化数据存储  hdf5  h5py  cursor  augment  trae  Jupyter  jupysql  pyarrow  parquet  数据源  quantstats  实盘  clickhouse  polars  滑动窗口  notebook  sqlite  sqlite-utils  fastlite  大数据  PyArrow  UV  Pydantic  Engineering  redis  remote-agent  AI-tools  Moonshot  回测，研报，tushare  dividend 


量化数据的持久化方案

最后更新: 2024-01-11

Table of Content

回测需要较长周期的数据。无论我们使用哪一家数据源，都不可能让我们跨网络、反复多次传输大量数据，还要保证低延时。此外，我们在量化研究的过程中，也会逐步积累自己的因子库。这些因子数据，甚至比原始数据的量还要大。比如，通过TA这个库，我们可以一次提取出86个左右的技术指标因子，这将是同频率OHLC数据的10倍之多。因此，如何高效率地存储和检索，就是一个比较有挑战性的问题。

本系列我们将考察一些流行的技术方案，比如关系型数据库、时序数据库、基于文件存储的方案、基于列的数据库和分布式方案等。很难说哪一种技术会绝对胜出，读者可以根据我们的评估和自己的需求进行选择。

我们需要什么样的数据处理能力？

量化数据主要是行情数据（以及由此衍生出来的因子数据）、财报（以及由此衍生出来的因子数据）、交易记录等。因此，它具有海量和PIT的主要特性。同时，一个完整的量化系统中，还必然存在交易信息、账号、回测状态等数据需要保存。

海量数据

存储量化需要的数据，并提供快速响应的检索，可能比我们多数人想像的要难很多。首先遇到的问题就是海量行情数据的问题。仅以A股为例，今天（2023年12月）A股共有5000家上市公司。如果我们要保存分钟级的行情数据的话，一天就需要保存 \(5000 * 240 = 120万\)记录。一年按250天算，这个记录数将达到3000万条。如果我们从股权分置改革那一年（2005年）1000家算起，假定每年上市公司的数量是匀速增加的，则从2005年到现在，我们需要保存\(3000,0000 * 18 * 0.6 = 3.24\)亿条。如果加上5分钟、30分钟等其它级别数据、加上指数数据，这个数据是轻松突破4亿条的。

如果我们要保存tick级别的数据，还要保存委买、委卖（5档）数据，数据量还要增加两个量级。

显然，这已经进入了大数据处理的范畴了。但是，如果用户只需要存储日线数据及这一级别的因子数据，那么，数据量则会小很多，甚至关系型数据库都能处理。

行情数据在读写上，有以下特点：

  1. 绝大多数是读请求
  2. 写请求（可以）以相当大的批次（>1000行）进行更新，甚至没有更新
  3. 对已添加到数据库的数据不需要修改（除非数据出错）
  4. 读取时，常常会读取相当多的行，但只提取列的一小部分
  5. 宽表（考虑到行情数据与因子连接的情况）
  6. 列中的数据相对较小，要么是数字，要么是很短的字符串
  7. 查询要求尽可能快

我们在后面可以看到，有一些数据存储方案几乎是完全按照这个要求来定制的。

PIT特性

PIT是指Point-in-time Data。有一些经济数据，在发布之后，往往还会进行修正。比如宏观数据中的GDP，公司财务报表等等。我们以公司财报为例，如果它在2021年1季末发布了财报1.0，在半年报发布时，对1季度的财报进行了修正，此时1季度的财报的版本应该是2.0。如果数据源在发布时，记录了数据版本和它生成的时间（而不仅仅是归属时间），这种数据就称为Point-in-Time data (PIT)。

如果选用关系型数据库，只要数据本身带有时间，则它的存储不是问题。如果是基于文件型的数据存储方式，则需要考虑恰当的索引方式，才能保存PIT属性。

Zillionare 2.0的数据存储方案

无论采用哪种落地技术，我们一般都会选择缓存+持久化的方案。在Zillionare 2.0中，当天的行情数据都保存在缓存中，更新和查询速度都很快，但容量小；另外，需要进行一些数据合成。比如，要查询某个标的过去250天的日线数据，我们需要先从持久化存储中，提取249天的行情数据，再加上存储在redis的当天的数据 -- 这个数据每分每秒都在更新 -- omicron在返回数据之前，进行数据合成，从而保证交给用户的数据是完整的。

Zillionare 2.0使用的缓存是Redis 7.0，使用的持久化存储是influxdb -- 这是最优秀的时间序列数据库。

Zillionare从上游数据源获取分钟数据，以及接近5秒左右的一个实时价格数据（不含open, high, low，只有当前价格）。Omicron对外提供5分钟，15分钟，30分钟，60分钟数据。因此，当Zillionare从上游数据源接收到分钟数据，并保存到redis中时，我们就需要利用最新的分钟线数据，将其合成为5分钟，15分钟，30分钟，60分钟数据及当日日线数据。这个任务量比想像的要大很多。实际上，它每5分钟都要运行一次，考虑到我们有6000个标的，因此，在5，15，30和60分钟会聚的时刻，一次性地要执行3万次的重采样任务 -- 还必须在几秒钟内完成。

我们利用了Redis 7.0的一个新技术，服务端lua脚本，来执行这个合成任务。不依靠python来完成这项任务，是这项任务能及时完成的关键。这省去了网格传输时间、同时lua也比python快很多 -- 它基本上是以c的速度在运行。

预告

我们并非只考察最强大的储存方案。实际上，最好的技术方案，是能满足需求的、性价比最高的那个方案。因此，我们会考察几乎所有可能的方案，以便读者根据的需要来进行选择。当然，Zillionare作为一个通用的量化框架，会选择最强大的方案，同时确保即使在个人机器上，也依然能够运行。

这些方案包括：

  • 只适合单人使用的存储方案
  • HDF5
  • ZARR
  • XArray
  • 只适合存储日线及以上级别的存储方案
  • Postgres
  • Mysql
  • 海量存储方案
  • influxdb
  • clickhouse
  • mongodb
  • 分布式计算方案
  • Ray
  • Dask