隨著國內量化金融的高速發展，行情數據所包含的微觀交易結構信息越來越受到券商自營團隊、資管團隊以及各類基金的重視。這些交易團隊迫切希望擁有一個與生產環境類似的投研仿真環境，提升研發的效率和質量。

作為國內領先的高性能時序數據庫廠商，DolphinDB 在服務眾多券商、私募、公募、資管和交易所客戶的過程中，持續總結和吸收行情中心項目建設的經驗，并不斷融入到 DolphinDB 數據庫系統中，最終歸納形成了一套新型行情中心解決方案。

本文將為大家分享基于 DolphinDB 的行情中心解決方案——一個低延時、超高速的實時行情數據的指標計算以及基于歷史行情數據的投研和仿真系統。

1. 概述

圖 1：以行情為中心的券商交易（生產）系統和投研（仿真）系統

傳統的券商行情系統主要指實時行情解碼系統或行情轉發系統，如上圖右欄所示，其目標是將交易所實時行情（快照、逐筆委托和成交）以最低的延時傳輸給行情計算系統和交易執行系統。為了降低延時，實時行情的供應商甚至啟用FPGA為解碼提速。一些新興的供應商還推出低延時的分布式消息總線服務，讓實時行情快速地傳遞到更多的用戶系統中。但這些技術手段沒有離開行情原始數據服務的范疇，而且進一步提升的空間越來越小。

與實時行情解碼系統或行情轉發系統處于激烈的競爭不同，基于實時行情數據的指標計算以及基于歷史行情數據的投研和仿真系統建設則剛剛開始——它是券商現有實時行情系統的延伸，包括：數據獲取，指標計算，數據存儲和數據分發，亦即圖1左欄部分。下文中將統一稱為“行情中心”。

1.1 行情中心的定位

行情中心建設通常是由IT部門或者數據部門主導，其他業務部門提出業務和技術需求為輔的系統建設項目，行情中心也常會和大數據平臺、數據中臺等項目緊密配合或互為補充。最終使用行情中心的用戶可以通過兩種維度劃分：（1）面向個人用戶或機構用戶，（2）面向內部用戶或外部用戶。

表 1：行情中心用戶分類

從用戶服務角度，行情中心的核心服務如下圖所示，自上而下可以概括為：（1）數據獲取，（2）指標計算，（3）數據存儲，和（4）數據分發。

圖2：行情中心核心服務

（1）數據獲取主要是對接多個數據源廠商，以及對接多種格式的數據類型用于后續計算和處理。在這一層中需要對原始數據進行解析、校驗、清洗和處理。行情中心必須有足夠的擴展性和靈活性，能快速對接不同類型不同來源的數據。

（2）指標計算是對清洗后的數據進行計算，并將結果反饋給下游用戶。數據的計算主要涵蓋批量計算、實時計算和匯總計算。不同頻率不同類型的數據，計算的復雜程度和處理的方式不一樣，需要行情中心有不同的計算引擎來分別應對。投研（仿真）環境和交易（生產）環境需要完全一致的計算結果，支持批流一體的計算引擎可以縮減開發成本，加快交易策略和模型上線。

（3）數據存儲是將原始數據和加工計算后的各類指標數據存儲到數據庫，并提供高效的數據檢索能力。行情中心數據量大，例如滬深交易所每天產生的行情、訂單和成交數據在3~5G，全量歷史數據大概在百T級；對源數據加工處理后，也會生產海量的數據。快照、訂單、成交、指標等數據都有準確的時間戳，是典型的時序數據。由于數據量大，行情中心對時延也有較高要求，文件IO極易成為性能瓶頸，分布式時序數據庫是理想的存儲選擇。同時，行情中心對可靠性要求高，需要完善的高可用方案。

（4）數據分發指行情中心推送實時和歷史數據到下游系統。實時數據的推送對數據分發的時延和穩定性有較高要求，消息中間件、內存數據庫、跨進程的共享內存是常用的技術方案。歷史數據的推送可以通過數據庫的在線查詢，也可以通過離線的數據下載來完成。數據回放是行情中心里最特殊的重要功能，在實際應用中需要多表關聯回放，例如委托和成交關聯，同時要求嚴格按照時間序列回放。

1.2 行情中心發展趨勢

在業務層面上，行情中心從簡單地為下游系統提供行情原始數據的查詢和下載服務，向交易和投研系統提供更多數據衍生服務演進：

Level 2和逐筆行情數據的重要性日益凸顯。這些數據中包含的市場微觀結構信息可能為投資帶來更為穩定的回報。

行情中心需要提供更多品類的數據，能夠為周邊的資管、交易、風險、估值和研究等多個應用方向和業務條線服務。

除了作為原始行情數據的存儲和查詢工具，更需要在業務層面上提供更多樣的計算指標，提升增值服務能力。這些指標或作為策略和交易系統的基準輸入，或作為機器學習系統的特征工程輸入。隨著機器學習在量化交易中的應用越來越深入，計算指標越來越成為行情中心的一個基礎需求。

行情系統除了滿足常規的交易需求，越來越展現出在投研（仿真）系統中的價值。產研一體化可以大大提升基金尤其是私募基金的投研效率和質量。

在技術層面上，行情中心也從一個簡單的數據存儲和查詢系統，正在往一個存查算一體化的系統演化：

數據量極為龐大。除了原始的行情數據，還要保存計算得到的指標結果，需要具備海量數據的存儲能力。

對行情數據的實時流式處理能力較為迫切。

行情中心處于整個業務鏈條的上游，對計算性能有較高要求。

產研一體化的業務要求需要批流一體的計算技術來保障。

1.3 行情中心業務框架

行情中心業務5層邏輯架構是一種較為清晰和簡單的拆分方式，如下圖所示具體包括接入層、計算層、存儲層、應用層和分發層。

圖3：行情中心業務框架????

這里重點介紹行情中心計算層的業務需求。計算層是對原始行情數據以及其它輔助數據的再加工。大量實踐表明，行情中心非常適合計算市場中一些具有共性訴求的中間指標或直接可參與交易決策的部分指標，主要有四個原因：

（1）行情中心離源數據更近綜合時延更低；

（2）行情中心的數據種類更豐富可計算的維度更廣；

（3）行情中心開發一次指標，計算一次指標后即可被下游多個系統多個用戶重復使用，整體上更經濟；

（4）帶有計算功能的行情中心，可以部署在基金、資管等機構本地，作為投研（仿真）系統的重要組成部分。

數據轉發主要實現L1/L2行情的直接轉發，通常適用于普通行情服務；價源優選是行情中心較為特色的功能，通過多路行情選出最快的行情為下游客戶提供低延時行情服務；行情中心也需要提供其他源數據的直接轉發服務。

基于交易價格和交易量等行情信息構建技術類指標，是行情中心的重要計算業務之一。TA-LIB、MyTT、WorldQuant 101 Alpha Factor是典型的技術類指標。技術指標是基于機器學習、深度學習的量化交易模型的主要特征輸入。在其它量化交易模型中，技術指標也可以和其它類型的因子一起作為模型的輸入，優化模型。

分時K線、VWAP、相關性計算、資金流分析、ETF和指數的IOPV計算、波動率預測、Value at Risk（VaR）、衍生品定價、訂單簿合成等量化金融中常用的計算是很多策略模型必須要用到中間指標。這些中間指標模型的開發和計算有較高的復雜度和難度，行情中心提供標準化的實現可以賦能基金、資管等機構。

2. 行情中心的技術需求

為實現2.2中行情中心的業務框架，需要相應的技術儲備，主要包括存儲層和計算層功能所必須滿足的技術要求。

2.1 存儲層

行情數據的存取是一個行情中心最基本的需求。行情中心的大部分數據是典型的時間序列數據，時序數據庫是最典型的存儲解決方案。但是與物聯網、APM等時序應用場景相比，行情中心具有明顯的金融的細分領域特點。

交易數據的不唯一性

在時序數據庫的一個表中，多個 tag 的組合構成唯一的時間序列。一個序列在不同時間戳上通常具有唯一值，例如一個物聯網傳感器，在某一個時間點上具有唯一采樣值。但是金融市場的交易規則決定了同一個股票在同一時間戳上可以形成多筆交易（不同的對手盤導致）。很顯然，對手盤的訂單號、成交價格不適合作為新的tag，來確保唯一性。通常以物聯網為主要應用場景的時序數據庫都有這個限制，例如InfluxDB和TDengine都要求一個時間序列在一個時間戳上具有唯一值。

多檔報價數據的存儲

行情中心的 level 2 快照數據在一個時間截面上存在多檔的報價數據（買一，買二，賣一，賣二等）。當檔數固定且不多的情況下，可以進行扁平化處理，即用多個字段表示不同的檔位。但是檔位比較多，或者檔數可變的情況下，用一個數組來表示多檔數據是一種更通用更高效的解決方案。因此數據庫支持數組類型，對于解決行情中心的存儲問題非常有幫助。

寬表存儲

物聯網應用通常只關心單個時間序列的數據。金融應用在關心單個標的的時間序列的同時，更關注一個時間截面上多個標的的關系，亦即面板數據分析。為了支持面板數據分析，通常需要數據庫能支持數據透視（Pivoting）或直接支持寬表存儲（每列代表一個標的，每行代表一個時間戳）。

委托和成交的關聯

逐筆的委托和成交數據是行情中心數據庫中最基礎的兩個大表。因為數據量很大，只能采用分布式表來存儲。這樣委托和成交表關聯時的效率很低。分布式數據庫中，分片的co-location存儲是提升分布式表關聯性能的最有效手段。

時序建模 + 關系建模

行情中心數據庫中的大部分基礎數據都可以用時序建模。但是部分基礎數據和計算結果仍然需要關系模型的支持。例如，股票的參考數據（reference data）不能用時序建模。又譬如因子計算結果表，雖然也是時間序列，但是包含了證券和因子兩個實體，實質上是證券和因子隨著時間變化的一個關系，方便按照因子和證券兩個維度來進行快速的查詢。

高可用

一個行情中心需要7 x 24為內部或外部用戶提供行情數據及計算服務。分布式存儲引擎必須滿足高可用的要求。

2.2 計算層

一個行情中心，除了滿足最基本的原始數據查詢和下載的需求外，還需要支持常用的計算業務，這樣可以大幅提升數據的使用率，簡化行情中心客戶端應用的開發。

多表數據回放

行情中心的一個重大需求是在研發環境仿真交易所的數據流，在此基礎上實現策略和交易仿真。對逐筆委托和成交數據以及快照數據的回放，是實現仿真的關鍵技術之一。回放除了性能上越快越好之外，功能上一般有三個需求: （1）多個表的數據能嚴格按照時間順序回放，（2）能選擇不同的時間字段（例如事件發生的時間戳或接收數據的時間戳）進行回放，（3）能按指定的速率進行回放。

窗口函數和面板數據處理

技術指標分析、相關性計算、VWAP計算以及分時K線的處理都離不開最基本的窗口函數。窗口函數除了能用增量算法實現提升性能外，功能上的要求通常包括：（1）能實現滑動、滾動、累計以及任意定制的窗口類型，（2）能按行數和時間兩種度量來推進窗口，（3）多個窗口函數能嵌套執行完成復雜的指標計算。窗口函數通常在一個時間序列上執行，但在行情數據處理時，時間截面分析也非常常用，這就形成了所謂的面板數據處理。

數據透視

金融數據分析通常會把原始數據轉化成矩陣（面板數據）的形式，譬如每一列是一個證券，每一行是一個時間點。轉換成矩陣后，計算更簡單、更高效。截面指標計算、相關性計算、ETF的IOPV計算等都可以通過矩陣計算來完成。行情中心的原始數據存儲通常不是矩陣形式，需要通過數據透視（pivoting）來轉換。

非同步關聯

行情中心存儲的委托、交易和快照等數據在計算時經常需要按股票和時間進行關聯。當按時間關聯時，通常兩個表中的時間不是相等的，而是滿足某種關系，譬如最近的一條記錄，某個時間窗口內的記錄等。這種關聯，我們稱之為非同步關聯，asof join和window join是最常用的非同步關聯。噪音平滑、交易成本分析等計算都會用到上述非同步關聯的方法。

流式計算和批流一體

行情中心既要處理研發環境中的歷史數據，又要處理生產環境中的實時數據。研發環境中的歷史數據是全量數據，可以用批處理的計算方法。生產環境中實時數據是逐條進來的，只能采用更為高效的流式增量計算。兩個環境的計算實現方法如果完全獨立，則意味著要開發兩次，大幅增加了一個機構的時間成本和資源成本。批流一體的技術需求應運而生。

多范式腳本編程

要滿足行情中心的計算需求，光有SQL是不夠的。最好能有一門在SQL基礎上擴展的腳本語言來支撐復雜的計算需求。對于行情中心的計算需求，函數式編程和向量式編程可以提升開發的效率和運行的效率。對于一部分性能要求特別高的計算需求，如衍生品定價，腳本語言如能支持即時編譯（JIT），會是一個很大的優勢。

分布式計算

行情中心通常服務于多個并發用戶，部分計算任務又會涉及大量數據，需要具備分布式計算的能力。分布式計算需要解決三個問題：（1）當計算資源不足時，可以通過增加計算節點來擴展資源，（2）當部分計算節點宕機時，可以將計算任務轉移到其他節點，（3）可以通過多個節點和多個CPU核的并行處理，降低一個復雜任務的計算時延。

3. DolphinDB 的行情中心解決方案

DolphinDB 是一款高性能分布式時序數據庫，集成了功能強大的編程語言和高容量高速度的流數據分析引擎，為海量數據（特別是時間序列數據）的快速存儲、檢索、分析及計算提供一站式解決方案。DolphinDB操作簡單，可擴展性強，具有良好的容錯能力及優異的并發訪問能力。DolphinDB 可以在Linux或Windows系統、單個節點或集群、本地或云服務器中部署。

圖 4：DolphinDB 三位一體融合設計

DolphinDB采用三位一體的融合設計架構，強調數據庫、編程語言和分布式計算三者的融合。這突出了數字時代用戶對數據挖掘的需求。DolphinDB數據庫不再只是一個存儲中心，更是一個計算和服務中心。用戶希望通過深挖數據的價值，讓數據（庫）從一個成本中心轉化為一個利潤中心。DolphinDB的用戶除了DBA和IT人員， 更包括公司的業務和研發人員，他們可以使用DolphinDB內置的腳本語言以及豐富的函數庫，快速展開業務上的二次開發。

圖 5：DolphinDB 主要計算和存儲能力

DolphinDB 對金融行業做了大量的針對性功能和優化，在行情中心業務場景中，通過其強大的存儲和計算核心能力賦能行情中心技術建設：

3.1 存儲能力

1、同一時間戳存儲（交易數據的不唯一性）

表 2：交易數據不唯一

表2為深交所開盤集合競價Level 2訂單簿行情，存在多筆訂單的SecurityID和TransactTime完全一致的情形。其他數據庫存儲技術會把這兩個字段作為主鍵提高查詢速度，但由于主鍵必須唯一，導致這些數據庫無法原生存儲不唯一數據，只能在應用層或數據庫層做特殊處理，這會導致數據錯誤或性能下降等諸多問題。

圖 6：DolphinDB 原生支持不唯一數據存儲

DolphinDB區別于其他類型數據庫，在底層架構上原生支持不唯一數據存儲，同時TSDB存儲引擎還能保證計算低延時。

2、數組存儲（多檔報價數據的存儲）

表 3：10檔行情數據示例

表3為10檔行情原始數據，每一檔包含買價、賣價、買量和賣量4列數據，因此需要40列。

表 4：Array Vector 10 檔行情存儲

DolphinDB支持數組（array）類型的列，在array vector中可以同時存10檔數據。如表4所示，只需要OfrPXs、BidPXs、OfrSizes和BidSizes 4列即可存儲10檔行情。數據壓縮比可從4倍提高至10倍，間接提高了查詢速度。另外，array vector支持不定長存儲，可以用于原始行情和因子存儲。

在量化程序開發過程中，array vector通過index進行數據遍歷，而傳統存儲方式需要硬編碼處理每個字段，大大增加了代碼復雜度并容易出錯。

3、寬表存儲

橫截面計算在時序數據處理中極為常見，交易中經常需要存儲多個標的甚至全部標的在同一橫截面上的因子，并且需要對橫截面進行面板數據分析。寬表存儲天然適合面板數據，并能減少數據冗余，提高查詢速度。

表 5：DolphinDB 寬表存儲

如表5所示，在一張寬表中存儲4500只股票的1098個因子。DolphinDB支持32767列大寬表。一部分時序數據庫不支持大寬表或者存在明顯的性能問題。例如ClickHouse會把每列數據都存為一個文件，在大寬表中多列數據文件讀寫就會遇到顯著的性能下降。DolphinDB自研的TSDB存儲引擎能夠保證大寬表下的高性能讀寫。

4、co-location存儲（委托和成交的關聯）

圖 7：co-location 與非co-location 存儲方案對比

在量化交易中，需要關聯逐筆委托和逐筆成交用于微觀結構分析、因子生成和交易策略。DolphinDB的co-location存儲架構會強行將同一交易日的訂單表和成交表存儲在同一數據節點中，在關聯計算時只需要讀取同一節點數據，如圖7左側所示。這樣的存儲架構可以避免節點間的數據傳輸，大幅提高計算速度。

圖7右側是非co-location存儲方案，2022.06.15日的trade數據在DataNode1節點上，order數據在DataNode2上，只能通過網絡傳輸把兩表數據匯集后再進行關聯計算，這樣會大大增加網絡開銷，降低計算速度。非co-location數據庫存儲在歷史數據回測時，網絡傳輸量將呈指數級上升，甚至發生網絡阻塞，導致整個集群不可用。通常一個交易日的逐筆委托和逐筆成交量大約在5GB左右，2張表這樣就需要10GB的網絡傳輸，當處理跨年數據時，極易打滿整個集群的網絡。

5、多模數據庫（時序建模+關系建模）

除需支持時序模型外，金融業務還需要支持關系模型。時序模型主要存儲如行情、訂單、委托和指標因子等具有時序特征的大數據；在實際業務中，如計算期權面值需要用到合約乘數，又比如對組合需要根據行業分類進行估值、因子、歸因和風險計算，這些場景都是典型的關系模型。

DolphinDB 是一個多模數據庫，同時支持時序數據模型和關系數據模型。支持as of join, window join, cross join, equal join, full join, inner join, left join和prefix join等多種數據關聯方式。時序模型支持非同步關聯，關系模型支持等值關聯。

6、高可用

圖 8：DolphinDB 高可用架構

DolphinDB是一個分布式數據庫，自上而下具有完善的高可用方案。

應用層高可用

應用程序可以直連到任意計算節點，保證應用層高可用；也可以采用HTTP經過負載均衡節點，再把請求發送到計算節點。

計算節點高可用

DolphinDB支持計算和存儲節點分離，支持多計算節點部署，只要有一個計算節點可用，整個集群仍然可用。

元數據高可用

存儲數據時會產生大量元數據，元數據是數據的基本信息，計算節點會首先讀取元數據，然后再從數據節點中讀取源數據。在元數據管理上，DolphinDB采用了Raft協議保證高可用。

數據節點高可用

DolphinDB采用了自研的分布式文件管理系統（DFS），支持數據多副本存儲，兩階段提交協議保證數據的強一致性。

多級存儲

DolphinDB支持多級存儲，可以將最常用的熱數據存儲到SSD固態硬盤中提高數據的讀寫速度，較冷的數據存儲到HDD機械硬盤中，不太使用的歷史數據存儲到S3中。

多集群數據同步

不同機房間可以通過異步復制或定時任務實現數據的同步。

3.2 計算能力

除了數據存儲，行情中心的計算同樣極為重要。大多數時序數據庫更側重于數據存儲和較為簡單的計算，DolphinDB 在設計理念上將計算置于了和存儲同等重要的位置。以下計算能力可以很好地應用在行情中心建設上。

1、多表數據回放

DolphinDB 支持歷史數據回放。交易所提供的Level 2行情有3大類數據，分別是快照類數據、逐筆成交類數據和逐筆委托類數據。在回測中，我們常需要將這三種不同類型的數據關聯回放，使回測過程盡量模擬生產。

1.orderDS = replayDS(sqlObj=<select * from loadTable("dfs://order", "order") where Date = 2020.12.31>, dateColumn=`Date, timeColumn=`Time) 2.tradeDS = replayDS(sqlObj=<select * from loadTable("dfs://trade", "trade") where Date = 2020.12.31>, dateColumn=`Date, timeColumn=`Time) 3.snapshotDS = replayDS(sqlObj=<select * from loadTable("dfs://snapshot", "snapshot") where Date =2020.12.31>, dateColumn=`Date, timeColumn=`Time) 4.inputDict = dict(["order", "trade", "snapshot"], [orderDS, tradeDS, snapshotDS]) replay(inputTables=inputDict, outputTables=messageStream, dateColumn=`Date, timeColumn=`Time, replayRate=10000, absoluteRate=true)

上述示例代碼：首先，能同時回放order，trade和snapshot這三張表；其次，交易邏輯是投資者先下交易訂單（order），交易所撮合匹配成交（trade）,最后每3秒向全市場發布快照行情（snapshot），DolphinDB的異構回放會把這三張表“組合成一張關聯的大表”，并嚴格按照時間序列模擬生產回放；最后，可以指定回放速度，如10000筆每秒。

2、窗口函數

表 6：DolphinDB 窗口函數

DolphinDB 支持數十種復雜的滑動、滾動和累計窗口計算函數。支持均值、最大、最小、中間值等較為簡單的窗口計算；也支持最小二乘數估計、person 相關性、協方差、標準差、移動加權平均等較為復雜的函數。滿足技術指標中的各類復雜計算。

DolphinDB 包含1400多個內置函數，適用于多種數據類型（數值、時間、字符串）、數據結構（向量、矩陣、集合、字典、表），函數類別包括：數學函數、統計函數、邏輯函數、字符串函數、時間函數、數據操作函數、窗口函數、連接函數、高階函數、元編程/分布式計算函數、文件/路徑函數、數據庫函數、流計算函數、系統管理函數、批處理作業函數、定時任務函數、性能監控函數和用戶權限管理函數。

3、數據透視和面板數據

DolphinDB 特有的 pivot by 數據透視功能，能夠把原始數據轉化成矩陣（數據面板）。以 IOPV（基金凈值）計算為例。

1.timeSeriesValue = select tradetime, SecurityID, price * portfolio[SecurityID]/1000 as constituentValue from loadTable("dfs://LEVEL2_SZ","Trade") where SecurityID in portfolio.keys(), tradedate = 2020.12.01, price > 0 2.// 利用Pivot by數據透視匯總（rowSum）所有成分券在某一時刻的價值，即IOPV；如果當前時刻沒有成交價格，利用ffill函數使用前一筆成交價格。 3.iopvHist = select rowSum(ffill(constituentValue)) as IOPV from timeSeriesValue pivot by tradetime, SecurityID

圖9展示了上述代碼中 timeSeriesValue 表的數據格式，該表共有3個字段，分別是 tradetime、SecurityID 和 constituentValue，其中 constituentValue 是當前時刻股票的價值（price*qty）。

圖 9：股票在時間序列上的價值

計算一只 ETF 的 IOPV，則需要把籃子中所有股票當前時刻的價值進行匯總，在這種場景下，可以使用 pivot by 生成矩陣（面板數據）。執行代碼3可以看到 pivot by 后的面板數據。

tmp = selectconstituentValue from timeSeriesValue pivot by tradetime, SecurityID

代碼 3：pivot by生成矩陣（面板數據）

tmp 表數據如圖10，行對應當前時刻，列對應各只股票。在 tmp 表的基礎上只要執行 rowSum 就能匯總得到該只基金的 IOPV。

圖 10：pivot by生成的股票價值矩陣（面板數據）

4、非同步關聯

asof join

asof join 能夠關聯距離當前時刻最近的數據，如圖11箭頭所示，trade 總是關聯距離他最近時刻的 order 數據。

asojTable = select * from aj(trades, orders,`Symbol`Time)

代碼 4：asof join 非同步關聯

圖 11：asof join 非同步關聯邏輯

asof join 關聯后的結果如下：

表 7：asof join 關聯結果

window join

Window join 可以對某一段時間范圍的數據進行聚合，例如計算100毫秒內的均價。

winjTable = select * from pwj(trades, orders, - 100000000:0, <[avg(Bid_Price) as Avg_Bid_Price, avg(Offer_Price) as Avg_Offer_Price]> ,`Symbol`Time)

代碼 5：window join 非同步關聯

Window join 關聯后的結果如下：

表 8：window join 關聯結果

5、流式計算和流批一體

八種流計算引擎

圖 12：DolphinDB 流計算引擎

DolphinDB 支持多種流計算引擎，包括時間序列引擎、橫截面引擎、響應式狀態引擎、會話窗口引擎、異常檢查引擎和多種關聯引擎。多樣的流計算引擎能夠滿足實盤交易中的各種計算場景。

增量計算

圖 13：DolphinDB 增量算法

在流數據計算中，有大量的計算需要隨著時間窗口移動，例如上圖13所示的 moving average，會計算最新10筆數據的均價。DolphinDB 的增量算法計算步驟更少，計算時延更低。

流批一體

圖 14：DolphinDB 實現了流批一體架構

流批一體是指歷史批量數據建模分析使用的代碼和實時流式計算使用的代碼一致，并保證流式計算和批量計算的結果完全一致，被稱之為“流批一體”。批流一體的優勢在于只需要寫一套投研階段使用的代碼就能在實時生產中復用，可以大幅減少開發工作量，并確保兩個環境計算結果的一致性。

流批一體能夠極大降低產研一體化技術架構的復雜度。

6、多編程范式

SQL和腳本語言融合

在DolphinDB中，腳本語言與SQL語言是無縫融合在一起的。這種融合主要體現在幾個方面：（1）SQL語句是DolphinDB語言的一個子集，一種表達式。SQL語句可以直接賦給一個變量或作為一個函數的參數；（2）SQL語句中可以使用上下文創建的變量和函數。如果SQL語句涉及到分布式表，這些變量和函數會自動序列化到相應的節點；（3）SQL語句不再是一個簡單的字符串，而是可以動態生成的代碼；（4）SQL語句不僅可以對數據表（table）進行操作，也可對其它數據結構如scalar, vector, matrix, set, dictionary進行操作。

向量化編程

向量化編程是DolphinDB中最基本的編程范式。DolphinDB 中絕大部分函數支持向量作為函數的入參。函數返回值一般為兩種，一種是標量（scalar），這類函數稱為聚合函數（aggregated function）。另一種返回與輸入向量等長的向量，稱之為向量函數。向量化操作有三個主要優點：（1）代碼簡潔；（2）降低腳本語言的解釋成本；（3）可對算法優化，提升性能。

函數化編程

DolphinDB支持函數式編程，包括純函數（pure function）、自定義函數（user-defined function）、匿名函數（lambda function）、高階函數（higher order function）、部分應用（partial application）和閉包（closure）。

即時編譯（JIT）

即時編譯，又稱及時編譯或實時編譯，是動態編譯的一種形式，可提高程序運行效率。解釋執行是由解釋器對程序逐句解釋并執行，靈活性較強，但是執行效率較低，以Python為代表。即時編譯融合了兩者的優點，在運行時將代碼翻譯為機器碼，可以達到與靜態編譯語言相近的執行效率。DolphinDB中的即時編譯功能顯著提高了for循環，while循環和if-else等語句的運行速度，特別適合于無法使用向量化運算但又對運行速度有極高要求的場景。使用即時編譯在某些場景下性能會有幾百倍的提升。

4. DolphinDB 行情相關客戶案例

DolphinDB 已成為了國內外眾多券商、私募、資管、對沖基金和金融信息服務商的長期合作伙伴。客戶的使用場景包括但不限于：

• 實時行情接入
• 歷史行情的導入
• 實時和歷史行情落庫
• 實時行情流式指標和因子計算
• 歷史行情批量指標和因子計算
• 為內部和外部用戶提供行情的查詢和計算服務
• 利用行情數據開發交易策略
• 利用行情回放功能進行策略回測
• 將 DolphinDB 作為行情的存儲和計算平臺，為下游交易系統提供指標和因子信號
• 使用流批一體實現產研一體化

4.1 券商和信息服務商行情中心項目

（1）某券商行情資訊中心，之前和某系統供應商合作，供應商推薦 ClickHouse，但是為了能夠更方便地做數據二次加工，同時符合信創要求使用國產芯片的服務器，更換為 DolphinDB 來存儲 level2 的高頻數據。

（2）某臺灣券商原先使用 Python+HDF5 做K線的計算，隨著臺灣交易所行情頻率的提高，數據量激增，原有系統無法滿足需求，遂使用 DolphinDB 生成不同頻率的K線輸出至 python 供C端查詢。

（3）國內最大的 FICC 領域信息提供商，用 DolphinDB 搭建行情數據平臺，為外部應用提供數據查詢和計算服務。

4.2 某頭部券商

證券投資部門做實時行情的處理，定制開發了行情插件，把股票快照、指數快照、股票逐筆實時行情接入 DolphinDB。通過流表的訂閱，數據實時落庫與實時因子計算同時進行，對開盤高峰期數據計算多個指標，亞毫秒級完成了全部計算，性能提高100多倍。計算結果寫入 RabbitMQ，供下級的業務消費。之前使用Java，開發周期長、計算速度慢，預計3個月開發工作量；使用 DolphinDB 后，采用 DolphinDB 流式計算框架，1周完成開發工作，計算速度提高百倍。

4.3 某知名私募

主要使用場景是海量數據下因子挖掘和策略研發，需要使用歷史行情和實時行情，數據接入用 DolphinDB 進行數據的計算和存儲。原先采用 Python 用于投研環境策略研發、C++用于生產環境代碼開發，因此導致投研環境和生產環境割裂，需要極大的開發工作量，投研生產代碼邏輯不一致需要進行大量測試。客戶使用 DolphinDB 后，采用流批一體實現了投研環境和生產環境代碼一致性；同時因子的計算速度要比原來提高上百倍，因子開發工作量也大幅度降低。最終實現產研一體化。

總結

以上是生活随笔為你收集整理的基于 DolphinDB 的行情中心解决方案的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。