量化策略不应该直接读取远程行情 API。问题并不在于 HTTP 请求本身，而在于一旦策略代码同时负责“获取数据”和“计算信号”，数据源的接口参数、网络状态、认证方式、返回结构都会进入策略内部。

更合适的做法，是在策略与行情 API 之间增加一层

。它负责把外部金融数据接口转换为策略约定的数据结构，而策略只关心“给我某个标的的一段 K 线”。

这样做的直接收益不是代码看起来更“架构化”，而是三个更实际的问题变得容易处理：

回测可以测试、数据源可以替换、接口异常不会污染策略逻辑。

一、直接在策略里请求行情有什么问题

很多个人量化项目最初都会写成下面这样：

from quantdash import QuantDash

qd = QuantDash()

def run_strategy():
    df = qd.klines.get(
        "600519.SH",
        period="1d",
        count=200,
        adjust="forward",
        to_dataframe=True,
    )

    df["ma20"] = df["close"].rolling(20).mean()
    return df


对于几十行的研究脚本，这样写完全合理。

问题出现在代码开始承担更多职责之后。例如同一个策略需要：

 实际承担了两类完全不同的职责：

API Key
  ↓
行情 SDK
  ↓
网络请求
  ↓
接口参数
  ↓
返回 DataFrame
  ↓
异常处理


当这两部分混在一起后，一个数据接口参数变化，也可能要求修改策略文件。

数据访问层并不一定需要单独部署一个服务。

对于 Python 个人量化项目，它甚至可以只是一个包含几个类的模块。

它真正需要完成的是建立一条边界：

策略
 │
 │  我要 600519.SH 的 200 根日 K
 ▼
数据访问接口
 │
 ├── QuantDashAdapter
 ├── LocalFileAdapter
 └── TestAdapter
 │
 ▼
外部 API / 本地文件 / 测试数据


例如先定义策略真正需要的请求：

from dataclasses import dataclass


@dataclass(frozen=True)
class BarRequest:
    symbol: str
    period: str = "1d"
    count: int = 200
    adjust: str = "forward"


from typing import Protocol
import pandas as pd


class BarSource(Protocol):
    def load_bars(self, request: BarRequest) -> pd.DataFrame:
        ...


注意，这里完全没有出现 QuantDash、REST API 或其他供应商名称。

下面以 QuantDash 作为行情 API 示例。

from quantdash import QuantDash

qd = QuantDash()


 环境变量读取 API Key；K 线通过 

 获取，并可直接返回 Pandas DataFrame。官方公开示例展示的 K 线字段包括 

因此可以写一个很薄的适配器：

import pandas as pd
from quantdash import QuantDash


class QuantDashBarSource:
    def __init__(self):
        self.client = QuantDash()

    def load_bars(self, request: BarRequest) -> pd.DataFrame:
        return self.client.klines.get(
            request.symbol,
            period=request.period,
            count=request.count,
            adjust=request.adjust,
            to_dataframe=True,
        )


现在 QuantDash 的接口细节只存在于这个类。

def moving_average_signal(
    source: BarSource,
    request: BarRequest,
    window: int = 20,
):
    df = source.load_bars(request).copy()

    required = {"trade_date", "close"}
    missing = required - set(df.columns)

    if missing:
        raise ValueError(f"缺少必要字段: {sorted(missing)}")

    if len(df) < window:
        raise ValueError(
            f"数据不足，需要至少 {window} 行，实际只有 {len(df)} 行"
        )

    df["ma"] = df["close"].rolling(window).mean()
    df["signal"] = (df["close"] > df["ma"]).astype(int)

    return df


source = QuantDashBarSource()

request = BarRequest(
    symbol="600519.SH",
    period="1d",
    count=200,
    adjust="forward",
)

result = moving_average_signal(source, request)


从策略函数的角度看，它已经不知道数据来自 QuantDash。

数据访问层最容易被忽略的价值，不是换数据源，而是

import pandas as pd


class MemoryBarSource:
    def __init__(self, df: pd.DataFrame):
        self.df = df

    def load_bars(self, request: BarRequest) -> pd.DataFrame:
        return self.df.copy()


test_df = pd.DataFrame(
    {
        "trade_date": pd.date_range(
            "2026-01-01",
            periods=30,
            freq="D",
        ),
        "close": list(range(1, 31)),
    }
)

source = MemoryBarSource(test_df)

result = moving_average_signal(
    source,
    BarRequest(symbol="TEST"),
    window=5,
)

assert result["signal"].iloc[-1] == 1


如果策略内部直接调用行情 SDK，这类单元测试就很难做到。

数据访问层让“算法测试”和“数据接口测试”分离

测试 A：
固定 DataFrame → 策略 → 信号是否正确

测试 B：
QuantDash Adapter → 返回结构是否符合内部契约


一旦结果异常，就更容易知道问题发生在哪一层。

而不是面对一个几百行函数猜测到底是行情变了、接口失败了，还是策略公式写错了。

五、不要把数据访问层写成另一个大杂烩

增加一层并不意味着代码一定会变好。

def load_bars(...):
    df = ...
    df["ma20"] = df["close"].rolling(20).mean()
    return df


这样又把策略逻辑放到了数据层。

数据访问层：
负责获得和校验 K 线

策略层：
负责计算 MA20


2. 把所有供应商参数继续暴露给策略

load_bars(
    provider="xxx",
    token="...",
    retry=3,
    endpoint="...",
    raw_response=True,
)


这虽然多了一层函数，但策略仍然知道大量外部实现细节。

接口应该描述“策略需要什么”，而不是“供应商 API 有什么”。

一个只有三个研究脚本的项目，没有必要一开始就设计：

Controller
Service
Repository
Gateway
Factory
Provider
Adapter
DAO


对于小型 Python 量化系统，一个 Protocol 加一两个 Adapter 通常已经足够。

如果一个策略使用前复权行情，而另一个数据源返回不复权行情，即使字段名称完全一致，两组数据也不能直接互换。

不要只统一字段，而忽略字段背后的金融语义。

个人量化项目可以从下面的目录开始：

project/
├── data/
│   ├── base.py
│   ├── quantdash_source.py
│   └── memory_source.py
│
├── strategies/
│   └── ma.py
│
├── tests/
│   └── test_ma.py
│
└── main.py


strategy
   ↓
BarSource
   ↑
QuantDashBarSource


这一个变化，就能把“策略”和“行情供应商”拆开。

量化策略不直接调用行情 API，不是为了追求复杂的软件架构，而是为了建立清晰的数据边界。

一个可维护的量化项目至少应该区分：

外部金融数据
        ↓
数据访问层
        ↓
内部数据契约
        ↓
策略与回测


量化策略为什么需要数据访问层

编程语言

架构设计

后端

量化策略应通过数据访问层（DAL）对接行情API，而非直接调用。这能解耦策略逻辑与数据源细节，便于回测、替换数据源及隔离异常。定义BarSource契约，用Adapter封装QuantDash等具体实现，策略仅依赖内部数据契约，显著提升代码可测试性与维护性。

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

量化策略为什么需要数据访问层

量化策略为什么需要数据访问层

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐