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+競爭，並通過更低的准入門檻和現成的業務模組勝出。
