TickDB 为什么不支持美股 tick 数据？产品边界的坦诚解读
“我调研了 8 家数据供应商，最后发现一个残酷的事实：没有一家能同时满足我的所有需求。”
这是我在一个量化社群看到的帖子。发帖的人是一名从互联网大厂转行量化的工程师，他花了三周时间对比各家的数据 API，整理了一张 47 行的对比表，最后的结论是：数据供应商之间存在不可调和的能力边界，选择哪家，本质上是选择接受它的局限。
这个结论听起来悲观，但它是真实的。本文要做的，是把这种“局限”摊开来聊——具体到 TickDB 的 trades 接口为什么不支持美股和 A 股，它能支持什么，以及当你需要 tick 数据时，应该如何构建自己的数据组合。
一、tick 数据是什么？为什么量化开发者执着于它
在进入具体讨论之前，我们需要先对齐一个基础概念：什么是 tick 数据，它为什么重要。
Tick data（逐笔成交数据）记录的是市场上每一笔成交的详细信息。一条典型的 tick 数据包含：
- 价格：这笔成交的执行价格
- 成交量：这笔成交的数量
- 时间戳：精确到毫秒甚至微秒的成交时间
- 方向（可选）：这笔成交是主动买入还是主动卖出
与 K 线数据相比，tick 数据的信息密度高出几个数量级。同样是 9:30 到 10:00 这 30 分钟：
- 1 分钟 K 线只有 30 根
- Tick 数据可能有 5 万到 20 万条记录，取决于标的的流动性
这种信息密度的差异，使得 tick 数据在以下场景具有不可替代的价值：
订单流分析（Order Flow Analysis）：通过追踪每笔成交的方向和节奏，计算 Delta（主动买入量 - 主动卖出量）、VPIN（成交量同步性指标）等因子。这些因子在高频交易和短期择时中有显著的预测能力。
流动性微观结构研究：分析订单簿的动态变化，理解价差分布、订单碎片化程度、冰山订单的可见比例等。这些研究直接影响做市商和 Alameda 类机构的策略设计。
事件驱动的精确回测：对于财报发布、美联储决议等瞬时事件，tick 数据可以还原事件前后的完整价格路径，避免 K 线“平滑化”带来的信号损失。
正因为这些价值，Polygon、Interactive Brokers 的 API、Alpaca 等供应商都把美股 tick 数据作为核心卖点来营销。如果你问任何一个量化开发者“你需要什么数据”，tick data 大概率会出现在他的回答里。
那么，TickDB 为什么选择不做这个能力？
二、TickDB trades 接口的真实能力边界
先说清楚现状。
TickDB 的 trades 接口支持的标的范围如下：
| 市场 | 支持情况 | 说明 |
|---|---|---|
| 数字货币 | ✅ 全品种支持 | BTC、ETH 等主流币种的完整逐笔成交 |
| 港股 | ✅ 部分支持 | 具体覆盖范围以 API 文档为准 |
| 美股 | ❌ 不支持 | 明确不提供 |
| A 股 | ❌ 不支持 | 明确不提供 |
与此同时，TickDB 的其他数据接口在美股方向的能力是：
| 接口 | 美股支持情况 |
|---|---|
/kline（历史 K 线） |
✅ 支持，10 年级别，清洗对齐 |
/kline/latest（实时 K 线） |
✅ 支持 |
depth（订单簿深度） |
✅ 支持，但限 1 档 |
trades（逐笔成交） |
❌ 不支持 |
这个能力矩阵清晰地说明了 TickDB 的定位：它不是全量市场数据的集大成者，而是一个在特定领域做到深度的专业工具。
三、为什么不做美股 tick？成本的账和定位的账
产品不做某件事，要么是“做不了”，要么是“不想做”。TickDB 不支持美股 tick 数据，属于后者。但“不想做”背后有更复杂的经济学和战略逻辑。
3.1 数据分发成本的结构性差异
K 线数据是“压缩后”的数据。一条 1 分钟 K 线包含 4 个字段（开高低收），而同样的时间窗口内可能产生数万条 tick 记录。
这意味着：
- 存储成本：tick 数据的存储需求是 K 线的 100-1000 倍
- 带宽成本：实时推送 tick 数据的带宽消耗是 K 线的 100 倍以上
- 分发成本：在订阅制模式下，tick 数据的定价需要覆盖上述成本
对于一个以 API 订阅为核心商业模式的数据供应商来说，tick 数据的定价必须显著高于 K 线数据。但问题是：市场能接受的价格，和覆盖成本所需的价格之间，存在巨大的鸿沟。
以 Polygon 为例，它的美股逐笔数据定价是专业级别（Professional 计划月费在数百到数千美元不等），这个价格已经把大量个人开发者和小型团队挡在门外。
TickDB 如果要自建美股 tick 数据能力，面临的不是“能不能做到”的问题，而是“以什么价格做到才能覆盖成本，同时保持竞争力”的问题。
3.2 数据源授权的隐性门槛
美股市场数据的分发涉及复杂的版权和分发权问题。交易所（NYSE、NASDAQ、CBOE）的实时数据和历史数据是分开授权的：
- 实时数据需要交易所的直接授权或通过授权数据聚合商（如 Polygon、Refinitiv）获取
- 历史数据的授权更复杂，涉及数据的“衍生性”和“重分发权”
对于历史 tick 数据，很多供应商（包括 Polygon）并不拥有完整的重分发权。他们能提供 API 访问，但受限于“仅供个人使用”或“不可用于商业再分发”等条款。
这意味着，即使 TickDB 想接入美股 tick 数据，也需要解决一个根本问题：数据的合规来源是什么？授权链条是否完整？
这不是技术上能不能做到的问题，而是法律和商业合规层面的障碍。
3.3 产品定位：做“验证过的价值”而非“原始信号”
这是最关键的一点，也是理解 TickDB 战略选择的核心。
TickDB 的产品定位是为量化策略提供“已验证的价值”——经过清洗、对齐、回溯测试过的历史数据，以及实时推送的标准化行情。这些数据的特点是：
- 清洗过：去除了异常值、分股调整、交易规则变更的影响
- 对齐过：多市场数据在同一时间轴上对齐，跨市场策略回测无偏差
- 可回测：历史数据与实时数据格式一致，回测到实盘迁移成本低
而 tick 数据（特别是 raw tick data）本质上是一种原始信号，它的价值需要经过大量处理才能提取：
- 去除交易所系统噪声（如修复延迟成交）
- 合并拆分股影响
- 补充流动性来源信息（如暗池交易）
- 订单路由和成交确认的时间差处理
这不是 TickDB 想做的事。TickDB 的定位是“让用户在数据之上构建策略”，而不是“让用户处理原始数据”。
做 tick 数据，你需要和 Polygon 竞争；做清洗过的 K 线数据，你服务的是不同的需求。
四、这对用户意味着什么？诚实的需求匹配指南
说了这么多，用户最关心的问题是：当我想做某个策略时，TickDB 够不够用？
答案是：取决于你的策略类型。以下是一份诚实的需求匹配指南。
4.1 这些场景，TickDB 完全够用
趋势跟踪和均值回归策略：大多数基于价格和成交量的中长期策略，1 分钟或 5 分钟 K 线已经提供了足够的信息密度。你不需要 tick 数据，也能实现有效的策略逻辑。
跨市场大类资产配置：TickDB 支持数字货币、港股、美股 K 线，覆盖了主流资产类别。对于多资产组合的宏观对冲策略，这个能力边界足够了。
事件驱动的基础版本：财报季事件驱动策略，可以使用 K 线级别的价格异动作为入场信号。tick 数据能提供更精细的入场时机，但 K 线级别的信号已经能在大多数情况下捕获显著异动。
技术指标量化：MA、RSI、Bollinger Bands、MACD 这些经典指标，在 K 线数据上运行和 tick 数据上运行的差异，在中长期策略中几乎可以忽略。
4.2 这些场景，你需要考虑 tick 数据或补充数据源
高频做市商策略：持仓时间在秒级甚至毫秒级，需要 tick 级别的订单簿和成交数据来估算市场微结构参数。TickDB 的美股 1 档 depth 数据在这种场景下信息量不足。
订单流因子挖掘：如果你想计算 Delta、VPIN、订单不平衡（Order Imbalance）等因子，tick 数据是必须的。TickDB 的 trades 接口虽然支持港股和数字货币，但不支持美股。
瞬时事件后的价格路径回测：对于财报后 30 秒的价格走势分析，tick 数据能还原完整的流动性变化过程。K 线数据会把这段剧烈波动“平滑化”，导致回测结果失真。
暗池和流动性分析：机构级别的流动性研究，需要分析暗池交易比例、订单路由效率等指标，这些信息在标准 tick 数据中也未必完整，但需要更专业的供应商。
4.3 混合数据架构：现实世界的解决方案
坦率地说，没有一家数据供应商能覆盖所有需求。现实世界的数据架构通常是：
TickDB（K 线 + 深度数据）
+
Polygon / Alpaca（美股 tick 数据，按需查询）
+
自建数据管道（特定标的的历史补充）
这种混合架构的成本和复杂度会更高，但它是应对现实需求的最优解。
如果你在寻找的是“单一数据源解决所有问题”，TickDB 不是答案。但如果你能接受“专业工具解决专业问题，工具之间通过标准 API 协作”，TickDB 能在它的能力边界内提供极高的价值。
五、诚实对比：TickDB 与美股 tick 数据供应商
为了方便你在选型时做判断，以下是一份聚焦于美股数据场景的能力对比：
| 能力维度 | TickDB | Polygon | Alpaca | Interactive Brokers |
|---|---|---|---|---|
| 美股 tick 数据 | ❌ 不支持 | ✅ 支持 | ✅ 支持 | ✅ 支持 |
| 美股历史 K 线 | ✅ 10 年级别 | ✅ 支持 | ✅ 支持 | ✅ 支持（需订阅） |
| 美股 depth 订单簿 | ✅ 1 档 | ✅ 支持 | ✅ 支持 | ✅ 支持 |
| 数字货币完整数据 | ✅ 支持 | ✅ 支持 | 部分 | ❌ 不支持 |
| 数据清洗和对齐 | ✅ 是 | 部分 | 部分 | 部分 |
| WebSocket 实时推送 | ✅ 是 | ✅ 是 | ✅ 是 | ✅ 是 |
| 统一 API 多市场 | ✅ 是 | 部分 | 部分 | 部分 |
| 免费层额度 | ✅ 有 | 有限 | ✅ 有 | ❌ 无（需账户） |
这张表想传达的信息很明确：没有完美的供应商，只有适合你当前阶段的工具。
六、关于产品边界的元思考
写到这里，我想停下来聊一个更抽象的问题：一个产品应该对用户坦诚自己的局限吗？
从营销的角度，答案是“不”。最好的营销是让用户觉得产品无所不能，至少在宣传材料上。
但从长期信任的角度，答案是“必须”。量化开发者是世界上最挑剔的技术用户群体之一。他们会做回测，会对比数据，会在实盘中验证每一个承诺。
当他们发现产品宣传与实际能力存在差距时，信任的崩塌是不可逆的。
TickDB 选择不做什么（美股 tick 数据），不是一种缺陷，而是一种产品哲学的体现——在能力边界内做到极致，而不是在所有方向上平均用力。
这意味着你会失去一部分用户（比如需要美股 tick 的高频策略开发者），但你会留住另一部分用户——那些需要可靠、清洗过、统一格式的历史数据，并且愿意为这种可靠性付费的人。
产品边界是过滤器，不是缺陷。
结语
回到文章开头那个量化工程师的结论：“数据供应商之间存在不可调和的能力边界，选择哪家，本质上是选择接受它的局限。”
这句话是对的。但我想补充的是：接受局限不是妥协，而是战略聚焦的必然结果。
TickDB 不做美股 tick 数据，因为它选择了另一条路：把 K 线数据做到最扎实，把深度数据做到最稳定，把 API 体验做到最顺畅。
如果你需要美股 tick 数据，Polygon 和其他供应商是更好的选择。如果你需要跨市场、可回测、格式统一的 K 线数据，TickDB 可能是答案的一部分。
不是所有问题都需要一个工具解决。好的架构，是让专业工具各司其职。
下一步行动
如果你想评估 TickDB 是否适合你的策略：
- 访问 tickdb.ai 查看完整的 API 文档
- 在控制台申请免费 API Key，测试
/kline和depth接口 - 对比你当前的 tick 数据需求，看看是否可以用 K 线或 depth 数据替代
如果你同时需要美股 tick 数据：
TickDB 适合作为混合数据架构中的“K 线层”，配合 Polygon 等专注 tick 数据的供应商使用。两者不是替代关系，而是互补关系。
如果你正在做技术选型，可以将本文提到的需求匹配指南作为评估框架：列出你的策略需要的数据类型，对照每家供应商的能力边界，打分后做决策。
本文不构成任何投资建议。市场有风险，投资需谨慎。