基于GDAX API查询超350个数据点的历史数据方案咨询

嘿，我懂你想用GDAX API拉取某产品的每日历史定价数据，但被单次请求最多350根K线的限制卡了对吧？别慌，下面给你一套实操性很强的解决方案：

1. 先吃透核心限制 #

官方提示：单次请求最多可获取350根K线（candles）数据，若所选起始/结束时间与粒度组合会产生超过350个数据点，请求将被拒绝。

对于每日粒度（对应参数granularity=86400，因为1天=86400秒），单次请求最多能覆盖350天（大概11个月）的数据。如果你的目标时间范围超过这个时长，就必须拆分多次请求，分段拉取后再合并数据。

2. 具体实现步骤 #

第一步：拆分时间范围 #

先算出你需要覆盖的总天数，再拆分出每段请求的时间区间：

• 假设你要从2020-01-01拉到2024-01-01的每日数据，先算总天数：(2024-01-01 - 2020-01-01).days = 1461天
• 计算请求次数：1461 // 350 = 4次，还剩61天，所以总共需要5次请求
• 前4次每次拉350天，最后一次拉剩余的61天

第二步：循环发起请求（附伪代码） #

用循环逐个时间段发起请求，每次请求后更新起始时间，直到覆盖整个目标范围。这里给你一个Python的示例代码：

import requests
from datetime import datetime, timedelta

# 配置参数
product_id = "BTC-USD"  # 替换成你要查询的产品ID
granularity = 86400     # 每日粒度（秒）
start_date = datetime(2020, 1, 1)
end_date = datetime(2024, 1, 1)
all_candles = []

current_start = start_date
while current_start < end_date:
    # 计算当前请求的结束时间：最多350天，不超过总结束时间
    current_end = min(current_start + timedelta(days=350), end_date)
    
    # 组装API请求参数，时间格式必须是ISO 8601
    params = {
        "start": current_start.isoformat(),
        "end": current_end.isoformat(),
        "granularity": granularity
    }
    
    # 发起请求
    response = requests.get(f"https://api.gdax.com/products/{product_id}/candles", params=params)
    if response.status_code == 200:
        # API返回的K线是按时间倒序排列的，反转后再合并到总列表
        candles = response.json()
        candles.reverse()
        all_candles.extend(candles)
        print(f"成功拉取 {current_start.date()} 到 {current_end.date()} 的数据")
    else:
        print(f"请求失败：状态码 {response.status_code}，响应内容：{response.text}")
        break
    
    # 更新下一次请求的起始时间
    current_start = current_end
    # 加个小延迟，避免触发API限流
    # time.sleep(1)

# 最终all_candles就是所有时间段的每日K线数据
print(f"全部拉取完成，共获取 {len(all_candles)} 根每日K线")

第三步：处理数据细节 #

• 去重：相邻请求的时间区间可能会有重叠（比如刚好卡在同一天的边界），可以通过检查K线的时间戳，剔除重复条目
• 重试机制：如果遇到网络波动或限流，可以给请求加个重试逻辑（比如用tenacity库），避免单次失败中断整个流程
• 时区问题：API要求时间是UTC时间，如果你用的是本地时间，记得转换为UTC后再发起请求，避免时间范围偏差

3. 额外注意事项 #

• 确认granularity参数正确：每日粒度必须是86400，用错数值会导致数据点数量超出限制，触发请求被拒绝
• 遵守API速率限制：GDAX API有请求频率限制，不要短时间内发起大量请求，建议每次请求后加1秒左右的延迟

内容的提问来源于stack exchange，提问作者George Edwards