OneTick：交易所捕捉欺骗者、对冲基金寻找Alpha的平台
Bloomberg是给需要终端的分析师用的。TradingView是给需要图表的散户用的。但当交易所想要实时检测某个交易者在一个场所发出虚假订单来操纵另一个场所的价格时——它需要的是OneTick。
OneTick是专为金融市场设计的企业级时间序列数据库和流式分析引擎。不是像TimescaleDB或InfluxDB那样的通用TSDB，也不是像ClickHouse那样的快速列存储。它是一个理解金融数据的平台：交易/报价关系、订单簿深度、公司行为、跨市场相关性。客户包括交易所、投资银行、对冲基金、做市商和经纪商。
OneTick的三大支柱
平台用单一引擎解决三个根本不同的问题：
| 支柱 | 使用者 | 目的 |
|---|---|---|
| 市场监控（Surveillance） | 交易所、监管机构、合规部门 | 操纵检测，MiFID II / MAR / SEC / FINRA合规 |
| 量化研究 | 对冲基金、自营交易台 | Alpha生成、策略回测、微观结构分析 |
| 交易分析 | 卖方交易台、经纪商 | TCA、最佳执行监控、流动性管理 |
关键洞察：三个工作负载都运行在同一个引擎上，同时处理历史数据和实时数据。不需要为流式处理和回测分别维护系统——这是一个统一平台。
架构：有向无环图（DAG）作为查询语言
OneTick的核心架构决策：查询不是用SQL构建的（尽管也支持SQL），而是作为Event Processor (EP)的**有向无环图（DAG）**来构建。
什么是Event Processor
Event Processor是计算的原子单元。每个EP执行单一操作：过滤、聚合、连接、派生字段计算、VWAP计算或订单簿重建。数据（tick）从源到汇通过EP链流动。
类比：工厂的装配线。Tick（带时间戳的记录）从左边进入图，通过处理器链，输出完成的结果：警报、聚合指标或信号。
为什么选择DAG而非SQL
| 方面 | SQL方法 | DAG（Event Processors） |
|---|---|---|
| 流处理 | 需要单独框架（Flink、Spark） | 原生——同一个图在流和历史上都能工作 |
| 复杂管道 | 嵌套子查询、CTE、窗口函数 | 可视化节点组合——每个节点独立可理解 |
| 复用性 | 复制粘贴SQL块 | EP是可插入不同图的可复用组件 |
| 调试 | EXPLAIN ANALYZE + 猜测 |
可以在图的任意节点采集数据 |
| 并行性 | DBMS优化器决定 | 按符号、日期、CPU核心显式并行化 |
图可以通过内置设计器（"paint-a-canvas"）可视化构建，也可以通过Python API编程构建。
性能
OneTick声称的（并经行业确认的）数字：
| 指标 | 值 |
|---|---|
| Tick摄入 | 每天超过1万亿个tick |
| 批量处理 | 每核每秒超过1000万个tick |
| 时间戳精度 | 亚毫秒 |
| 历史深度 | 从1970年开始的数据（通过TickData） |
| 资产类别 | 股票、期货、期权、固定收益、加密货币 |
市场监控：OneTick是行业标准
市场监控可以说是OneTick最强大的用例。交易所本身使用该平台监控交易活动。
检测哪些操纵行为
| 操纵行为 | 发生了什么 | 如何检测 |
|---|---|---|
| 欺骗（Spoofing） | 交易者下大单移动价格，在执行前取消 | 下单/取消比率分析，取消速度 |
| 分层（Layering） | 在多个价格水平下单制造供需假象 | 订单簿中的"阶梯"模式+与对面执行的相关性 |
| 对敲（Wash Trading） | 交易者自买自卖制造虚假成交量 | 账户交叉检查、时序分析、IP地址 |
| 抢先交易 | 经纪商在大客户订单前交易 | 自营交易与客户流之间的时间相关性 |
| 收盘价操纵 | 在交易时段结束时故意交易操纵收盘价 | 最后几分钟活动与日内平均的分析 |
| 报价填塞 | 大量生成/取消订单以减缓竞争对手 | 异常消息频率，订单成交比 |
| 内幕交易 | 基于非公开信息交易 | 异常模式与公司事件的相关性 |
跨市场和跨资产监控
最复杂的情况：跨市场操纵。交易者在一个交易所移动期货价格，同时从另一个交易所的相关期权获利。
OneTick将多个场所的数据聚合到单一流中，搜索跨市场模式，即使工具之间的结构性联系不明显。
监管覆盖
| 监管机构/标准 | 管辖区 |
|---|---|
| MiFID II / MAR | 欧洲 |
| SEC / FINRA | 美国 |
| ASIC | 澳大利亚 |
| IIROC | 加拿大 |
白盒AI用于警报评分
监控的经典问题是误报。每天10,000个警报，5人的合规团队无法逐一审查。OneTick使用"白盒"ML：模型评估实际操纵的概率，同时展示原因——哪些因素导致了高分。不是黑盒，而是可解释模型，这对监管机构至关重要。
量化研究：从Tick到Alpha
对于对冲基金和量化交易台，OneTick不仅仅是数据存储。它是数据和分析共存的研究环境。
能做什么
-
市场微观结构分析。 重建过去任意时刻的订单簿，分析流动性深度、价差、订单流不平衡。
-
策略回测。 在历史tick数据上运行交易策略，具有时间点精度。无前瞻偏差。
-
信号生成。 测试假设："如果买卖价差在成交量上升时扩大3σ——这是反转的预测因子吗？"跨越数十年数据，覆盖所有工具。
-
Tick数据上的ML。 MDRE——类Python/Pandas的API。超参数调优、交叉验证、模型服务——直接在tick数据上，无需导出到单独系统。
访问方法
| 接口 | 适用对象 |
|---|---|
| Python / Pandas API | 数据科学家、ML工程师 |
| SQL | 熟悉关系数据库的分析师 |
| DAG设计器 | 可视化查询构建 |
| 专有图语言 | 经验丰富的OneTick用户 |
交易分析：TCA和最佳执行
MiFID II之后，最佳执行不是建议——而是法律要求。经纪商必须证明以最佳可用价格执行了客户交易。
交易成本分析（TCA）
| 基准 | 测量内容 |
|---|---|
| VWAP | 期间成交量加权平均价格 |
| 到达价格 | 收到订单时的价格 |
| 执行差额 | 交易决策与实际执行之间的差异 |
| 价差成本 | 买卖价差造成的损失 |
与替代方案的比较
| 特征 | OneTick | kdb+ (KX) | QuestDB | TimescaleDB |
|---|---|---|---|---|
| 专业化 | 金融——开箱即用 | 金融——需要开发 | 通用TSDB | 通用TSDB |
| 查询语言 | DAG + SQL + Python | q（学习曲线陡峭） | SQL | SQL |
| 流式+历史 | ✅ 统一引擎 | ✅ (kdb Insights) | ⚠️ 有限 | ⚠️ 通过扩展 |
| 监控 | ✅ 现成模型 | ❌ 需要构建 | ❌ | ❌ |
| TCA | ✅ | ❌ 需要构建 | ❌ | ❌ |
| 摄入性能 | >10M ticks/sec/core | ~10M+ ticks/sec/core | ~3M+ rows/sec | ~1M+ rows/sec |
| 开源 | ❌ 企业版 | ❌ 企业版 | ✅ Apache 2.0 | ✅ Apache 2.0 |
生态系统：OneTick + TickData
OneTick与TickData紧密集成。覆盖范围：
- 美国股票 — 从1970年开始
- 全球交易所 — 80+个场所
- 所有资产类别 — 股票、期货、期权、固定收益、外汇
- 加密货币 — 现货和衍生品
链接
- 🌐 OneTick: onetick.com
- 🌐 OneTick Use Cases: onetick.com/use-cases
- 📊 TickData: tickdata.com
- 🌐 kdb+ (KX): kx.com
- 🌐 QuestDB: questdb.io
- 🌐 TimescaleDB: timescale.com
结论
OneTick不是"又一个时间序列数据库"。它是金融数据的垂直整合平台，用单一引擎满足三个关键需求：交易所和合规的监控、对冲基金的量化研究、卖方的TCA/最佳执行。基于Event Processor的DAG架构是一个优雅的解决方案，适用于需要同时实时和深度历史分析相同数据的世界。
选择时的主要陷阱：不要将OneTick与QuestDB或TimescaleDB作为"数据库对数据库"来比较。OneTick是数据库+分析引擎+现成的业务应用。如果只需要快速tick摄入——选QuestDB。如果需要从数据摄入到监管报告的完整链路——OneTick仅与kdb+竞争，并通过更低的准入门槛和现成的业务模块胜出。
MarketMaker.cc Team
量化研究与策略
