用数据读懂金融市场

API 教程

TickDB API 开发教程、WebSocket 接入和 SDK 示例

119 篇文章
25 阅读

生产者-消费者模式在行情分发中的应用

当 100 万条消息撞上你的策略:生产者-消费者模式在行情分发中的实战 > "Every blocking call is a wasted cycle." 凌晨 3:47,你被一条 PagerDuty 告警叫醒。 生产环境监控面板显示:消息队列积压 47,000 条,历史最高。你的量化策略容器 CPU 飙到 98%,但吞吐量纹丝不动。重启服务后,队列瞬间清空——然后在 30 秒内再次积满。 这不

玩金融的小T api-guideasyncio.Queue背压控制
22 阅读

如何估算你的 TickDB 月消费?用量预测与成本优化指南

先问自己一个问题 你上周调用 TickDB 的费用超了,还是还有余量? 大多数人在正式接入之前,不会去想这个问题。等收到账单的那一刻,才发现自己低估了调用量——100 只股票、分钟级数据、7×24 小时运行,三个条件叠加在一起,一个月轻轻松松就是几十万次请求。 这不是 TickDB 的问题,是估算方法的问题。 本文给出两件事:第一,一个你能在接入前就算清楚的用量公式;第二,一套让实际调用量远低于理

玩金融的小T api-guide调用量估算公式缓存策略
24 阅读

从回测到实盘:填平那 5 道鸿沟

> "2012 年 8 月 1 日,骑士资本(Knight Capital)的新版算法上线。由于部署脚本中的一行代码忘记被注释,某个交易所的做市标志被设为 false。在 45 分钟内,系统向纽交所发送了大量错误的市价单,买入而非对冲了数万只股票。当天收盘时,骑士资本损失了 4.6 亿美元——约占公司市值的 75%。 > > 这不是市场出了错。这是回测与实盘之间那堵墙,第一次被炸药级别的巨响炸开给

玩金融的小T tutorial滑点延迟
20 阅读

优雅关闭与状态持久化:如何让程序随时重启而不丢数据

信号、缓冲区与 SQLite:构建可随时重启的量化数据管道 开篇 凌晨 3:47,你被一条告警震醒:数据管道在服务器例行更新后丢掉了重启前最后一小时的订单簿快照。 这不是"有可能发生"的边缘场景。这是每一个长期运行的数据采集系统必然遭遇的宿命:程序总会在最糟糕的时刻被中断——系统更新、资源告急、容器漂移、Kubernetes 优雅终止。区别只在于,你是否为此做好了准备。 大多数量化开发者的第一反应

玩金融的小T api-guide信号处理检查点
20 阅读

当日行情自动归档:用 TickDB 历史接口构建本地行情数据库

行情数据的宿命:要么实时,要么归档 一个老问题:你在交易日收盘后,想复盘当天的分钟级走势,却发现数据要么散落在交易所的 CSV 里,要么干脆就没有保存。 实时数据靠 WebSocket 推送能拿到,但断网怎么办?凌晨服务器重启了怎么办?TickDB 的 REST 历史接口为此设计——让盘后归档成为一个可重复的、受控的管道工程,而不是靠手工导出和 Excel 拼凑。 本文的目标很具体:每天定时拉取

玩金融的小T api-guideREST API 拉取SQLite/ClickHouse 入库
19 阅读

自定义 TickDB SKILL:为企业级场景扩展专属行情能力

企业级量化数据能力扩展:从数据孤岛到统一行情平台 > “你团队的行情数据,有多少个'烟囱'?” 每家量化机构都有自己的数据故事。有的团队用 Polygon 做美股,用 Binance 接入加密货币,用自有爬虫抓港股 level 2——三个月后,他们的行情系统里躺着 4 个 API 密钥、3 套鉴权逻辑、2 种数据格式,和无数个凌晨 3 点因为某个数据源宕机而被叫醒的夜晚。 这不是能力问题,是架构问

玩金融的小T api-guideSKILL 开发规范Function 扩展
64 阅读

零成本量化方案:免费数据源 + 开源回测框架 + 免费云资源

从零到策略:零成本量化系统搭建完整指南 > "我的第一个量化策略,是在一台 2015 年的 MacBook Air 上跑完的。那时候账户里没有钱,脑子里没有框架,手里只有一根网线和一堆问号。五年后回头看,那台 Air 上跑的东西虽然粗糙,但它让我真正理解了:量化这件事,门槛从来不在钱,在于你有没有把链路跑通的决心。" > > 以下是一份完整的零成本量化系统搭建指南——从数据源到回测框架,从本地运行

玩金融的小T tutorial免费数据源组合Backtrader/Zipline
43 阅读

统计套利配对筛选:协整检验与卡尔曼滤波实战

当价差不再随机:统计套利配对筛选的工业级实现 "价差收窄了 3 个标准差,你开仓了——然后它继续扩大,你爆仓了。" 这不是运气问题,是模型问题。大多数配对交易的失败,不是因为协整关系不存在,而是因为交易者把"历史协整"当成了"未来协整"。协整是动态的,hedge ratio 是漂移的,而你的固定阈值正在被市场的结构性变化悄悄杀死。 本文拆解一套工业级配对筛选流水线:从协整检验的统计过滤,到半衰期估

玩金融的小T api-guide协整检验半衰期
25 阅读

TickDB 的 WebSocket 心跳机制:为什么原生 ping/pong 是工程优势

凌晨 3 点 17 分,服务器日志里突然涌入一片连接断开的记录。你的量化策略刚刚错过了过去 4 分钟的行情数据——而你甚至不知道连接是什么时候断的。 这不是个案。在高频交易系统、数据监控服务、实时流处理平台中,WebSocket 连接“静默死亡”是工程团队最头疼的问题之一:连接看起来还活着,但数据已经停了;TCP 层面没有报错,但应用层已经彻底失联。 问题的根源往往不在网络本身,而在你是否正确实现

玩金融的小T api-guideRFC 6455ping/pong 帧
24 阅读

策略容量估算:你的策略能承载多少资金

策略容量估算:你的策略能承载多少资金 三个资金量,同一个策略,截然不同的命运 2023 年夏天,一位量化交易者带着他的均值回归策略进入实盘。 回测 5 年,年化收益 82%,夏普比率 3.2,最大回撤 6.3%。一切看起来近乎完美。 第一阶段,他放入 20 万。收益曲线与回测几乎重合,月胜率稳定在 68%。 第二阶段,他追加到 50 万。前两个月正常,第 91 天开始,滑点从预期的 0.02% 悄

玩金融的小T tutorial成交量约束冲击成本模型
22 阅读

多源数据融合实战:用 TickDB 作为第二路行情交叉验证

多源数据融合实战:用 TickDB 作为第二路行情交叉验证 > “量化策略的死法只有两种:一种是策略本身失效,另一种是数据源背叛了你。” 这不是危言耸听。2019 年某头部量化私募的技术事故至今仍被圈内反复讨论——主数据源在美股开盘瞬间出现 47 秒延迟,依赖单一数据源的 CTA 策略在毫无察觉的情况下追高杀跌,单日亏损超过策略历史最大回撤的两倍。 事故报告写得很清楚:不是策略错了,是数据骗了你。

玩金融的小T api-guide双源对比算法自动切换逻辑
17 阅读

自定义 TickDB SKILL:为企业级场景扩展专属行情能力

企业级行情扩展:从标准 API 到自定义 SKILL 的实战指南 想象一个场景:你的量化团队需要实时监控 200 个标的的异常波动,当检测到流动性枯竭时自动触发对冲信号,同时将这些数据同步到内部的数据仓库。当团队规模从 3 人扩展到 30 人时,每个人都在重复造轮子——有人封装了 WebSocket,有人写了 K 线缓存,有人做了告警推送。 这是企业级行情系统的典型困境:标准 API 能解决 80

玩金融的小T api-guideSKILL 开发规范Function 扩展
19 阅读

Go 语言量化开发入门:高性能行情网关的实现

从 Python 到 Go:量化行情网关的性能跃迁 凌晨三点,你的 Python 脚本又超时了。 这不是你第一次在半夜被监控告警吵醒——订单流分析脚本在处理 burst 行情时,Python 的 GIL 像一道无形的墙,把你的四核 CPU 变成了单核跑道。G event/s 的消息量,脚本处理不过来了,延迟从 5ms 飙升到 200ms,等你反应过来,套利窗口早就关闭了。 这不是你的策略有问题,是

玩金融的小T api-guideGo 协程channel
22 阅读

缺失值填充策略:向前填充、线性插值还是剔除?

缺失值填充策略:向前填充、线性插值还是剔除? 一、开篇 > "一只股票停牌三个月,期间指数上涨 30%。你用前值填充跑回测,策略夏普 2.4;你用线性插值跑回测,策略夏普 1.1。你相信哪个数字?" 这不是一个学术问题。这是每一个量化工程师在清洗数据时都会遇到的真实困境。 A股的午休断连、港股的半天交易、美股的盘前盘后——当你的时间序列被这些"空洞"打断时,选择何种填充策略,直接决定了你的回测结果

玩金融的小T api-guide填充策略对比回测敏感性分析
37 阅读

TickDB 能做什么、不能做什么:一份诚实的产品能力图谱

数据源选型地狱:一个 API,六个市场,十二个坑 凌晨两点半,你坐在屏幕前,面前是三份数据供应商的文档和两份 GitHub issue——一份是对方用户抱怨接口不稳定,另一份是你自己在两个月前写的,同样的问题。 这不是能力问题,是信息不对称问题。 你不知道那个 API 声称支持的"美股全市场数据"其实只到日线级别;你不知道"实时流"在极端行情下会退化成 30 秒轮询;你更不知道那个看起来很美的"t

玩金融的小T api-guide市场覆盖矩阵接口支持表
20 阅读

从回测到实盘:填平那 5 道鸿沟

五年实盘经验总结:回测与实盘的五大鸿沟 > "我的策略在回测中夏普比率 3.2,最大回撤 8%。上线实盘第一周,净值跌了 15%。" 这不是你策略的问题。这是回测与实盘之间的结构性鸿沟,每一位量化交易者都必须跨越的认知深坑。 本文拆解从回测到实盘的五大核心鸿沟:滑点、延迟、断连、过拟合、心态。每一个都配有可落地的工程解决方案,以及一段可以直接拷贝到生产环境的代码。 这不是理论课。这是一份实盘避坑指

玩金融的小T tutorial滑点延迟
20 阅读

事件驱动回测框架:从零搭建一个可扩展的回测引擎

当回测骗了你:向量化的甜蜜陷阱与事件驱动的真实代价 凌晨两点,你盯着屏幕上的夏普比率 3.27,心跳加速。这是三个月心血换来的成果——一个基于 MACD 金叉的策略,在过去五年的美股数据上跑出了惊人的回测曲线。你截图保存,发给朋友,准备第二天开始实盘。 一周后,账户亏掉了 12%。 这不是因为策略失效,而是因为你的回测框架从根上就是错的。它用"收盘价成交"的假设,掩盖了订单根本不可能在那个价格全部

玩金融的小T api-guide事件循环Order 状态机
18 阅读

TickDB vs Tushare:A 股数据源的跨市场能力对决

前言 > "数据的选择决定了策略的天花板。" 在中文量化社区,这个问题几乎是每个入门者都会面对的:Tushare 还是聚宽? 随着 A 股量化内卷加剧、跨境策略需求增加,这个问题的答案正在变得复杂。 Tushare 以其丰富的数据品类和零门槛的免费层,稳坐 A 股数据获取的"社区标准"。但当你的策略需要同时覆盖港股、追踪数字货币事件、或者需要实时监控订单簿深度时,Tushare 的边界开始显现。

玩金融的小T api-guideA 股数据质量跨市场能力
20 阅读

Python 量化生态全览:从数据到回测到实盘的工具链

> "你的策略能不能赚钱我不知道,但你的工具链选错了,下班时间肯定赔进去。" 这不是夸张。我见过太多量化新手,花三周时间折腾了一个回测框架,才发现它根本不支持自己想要的数据频率;也见过老手在实时信号触发时,因为代码没有异步处理,眼睁睁看着滑点从 0.02% 变成 0.5%。 Python 量化不是一门技术,而是一套工具链。工具链的核心在于分层——每一层都有它的使命、它的边界、以及它与其他层的衔接方

玩金融的小T api-guidePandasNumPy
Esc
输入关键词开始搜索