最好的編程 語言 的 算法交易 系統

+

最好的編程語言的算法交易系統？ 通過對2013年7月26日邁克爾·霍爾 - 摩爾 其中一個我收到了QS郵袋中最常見的問題是“什麼是最好的編程語言，算法交易？”。 簡單的答案是，有沒有“最好”的語言。 策略參數，性能，模塊化，開發，永續性和成本都必須加以考慮。 本文將概述的算法交易系統架構的必要組成部分和執行方面的決策如何影響語言的選擇。 首先，一個算法交易系統的主要組成部分將被視為，如研究工具，投資組合優化器，風險經理和執行引擎。 隨後，不同的交易策略進行審查，以及它們如何影響系統的設計。 在特定的交易與可能的交易量的頻率都將被討論。 一旦交易策略已被選擇，有必要建築師整個系統。 這包括對罕見的，潛在的災難性事件選擇硬件，操作系統（S）和系統彈性。 而結構正在考慮，適當考慮必須支付給性能 - 既要研究工具以及實時執行環境。 什麼是交易系統意欲何為？ 在決定“最好”的語言與其中寫入的自動交易系統，有必要定義的要求。 在系統將要執行純粹基於？ 請問系統需要一個風險管理或投資組合構建模塊？ 請問系統需要高性能backtester？ 對於大多數策略交易系統可被劃分成兩大類：研究和信號產生。 研究涉及超過歷史數據的戰略績效評價。 在評估前的市場數據交易策略的過程稱為回溯測試。 數據大小和算法複雜性都會對backtester的計算強度大的影響。 CPU速度和並發性通常是限制因素的優化研究執行速度。 信號的產生涉及生成一組交易信號從一個算法，通常通過經紀人發送這些命令到市場。 對於一定的策略需要較高的性能水平。 的I / O的問題，例如網絡帶寬和延遲往往在優化執行系統的限制因素。 這樣的語言為你的整個系統的每個部件的選擇可能完全不同。 類型，頻率和策略的卷 採用算法策略的類型將對系統的設計有很大的影響。 這將是必要的，以考慮被交易的市場中，連接到外部數據供應商，頻率和策略的體積，便於開發和性能優化的之間的折衷，以及任何定制的硬件，其中包括共同定位定制 服務器的GPU或FPGA中，可能是必要的。 該技術的選擇了低頻美國股票策略將是不同於期貨市場高頻統計套利策略交易大不相同。 這涉及到一個戰略的手在此之前的語言許多數據供應商的選擇必須進行評估。 將有必要考慮在供應商脫機的面的連接到供應商的任何的API結構，數據的及時性，存儲要求和彈性。 這也是明智的，具備快速訪問多個供應商！ 各種樂器都有自己的存儲怪癖，其實例包括股票和到期日期為期貨（不提任何具體的場外交易數據）的多個股票代碼。 這需要被考慮到平台設計。 策略的頻率很可能是怎樣的技術棧將被定義的最大驅動力之一。 策略更頻繁使用的數據要比微小的或第二條要求顯著考慮與性能有關。 的策略超過了第二條（即勾選數據）導致的性能驅動設計的基本要求。 為高頻策略市場數據的相當量將需要存儲和評估。 軟件如HDF5或KDB +通常用於這些角色。 為了處理廣泛卷所需HFT應用的數據，一個廣泛優化backtester和執行系統必須使用。 C / C ++（可能具有一些彙編器）是可能的最強語言候補。 超高頻戰略將幾乎肯定需要自定義硬件如FPGA，交流合作的位置和籽粒/網絡接口調整。 研究系統 研究系統通常涉及交互式開發和自動化腳本的混合物。 前者往往需要一個IDE內進行如Visual Studio，MATLAB或R工作室。 後者涉及大量的數值計算，在眾多的參數和數據點。 這導致了語言的選擇，提供一個簡單的環境，以測試代碼，而且還提供了足夠的性能，以評估在多個參數尺寸策略。 在這個空間裡典型的IDE包括微軟的Visual C ++ / C＃，其中包含大量的調試功能，代碼完成功能（通過“智能感知”）和整個項目的棧簡單的概述（通過數據庫ORM，LINQ）; MATLAB軟件 其目的是，獲得豐富的數值線性代數和矢量化操作，但在交互式控制台方式; ř工作室。 它包裝在一個完全成熟的IDE R統計語言控制台; Eclipse IDE中為Linux Java和C ++; 和半私有的IDE中，例如Enthought雨棚為Python，其中包括數據分析庫，如NumPy的。 SciPy的。 scikit學習在一個交互式（控制台）的環境和大熊貓。 數值回測，上述所有語言是合適的，儘管這不是必須利用一個GUI / IDE作為代碼將被執行“在後台”。 在這個階段的主要考慮是，執行速度。 編譯型語言（如C ++）是非常有用的，如果回測參數尺寸較大。 記住，這是必要的，以提防這種系統的，如果是這樣的話！ 解釋型語言如Python經常利用高性能庫，比如與NumPy /大熊貓的回測的步驟，以保持合理程度的競爭力編譯當量。 最終選擇了回測的語言將特定算法需求以及圖書館的範圍，在語言（更多關於該下文）來確定。 然而，用於該backtester和研究環境的語言可以是完全獨立的沒有在這個組合構建，風險管理和執行部件使用的，如將要看到的。 組合構建與風險管理 在投資組合構建與風險管理組件通常是由零售算法交易商忽視。 這幾乎總是錯誤的。 這些工具提供由資本將得以保留的機制。 他們不僅試圖緩解“冒險”的賭注的數量，而且還最大限度地減少自己的行業客戶流失，降低了交易成本。 這些組件的複雜的版本可以對利潤率的質量和consistentcy一個顯著效果。 這是簡單的創建一個策略的投資組合構建機制和風險管理人員穩定可以很容易地修改以處理多個系統。 因此，它們應該在算法交易系統的設計的一開始就被認為是必要組分。 在投資組合構建系統的任務是把一組所需的交易而產生的一系列實際的交易，最大限度地減少客戶流失的，保持暴露於各種因素（如部門，資產類別，波動性等）和資本配置優化各種 在投資組合策略。 組合構建通常會減少到一個線性代數問題（如一個矩陣因子），因此性能是高度依賴於數值線性代數實施可用的有效性。 公共庫包括的差別的。 LAPACK和NAG用於C ++。 MatLab的也擁有廣泛的優化矩陣運算。 Python的使用NumPy的/ SciPy的這種計算。 一個經常重新平衡投資組合將需要編譯（和很好的優化！）矩陣庫來進行這一步了，以免瓶頸的交易系統。 風險管理是一個算法交易系統的另一個極為重要的一部分。 風險可以有多種形式：波動加劇（！雖然這可能被視為理想的一定的策略），增加資產類別，交易對手缺省情況下，服務器中斷之間的相關性，“黑天鵝”事件，並在交易編碼未被發現的錯誤， 僅舉幾例。 風險管理組件嘗試和預測資產類別和交易資金的​​後續效應（S）之間的過度波動和相關性的影響。 通常，這減少了一組統計計算，如蒙地卡羅“壓力測試”的。 這是非常相似的一個衍生物定價引擎的計算需求，因此將CPU限制。 這些模擬是高度parallelisable（見下文），並在一定程度上，也可以“扔有問題的硬件”。 執行系統 執行系統的任務是接收濾波的交易信號來自投資組合構建與風險管理的組成部分，並將它們發送到一個券商或市場准入等手段。 對於廣大散戶的算法交易策略，這涉及到一個API或FIX連接到經紀公司，如盈透證券。 在語言選擇時的主要考慮因素包括API的一個API，執行頻率和預計延誤質量，語言包裝的可用性。 API的“質量”指的是多麼有據可查的，它提供了什麼樣的表現，是否需要被訪問的獨立軟件或是否一個網關可以建立在一個無頭的方式（即沒有GUI）。 在盈透證券的情況下，交易平台工具需要運行在GUI環境中才能訪問他們的API。 我曾經安裝一個桌面的Ubuntu版本到亞馬遜雲服務器遠程訪問盈透證券，純粹是因為這個原因！ 大多數API將提供C ++和/或Java接口。 它通常是到社會發展特定語言的包裝為C＃，Python中，R時，Excel和MATLAB。 請注意，每增加插件使用（尤其是API包裝），還有餘地的錯誤蔓延到系統中。 務必測試這樣的插件，並確保他們積極維護。 一個值得計是怎麼看許多新的更新代碼庫已在最近幾個月。 執行頻率是在執行算法至關重要。 需要注意的是數百個訂單，可每分鐘發送一次，因此性能是至關重要的。 滑移將通過嚴重不良執行系統再發生，這將對盈利能力產生重大影響。 靜態類型語言（見下文），如C ++ / Java的一般都是最佳的執行，但有一個權衡的開發時間，測試和維護的方便性。 動態類型語言，如Python和Perl現在一般“不夠快”。 始終確保組件被設計以模塊化的方式（見下文），以便它們可以被“換出”出作為系統鱗。 建築規劃和開發過程 交易系統的組件，其頻率和體積的要求已在上面討論過，但系統的基礎設施還沒有被覆蓋。 那些充當分銷商或在小型基金的工作將有可能被“戴帽子的許多”。 這將是必要的是涵蓋的α-模型，風險管理和執行參數，並且還系統的最終實施。 在深入研究特定語言的最佳的系統架構的設計將被討論。 關注點分離 一個必須在一開始就做出的最重要的決定是如何“分開的關注”交易制度。 在軟件開發中，這基本上意味著如何在交易系統的不同方面分解為獨立的模塊化組件。 通過暴露接口在各組分很容易換出系統用於其他版本援助性能，可靠性或維修的部件，而不需要修改任何外部依賴代碼。 這是“最佳做法”這樣的系統。 對於在較低頻率等策略措施建議。 對於超高頻交易規則手冊可能在調整系統以更高的性能為代價不容忽視。 更緊密耦合系統可以是合乎需要的。 創建算法交易系統的一個組成部分的地圖是值得在本身的製品。 不過，最佳的做法是，以確保沒有對歷史和實時市場數據輸入單獨的組件，數據存儲，數據訪問API，backtester，策略參數，組合構建，風險管理和自動執行系統。 例如，如果正在使用的數據存儲區是目前表現不佳，甚至在顯著優化的水平，它可以被換出最小重寫到數據攝取或數據訪問API。 作為迄今為止作為backtester和隨後的部件而言，沒有任何區別。 分離的部件的另一個好處是，它允許整個系統中使用的各種編程語言。 沒有必要被限制在一個單一的語言，如果各部件的通信方法是獨立於語言。 這將是這種情況，如果他們通過TCP / IP，ZeroMQ或某些其它語言無關的協議進行通信。 作為一個具體的例子，考慮回測系統的情況下被用C ++編寫的“數字運算”的表現，而投資組合經理和執行系統使用的是SciPy的和IBPy用Python編寫的。 性能注意事項 性能是一個顯著考慮大多數交易策略。 對於較高頻率的策略是最重要的因素。 “性能”涵蓋了範圍廣泛的問題，如算法的執行速度，網絡時延，帶寬，數據I / O，並發/並行和縮放。 每一個領域都分別涵蓋大型教科書，因此本文將只劃傷每個主題的表面。 體系結構和語言的選擇現在將其對性能的影響方面進行討論。 由高德納所表達的普遍看法。 計算機科學的創始人之一，是“過早的優化是一切罪惡的根源”。 這幾乎總是這樣 - 建設一個高頻交易算法時除外！ 對於那些誰感興趣的頻率較低的策略，常用的方法是建立一個系統以盡可能簡單的方式，只有優化瓶頸開始出現。 剖析工具被用來確定何處出現瓶頸。 型材可以為所有上面列出的因子來進行，無論是在微軟Windows或Linux環境。 有許多可用的這樣做的操作系統和語言的工具，以及第三方工具。 語言的選擇，現在將在性能方面進行討論。 C ++，Java和Python的，R和Matlab都包含高性能庫（無論是作為其標準或外部部件）的基本數據結構和算法的工作。 C ++附帶的標準模板庫，而Python包含NumPy的/ SciPy的。 常見的數學任務是在這些庫被發現，這是很少有益寫一個新的實現。 如果高度定制化的硬件架構是必需的，一個算法正在廣泛使用的專有擴展（如自定義緩存）的一個例外是。 但是，可以更好地用於開發，優化交易基礎設施的其它部分浪費時間往往是“車輪再造”。 開發時間非常寶貴尤其是在鞋底開發的背景下。 延遲通常是執行系統的一個問題為研究工具通常位於同一機器上。 對於前者，延遲可發生在沿執行路徑的多個點。 數據庫必須先諮詢（磁盤/網絡延遲），必須產生信號（操作SYSTE，籽粒短信延遲），發送交易信號（NIC延遲）和訂單處理（交換系統內部的延遲）。 對於較高頻率的操作，有必要十分熟悉籽粒優化以及網絡傳輸的優化。 這是一個深區域和是顯著超出了本文的範圍，但如果一個UHFT算法期望然後意識到知識的深度所需的！ 緩存是在一個量化交易顯影劑工具箱非常有用的。 緩存是指存儲的方式，允許更高性能的訪問頻繁訪問的數據，在數據的潛在過時為代價的概念。 從磁盤備份關係數據庫提取數據，並把它到內存中時，一個常見的用例發生在Web開發。 為數據的任何後續請求不必“撞數據庫”等性能的提高是顯著。 對於交易情況緩存可以是非常有益的。 例如，一個策略組合的當前狀態可以被存儲在一個高速緩存中，直到它被重新平衡，使得該列表不需要在交易算法的每個循環來再生。 這種再生可能是較高的CPU和磁盤I / O操作。 然而，緩存並非沒有其自身的問題。 再生緩存數據全部一次，由於緩存存儲的volatilie性質，可以將基礎設施顯著的需求。 另一個問題是狗樁。 其中多個世代的一個新的高速緩存副本進行了非常高的載荷，從而導致級聯故障下。 動態內存分配是在軟件執行一項昂貴的操作。 因此，當務之急是如何分配內存和程序流程中釋放的更高性能的交易應用得到很好識別。 較新的語言標準，如Java，C＃和Python的所有執行自動垃圾回收。 這是指釋放動態分配的內存中的對象時，超出範圍。 在開發過程中垃圾收集是非常有用的，因為它減少了錯誤，並有助於可讀性。 然而，這是經常次優的某些高頻交易策略。 定制垃圾收集常常希望對這些情況。 在Java中，例如，通過調整垃圾收集器和堆的配置，也能夠獲得高的性能HFT策略。 C ++不提供本機的垃圾收集器，因此，有必要來處理所有的內存分配/釋放作為對象的實現的一部分。 雖然潛在的錯誤發生（可能導致懸擺指針），這是非常有用的有對象如何出現在堆對於某些應用的細粒度控制。 當選擇一個語言確保研究如何垃圾收集器的工作原理，以及是否可以被修改，以優化對特定的用例。 在算法交易系統的許多操作都適合進行並行化。 這是指在多個編程操作同時的概念，即在“平行”。 所謂“embarassingly平行”算法包括能完全獨立於其它步驟，計算步驟。 某些統計操作，如Monte Carlo模擬，是embarassingly並行算法在每個隨機抽獎和後續的路徑操作的好例子可以在不其他路徑的知識來計算。 其他算法僅部分parallelisable。 流體動力學模擬是這樣一個例子，其中計算的域可以被細分，但最終這些域必須彼此並且因此操作是部分連續的通信。 Parallelisable算法受到阿姆達爾定律。 它提供了一個理論上限為並行化算法的性能增加時受$ N $獨立的過程（例如，在一個CPU核心或線程）。 並行化已成為作為優化的手段越來越重要，因為處理器的時鐘速度已經停滯不前，因為新的處理器包含許多內核與執行並行計算。 消費者的圖形硬件的崛起（predominently視頻遊戲）導致了圖形處理單元（GPU），其中包含數百個“核”為高並發操作的發展。 這些GPU是現在很實惠。 高層框架，如Nvidia的CUDA已導致學術界和金融廣泛採用。 這樣的GPU硬件一般只適用於定量金融學的研究方面，而其他更多的專用硬件（包括現場可編程門陣列 - 的FPGA）用於（U）HFT。 如今，大多數現代漢語語言支持程度的並發/多線程的。 因此，它是簡單的，以優化一個backtester，因為所有的計算一般是獨立於其他。 結垢軟件工程和操作是指系統來處理持續增加負荷更大請求的形式，更高級處理器的使用和更多的存儲器分配的能力。 在算法交易策略是能夠擴展它是否可以接受更大數量的資金，仍然產生穩定的回報。 該交易技術堆棧擴展它是否能承受較大的交易量和增加的延遲，沒有瓶頸。 而系統的設計必須按比例的，它往往是很難預測預先將發生的瓶頸。 Rigourous測井，測試，分析和監測將在允許系統進行擴展極大地幫助。 語言本身經常被描述為“不能擴展”。 這通常是誤傳的結果，而不是鐵一般的事實。 這是總的技術堆棧，應確定為可擴展性，而不是語言。 顯然，某些語言比其他人在特定的使用情況下更高的性能，但有語言永遠比另一種在任何意義上“更好”。 管理規模的一種方法是分離的擔憂，如上所述。 為了進一步引進來處理“尖峰”系統（即突然波動而引發的交易筏）的能力，這是非常有用的創建“消息隊列結構”。 這只是意味著放置元件之間的消息隊列系統使得訂單“堆疊”，如果某種組分是無法處理大量請求。 而不是被丟失請求他們只是保存在堆棧，直到該消息被處理。 這是發送的交易來執行引擎中特別有用。 如果發動機正在遭受猛烈的等待時間，然後將備份的交易。 甲以商品信號發生器和執行API之間隊列將在潛在的貿易滑移為代價緩解這個問題。 一個受人尊敬的開源消息隊列經紀人是RabbitMQ的。 硬件和操作系統 運行你的戰略的硬件可以有你的算法的盈利能力產生顯著的影響。 這是不局限於高頻貿易商任一個問題。 選擇不當的硬件和操作系統可能會導致在最不合時宜的時刻機毀人亡或自動重啟。 因此，有必要考慮您的應用程序將駐留。 的選擇通常是個人台式機，一個遠程服務器，“雲”提供商或交換共同定位服務器之間。 台式機易於安裝和管理，特別是新的用戶友好的操作系統，如Windows 7/8，Mac OSX和Ubuntu Linux系統。 然而桌面系統確實擁有一些顯著的缺點。 最重要的是，專為台式機操作系統的版本，可能需要重新啟動/修補（往往在最糟糕的時候！）。 他們還使用了更多的計​​算資源所蘊含需要一個圖形用戶界面（GUI）的。 Utilising硬件在家庭（或當地辦事處）的環境中可能會導致互聯網連接和電源的正常運行時間的問題。 桌面系統的主要好處是顯著的計算能力可以為遠程專用服務器（或基於雲的系統）相媲美的速度成本的一小部分購買。 專用的服務器或基於雲的機器，而通常比台式機的選擇更昂貴的，允許更多的顯著冗餘的基礎設施，如自動數據備份，能夠更直接地確保正常運行和遠程監控。 它們更難管理，因為它們需要使用操作系統的遠程登錄功能的能力。 在視窗這通常是通過GUI遠程桌面協議（RDP）。 在基於Unix的系統命令行的Secure Shell（SSH）被使用。 基於Unix的服務器基礎設施幾乎都是基於命令行的這立即使得基於GUI的編程工具（如MATLAB或Excel）無法使用。 甲共同定位服務器，作為短語中使用資本市場上，僅僅是為了減少交易算法的延遲駐留在一個交換的專用服務器。 這是對某些高頻交易策略，這依賴於低延時，以便產生阿爾法絕對必要的。 硬件選擇和編程語言的選擇的最後一個方面是平台獨立性。 是否需要為代碼在多個不同的操作系統上運行？ 是專門的代碼是在一個特定類型的處理器架構上運行，如Intel在x86 / x64或者才有可能對RISC處理器上執行，例如由ARM生產的？ 這些問題將高度依賴的頻率和策略類型正在實施。 韌性和測試 一個失去對算法交易了很多錢的最佳方法是創建一個系統，沒有彈性。 這指的是系統正受到罕見的事件，如券商破產，突然過度波動，區域範圍的停機雲服務器提供商或意外刪除整個交易數據庫時的耐久性。 年利潤可以在幾秒鐘之內有設計拙劣的架構被淘汰。 這是絕對必須考慮的問題，如debuggng，檢測，日誌記錄，備份，高可用性和監控作為系統的核心部件。 很可能的開發時間，在任何合理的複雜的自定義量化交易應用的至少50％將在調試，測試和維護花費。 幾乎所有的編程語言或者附帶相關的調試器或擁有備受推崇的第三方替代品。 從本質上講，一個調試器允許執行與代碼路徑插入任意破發點的節目，這暫時停止，以調查系統的狀態執行。 調試的主要好處是，它有可能事先調查的代碼的行為，以一公知的崩潰點。 調試是工具箱用於分析編程錯誤中的必要成分。 然而，他們被更廣泛地應用於編譯語言如C ++或Java，因為解釋語言如Python往往更容易調試，由於較少的LOC和更簡潔的語句。 儘管這種趨勢Python不附帶的PDB。 這是一個複雜的調試工具。 微軟的Visual C ++ IDE擁有豐富的圖形用戶界面的調試功能，而在命令行Linux的C ++程序員，gdb調試器存在。 測試在軟件開發是指施加已知的參數和結果，以一個基本代碼中的特定功能，方法和目的，在為了模擬行為和評估多個代碼路徑，從而有助於確保一系統的行為，因為它應該的過程。 最近的一個範例被稱為測試驅動開發（TDD），在測試代碼開發了針對沒有實現指定接口。 在此之前完成實際的代碼庫的所有測試將失敗。 由於代碼被寫入“填補空白”，該測試將最終全部通過，在這一點上的發展應該停止。 TDD需要大量的前期規格設計，以及紀律，以開展成功的健康程度。 在C ++中，加速提供了一個單元測試框架。 在Java中，JUnit的庫中存在實現同樣的目的。 Python中也有單元測試模塊作為標準庫的一部分。 很多其他語言擁有的單元測試框架，往往有多種選擇。 在生產環境中，複雜的日誌記錄是絕對必要的。 記錄是指輸出消息，用不同嚴重程度的，關於一個系統的執行行為到平面文件或數據庫的過程。 日誌是一個“攻擊的第一行”打獵意外的程序運行時行為的時候。 不幸的是，日誌系統的缺點，往往只是被事後發現！ 如下面討論的備份，日誌記錄系統應適當考慮前一個系統的設計。 在Microsoft Windows和Linux都具有廣泛的系統日誌記錄功能，和編程語言往往附帶有涉及大部分用例的標準日誌庫。 它往往是明智的集中，以分析它在以後的日誌信息，因為它往往會導致對提高性能和減少錯誤，這將幾乎肯定會對您的交易收益產生積極影響的想法。 雖然系統的日誌記錄將提供關於在過去已經蒸發信息，監控應用程序將提供深入了解正在發生的事情現在。 該系統的所有方面，應考慮進行監測。 系統級指標，如磁盤使用率，可用內存，網絡帶寬和CPU的使用提供了基本的負載信息。 交易指標，如不正常的價格/容量，突然快速提款和帳戶曝光不同行業/市場也應持續監控。 此外，閾值系統應該煽動提供通知，當某些指標被突破，提升取決於指標的嚴重程度通知方式（電子郵件，短信，自動電話）。 系統監控往往是系統管理員或業務經理的領域。 然而，作為唯一的交易顯影劑，這些指標必須被確定為較大的設計的一部分。 監測許多解決方案有：專利，主持和開放源代碼，允許指標為特定用例廣泛的定制。 備份和高可用性應該是一個交易系統的首要關注。 結論 邁克爾·霍爾 - 摩爾 邁克是QuantStart的創始人，曾參與了定量金融行業在過去的五年中，主要是作為一個定量的開發，後來成為一個定量交易員諮詢對沖基金。