摘要：隨著大數(shù)據(jù)時(shí)代的來臨,證券行業(yè)這種數(shù)據(jù)密集型產(chǎn)業(yè)對(duì)數(shù)據(jù)處理的性能有著愈發(fā)急切的需求。傳統(tǒng)的磁盤-數(shù)據(jù)庫(kù)模式的處理速度愈發(fā)不能滿足需要。文中采取內(nèi)存計(jì)算方式給出了該問題的一個(gè)解決方向。首先結(jié)合目前研究現(xiàn)狀簡(jiǎn)要說明內(nèi)存計(jì)算的概念,并總結(jié)出內(nèi)存計(jì)算的特點(diǎn)。然后從單節(jié)點(diǎn)和多節(jié)點(diǎn)兩個(gè)方向結(jié)合證券行業(yè)不同的業(yè)務(wù)場(chǎng)景給出對(duì)應(yīng)的系統(tǒng)架構(gòu),并指出相關(guān)條件下需要關(guān)注的問題和解決方向。

　　關(guān)鍵詞：內(nèi)存計(jì)算;證券;單節(jié)點(diǎn);多節(jié)點(diǎn);架構(gòu)設(shè)計(jì)

　　1總述

　　隨著大數(shù)據(jù)時(shí)代的來臨，證券行業(yè)的發(fā)展日新月異，交易數(shù)據(jù)量越來越大，日交易額已經(jīng)步入千億級(jí)別，2016年雖然A股市場(chǎng)較為低迷，以震蕩為主，但是已有統(tǒng)計(jì)數(shù)據(jù)表明，截止2016年末，僅滬深兩市場(chǎng)的日交易額均已達(dá)億元級(jí)別。近幾年隨著交易所融資融券，股票質(zhì)押，券商投行，再融資，并購(gòu)重組等新業(yè)務(wù)推進(jìn)步伐的加快，基金公司、券商、私募等機(jī)構(gòu)投資者也對(duì)量化交易、策略交易、做市、程序化交易等有著愈發(fā)迫切的需求。滬港深市場(chǎng)交易種類繁多，交易數(shù)據(jù)的快速增長(zhǎng)，大規(guī)模數(shù)據(jù)和業(yè)務(wù)場(chǎng)景的高時(shí)效性要求與傳統(tǒng)的內(nèi)存-磁盤訪問模式產(chǎn)生了巨大矛盾，隨著數(shù)據(jù)量的激增，在傳統(tǒng)計(jì)算模型中的諸多問題逐漸顯現(xiàn)出來,如內(nèi)存容量的大小,原始數(shù)據(jù)緩存的尋址命中率,磁盤的I/O瓶頸(輸入/輸出)，數(shù)據(jù)處理效率等問題，基于底層數(shù)據(jù)查詢方式的局限,目前這些問題在現(xiàn)有的架構(gòu)上都只能在軟件或者硬件上初步緩解,如更新系統(tǒng)架構(gòu),更換更好的CPU,服務(wù)器等硬件設(shè)施,但是并不能從根本上解決這些問題。

　　內(nèi)存計(jì)算的出現(xiàn)給這種數(shù)據(jù)密集型訪問的處理方式提供了一個(gè)較好的解決方案。以內(nèi)存計(jì)算為基礎(chǔ)的內(nèi)存數(shù)據(jù)庫(kù)可以從很大程度上緩解目前的性能瓶頸。其支持?jǐn)?shù)據(jù)直接訪問的高處理效率很好的貼合了當(dāng)前證券行業(yè)的業(yè)務(wù)現(xiàn)狀。內(nèi)存數(shù)據(jù)庫(kù)系統(tǒng)帶來的優(yōu)越性能不僅僅在于對(duì)內(nèi)存讀寫比對(duì)磁盤讀寫快上，更重要的是，從根本上拋棄了許多傳統(tǒng)的磁盤數(shù)據(jù)管理方式，并基于全部?jī)?nèi)存數(shù)據(jù)的管理進(jìn)行了新的體系結(jié)構(gòu)的設(shè)計(jì)，并且在數(shù)據(jù)緩存、快速算法、并行操作等方面有相應(yīng)的改進(jìn)，故相比于傳統(tǒng)數(shù)據(jù)庫(kù)的數(shù)據(jù)處理速度來說有極大的提高。

　　本文第2節(jié)介紹內(nèi)存計(jì)算的相關(guān)特點(diǎn)及當(dāng)前的發(fā)展?fàn)顩r,并根據(jù)系統(tǒng)硬件架構(gòu)的不同概述對(duì)應(yīng)的設(shè)計(jì)要點(diǎn)。第3節(jié)針對(duì)于單節(jié)點(diǎn)系統(tǒng)框架,重點(diǎn)從性能,并發(fā)的角度設(shè)計(jì)系統(tǒng)架構(gòu);第3節(jié)針對(duì)于多節(jié)點(diǎn)系統(tǒng)框架,重點(diǎn)從網(wǎng)絡(luò),多節(jié)點(diǎn)間通信的角度分析系統(tǒng);第5節(jié)總結(jié)內(nèi)存計(jì)算架構(gòu)并給出進(jìn)一步研究方向。

　　2內(nèi)存計(jì)算概述

　　內(nèi)存計(jì)算的概念早在20世紀(jì)90年代的時(shí)候就已經(jīng)有人提出并付諸實(shí)驗(yàn),只是局限于當(dāng)時(shí)的技術(shù)水平等條件,研究的步伐沒有現(xiàn)在這么快。目前較權(quán)威的機(jī)構(gòu),如IBM對(duì)其說明為：針對(duì)數(shù)據(jù)訪問密集型應(yīng)用,為了提高數(shù)據(jù)處理效率,將數(shù)據(jù)全部或部分放置于內(nèi)存,利用內(nèi)存的高讀取速度來提高處理速度,結(jié)合具體業(yè)務(wù)場(chǎng)景來看,內(nèi)存計(jì)算還需要另外專門設(shè)計(jì)搭配的軟件體系架構(gòu)、軟件接口等[1]。據(jù)此,內(nèi)存計(jì)算應(yīng)包含如下幾個(gè)特性：

　　1)大容量?jī)?nèi)存(單節(jié)點(diǎn)或者多節(jié)點(diǎn)),可將待處理的數(shù)據(jù)全部或者主要的部分存放于內(nèi)存中;

　　2)良好的業(yè)務(wù)處理模型和接口;

　　3)數(shù)據(jù)規(guī)模大,較高的時(shí)效性要求;

　　4)支持業(yè)務(wù)的并行處理。

　　綜上,內(nèi)存計(jì)算是在大數(shù)據(jù)環(huán)境下,憑借計(jì)算機(jī)軟硬件的快速發(fā)展,并通過體系架構(gòu)和編程模型的重大革新,將數(shù)據(jù)的處理主要放在內(nèi)存中完成,取代原來數(shù)據(jù)傳統(tǒng)操作的新型的并發(fā)計(jì)算架構(gòu)。

　　目前國(guó)內(nèi)證券行業(yè)的蓬勃發(fā)展,大券商實(shí)力較為雄厚,經(jīng)過多年的積淀,對(duì)性能,規(guī)模,災(zāi)備,監(jiān)控等都有著較高的要求,分布式多節(jié)點(diǎn)部署可以較好的切合需要。相比較而言,小型券商也有類似的需求,只是受限于自身的發(fā)展情況,單節(jié)點(diǎn)已經(jīng)能滿足大部分需要。

　　1)單節(jié)點(diǎn)

　　單節(jié)點(diǎn)內(nèi)存計(jì)算系統(tǒng)是指運(yùn)行于單個(gè)物理節(jié)點(diǎn)上,擁有一個(gè)或多個(gè)處理器和共享內(nèi)存(集中式共享內(nèi)存,或非一致性共享內(nèi)存(non-uniformmemoryaccess,NUMA))單節(jié)點(diǎn)上的內(nèi)存計(jì)算主要是壓榨CPU的性能,同時(shí)優(yōu)化軟件處理流程,磁盤讀取方式和業(yè)務(wù)處理邏輯,同步采用新型計(jì)算架構(gòu),采用大內(nèi)存和多線程并行,以達(dá)到充分發(fā)揮內(nèi)存和CPU的cache的緩存處理能力,提高處理性能的目的。

　　2)多節(jié)點(diǎn)

　　單節(jié)點(diǎn)內(nèi)存計(jì)算因局限于硬件資源,在處理更大規(guī)模數(shù)據(jù)的時(shí)候,由于先天架構(gòu)的局限,在硬件的橫向擴(kuò)展方面的問題并不一定完全兼容。故分布式系統(tǒng)的內(nèi)存計(jì)算開發(fā)和應(yīng)用也逐漸豐富起來。比如以MapReduce為代表的大規(guī)模分布式內(nèi)存處理技術(shù)。這種內(nèi)存計(jì)算處理方式充分考慮了硬件的擴(kuò)展性,天然支持多個(gè)節(jié)點(diǎn)(計(jì)算機(jī)/服務(wù)器)構(gòu)成的集群來構(gòu)建分布式內(nèi)存,并通過統(tǒng)一的資源調(diào)度,使待處理數(shù)據(jù)有序的存儲(chǔ)于對(duì)應(yīng)分布式內(nèi)存中,并根據(jù)一定的規(guī)則實(shí)現(xiàn)大規(guī)模數(shù)據(jù)的快速訪問和并行處理。

　　3單節(jié)點(diǎn)系統(tǒng)設(shè)計(jì)要點(diǎn)

　　在該業(yè)務(wù)場(chǎng)景下，因其不涉及與外部的交互，所有的業(yè)務(wù)均是由券商自己?jiǎn)喂?jié)點(diǎn)內(nèi)部完成，故技術(shù)上著重考慮的是單機(jī)性能方面的問題。如系統(tǒng)內(nèi)高并發(fā)的解決，復(fù)雜業(yè)務(wù)的接口設(shè)計(jì),業(yè)務(wù)流程的優(yōu)化等。

　　簡(jiǎn)要的系統(tǒng)框架圖如下：

　　在簡(jiǎn)單的網(wǎng)絡(luò)環(huán)境下,(暫不考慮行情等其他輔助插件),性能的提升需緊密結(jié)合業(yè)務(wù)流程,精簡(jiǎn)不需要的冗余步驟,圍繞多線程并發(fā)開展業(yè)務(wù)流程設(shè)計(jì)。打好系統(tǒng)的底層基礎(chǔ)架構(gòu),充分考慮后續(xù)的延展性和健壯性。

　　在具體的數(shù)據(jù)處理上,現(xiàn)也有給出較好解決方案的處理框架,如Grace[2],Ligra[3],GRACE[4]和GraphLab[5]。大體思路都是一樣,都利用多核CPU和大內(nèi)存,結(jié)合多線程并行技術(shù),達(dá)到充分利用內(nèi)存和CPU的目的,只是三者的處理機(jī)制和側(cè)重點(diǎn)有所區(qū)別。Grace提出的是一種聚集圖更新策略,針對(duì)于圖劃分間(線程間)進(jìn)行了通信和負(fù)載均衡優(yōu)化,以此提高圖處理效率;Ligra的計(jì)算方式則是以圖為中心,提出了一種輕量級(jí)的圖處理架構(gòu),重點(diǎn)在于更容易實(shí)現(xiàn)對(duì)應(yīng)的圖遍歷算法;GRACE重點(diǎn)針對(duì)的是同步/異步模式,提出了一種可以根據(jù)具體需求場(chǎng)景,由用戶自行決定或者切換同步/異步執(zhí)行的并行圖處理結(jié)構(gòu)。最后,GraphLab是一種基于圖模型處理的機(jī)器學(xué)習(xí)算法,其并行框架是異步的。

　　在數(shù)據(jù)存貯上,內(nèi)存數(shù)據(jù)庫(kù)起步很早,如MMDB[6-7](mainmemorydatabase),在數(shù)據(jù)訪問,主存和磁盤的尋址映射,內(nèi)存索引結(jié)構(gòu)的優(yōu)化,查詢的優(yōu)化,日志記錄和優(yōu)化上都有相應(yīng)的提高,現(xiàn)也得到了較好的效果,近幾年已有商業(yè)化的解決方案出現(xiàn)。類似的解決方案還有,hyper和hekaton,Hyper[8]是一種混合OLTP和OLAP的高性能內(nèi)存數(shù)據(jù)庫(kù);Hekaton[9]是一個(gè)基于行,針對(duì)事務(wù)處理(TP)的的內(nèi)存數(shù)據(jù)管理系統(tǒng),其優(yōu)化過的應(yīng)用可提升50倍的速度,并且完全集成了SQLServer。

　　雖然在底層上對(duì)數(shù)據(jù)的訪問有了極大的改進(jìn),但是在業(yè)務(wù)設(shè)計(jì)上也不能忽視數(shù)據(jù)的訪問成本,流程的設(shè)計(jì)也需要兼顧數(shù)據(jù)的增刪改查邏輯,避免無謂的資源消耗。

　　4多節(jié)點(diǎn)系統(tǒng)設(shè)計(jì)要點(diǎn)

　　在多節(jié)點(diǎn)的環(huán)境下，相對(duì)于內(nèi)存讀取的速度，網(wǎng)絡(luò)間通信的讀寫至少要慢上兩個(gè)數(shù)量級(jí)。如何解決網(wǎng)絡(luò)內(nèi)節(jié)點(diǎn)間通信，數(shù)據(jù)傳輸，節(jié)點(diǎn)間同步，安全問題和節(jié)點(diǎn)宕機(jī)的災(zāi)備恢復(fù)等則是需要考慮的重點(diǎn)。

　　簡(jiǎn)要的系統(tǒng)框架圖如下：

　　在該多節(jié)點(diǎn)的網(wǎng)絡(luò)環(huán)境下,(暫不考慮行情等其他輔助插件),底層需要加入仲裁機(jī)這個(gè)角色,承擔(dān)負(fù)載均衡,排隊(duì)等職責(zé),用來均衡多系統(tǒng)核心的負(fù)載,并對(duì)數(shù)據(jù)包進(jìn)行去重,排序來保持業(yè)務(wù)處理的可靠性。網(wǎng)絡(luò)節(jié)點(diǎn)的布置中還需要用相應(yīng)的網(wǎng)絡(luò)協(xié)議和對(duì)應(yīng)的鏈路訪問機(jī)制來維護(hù)節(jié)點(diǎn)間的路由狀態(tài)和鏈路暢通,最常用的如OSPF(OpenShortestPathFirst開放式最短路徑優(yōu)先),RIP(RoutingInformationProtocol路由信息協(xié)議),BGP/BGP4(BorderGatewayProtocol，邊界網(wǎng)關(guān)協(xié)議)等。

　　節(jié)點(diǎn)間通信除了上述開銷之外,還需要加入容錯(cuò),災(zāi)備,節(jié)點(diǎn)間同步等處理機(jī)制,用來保證業(yè)務(wù)狀態(tài)的正確性和唯一性。由于內(nèi)存數(shù)據(jù)的易失性的影響,相應(yīng)數(shù)據(jù)的災(zāi)備,恢復(fù)等異常處理機(jī)制是至關(guān)重要的。重載是最容易想到也是實(shí)現(xiàn)起來最方便的,如MapReduce,其容錯(cuò)機(jī)制主要通過定期檢查鏈路中的各個(gè)父子節(jié)點(diǎn),對(duì)于故障的子節(jié)點(diǎn),及時(shí)從其他子節(jié)點(diǎn)中獲取對(duì)應(yīng)的任務(wù)列表并重復(fù)執(zhí)行,恢復(fù)到故障前的狀態(tài),而對(duì)于出現(xiàn)故障的父節(jié)點(diǎn),則通過從集群中的其他父節(jié)點(diǎn)上復(fù)制數(shù)據(jù)備份并傳輸?shù)奖镜睾笾匦录虞d的方法來解決。需要在原有的業(yè)務(wù)處理邏輯上加入對(duì)應(yīng)網(wǎng)絡(luò)機(jī)結(jié)構(gòu)的改造,需要整合多核心情況下的業(yè)務(wù)流程,確保多個(gè)核心可以充分發(fā)揮各自的能力,提高處理性能和CPU的利用率,解決負(fù)荷偏載,死鎖等問題。

　　5結(jié)束語

　　本文首先初步分析了內(nèi)存計(jì)算特點(diǎn)和發(fā)展情況，結(jié)合目前證券行業(yè)的現(xiàn)狀,進(jìn)一步闡述了證券行業(yè)面臨的挑戰(zhàn)和問題;并從內(nèi)存計(jì)算的兩種不同架構(gòu),機(jī)制以及模型等方面對(duì)內(nèi)存計(jì)算技術(shù)的應(yīng)用進(jìn)行了簡(jiǎn)要的說明，并對(duì)現(xiàn)有的一些較好的科研成果進(jìn)行了總結(jié)。當(dāng)然，內(nèi)存計(jì)算的研究問題還有很多需要進(jìn)一步深入研究才能解決。比如，目前的多節(jié)點(diǎn)內(nèi)存計(jì)算系統(tǒng)中的重演機(jī)制帶來的存儲(chǔ)開銷問題,分布式共享內(nèi)存[10]、內(nèi)存數(shù)據(jù)庫(kù)等,節(jié)點(diǎn)的容錯(cuò)方式均是通過接口來移動(dòng)和復(fù)制其他節(jié)點(diǎn)的數(shù)據(jù),或以記錄日志重演的方式更新集群間各個(gè)節(jié)點(diǎn)。而這兩種方法對(duì)于數(shù)據(jù)密集型的應(yīng)用來說,開銷和負(fù)荷太大,集群節(jié)點(diǎn)之間大量數(shù)據(jù)的復(fù)制帶來的硬件存儲(chǔ)的開銷以及遠(yuǎn)小于內(nèi)存帶寬的網(wǎng)絡(luò)傳輸帶寬帶來的漫長(zhǎng)耗時(shí),這都是后續(xù)需要分析和研究的問題。

　　參考文獻(xiàn)：

　　[1]Inmemorydatabase：HANA,exadataX3andflashmemo⁃ry.2012[EB/OL].http：//flashdba.com/2012/10/10/in-memorydatabases-part2/.

　　[2]ShunJ,BlellochGE.Ligra：Alightweightgraphprocessingframeworkforsharedmemory[C].In：Proc.ofthe18thACMSIGPLANSymp.onPrinciplesandPracticeofParallelPro⁃gramming.ACMPress,2013:135-146.

　　[3]PrabhakaranV,WuM,WengX,etal.Managinglargegraphsonmulti-coreswithgraphawareness[C].In：Proc.ofthePre⁃sentedasPartofthe2012USENIXAnnualTechnicalConf.(USENIXATC2012).2012:41-52.

　　[4]WangG,XieW,DemersA,GehrkeJ.Asynchronouslargescalegraphprocessingmadeeasy[C].In：Proc.ofthe6thBi⁃ennialConf.onInnovativeDataSystemsResearch(CIDR2013).Asilomar,2013.

　　[5]LowY,GonzalezJ,KyrolaA,etal.Graphlab：Anewparallelframeworkformachinelearning[D].arXivpreprintarXiv：1006.4990,2010.

　　[6]Garcia-MolinaH,SalemK.Mainmemorydatabasesystems：Anoverview[J].IEEETrans.onKnowledgeandDataEngineer⁃ing,1992,4(6):509-516.

　　[7]DeWittD,KatzRH,OlkenF,ShapiroLD,StonebrakerMR,WoodDA.Implementationtechniquesformainmemorydata⁃basesystems[J].In：Proc.oftheSIGMOD.1984,14(2):1-8.

　　[8]KemperA,NeumannT.HyPer：AhybridOLTP&OLAPmainmemorydatabasesystemBasedonvirtualmemorysnap⁃shots[J].In：Proc.ofIEEEthe27thInt’lConf.onDataEngineering.Hannover,2011:195-206.

　　[9]DiaconuC,FreedmanC,IsmertE,LarsonPA,MittalP,Stone⁃cipherR,VermaN,ZwillingM.Hekaton：SQLserver’smemo⁃ryoptimizedOLTPengine[J].In：Proc.ofthe2013ACMSIG⁃MODInt’lConf.onManagementofData.ACMPress,2013:1243-1254.

　　[10]NitzbergB,LoV.Distributedsharedmemory：Asurveyofis⁃suesandalgorithms[J].Computer,1991,24(8):52−60.

---

轉(zhuǎn)載請(qǐng)注明來自：http://www.jinnzone.com/zhengquanlw/67760.html