回測與實時交易數據處理和抽象
我是一個試圖建立一個交易系統的人，理想情況下，該系統最終可擴展到 1-15 秒解析度的日內交易策略。我在理解應用於回測的數據饋送和應用於實時交易的數據饋送之間的區別時遇到了一些麻煩，我有一些具體問題：
回測和實時交易通常建立在相同的抽象之上還是在相同的交易/處理引擎上執行？
我的第一個想法是它們是，因為理想情況下它們應該以相同的方式執行以進行回測準確性和真實性
實時數據饋送和歷史數據集是否通常在其各自的處理程序中提供相同的介面來查詢/檢索其數據集？
我係統的目前狀態僅在歷史數據上執行以進行回測，交易引擎會更新數據處理程序本身的時間步長。對於更高頻率的實時數據，這似乎不是一個可行的解決方案，因為它依賴於交易引擎來更新數據饋送，而不是數據饋送處理程序。經過一些研究，基於查詢的機制似乎更適合實時數據，因為它將數據管理控制權交給了處理程序。儘管我無法理解如何將靜態歷史數據載入到數據流中以相同的方式進行處理。
如何最有效地處理數據流？
假設歷史數據和實時數據都被輸入到事件流中。我無法理解這些流是如何被交易引擎查詢或以其他方式可預測地檢索的。時間序列數據庫似乎最有意義，純粹是因為它能夠處理大量數據並儲存足夠的回溯數據，但大多數時間序列數據庫雖然對個人來說相當昂貴，我不確定它是不是成本最高的處理大量數據的有效方法。還有哪些其他選項可以為歷史和實時數據饋送提供有效的查詢引擎？
我可能有點超出我的深度，因為我對此還是很陌生，所以請告訴我我是否採取了錯誤的方法。我還想了解更多關於這些系統是如何設計的資訊，或者任何其他有關數據處理方法的資源/書籍。
是的，我建議讓歷史回測和實時交易盡可能相似。當您不可避免地看到不同的回測和實時結果時，這會給您留下一個較小的可變性來源。
實時數據饋送和歷史數據集是否通常在其各自的處理程序中提供相同的介面來查詢/檢索其數據集？
回測和實時交易通常建立在
$$ … $$在同一個交易/處理引擎上執行？
這是兩個不同的東西。兩者都很重要。
擁有相同的界面可以讓您在回測和生產中重用相同的程式碼。可以說，這稍微重要一些，因為：
- 大多數策略都是非常複雜的狀態機，用兩組不同的介面重複實現相同的策略是非常困難的。
- 在上游的某個時刻，幾乎不可能使用完全相同的“處理引擎”進行回測和生產，因為前者從文件中讀取，而後者讀取多播/單播訂閱，而前者大部分時間都在等待而後者可以繼續閱讀。我見過一些公司竭盡全力將兩者統一起來，甚至讓他們的回測平台重放整個數據包擷取只是為了回測 1 個符號，但收益不大。
- “回測”的目的不一定是為了獲得像 PnL 這樣的準確指標，並且可能有許多其他目標導致您設計回測循環（可能是“處理引擎”的主要部分）以優先考慮速度（吞吐量）精度過高，或併行處理超過串列處理，非同步超過同步等。
如何最有效地處理數據流？
請參閱我關於數據庫的其他文章。