评估市场数据 API 时应检查哪些内容？
定义及工作原理
市场数据 API 是一种软件接口，可将市场相关信息（例如报价、成交、K线）从一个或多个数据源传输到您的应用程序。在评估供应商之前，应将 稳定机制（API 如何表示和传输数据）与 可变条件（底层市场行为、供应商选择发布的内容以及更新频率）区分开来。这有助于您避免将“API 返回了数据”误解为“数据满足您的用途”。
典型的请求/响应流程包括身份验证、选择端点、选择金融工具标识符、指定时间范围或订阅，以及接收包含字段和元数据（通常是时间戳和状态指示符）的有效载荷。请假设时间处理至关重要：同一事件可能因供应商时钟、数据摄入延迟以及时间戳定义方式的不同而在不同时间出现。
证据检查清单：需要验证的内容
使用尽职调查清单，并收集可书面审查的证据。
- 数据覆盖范围和标识符
- 哪些金融工具可用（及其标识方式）？使用供应商文档确认映射关系和支持的格式。
- 您的使用场景是否包含所有必需的字段类型（例如，买价/卖价、最新成交、成交量、OHLC K线、经公司行为调整的序列）？
- 字段定义和归一化
- 确认每个字段的精确定义。例如，明确供应商数据流中“最新”（last）的含义，以及K线是基于成交还是报价生成的。
- 检查供应商如何对符号、小数位、货币代码和单位进行归一化处理。
- 时间戳、时区和排序
- 验证每个时间戳代表的含义（事件时间 vs. 处理时间）以及所使用的时区标准。
- 测试排序：在高负载下更新是否乱序到达？API 如何标识这种情况？
- 更新频率和传输模式
- 确定 API 是轮询模式（请求/响应）还是流式模式（订阅）。在网络波动下，两者行为不同。
- 使用您自己的测试日志验证预期的更新频率和实际负载下的表现。
- 可靠性和故障模式 至少应识别并测试一种重大故障模式：
- 中断期间出现的数据缺失或数据缺口。
- 重试导致事件重复。
- 速率限制导致部分数据未覆盖。
- 错误响应未保留请求上下文。
- 速率限制、配额和成本驱动因素 即使没有实时定价声明，您也可以验证成本驱动因素：
- 每个密钥的速率限制，以及不同端点是否有独立的限制。
- 有效载荷大小（每请求的金融工具数量、K线粒度）和带宽影响。
- 任何限制再分发或存储的许可或使用限制。
- 历史数据回填和可复现性 如果您需要历史数据序列，请验证是否能后续复现相同数据集：
- 是否支持特定时间范围的数据回填？
- 数据是否可能修订？如果可能，更新值如何通知？
- 安全性和数据完整性检查
- 确认身份验证方法要求（不要假设其对您的环境已足够）。
- 验证响应中的完整性信号（例如，校验和或状态标志，如提供），并记录所有响应元数据。
限制、风险与“红旗”思维
市场数据质量问题通常源于 您的假设 与 供应商发布内容 之间的不匹配。
- 时间不一致：历史或实时时间戳可能与您的系统时钟不一致，导致排序或时间窗口错误。
- 供应商数据流解释差异：字段语义在不同来源间可能不同（例如，K线构建方式）。历史关系可能失效，因为未来市场行为会变化，且数据流可能随时间反映不同类型的事件。
- 操作风险：速率限制、网络抖动或服务中断可能导致数据缺口、重复或延迟更新。如果您将数据到达等同于事件发生，这些可能扭曲下游计算。
- 验证差距：仅凭文档不足以作为您环境中的证据。应进行受控测试：尽可能将样本输出与独立参考源对比，并记录差异。
一个重要的清晰标准是：您能够使用明确的假设解释您的数据管道——您使用的时间定义、如何处理缺失值、如何去重，以及触发速率限制时的应对措施。
验证与后续应提出的问题
为独立评估，请选择一小部分代表性金融工具和时间窗口，然后在您自己的日志中验证以下几点：
- 时间戳是否满足您的排序要求？
- 在实际请求量下，是否存在可观察的数据缺口、重复或错误突发？