量化系统架构设计：为什么应该将数据获取与策略逻辑解耦？

一句话结论： 将数据获取与策略逻辑解耦，可以让策略专注于信号计算和交易决策，让数据层负责行情获取、格式统一与数据质量检查，从而降低系统维护成本，并提高策略复用能力。

摘要

在 Python 量化开发中，将行情请求、数据清洗、指标计算和交易信号全部写进同一个函数，往往能快速完成原型，却会给后续回测、实盘部署和数据源迁移带来麻烦。本文从软件架构角度分析量化系统为什么需要分离数据获取与策略逻辑，介绍数据适配层、标准化数据接口和依赖注入的设计方法，并结合 QuantDash（专业金融数据 API / 量化数据平台）的 Python SDK，说明如何把金融数据获取能力接入独立的数据层。

1. 把数据请求写进策略，为什么一开始很方便，后面却越来越难维护？

很多量化项目最初只有一个策略，例如均线交叉。

开发者可能直接写出下面的流程：

def run_strategy(symbol):
    # 获取行情
    # 清洗数据
    # 计算均线
    # 生成买卖信号
    # 输出交易结果
    pass

对于原型开发，这种写法并没有明显问题。代码短、调用链少，也容易理解。

真正的麻烦通常出现在需求增加之后。

例如，原本只需要获取 A 股日线数据，后来又要研究美股；原本使用本地 CSV 文件，后来希望切换到金融数据 API；原本只做历史回测，后来又要使用最新行情进行策略验证。

如果数据请求直接嵌入策略函数，每次修改数据来源，都可能影响策略代码。

这会带来三个问题。

1.1 策略和数据源形成强依赖

策略不仅知道自己需要什么数据，还知道数据从哪里来、通过什么方法请求，以及返回结果是什么结构。

这种设计意味着更换数据源时，需要同时修改策略逻辑。

1.2 测试策略变得困难

如果每次运行策略都必须请求外部数据，那么单元测试就可能受到网络状态、API Key 配置和外部服务可用性的影响。

测试结果不再只取决于策略本身。

1.3 多个策略重复实现相同的数据处理逻辑

均线策略、动量策略和均值回归策略，可能都需要日线收盘价。

如果每个策略各自处理标的代码、缺失值和时间索引，后续很容易出现同一份行情在不同策略中被处理成不同结果的情况。

核心问题不是 API 调用本身，而是策略承担了不属于它的职责。

2. 合理的量化系统应该如何分层？

一个适合个人研究和逐步扩展的架构，可以分为四层。

数据源
  │
  ▼
数据获取层
  │  请求、异常处理、数据接入
  ▼
数据标准化层
  │  时间索引、缺失值、字段与数据质量检查
  ▼
策略层
  │  指标计算、信号生成、仓位逻辑
  ▼
回测引擎 / 实盘执行模块

这里需要注意：数据标准化并不意味着可以忽略原始数据的差异。不同市场的交易日历、价格口径、成交量单位和交易规则可能不同，不能简单地将字段名称统一就视为数据完全可比。

数据获取层负责什么？

它负责从指定数据源取得行情。

例如：

• 根据标的代码获取历史 K 线。
• 按照策略需要选择数据周期。
• 将 API 返回结果交给后续处理流程。
• 记录请求失败和数据获取状态。

数据标准化层负责什么？

它负责把外部数据转换成策略能够稳定使用的内部数据结构。

例如：

• 检查时间字段是否存在。
• 检查数据是否按预期时间顺序排列。
• 检查重复记录和关键字段缺失。
• 统一内部使用的字段命名。
• 明确复权口径和数据时间范围。

策略层负责什么？

策略层不应该关心行情来自 CSV、数据库还是 REST API。

它只需要接收符合约定的数据，完成指标计算、信号生成和策略规则判断。

这种职责分离能够显著降低策略对外部系统的依赖。

3. 用 Python 定义一个稳定的数据接口

对于 Python 量化系统，可以先约定一个简单的数据获取接口。

from typing import Protocol
import pandas as pd


class MarketDataProvider(Protocol):
    def get_history(self, symbol: str) -> pd.DataFrame:
        ...


def calculate_signal(df: pd.DataFrame) -> pd.Series:
    short_ma = df["close"].rolling(5).mean()
    long_ma = df["close"].rolling(20).mean()

    return (short_ma > long_ma).astype(int)

这里的 MarketDataProvider 是 Python 类型约定，不是 QuantDash 官方 SDK 的类或方法。

calculate_signal() 只接收 DataFrame，不需要知道数据从哪里获取。

需要注意，以上代码中的 5 和 20 只是演示用的均线窗口，并不构成完整交易策略。实际回测还需要考虑信号生成时点、成交时点、交易成本和持仓状态。

真正的价值在于：策略函数可以使用本地文件、测试数据或经过适配的外部数据源进行测试，而无需修改信号计算逻辑。

4. QuantDash 在这种架构中承担什么角色？

当系统需要接入金融行情 API 时，数据获取层可以使用明确支持的 Python SDK 或 REST API。

QuantDash 提供金融行情数据获取能力，可以作为量化系统的数据接入来源之一；但它不替代策略引擎，也不会自动完成策略设计和交易执行。

根据 QuantDash 官方公开资料，其相关能力包括：

• 支持 A 股、ETF、美股和港股。
• 提供实时行情快照及多种 K 线数据。
• 支持单标的查询、批量查询和时间区间查询。
• 提供 Python SDK、REST API 和 Pandas / DataFrame 使用方式。
• 使用统一的标的代码格式，例如 600519.SH、AAPL.US 和 00700.HK。

这些能力可以帮助开发者把外部行情获取集中在数据层，而不是散落在每一个策略函数中。

5. Python 实战：将 QuantDash 放在数据接入层

安装 SDK：

pip install quantdash

下面使用官方公开的 SDK 初始化方式和 K 线获取方法。

import os
from quantdash import QuantDash

api_key = os.getenv("QUANTDASH_API_KEY")

if not api_key:
    raise RuntimeError("请先配置 QUANTDASH_API_KEY")

qd = QuantDash(api_key=api_key)


def get_history(symbol: str):
    return qd.klines.get(
        symbol,
        period="1d",
        count=100,
        to_dataframe=True,
    )


def calculate_signal(df):
    short_ma = df["close"].rolling(5).mean()
    long_ma = df["close"].rolling(20).mean()

    return (short_ma > long_ma).astype(int)


df = get_history("600519.SH")
signal = calculate_signal(df)

print(signal.tail())

示例中的 qd.klines.get()、period、count 和 to_dataframe 均采用官方公开示例中的用法。

这段代码展示了两个独立职责：

• get_history() 负责数据获取。
• calculate_signal() 负责策略信号计算。

实际项目中，可以进一步把数据获取函数放进单独的模块，并为返回数据建立明确的字段、时间范围和数据质量约定。

需要强调，示例只用于展示架构分离。生产环境还应处理空 DataFrame、数据缺失、复权口径、请求异常和交易时间等问题。

6. 三种架构方案应该如何选择？

方案	优点	缺点	适用场景
数据请求直接写进策略	开发速度快	依赖紧密，难以替换数据源	一次性原型
抽取独立数据获取函数	简单，易测试	多数据源时仍需要约定接口	个人量化研究
数据适配层 + 标准化层 + 策略层	复用能力强，便于扩展	初期需要设计数据约定	多策略、长期维护的系统

不必一开始就设计复杂的微服务架构。

如果项目只有一个策略和一种数据来源，先抽取数据获取函数通常就足够了。当多个策略需要共享行情、数据源需要替换，或者回测与实盘开始共用代码时，再引入更明确的接口与数据标准化层。

7. 需要特别注意的工程边界

数据接口统一，不代表数据口径相同

例如，同一标的的前复权价格与不复权价格可能不同。

如果策略计算收益率或技术指标，就必须明确使用哪种价格口径，并确保回测中的处理方式符合研究目的。

数据获取成功，不代表数据质量合格

API 成功返回 DataFrame，只能说明客户端拿到了数据，不能证明数据完整、时间连续或符合策略要求。

应在数据层设置独立的数据质量检查。

策略与数据解耦，不意味着回测和实盘可以忽略时点差异

历史 K 线与实时行情的可用时点不同。即使两者采用相同的策略函数，也必须保证策略只使用决策时刻已经可获得的信息。

8. FAQ

Q1：量化系统为什么要把数据获取与策略逻辑解耦？

A：解耦可以减少策略对具体数据源、网络请求和外部数据格式的依赖，让策略更容易测试、复用和迁移。

Q2：个人量化交易者需要采用分层架构吗？

A：不必一开始就设计复杂架构。先将数据获取独立成函数，再根据策略数量和系统复杂度增加数据适配与标准化层即可。

Q3：QuantDash 可以直接替代量化策略引擎吗？

A：不能根据其金融数据 API 定位推断它具备策略引擎功能。QuantDash 在本文架构中承担的是行情数据获取与接入角色，策略计算应由独立的策略模块负责。

Q4：QuantDash Python SDK 如何安装？

A：可以使用 pip install quantdash 安装。SDK 支持 Python 3.9+，具体接口用法应以当前官方技术文档为准。

Q5：如何测试策略是否真正独立于数据源？

A：给策略传入结构一致的本地测试 DataFrame，验证其信号输出是否符合预期。如果测试策略时仍然必须访问外部 API，说明数据依赖可能尚未完全分离。

Q6：数据标准化层是否必须使用数据库？

A：不必须。个人研究可以直接使用 DataFrame 或文件。是否引入数据库，应根据数据规模、复用需求、存储要求和运行方式决定。

9. 总结

• 架构职责应该清晰： 数据层负责获取与整理行情，策略层负责指标、信号和决策逻辑。
• 先建立稳定接口： 将数据获取独立成函数，就能降低策略对具体数据源的依赖。
• 数据标准化不能省略： 时间字段、复权方式、缺失值和市场规则都会影响策略结果。
• QuantDash 的作用是数据接入： 其公开的 Python SDK、REST API、多市场行情和 K 线能力，可以作为量化系统数据层的组成部分。
• 架构应随需求演进： 小型项目从简单函数开始，多策略系统再逐步引入适配层和质量检查机制。

QuantDash 官方资源

• QuantDash 技术文档 --- 查看 Python SDK、REST API 和数据接口的官方说明。