逐笔成交方向推断:用 tick 数据还原每笔交易的买卖方向
文章 价格之上,还有暗流 2010年5月6日,美股市场发生了著名的"闪电崩盘"(Flash Crash)。道琼斯工业平均指数在几分钟内暴跌近1000点,然后又几乎完全反弹回来。事后的调查报告中,有一幅图让所有量化研究员屏住了呼吸——那张图不是价格走势图,而是一张密密麻麻的散点图,每个点代表一笔成交,横轴是时间,纵轴是成交量,点被标记为红色(卖出)或蓝色(买入)。在那几十秒的崩盘窗口中,蓝色点几乎完
TickDB API 开发教程、WebSocket 接入和 SDK 示例
文章 价格之上,还有暗流 2010年5月6日,美股市场发生了著名的"闪电崩盘"(Flash Crash)。道琼斯工业平均指数在几分钟内暴跌近1000点,然后又几乎完全反弹回来。事后的调查报告中,有一幅图让所有量化研究员屏住了呼吸——那张图不是价格走势图,而是一张密密麻麻的散点图,每个点代表一笔成交,横轴是时间,纵轴是成交量,点被标记为红色(卖出)或蓝色(买入)。在那几十秒的崩盘窗口中,蓝色点几乎完
连接是有极限的。但你的策略可能还没摸到它。 凌晨三点,你的监控面板弹出一条告警——某只小盘股瞬间闪崩 23%。你下意识打开订单簿想复盘,结果数据卡在 5 秒前的快照上,等画面刷新出来,流动性已经消失了。 这不是网络问题。这是很多数据源在多标的并发推送时的真实表现:连接数不够用,报文在服务端排队,延迟像滚雪球一样越滚越大。 关于 TickDB 的 WebSocket 连接,官方文档写的是"单连接支持
为什么 TickDB 的 API Key 放 Header 而不是 URL?鉴权方式的安全性解读 一、一个真实的教训 2019 年,某金融科技公司在 GitHub 上泄露了一份代码。泄露的不是算法,不是策略,而是一个 URL: 这个 API Key 是生产环境的。 三小时后,攻击者用这个 Key 下单了 47 笔期权价差套利,锁定了 120 万美元的名义价值。攻击者知道这是真实的——因为订单簿和成
你读了三遍的论文,还是不知道怎么写代码 第一次读,你被数学推导震撼。 第二次读,你试图理解核心假设。 第三次读,你决定动手实现——然后卡在了数据获取上。 你的屏幕左边是 PDF,右边是空白的 IDE。策略逻辑你已经倒背如流,但回测需要什么数据?Tick 数据还是 K 线?需要多久的历史?论文里的参数在代码里怎么初始化? 这不是能力问题。这是方法论问题。 学术量化论文的复现,本质上是一场「从论文语言
你的策略不会说话,但 AI 可以替你开口 凌晨三点,你的手机震了。 你迷迷糊糊拿起手机,看到飞书推送:「AAPL.US 买盘压力比突破 2.5,建议关注」——这不是你自己写的监控脚本,是 AI Agent 在替你看着。 这不是科幻。是你接下来的 20 分钟能亲手搭出来的东西。 本文手把手演示:用 AI Agent 调用 TickDB 的行情 SKILL,把自然语言查询变成可执行的量化信号。不需要你
程序员的午夜惊魂:那条没存进去的数据去哪了 凌晨 3 点,你的行情监控服务突然被云厂商重启了。WebSocket 断开的瞬间,最后一笔深度数据——买卖盘口里那个关键的 45,000 股卖压堆积——还没来得及落盘就没了。 重启后的程序空空如也。它不知道刚才发生了什么,订单簿初始化为零,从头开始重建。10 分钟后,它才重新捕捉到类似的价格信号,但彼时市场环境早已不同——那次机会窗口,就这样永远错过了。
开篇 凌晨 3:47 分,警报声打破了寂静。 一位量化工程师从睡梦中惊醒,手机屏幕上是一条异常通知:他的趋势策略在过去 4 小时内连续亏损 12 次,账户回撤达到了 8%。他翻身下床,手忙脚乱地打开终端,试图手动停止策略——但市场在那个瞬间已经崩了。他的策略继续开仓,仓位在一片混乱中被强制平仓。账户净值从峰值回撤了 23%。 这不是虚构的场景。这是 2010 年 5 月 6 日“闪电崩盘”中真实发
前言 凌晨两点,一位量化开发者盯着屏幕发呆。他的均值回归策略在过去三个月回测中表现优异,但实盘收益却持续亏损。他反复检查因子逻辑、订单路由、交易成本——一切看起来都没问题。 直到他意识到一个被忽视的细节:他的回测数据是分钟级 K 线,而他的实盘信号基于逐笔成交。分钟 K 线抹平了订单簿的微观结构——那些藏在买卖价差里的流动性陷阱、那些被快照遗漏的冰山订单。他需要 tick 数据,而且必须是美股的。
凌晨两点,告警拉响。延迟从 50ms 飙升至 800ms,内存占用率冲破 80%。根因查了一个通宵:策略监控系统订阅了 847 个标的,单连接每秒接收超过 3000 条消息。 这不是孤例。几乎所有构建实时行情系统的开发者,都会在某个节点面对同一个问题:一个 WebSocket 连接,到底能承载多少订阅量? 官方文档写的“不限”二字,是技术宣言还是营销话术?代价是什么,边界在哪? 本文的答案是:亲自
中小资金量化:100 美元 / 月的精确花法 --- 本文导航 - 你的预算正在被三种隐性成本吞噬 - 成本分配模型:三类资金的“黄金比例” - 实时数据 vs 历史数据:ROI 剪刀差 - 三种典型场景的选型决策树 - 生产级数据获取代码模板 - 100 美元 / 月预算分配方案(直接可抄) - 结语与分层行动引导 --- 你的预算正在被三种隐性成本吞噬 做量化的人常有一种错觉:只要找到“便宜的
订单簿买卖压力比:从 depth 数据到交易信号的完整实现 价格是投资者看到的最终结果,而订单簿是所有结果的源头。 每一笔成交价背后,都有买方想要买入的数量、卖方想要卖出的数量、以及他们各自愿意接受的价格档位。盘口上密密麻麻的数字不只是静态的挂单,更是一个实时博弈的快照。但当你打开 Level 2 行情,看着十几档甚至几十档的挂单量,你可能会陷入一种熟悉的困境:数据太多,信号太少。 这就是买卖压力
Python 量化生态全览:从数据到回测到实盘的工具链 > “工具选错,三周白干。” 这是我第三次听到朋友抱怨同样的事情:他花了整整三周学完 Backtrader,准备回测一个财报事件策略,结果发现数据源根本无法满足他的需求——不是精度不够,就是接口不支持实时推送。他最后不得不推翻重来。 这不是个例。Python 量化生态的现状是:工具太多,信息太杂,新人很容易在一个错误的地方消耗大量时间。 本文
"你的策略在过去三年赚了 47%,夏普比率 1.8,最大回撤 8%。你信心满满把它部署到实盘——第一周亏掉了 12%。" 这不是策略失效,是数据在说谎。 回测与实盘之间的鸿沟,往往不在模型,而在数据管道中的静默缺失:数据源没有报错,没有告警,只是悄悄地少给了几天数据。缺失的数据让回测低估风险、高估收益。等你发现问题,对账单已经红了。 数据缺失不会发出声音。必须主动去听。 本文系统拆解历史数据的完整
六家美股数据源 WebSocket 实现质量横评:谁最稳定? 凌晨 3:47,我的 Slack 被一条告警炸醒: > 这不是回测环境,是实盘。策略正在捕捉期权波动率的均值回归机会,而数据源在这最不该断的时候断了。等我手动重启服务、重新订阅、补全数据,15 分钟的流动性窗口已经关闭。 那天早上我亏了 800 美元。但比钱更让我痛苦的是:这个问题本可以避免——如果我选的数据源 WebSocket 实
从回测到实盘:填平那 5 道鸿沟 --- > "回测收益率 47%,实盘第一周亏损 12%。" 这不是你的策略出了问题,而是你的认知模型从一开始就是残缺的。回测和实盘之间隔着五道真实的工程鸿沟:每一个都有人在上面摔死,每一个也都有可工程化的解决方案。 本文不喂鸡汤。我们逐道鸿沟拆解——先说机制,再说代码,最后给出可操作的填平方案。 --- 一、为什么回测永远是"乐观的" 回测系统是一个事后诸葛亮式
成交价与信号价的距离,比你想象的更致命 你盯着屏幕上那条完美的回测曲线,年化收益率 47%,夏普比率 3.2。实盘跑了三个月,收益率变成了 12%。你把因子调了又调,把数据对齐方式改了又改,回测曲线依然漂亮,实盘曲线依然惨淡。 问题往往不在策略本身,而在执行层。 回测引擎用收盘价模拟成交,每笔交易都被假设为"立即以信号价完成"。但真实市场中,买一价在变,经纪商路由在排队,你的订单滑过报价,成交在更
"你的 API Key 还有效,但今日配额用完了" 凌晨两点,你刚写完一套财报事件驱动策略的回测脚本。回测结果漂亮得不像话——年化 34%,夏普 2.1,最大回撤 8%。你信心满满地点下"部署",然后收到了一条报错: 你盯着 愣了三秒,心想:这玩意儿到底限到什么程度? 本文用实测告诉你:TickDB 免费层能做什么、不能做什么,以及配额耗尽后代码应该如何优雅地应对。 --- 免费层到底给了多少?
开头不要重复标题,用场景钩子 --- 你以为写代码是量化最难的环节。 直到你第一次跑回测,发现一只股票的价格在某个时间点突然从 150 元变成了 90 元——不是分红,不是拆股,只是“前复权”还是“不复权”的区别。 然后你研究期权数据,发现希腊字母字母表都认识,但 delta、gamma 混在一起分不清到底该用哪个。 你开始怀疑人生:当年学编译原理、操作系统、分布式系统都没这么费劲,怎么几个金融概
> "The way a CEO answers an analyst's question tells you more than the earnings report itself." 在二级市场,财报电话会议(Earnings Call)是机构投资者获取管理层情绪信号的核心渠道。语调是防御还是进攻?语速加快还是迟疑?被追问时是否换话题?这些信息不会出现在任何 PDF 里,但它们藏在音频里。
策略连续亏损自动熔断:用状态机保护你的账户 凌晨三点,Slack 发出刺耳的告警。 你从床上弹起来,手机屏幕上显示着策略组的监控面板——实盘账户的回撤曲线已经击穿了预设的警戒线。你揉了揉眼睛,确认自己没有看错:过去 72 小时,策略连续亏损 23 笔,累计回撤 8.7%,而你的熔断阈值设定在 5%。 问题在于,你的熔断逻辑是人工判断的——阈值在那里,但没有人半夜三点盯着屏幕。策略还在跑,还在开仓,