设计或运维行情数据基础设施时用：从 Level 1/2/3…

在选型、搭建或排查金融市场行情数据（实时/延迟报价、盘口深度、供应商与交易所许可、分发架构、历史数据与数据质量）时给出端到端做法。

适用场景

解决思路

1. 按用途选数据层级：组合管理与客户报告用 Level 1（NBBO、最新成交、成交量、日 OHLC）；活跃股票交易台与算法执行用 Level 2（每侧 5-20 档聚合深度）；做市/HFT 与队列位置建模用 Level 3（逐笔订单明细、订单生命周期，如 Nasdaq ITCH、NYSE Arca）；面向客户的展示型应用用延迟 15 分钟的 Level 1。
2. 按 Reg NMS 基准选数据源：最佳执行合规以 SIP NBBO 为权威基准（CTA/CQS 对应 Tape A/B、UTP 对应 Tape C、OPRA 对应期权）；需要更低延迟与 Level 2/3 深度时订阅多个直接交易所馈送（NYSE Arca、Nasdaq TotalView/ITCH、Cboe PITCH、IEX DEEP），自行内部计算 NBBO，并为每个交易所单独实现协议解析器。
3. 按标准评估供应商：资产类别覆盖、延迟、可靠性/uptime SLA、API 质量、含交易所费用在内的总许可成本、历史数据深度、支持能力、数据质量处理；对照 Bloomberg（Terminal、B-PIPE、Data License、BEAP）、Refinitiv/LSEG（Eikon、Elektron/LSEG Real-Time、DataScope、Tick History）、ICE Data Services、FactSet、S&P Capital IQ、Morningstar，以及免费/开放源（15 分钟延迟报价，仅可用于非时效性展示）。
4. 划分许可类别：区分非专业（个人使用、费用低）与专业（商业用途、费用显著更高）；区分 display（人在屏幕上查看）与 non-display（算法、风险引擎、定价等自动化消费，按应用类型而非按用户计费）；逐交易所确认 derived data 的再分发政策。
5. 选择许可模式：按用户/设备（必须精确的月度计数）、企业级（固定费用覆盖定义实体）、按使用量的非展示（按交易、风险、估值等应用类别计费）。
6. 履行报告义务：按月/季度向每个交易所或通过数据供应商提交订阅者数量，避免少报——少报会触发补收费、罚款与合同终止。
7. 合规处理再分发：面向客户的原始交易所数据必须取得明确的分发协议并支付额外费用；通过供应商平台消费的数据通常由供应商代为处理再分发。
8. 做成本管理：定期审计使用情况以取消未用订阅；非实时必要时改用延迟数据；主动追踪非展示用途，避免只在交易所审计时才发现未申报的非展示义务。
9. 部署 ticker plant 作为集中摄入与归一化层：解析交易所协议（ITCH、PITCH、FIX），归一化为统一 schema，做符号映射，缓存最新值，应用 conflation，并监控 feed 健康。
10. 按消费端选 fan-out 模式：topic-based pub-sub（中间件 Solace、TIBCO、29West，低延迟场景用 Kafka）、request-reply（REST 用于按需查询）、multicast（共置超低延迟环境的网络级分发）。
11. 实施 conflation 策略：基于时间（每 N ms 下发最新值）、基于变化（抑制重复）、基于优先级（绝不对成交做 conflation，只对较慢消费者的报价做 conflation）。
12. 按用途选 API：历史/参考数据用 REST，实时流到 web/移动应用用 WebSocket，超低延迟消费端用专有二进制 API。
13. 云数据服务（AWS Data Exchange、Google Cloud Marketplace、Azure Data Share）只用于分析、组合管理与面向客户的应用，不用于延迟敏感的撮合。
14. 按用途选历史数据：组合分析与长周期回测用 EOD OHLCV 数据库；日内回测与微观结构研究用带微秒时间戳的 tick 级数据（Refinitiv Tick History、NYSE TAQ、LOBSTER），并预留容量——单个交易日的美股 tick 数据可能超过 10-20 TB。
15. 区分价格调整口径：交易级分析与监管记录用未调整价格；收益计算用拆股调整或完全调整（拆股+分红）价格。
16. 消除数据偏差：策略研究使用 point-in-time、无幸存者偏差的数据库（只含当前上市标的会系统性高估回测收益）；基本面同样使用 point-in-time 数据以避免前视偏差（初次财报可能被重述）。
17. 做数据质量检测：标记交易时段内未在预期时间更新的 stale 报价，并从交易与估值决策中剔除；做 feed 级（ITCH/PITCH 序列号缺口）与应用级（预期 vs 实际数据频率）缺口检测；处理交易所 trade-bust 消息，过滤偏离 NBBO 的异常成交（按价差与波动调整），并把大宗、拍卖、盘后等合法异常交易与错误区分开。
18. 建立监控与告警：feed 健康看板、交易所到接收端的延迟追踪、成交量与基线对比，对断连、延迟尖峰、stale、缺口配置自动告警。
19. 设计故障切换：采用主/备 feed 架构，在断连、延迟过大或质量超限时自动切换；确保下游系统优雅降级（例如从直接馈送回落到 SIP 时接受失去 Level 3 深度）。
20. 用指标验收：交易时段 feed uptime > 99.95%；中位延迟 < 1ms（直接）、< 50ms（SIP）；P99 延迟 < 10ms（直接）、< 100ms（SIP）；stale 率 < 0.1% 的标的；缺口率 < 0.01% 的预期消息。
21. 按典型峰值的 2-3 倍配置基础设施容量，以应对市场事件期间的数据量激增。
22. 在合规与最佳执行场景中以 SIP NBBO 为准，不要用自算的直接馈送最优价替代 SIP NBBO（两者因延迟可能不一致）。
23. 用精确计数而非估算来确定专业用户数量与非展示应用数量；不要忽略非展示使用费；不要假设延迟数据免费（某些平台上延迟数据仍会产生供应商交付成本与专业用户费用）。
24. 在落地具体市场数据栈、比较供应商成本或处理权限合规问题时，加载 references/examples.md 中的三个实战案例（中型 RIA 的供应商选型与许可、电子交易平台的 SIP+直接馈送架构、权限与交易所审计整改的成本敞口表）。

适用边界 · 注意事项

• 延迟敏感的策略（做市、HFT、共置策略）不适用 SIP 或云市场数据服务路径：SIP 处理带来约 10-50 微秒延迟、云服务叠加网络延迟，这类场景必须走直接交易所馈送与 multicast。
• 非时效性场景（组合管理、客户报告、投研展示）不必采购实时数据与 Level 2/3 深度，延迟 15 分钟的 Level 1 已足够，额外订阅会显著推高许可成本与带宽。
• 若需求是基本面、新闻/事件或第三方指数编制数据，其主要来源是供应商（Bloomberg、FactSet、S&P Capital IQ、MSCI 等）而非交易所行情馈送，本技能的馈送协议、许可与分发架构不直接适用。