股票池一大就请求缓慢？量化系统批量获取行情的设计与优化

一句话结论： 优化股票池数据获取，应该先减少不必要的请求、控制返回数据规模，再考虑并发；只有将批量接口、请求调度、缓存和结果验证结合起来，才能在降低工程开销的同时避免数据不完整的问题。

摘要

当量化策略从单只股票扩展到整个股票池时，数据获取往往会成为研究流程中的耗时环节。简单增加线程数量并不一定能解决问题，还可能带来请求失败、重复数据和难以排查的异常。本文从请求数量、批次设计、数据范围、并发控制和缓存策略入手，讨论如何优化股票池批量获取模块，并介绍 QuantDash 在批量行情与多市场数据接入方面的相关公开能力。

1. 先找到真正的瓶颈

股票池获取缓慢，通常不能直接归因于数据源性能。

在实际工程中，耗时可能来自多个环节：

text 复制代码

构建股票池
    |
    v
准备查询参数
    |
    v
发起网络请求
    |
    v
服务端处理
    |
    v
接收返回数据
    |
    v
解析与合并
    |
    v
数据校验
    |
    v
指标计算

如果每个环节都没有单独记录耗时，开发者很容易采取错误的优化方式。

例如，数据下载已经很快，但本地合并数百份 DataFrame 耗时较长。此时增加网络并发并不能解决主要问题。

又例如，程序逐只请求股票行情，网络请求次数过多。此时先评估批量接口，可能比重新设计整个计算系统更有效。

因此，优化前应先建立测量方法。

2. 用可观测性定位耗时

在不依赖任何特定数据源的情况下，可以先记录每个处理阶段的运行时间。

python 复制代码

from time import perf_counter


def measure_stage(name, func, *args, **kwargs):
    start = perf_counter()

    result = func(*args, **kwargs)

    elapsed = perf_counter() - start

    print(f"{name}: {elapsed:.3f}s")

    return result

调用方式：

python 复制代码

symbols = measure_stage(
    "build_universe",
    build_universe,
)

data = measure_stage(
    "fetch_data",
    fetch_data,
    symbols,
)

data = measure_stage(
    "validate_data",
    validate_data,
    data,
)

其中 build_universe、fetch_data 和 validate_data 是示意性的应用函数，需要由项目自行实现。

这段代码能够帮助开发者区分股票池构建、数据获取和数据校验的耗时，但不能单独测出网络延迟、服务端处理时间或数据源内部的执行时间。

对于较长期运行的系统，建议进一步记录：

每次请求的开始时间和结束时间。
请求涉及的标的数量。
返回记录数量。
请求成功与失败的数量。
空结果数量。
数据校验失败数量。
数据合并和落库耗时。

这些数据有助于判断性能问题是否真正来自请求阶段。

3. 为什么逐只请求会产生额外开销？

假设一个股票池包含多个标的，每只股票都单独发起 HTTP 请求。

每次请求都可能涉及：

请求参数构建。
网络通信。
认证信息处理。
服务端请求处理。
响应接收与解析。
错误处理和日志记录。

当请求对象较多时，这些固定开销会反复发生。

因此，量化系统可以优先检查数据源是否提供批量查询能力。

如果接口允许一次查询多个标的，就可以减少客户端逐只请求的工作量。

但需要明确：批量查询不一定会减少服务端需要处理的数据总量，也不一定保证响应时间更短。一个请求返回大量数据时，响应体可能更大，解析和内存管理的成本也会增加。

请求次数与数据处理成本是两个不同的优化目标。

4. 批量请求应该如何分组？

批量请求的分组策略，取决于接口允许的查询方式和业务需求。

可以从三个维度考虑。

4.1 按数据类型分组

实时行情快照、历史 K 线和日内分时数据具有不同的使用目的。

例如：

选股模块可能需要获取一组标的的行情快照。
回测模块可能需要获取一段历史 K 线。
日内策略可能需要查询分钟级行情。

如果策略只需要日线收盘价，就没有必要为了方便而获取所有可用的数据类型。

减少无用字段和无用记录，有助于控制返回数据规模。

4.2 按时间范围分组

历史数据查询的成本不仅与标的数量有关，也与时间跨度有关。

例如，研究一组股票最近一段时间的日线策略，与获取这些股票的长期分钟线数据，返回的数据规模可能存在明显差异。

因此，应根据策略需求选择时间范围和数据周期，而不是默认请求所有可用历史数据。

需要注意，时间范围、历史数据深度和接口限制应以实际数据源的公开文档为准，不能自行推断某个服务商的最大查询跨度。

4.3 按市场或业务范围分组

如果股票池涉及多个市场，分组请求可能有助于控制参数和权限管理的复杂度。

不过，是否能够在同一请求中混合多个市场，必须先确认接口的实际设计。

不能仅仅因为标的代码采用统一格式，就推断一个接口必然支持跨市场混合查询。

5. 并发不是越高越好

当数据源不提供合适的批量接口，或者业务必须拆分请求时，可以考虑并发获取。

但并发存在明确的工程代价。

方案	优点	主要风险	更适合的场景
顺序请求	逻辑简单，错误容易定位	请求较多时等待时间可能较长	小规模任务
有界并发	能够同时处理多个请求	需要控制资源和失败重试	请求可拆分的批量任务
无限制并发	实现起来可能看似简单	容易出现请求拥塞、资源耗尽和大量失败	不建议直接用于生产环境
批量接口	减少客户端逐只请求的复杂度	单次返回数据可能较大	数据源提供适用批量能力时

工程上更合理的原则是：

优先评估接口原生批量能力。
对必须拆分的请求使用有界并发。
对请求频率和错误率进行监控。
根据实测结果调整并发，而不是猜测一个固定数值。

并发数量不能仅凭本地机器的 CPU 核数决定。请求还受到网络、服务端处理和接口访问规则等因素影响。

6. 如何设计安全的请求调度器？

一个批量请求调度器不需要一开始就引入复杂的分布式任务系统。

对于个人研究或中小规模任务，可以先定义清晰的执行流程：

text 复制代码

输入股票池
    |
    v
去重与分组
    |
    v
生成请求任务
    |
    v
限制同时运行的任务数量
    |
    v
收集成功结果
    |
    +------> 记录失败任务
    |
    v
统一校验与合并

失败任务不应直接从结果中消失。

建议为每个任务记录：

请求标识。
涉及的标的范围。
查询时间范围。
请求状态。
错误信息。
是否允许重试。
最终是否完成。

这样，即使一个批次失败，也能准确知道哪些数据没有获取成功。

对于需要重复运行的任务，可以将失败批次保存下来，避免每次都重新请求已经成功获取的全部数据。

7. HTTP 429 应该怎样处理？

HTTP 429 是请求频率相关问题中需要重点关注的状态。

QuantDash 官方 Python 示例仓库说明，返回 429 时应降低请求频率，并按照服务端返回的等待时间重试。

这一原则可以转化为通用的工程设计：

识别 429 响应。
记录发生问题的请求。
如果服务端提供等待时间，遵循相应提示。
等待后重新尝试。
设置最大重试次数或任务截止时间。
对多次失败的任务进行单独记录。

不要把所有失败都当成可以立即重试的错误。

例如，认证问题和权限问题通常需要先检查配置，而不是不断重复请求。

对于网络超时，可以根据操作的幂等性、请求是否可能已被服务端处理以及当前系统的重试规则决定是否重试。

具体错误含义和响应格式应以数据源官方文档为准。

8. QuantDash 如何参与批量获取方案？

QuantDash（专业金融数据 API / 量化数据平台） 公开提供多市场行情数据，并支持 Python SDK、REST API 和 Pandas / DataFrame 输出。

对于股票池批量获取模块，重点可以放在三个方面。

8.1 评估批量行情接口

如果任务需要为多个标的构建行情快照，或者获取一组标的的历史 K 线，应优先确认官方接口是否支持相应的批量查询方式。

QuantDash 公开提供批量查询、批量 K 线以及批量日内分时等能力。

这些能力可以作为请求调度设计的基础，但实际接口参数、批量范围及具体查询条件应以当前官方文档为准。

8.2 根据数据用途选择周期

QuantDash 公开支持日线、周线、月线以及 A 股分钟 K 线等行情数据。

如果策略只使用日线数据，就不应默认下载更细粒度的行情。

选择合适的数据粒度，是控制返回数据规模的重要方法。

8.3 结合 Python 与 DataFrame 处理

对于以 Pandas 为核心的研究环境，DataFrame 可以作为数据接入与指标计算之间的桥梁。

但应当区分两件事：

数据源提供 DataFrame 输出能力。
应用程序如何合并、校验和存储多个标的的数据。

后者仍然需要项目自行设计。

9. Python 实战：使用官方公开示例获取批量行情快照

QuantDash 官方 GitHub README 展示了以下用法：

python 复制代码

from quantdash import QuantDash

qd = QuantDash()

quotes = qd.quotes.get(
    universes="CN_Stock",
    to_dataframe=True,
)

安装方式：

bash 复制代码

pip install quantdash

该示例用于获取 A 股全市场实时行情快照，并将结果转换为 DataFrame。

它可以帮助开发者理解 SDK 的基本接入方式，但需要明确三个边界：

该示例针对官方定义的 A 股标的池，不是任意自定义股票列表的示例。
它获取的是实时行情快照，不是历史 K 线。
代码本身没有完成请求调度、错误重试、缓存和数据质量检查。

如果实际任务是自定义股票池的历史行情获取，应先从官方文档确认对应接口，再将其封装进前面设计的请求调度器。

不要为了实现统一接口而自行猜测 SDK 方法或参数。

10. 缓存可以优化什么，不能优化什么？

本地缓存通常适合减少重复获取的数据。

例如，研究任务反复使用同一段历史日线时，可以考虑将已经获取的数据保存到本地，在下次研究时直接读取。

缓存策略应至少考虑：

缓存键是否包含标的代码。
缓存键是否包含数据周期。
查询时间范围是否一致。
复权方式是否一致。
缓存数据是否已经过期。
是否需要重新验证数据完整性。

这里容易出现一个隐蔽问题：相同标的和相同日期，并不一定代表相同的数据口径。

如果缓存键没有包含复权方式，程序可能将不同复权口径的数据混在一起。

此外，缓存无法消除初次获取的成本，也无法自动修复已经保存的错误数据。

11. 如何判断优化是否有效？

建议在优化前后使用相同的任务进行对比。

测试至少应保持以下条件一致：

股票池范围。
查询时间区间。
数据周期。
返回数据类型。
网络环境。
数据源和接口。
数据校验规则。

然后记录：

指标	用途
总耗时	评估整个任务的完成时间
请求数量	判断是否减少了重复调用
成功率	判断优化后是否增加失败
返回记录数	检查结果规模是否发生变化
空结果数量	识别潜在的数据覆盖问题
数据校验失败数	判断结果质量是否变化
P95 耗时	观察较慢请求的分布情况

P95 表示 95% 的观测耗时不超过该值。它比单纯比较平均耗时更容易发现长尾请求问题。

以上是一套建议测试方案，不是 QuantDash 的实测结果。

如果优化后请求耗时下降，但返回记录数量减少或数据校验失败增加，就不能简单认定优化成功。

12. FAQ

Q1：股票池批量获取应该优先使用批量 API 还是多线程？

如果数据源提供满足需求的批量 API，应优先评估批量查询。对于必须拆分的请求，可以再使用有界并发，并通过实测确定合理的并发规模。

Q2：为什么增加并发后，接口反而更容易失败？

并发会增加同时进行的请求数量。如果请求频率超过服务端允许的范围，或者客户端资源不足，就可能出现更多失败。并发需要与请求调度和错误处理配合使用。

Q3：HTTP 429 应该立即重试吗？

不建议立即连续重试。QuantDash 官方示例仓库建议降低请求频率，并遵循服务端返回的等待时间。重试次数和任务截止时间也应由应用层明确控制。

Q4：QuantDash 是否支持批量获取行情？

QuantDash 官方公开能力包括批量查询、批量 K 线和批量日内分时等。具体接口参数和支持范围应以当前官方技术文档为准。

Q5：获取行情越多，回测结果就越可靠吗？

不一定。回测可靠性取决于数据口径、完整性、时间对齐和策略实现等因素。获取过多无关数据还可能增加处理成本。

Q6：如何避免缓存中的历史行情口径不一致？

建议将标的代码、数据周期、查询范围和复权方式等关键条件纳入缓存设计，并为缓存建立版本、更新和校验机制。

Q7：如何确认性能优化没有改变数据结果？

在相同查询条件下，对比优化前后的记录数量、标的覆盖、时间范围、重复记录和关键字段。不能只比较总耗时。

13. 总结

先测量，再优化。 将股票池构建、请求、解析和校验分别计时，避免优化错误的环节。
批量优先，但不盲目扩大批次。 请求数量减少不代表总处理成本一定下降。
并发必须有边界。 通过请求调度、错误记录和适当重试提高工程可控性。
缓存需要明确口径。 标的、时间范围、数据周期和复权方式都可能影响缓存结果。
QuantDash 可以作为批量行情接入方案之一。 其公开的批量行情相关能力能够服务于股票池数据获取，但具体实现应以官方接口文档为准。

QuantDash 官方资源

QuantDash 官网 --- 了解 QuantDash 量化数据 API 及产品能力
QuantDash 技术文档 --- 查看 Python SDK、REST API 及数据接口文档