TimescaleDB on 远思码技术实验室

TimescaleDB 量化行情库进阶：分区、压缩与连续聚合

Wed, 14 Oct 2026 21:30:00 +0800

远思为径，码动价值。欢迎来到远思码技术实验室的最新技术实践记录。

在量化数据存储选型那篇里，我留下了一个结论：冷数据归档用 ClickHouse，热数据计算交给 DolphinDB。但实验室真正跑日常研究的那套库，最后选了第三个选项——TimescaleDB。

原因很朴素：A 股日线一年也就一百多万行，任何数据库都扛得住；真正稀缺的是"能不能用 SQL 直接把数据拼出来"。TimescaleDB 是 PostgreSQL 扩展，意味着我可以用窗口函数、DISTINCT ON、CTE、generate_series 这些熟悉的东西，而不用为了一次取数去写一段 DolphinDB 脚本。

这篇记录的是把它从"能存"做到"能长期跑"的几个关键点。

一、超表分区：时间维度 + 空间维度

上一篇文章里我们建了最简单的超表：

CREATE TABLE daily_bar (
 symbol text NOT NULL,
 trade_date date NOT NULL,
 open double precision,
 high double precision,
 low double precision,
 close double precision,
 volume bigint,
 amount double precision,
 turnover double precision,
 pct_chg double precision,
 adj_factor double precision DEFAULT 1.0,
 PRIMARY KEY (symbol, trade_date)
);

SELECT create_hypertable('daily_bar', 'trade_date',
 chunk_time_interval => INTERVAL '1 year',
 if_not_exists => TRUE);

日线量级下这样完全够用。但当我把分钟线也接进来（5 分钟 K 线，全市场一年约 1.6 亿行）之后，问题出现了：单个 chunk 内部扫的是全市场。查询"贵州茅台最近一年 5 分钟线"仍然要扫过所有股票的 5 分钟数据。

解决办法是引入空间维度，按 symbol 做哈希分区：

SELECT create_hypertable('minute_bar', 'ts',
 partitioning_column => 'symbol',
 number_partitions => 8,
 chunk_time_interval => INTERVAL '7 days',
 if_not_exists => TRUE);

建完之后，一张超表实际变成 8 × 时间片 个物理子表。查询条件里带 symbol 时，规划器直接裁掉 7/8 的分区。

经验值：number_partitions 别超过 CPU 核心数的两倍太多。分区太碎会让插入时的元数据开销超过收益，8 分片在实验室的 8 核机器上正好。

二、压缩：按 symbol 分段，按时间排序

时序数据最大的浪费是重复。同一只股票、连续的交易日，symbol 完全重复，价格变化很小。TimescaleDB 的列式压缩把"同一 segment 内的行"转成数组存储，压缩比通常在 5~20 倍。

ALTER TABLE minute_bar SET (
 timescaledb.compress,
 timescaledb.compress_segmentby = 'symbol',
 timescaledb.compress_orderby = 'ts DESC'
);

-- 7 天以前的数据自动压缩
SELECT add_compression_policy('minute_bar', INTERVAL '7 days');

两个参数的选择逻辑：

compress_segmentby 决定了"哪些行会被放在一起"。因为绝大多数查询都是按股票取一段连续时间，所以分段键选 symbol。
compress_orderby 决定段内排序。时间倒序排列，让"最新 N 条"的查询能快速定位。

实验室实测（8 核 / 32GB / NVMe，A 股 5 分钟线 1 年）：

状态	表大小	单股 1 年查询耗时
未压缩	6.3 GB	210 ms
压缩后	780 MB	240 ms
压缩后 + 带 symbol 条件	780 MB	35 ms

压缩后写入变慢（约 1.4 倍），但我们的写入集中在盘后批处理，完全无所谓。如果你的场景是盘中高频写入 + 实时查询，压缩窗口不要设得太短——被压缩的 chunk 不能再直接 INSERT，新数据会跑到新的 chunk 去，这是设计使然而不是缺陷。

三、连续聚合：日线自动滚成月线

研究里最烦的是"每次都要手写一段 group by 把日线变月线"。连续聚合（Continuous Aggregate）把这一步变成库里的物化视图，增量刷新：

CREATE MATERIALIZED VIEW monthly_bar
WITH (timescaledb.continuous) AS
SELECT symbol,
 time_bucket('1 month', trade_date) AS trade_month,
 first(open, trade_date) AS open,
 max(high) AS high,
 min(low) AS low,
 last(close, trade_date) AS close,
 sum(volume) AS volume,
 sum(amount) AS amount
FROM daily_bar
GROUP BY symbol, trade_month
WITH NO DATA;

SELECT add_continuous_aggregate_policy('monthly_bar',
 start_offset => INTERVAL '3 years',
 end_offset => INTERVAL '1 day',
 schedule_interval => INTERVAL '1 hour');

注意 end_offset => INTERVAL '1 day'：只刷新到昨天为止。当月数据还在变，如果聚合到当天，物化结果就是一个会不断被改写的"半成品"，容易在回测里用到未完成的月线。查询时当月数据仍然走实时聚合（TimescaleDB 会自动 union 未物化的部分）。

真实用法是这样：

-- 查询某只股票的月线序列，物化部分 + 实时部分自动拼接
SELECT trade_month, open, close, volume
FROM monthly_bar
WHERE symbol = '600519' AND trade_month >= '2020-01-01'
ORDER BY trade_month;

四、增量写入：幂等 upsert 与复权因子

盘后同步任务每天会重跑，必须保证幂等。ON CONFLICT DO UPDATE 是标准解法：

INSERT INTO daily_bar (symbol, trade_date, open, high, low, close,
 volume, amount, turnover, pct_chg, adj_factor)
VALUES (:symbol, :trade_date, :open, :high, :low, :close,
 :volume, :amount, :turnover, :pct_chg, :adj_factor)
ON CONFLICT (symbol, trade_date) DO UPDATE
SET close = EXCLUDED.close,
 volume = EXCLUDED.volume,
 pct_chg = EXCLUDED.pct_chg,
 adj_factor = EXCLUDED.adj_factor;

这里有个容易忽略的设计：存未复权价 + 复权因子，而不是直接存前复权价。

前复权价会在每次除权后整体重算，历史数据被"改写"，导致同一天的因子值在不同时间点算出来不一样；
业界惯例（也是 akshare 的 hfq 接口）是存后复权或存 adj_factor，复权在查询层做，历史数值永远不变。

查前复权价时在 SQL 里乘一下即可：

SELECT trade_date,
 close * adj_factor / MAX(adj_factor) OVER () AS close_qfq
FROM daily_bar WHERE symbol = '000001' ORDER BY trade_date;

反面教材：早期我用"每天重写整段前复权序列"的方式同步数据，结果同一个因子在 3 月跑出来 IC 是 0.031，6 月重跑变成 0.027。差的那一点就是除权。数值漂移是量化研究里最隐蔽的 bug。

五、保留策略与冷热分层

分钟线不能无限堆。实验室的策略是：

-- 3 年前的分钟线直接删除
SELECT add_retention_policy('minute_bar', INTERVAL '3 years');

日线则不删，因为它小到可以忽略（15 年 A 股日线约 2 GB，压缩后 300 MB 左右）。

如果要做真正的归档，可以把老 chunk 的压缩数据 COPY 导出到对象存储（实验室用的是内网的 MinIO），再用 drop_chunks 释放：

-- 导出后再删除
COPY (SELECT * FROM minute_bar WHERE ts < '2021-01-01')
TO PROGRAM 'gzip > /mnt/minio-archive/minute_bar_2020.csv.gz' CSV HEADER;

SELECT drop_chunks('minute_bar', older_than => INTERVAL '5 years');

六、一个取数函数，统一到矩阵

数据库再好，研究时用的还是 DataFrame。实验室封装了一个按需取数的函数，把"复权、停牌、字段选择"都收在这里：

# src/data/loader.py
from __future__ import annotations

import pandas as pd
from sqlalchemy import create_engine

DSN = "postgresql+psycopg2://quant:quant@127.0.0.1:5432/quant"


def load_bars(symbols: list[str], start: str, end: str,
 freq: str = "1d", adjust: str = "qfq",
 engine=None) -> pd.DataFrame:
 """取行情长表，自动按 adjust 做复权。

 adjust: 'none' | 'qfq'(前复权) | 'hfq'(后复权)
 返回列: symbol, trade_date, open, high, low, close, volume, amount
 """
 engine = engine or create_engine(DSN, pool_pre_ping=True)
 table = "daily_bar" if freq == "1d" else "minute_bar"
 tcol = "trade_date" if freq == "1d" else "ts"

 sql = f"""
 SELECT symbol, {tcol} AS trade_date, open, high, low, close,
 volume, amount, adj_factor
 FROM {table}
 WHERE {tcol} BETWEEN :start AND :end
 AND symbol = ANY(:symbols)
 ORDER BY symbol, {tcol}
 """
 df = pd.read_sql(sql, engine, params={"start": start, "end": end, "symbols": symbols})

 if adjust in ("qfq", "hfq") and not df.empty:
 df = df.sort_values(["symbol", "trade_date"])
 grp = df.groupby("symbol", sort=False)["adj_factor"]
 ratio = grp.transform("last") if adjust == "qfq" else 1.0
 for col in ["open", "high", "low", "close"]:
 df[col] = df[col] * df["adj_factor"] / ratio
 return df.drop(columns=["adj_factor"])

ratio 那一行就是前复权的全部秘密：把当前复权因子归一，最新的价格保持原始数值，历史价格被等比缩小。

七、踩过的坑清单

ALTER TABLE hypertable 的坑：超表上加索引必须建在超表上（CREATE INDEX ON daily_bar (...)）），不要手动往 chunk 上建，重建 chunk 之后索引就丢了。
主键必须包含时间分区列。TimescaleDB 的约束要求唯一索引包含分区列，PRIMARY KEY (symbol) 会直接报错。
time_bucket 与交易日历不是一回事。“按月"聚合出来的是自然月，2 月只有 15 个交易日，用它算月收益没问题，但用它算"每月调仓"就会和交易日错位。
别在压缩 chunk 上做大量 UPDATE。压缩块和解压块的写入路径不同，反复更新老数据会把压缩收益吃光。需要修正历史数据时，一次性 decompress_chunk → 更新 → compress_chunk。
vacuum 不是万能的。时序表几乎只增不改，但 drop_chunks 之后还是建议看一眼 autovacuum 的触发情况。

结语

数据层做到这里，已经不是"能存数据"的层次，而是”取数不成为研究瓶颈"：单股分钟线 35 ms、全市场日线截面 1 秒内出结果。

数据齐了、因子有了，接下来是最容易自欺欺人的一环：回测。下一篇从零写一个向量化回测引擎，把手续费、滑点、涨跌停、T+1 全部显式建模。

远思为径，码动价值。基础设施的耐心，最终都会体现在回测曲线是否可信上。

因子工程实战：从行情数据到可检验的 Alpha 因子

Mon, 12 Oct 2026 20:10:00 +0800

远思为径，码动价值。欢迎来到远思码技术实验室的最新技术实践记录。

在上一篇数据抓取里，我们已经把 A 股日线行情写进了 TimescaleDB 的超表。但干净的数据不等于可用的信号——从"能取到数据"到"能下单"，中间隔着整个因子工程。

这篇文章把我们实验室的因子流水线拆开讲：怎么写、怎么校验、怎么避免自己骗自己。

一、先立四条纪律

因子工程里绝大多数翻车，不是因为数学不够花哨，而是因为违反了下面前四条之一：

不使用未来信息。T 日收盘后才能拿到的数据，只能在 T 日收盘后生成信号，T+1 开盘执行。任何 center=True 的滚动窗口、任何全样本拟合的标准化，都是未来函数。
截面可比。因子值必须在同一个交易日的横截面上做标准化，而不是用时间序列均值。
可复现。因子定义、参数、数据版本都写进代码与因子表，重跑必须得到同样的数字。
可检验。一个因子在入库前必须回答两个问题：它对未来收益有没有单调信息（IC / 分层），扣掉成本后还剩多少（换手）。

第 4 条最容易被跳过，而它恰好是唯一真正重要的一条。

二、取数：把宽表拉成矩阵

实验室的行情表结构在上一篇文章里已经建好，核心字段是 symbol / trade_date / close / volume / amount / turnover / pct_chg。因子计算更适合"矩阵"而不是"长表"，所以第一步先 pivot：

# src/data/market.py
from __future__ import annotations

import pandas as pd
from sqlalchemy import create_engine

DSN = "postgresql+psycopg2://quant:quant@127.0.0.1:5432/quant"


def load_price_matrix(start: str, end: str, engine=None) -> dict[str, pd.DataFrame]:
 """返回 {'close','volume','amount','turnover','pct_chg'} 五张 T×N 矩阵。"""
 engine = engine or create_engine(DSN, pool_pre_ping=True, pool_size=4)
 sql = """
 SELECT symbol, trade_date, close, volume, amount, turnover, pct_chg
 FROM daily_bar
 WHERE trade_date BETWEEN %(start)s AND %(end)s
 ORDER BY trade_date, symbol
 """
 df = pd.read_sql(sql, engine, params={"start": start, "end": end})

 out: dict[str, pd.DataFrame] = {}
 for col in ["close", "volume", "amount", "turnover", "pct_chg"]:
 out[col] = df.pivot(index="trade_date", columns="symbol", values=col).sort_index()
 # 停牌日通常缺失，这里保留 NaN：后续因子计算里 NaN 会自然传播成"不可交易"
 return out

两个细节值得强调：

不要 fillna(method="ffill") 无脑填充。停牌日的价格是"没有成交"，强行前向填充会让动量因子把停牌期算成 0 收益，回测里会凭空产生收益。
矩阵的列（股票）会随时间变化。新股上市、退市都会造成列不对齐，后续用 DataFrame.align 或直接按日截面处理。

三、五个基础因子，先够用再说

不用一上来就上百个因子。实验室的第一版只用了五类，覆盖量价四个维度：

因子	定义	逻辑
`mom_20`	过去 20 日收益	动量效应
`rev_5`	过去 5 日收益取负	短期反转
`vol_20`	20 日收益率标准差取负	低波动异象
`turn_20`	20 日平均换手取负	高换手 = 拥挤
`bias_20`	`close / MA20 - 1` 取负	均值回复

# src/factor/basic.py
import numpy as np
import pandas as pd


def momentum(close: pd.DataFrame, n: int = 20) -> pd.DataFrame:
 """n 日动量：T 日因子 = T 日收盘 / T-n 日收盘 - 1（截止当日，不含未来信息）。"""
 return close / close.shift(n) - 1


def reversal(close: pd.DataFrame, n: int = 5) -> pd.DataFrame:
 return -momentum(close, n)


def volatility(pct: pd.DataFrame, n: int = 20) -> pd.DataFrame:
 # pct_chg 已是百分数，先转成小数
 return -(pct / 100).rolling(n).std()


def turnover_avg(turnover: pd.DataFrame, n: int = 20) -> pd.DataFrame:
 return -turnover.rolling(n).mean()


def bias(close: pd.DataFrame, n: int = 20) -> pd.DataFrame:
 ma = close.rolling(n).mean()
 return -(close / ma - 1)

上面每个因子都只用「截止当日」的数据，这是故意保持的语义：因子定义里不包含任何执行滞后，滞后只在回测引擎里统一做一次。原因很实际——如果因子内部先 shift(1)，回测引擎再叠一层 shift(1)，策略就凭空慢了半拍，收益会被系统性低估；反过来如果某处漏了 shift，又会偷到未来收益。滞后只在一处发生，才方便审计。下一篇的引擎会严格实现这条约定。

四、去极值与标准化：截面处理三步

原始因子值直接进模型会被几只极端值股票带偏。截面处理固定三步：

# src/factor/process.py
import numpy as np
import pandas as pd


def mad_winsorize(df: pd.DataFrame, n: float = 3.0) -> pd.DataFrame:
 """按日截面做 MAD 去极值（中位数 ± n * 1.4826 * MAD）。"""
 med = df.median(axis=1)
 mad = (df.sub(med, axis=0)).abs().median(axis=1) * 1.4826
 upper = med + n * mad
 lower = med - n * mad
 return df.clip(lower=lower, upper=upper, axis=0)


def zscore(df: pd.DataFrame) -> pd.DataFrame:
 """按日截面做 z-score。std=0（全市场同一个值）时返回 0 而不是 inf。"""
 mu = df.mean(axis=1)
 sd = df.std(axis=1).replace(0, np.nan)
 return df.sub(mu, axis=0).div(sd, axis=0)


def industry_neutralize(factor: pd.DataFrame, industry: pd.DataFrame) -> pd.DataFrame:
 """行业中性化：对每个交易日，把因子对行业哑变量做 OLS，取残差。

 industry: 与 factor 同形状的行业标签矩阵（如 "银行"、"电子"），缺失记为 NaN。
 """
 residual = factor.copy() * np.nan
 for date in factor.index:
 y = factor.loc[date]
 g = industry.loc[date]
 mask = y.notna() & g.notna()
 if mask.sum() < 30:
 continue
 dummies = pd.get_dummies(g[mask], drop_first=True, dtype=float)
 if dummies.empty:
 residual.loc[date] = y[mask]
 continue
 X = np.column_stack([np.ones(mask.sum()), dummies.to_numpy()])
 yv = y[mask].to_numpy()
 beta, *_ = np.linalg.lstsq(X, yv, rcond=None)
 residual.loc[date, mask] = yv - X @ beta
 return residual

顺序很重要：先 MAD 去极值 → 再行业中性化 → 最后 z-score。如果先标准化再中性化，残差的量纲会乱，后面做因子加权时权重就失去意义了。

提醒：行业中性化一定会"吃掉"一部分收益。如果你的因子本来就是行业轮动逻辑（比如"超配银行"），中性化之后就只剩行业内选股能力了——这不是坏事，只是要清楚自己在测什么。

五、检验：IC、分层、换手，一个都不能少

因子是否有效，实验室只用三个指标下结论。

5.1 IC 与 ICIR

# src/factor/evaluate.py
import numpy as np
import pandas as pd
from scipy.stats import spearmanr


def forward_return(close: pd.DataFrame, hold: int = 5) -> pd.DataFrame:
 """未来 hold 日收益（用于评价，绝不进入因子计算）。"""
 return close.shift(-hold) / close - 1


def daily_ic(factor: pd.DataFrame, fwd_ret: pd.DataFrame, method: str = "spearman") -> pd.Series:
 """每个交易日横截面上的因子与未来收益的相关性。"""
 ics = {}
 for date in factor.index:
 x, y = factor.loc[date], fwd_ret.loc[date]
 mask = x.notna() & y.notna()
 if mask.sum() < 50:
 continue
 if method == "spearman":
 ics[date] = spearmanr(x[mask], y[mask]).statistic
 else:
 ics[date] = np.corrcoef(x[mask], y[mask])[0, 1]
 return pd.Series(ics).sort_index()


def ic_summary(ic: pd.Series, periods_per_year: int = 244) -> dict:
 ir = ic.mean() / ic.std(ddof=1) if ic.std(ddof=1) else np.nan
 return {
 "IC均值": round(float(ic.mean()), 4),
 "IC标准差": round(float(ic.std(ddof=1)), 4),
 "ICIR": round(float(ir), 3),
 "IC>0占比": round(float((ic > 0).mean()), 3),
 "年化ICIR": round(float(ir * np.sqrt(periods_per_year / 5)), 2) if ir == ir else None,
 "样本天数": int(len(ic)),
 }

经验阈值（日频、5 日持有）：|IC均值| > 0.02、ICIR > 0.3、IC > 0 占比 > 0.55 才值得往下做分层测试。低于这个水平，后面所有回测都只是在拟合噪声。

5.2 分层收益

def layered_return(factor: pd.DataFrame, fwd_ret: pd.DataFrame, q: int = 5) -> pd.DataFrame:
 """按日截面分 q 组，等权持有 forward 收益，返回每组的年化收益。"""
 groups: dict[int, list[float]] = {i: [] for i in range(q)}
 for date in factor.index:
 x, y = factor.loc[date], fwd_ret.loc[date]
 mask = x.notna() & y.notna()
 if mask.sum() < q * 10:
 continue
 labels = pd.qcut(x[mask].rank(method="first"), q, labels=False)
 for g, idx in labels.groupby(labels).groups.items():
 groups[int(g)].append(float(y[mask].loc[idx].mean()))
 annual = {}
 for g, rets in groups.items():
 s = pd.Series(rets)
 annual[f"Q{g + 1}"] = round(float(s.mean() * (244 / 5)), 4) if len(s) else None
 return pd.DataFrame([annual], index=["年化收益"])

一个真正有效的因子，Q1 → Q5 应该单调，并且首尾组年化差异是稳定的，而不是靠某一年撑起来的。

5.3 换手率

IC 再漂亮，如果因子每天把整个组合换个遍，扣完成本就归零。实验室的标准做法是算因子秩的日间自相关来近似换手：

def rank_autocorr(factor: pd.DataFrame, lag: int = 1) -> float:
 """因子截面秩的自相关，越高越稳定（0.9 以上说明换手很低）。"""
 ranks = factor.rank(axis=1, pct=True)
 vals = []
 for date in ranks.index[lag:]:
 a = ranks.loc[date]
 b = ranks.shift(lag).loc[date]
 mask = a.notna() & b.notna()
 if mask.sum() < 50:
 continue
 vals.append(float(np.corrcoef(a[mask], b[mask])[0, 1]))
 return float(np.nanmean(vals))

六、落库：因子表长什么样

因子算完不要停在 notebook 里。实验室统一写入 factor_value 表，主键 (factor_name, trade_date, symbol)，字段 raw / z，外加版本号：

CREATE TABLE IF NOT EXISTS factor_value (
 factor_name text NOT NULL,
 trade_date date NOT NULL,
 symbol text NOT NULL,
 raw double precision,
 z double precision,
 version text NOT NULL DEFAULT 'v1',
 PRIMARY KEY (factor_name, trade_date, symbol)
);

SELECT create_hypertable('factor_value', 'trade_date',
 chunk_time_interval => INTERVAL '90 days',
 if_not_exists => TRUE);

写入时用 ON CONFLICT DO UPDATE 做幂等 upsert，这样重跑某一天的因子不会产生重复行：

from sqlalchemy import text

UPSERT = text("""
 INSERT INTO factor_value (factor_name, trade_date, symbol, raw, z, version)
 VALUES (:factor_name, :trade_date, :symbol, :raw, :z, :version)
 ON CONFLICT (factor_name, trade_date, symbol)
 DO UPDATE SET raw = EXCLUDED.raw, z = EXCLUDED.z, version = EXCLUDED.version
""")

七、几个一定会踩的坑

复权基准会变。前复权价格在每次除权后整体重算，历史因子值会"漂移"。实验室的做法是因子表存未复权价 + 复权因子，复权只在计算时做，并且记录 version。
ST / 退市股没剔除。z 值算对了，但买不进去。因子入库前就该把"不可交易"标出来，别等到回测才过滤。
成分股用的是今天的名单。这是幸存者偏差的经典来源，做指数增强类策略时必须用当期成分股快照。
IC 算的是样本内。因子是全样本算出来的，IC 也是全样本。真正的检验要在滚动窗口里做，下一篇会展开。

结语

到这里，我们有了一个可复现、可检验的因子表。接下来两件事必须按顺序做：先把回测引擎写对，再用它去证伪这些因子——先有可信的尺子，再去量东西。

远思为径，码动价值。数据给了原料，因子给了假设，剩下的交给回测去审判。