Algoritmiese Trading System Architecture

Algoritmiese Trading System Architecture Voorheen op hierdie blog ek oor die konseptuele argitektuur van 'n intelligente algoritmiese handel stelsel asook die funksionele en nie-funksionele vereistes van 'n produksie algoritmiese handel stelsel geskryf. Sedertdien het ek ontwerp het 'n stelsel-argitektuur wat ek glo kan voldoen aan diegene argitektoniese vereistes. In hierdie pos sal ek die argitektuur na aanleiding van die riglyne van die ISO / IEC / IEEE 42010 stelsels en sagteware-ingenieurswese argitektuur beskrywing standaard beskryf. Volgens hierdie standaard n argitektuur beskrywing moet: Bevat verskeie gestandaardiseerde argitektoniese sienings (bv in UML) en in stand te hou naspeurbaarheid tussen ontwerp besluite en argitektoniese vereistes sagteware argitektuur definisie Daar is steeds geen konsensus oor wat 'n stelsels argitektuur is. In die konteks van hierdie artikel, is dit gedefinieer as die infrastruktuur waarbinne aansoek komponente wat funksionele vereistes voldoen kan word vermeld, ontplooi, en uitgevoer word. Funksionele vereistes is die verwagte funksies van die stelsel en sy komponente. Nie-funksionele vereistes is maatreëls waardeur die kwaliteit van die stelsel gemeet kan word. 'N Stelsel wat ten volle voldoen aan die funksionele vereistes kan steeds nie na wense as funksionele vereistes ontevrede gelaat. Om te illustreer hierdie konsep beskou die volgende scenario: 'n algoritmiese handel stelsel wat jy nou net gekoop het / gebou maak uitstekende handel besluite te neem, maar is heeltemal in onbruik met die organisasies risikobestuur en rekeningkundige stelsels. Sou hierdie stelsel voldoen aan jou verwagtinge Konseptuele Architecture 'n konseptuele siening beskryf hoë vlak konsepte en meganismes wat bestaan ​​in die stelsel op die hoogste vlak van korrelig. Op hierdie vlak, die algoritmiese handel stelsel volg 'n gebeurtenis gedrewe argitektuur (EDA) oopgebreek oor vier lae, en twee argitektoniese aspekte. Vir elke laag en aspek verwys argitekture en patrone gebruik. Argitektoniese patrone bewys, generiese strukture vir die bereiking van spesifieke vereistes. Argitektoniese aspekte is kruissnydende kommer wat verskeie komponente span. Gebeurtenis gedrewe argitektuur - 'n argitektuur wat produseer, bespeur, verbruik, en reageer op gebeure. Gebeure sluit in reële tyd mark bewegings, komplekse gebeure of tendense, en handel gebeure bv indiening van 'n bevel. Hierdie diagram illustreer die konseptuele argitektuur van die algoritmiese handel stelsel Verwysing architecture 'n analogie te gebruik, 'n verwysing argitektuur is soortgelyk aan die bloudrukke vir 'n lasdraende muur. Dit bloudruk kan weer gebruik word vir verskeie bou-ontwerpe ongeag wat gebou is gebou as dit voldoen aan 'n stel algemeen voorkom vereistes. Net so, 'n verwysing argitektuur definieer 'n sjabloon bevat generiese strukture en meganismes wat gebruik kan word om 'n konkrete sagteware argitektuur wat spesifieke vereistes voldoen te bou. Die argitektuur vir die algoritmiese handel stelsel gebruik 'n ruimte gebaseerde argitektuur (SBA) en 'n model oog kontroleerder (MVC) as verwysings. Goeie praktyke soos die operasionele data stoor (ODS), die uittreksel te transformeer en vrag (ETL) patroon, en 'n datapakhuis (DW) word ook gebruik. Model oog kontroleerder - 'n patroon wat die voorstelling van inligting van die gebruikers interaksie met hulle skei. Ruimte gebaseerde argitektuur - spesifiseer 'n infrastruktuur waar losweg gekoppel verwerking eenhede met mekaar deur middel van 'n gedeelde assosiatiewe geheue genoem ruimte (sien onder). Strukturele View Die strukturele siening van 'n argitektuur toon die komponente en sub-komponente van die algoritmiese handel stelsel. Dit wys ook hoe hierdie komponente is ontplooi op fisiese infrastruktuur. Die UML diagramme in hierdie siening sluit komponent diagramme en ontplooiing diagramme. Hier is 'n gallery van die ontplooiing diagram van die algehele algoritmiese handel stelsel en die verwerking eenhede in die SBA verwysing argitektuur, asook verwante komponent diagramme vir elkeen die lae. Argitektoniese Tactics Volgens die sagteware-ingenieurswese Instituut 'n argitektoniese taktiek is 'n manier te bevredig 'n vereiste gehalte deur die manipulering een of ander aspek van 'n gehalte kenmerk model deur middel van argitektoniese ontwerp besluite te neem. 'N Eenvoudige voorbeeld gebruik word in die algoritmiese handel stelsel argitektuur manipuleer 'n operasionele data stoor (ODS) met 'n deurlopende bevraagteken komponent. Hierdie komponent sal voortdurend analiseer die ODS te identifiseer en te onttrek komplekse gebeure. Die volgende taktiek gebruik word in die argitektuur: die disruptor patroon in die geval en orde toue gedeelde geheue vir die geleentheid en orde toue Deurlopende bevraagteken taal (CQL) op die ODS Data filter met die filter ontwerp patroon op inkomende data Opeenhoping vermyding algoritmes op alle inkomende en uitgaande verbindings Active tou bestuur (AQM) en eksplisiete opeenhoping kennisgewing Commodity rekenaar hulpbronne met kapasiteit vir opgradering (skaalbare) Active ontslag vir al enkele punte van mislukking Indexatie en optimale volharding strukture in die ODS Skeduleer gereelde data rugsteun en skoon-up skrifte vir ODS transaksie geskiedenis op alle databasisse checksums vir alle bestellings op te spoor foute Annoteer gebeure met tyd tempel te verjaar gebeure slaan Bestel validering reëls bv maksimum handel hoeveelhede outomatiese handelaar komponente gebruik 'n in-geheue databasis vir ontleding Twee stadium verifikasie vir gebruikerkoppelvlakke verbinding met die TGT Enkripsie op gebruikerkoppelvlakke en verbindings na die TGT Observer ontwerp patroon vir die MVC om menings te bestuur Bogenoemde lys is net 'n paar ontwerp besluite wat ek geïdentifiseer tydens die ontwerp van die argitektuur. Dit is nie 'n volledige lys van taktiek. As die stelsel word ontwikkel bykomende taktiek moet in diens geneem word oor verskeie vlakke van korrelig om funksionele en nie-funksionele vereistes te voldoen. Hieronder is drie diagramme beskryf die disruptor ontwerp patroon, filter ontwerp patroon, en die voortdurende bevraagtekening komponent. Gedragswetenskappe Sien die lig van 'n argitektuur wys hoe die komponente en lae moet in wisselwerking met mekaar. Dit is sinvol as die skep van scenario's vir die toets van argitektuur ontwerp en vir die begrip van die stelsel van end-tot-end. Hierdie siening bestaan ​​uit volgorde diagramme en aktiwiteite diagramme. Aktiwiteit diagramme toon die algoritmiese handel stelsels interne proses en hoe handelaars is veronderstel om met die algoritmiese handel stelsel word hieronder getoon. Tegnologie en raamwerke Die finale stap in die ontwerp van 'n sagteware-argitektuur is om potensiële tegnologie en raamwerke wat gebruik kan word om die argitektuur te besef identifiseer. As 'n algemene beginsel is dit beter om te hefboom af van bestaande tegnologie, met dien verstande dat hulle voldoende bevredig beide funksionele en nie-funksionele vereistes. 'N Raamwerk is 'n besef verwysing argitektuur bv JBoss is 'n raamwerk wat die JEE verwysing argitektuur besef. Die volgende tegnologie en raamwerke is interessant en moet in ag geneem word wanneer die uitvoering van 'n algoritmiese handel stelsel: CUDA - NVidia het 'n aantal produkte wat 'n hoë werkverrigting rekenaar Finansies modellering ondersteun. 'N Mens kan bereik tot 50x prestasie verbeterings in die bestuur van Monte Carlo simulasies op die GPU in plaas van die CPU. Apache River - River is 'n instrument-kit wat gebruik word om verspreide stelsels te ontwikkel. Dit is gebruik as 'n raamwerk vir die bou van toepassings gebaseer op die SBA patroon Apache Hadoop - in die geval dat deurdringende meld is 'n vereiste, dan is die gebruik van Hadoop bied 'n interessante oplossing vir die groot-data probleem. Hadoop ontplooi kan word in 'n cluster omgewing ondersteun CUDA tegnologie. AlgoTrader - 'n open source algoritmiese handel platform. AlgoTrader kan potensieel ontplooi in die plek van die outomatiese handelaar komponente. FIX Engine - 'n selfstandige toepassing wat die Finansiële Information Exchange (FIX) protokolle insluitend FIX ondersteun, vinnig, en FIXatdl. Terwyl nie 'n tegnologie of 'n raamwerk, moet komponente word gebou met 'n aansoek Programming Interface (API) om interoperabiliteit van die stelsel en sy komponente te verbeter. Ten slotte Die voorgestelde argitektuur is ontwerp om baie generiese vereistes geïdentifiseer vir algoritmiese handel stelsels te bevredig. Oor die algemeen algoritmiese handel stelsels is bemoeilik deur drie faktore wat wissel met elke uitvoering: Afhanklike gebiede op eksterne onderneming en ruil stelsels Uitdaag-funksionele vereistes en veranderende argitektoniese beperkings Die voorgestelde sagteware argitektuur sou dus moet word aangepas op 'n geval-tot-geval grondslag ten einde om spesifieke organisatoriese en regulatoriese vereistes voldoen, asook aan die plaaslike beperkings te oorkom. Die algoritmiese handel stelsel argitektuur moet gesien word as net 'n punt van verwysing vir individue en organisasies wat hul eie algoritmiese handel stelsels te ontwerp. Vir 'n volledige kopie en bronne wat gebruik gaan aflaai 'n afskrif van my verslag. Dankie. TagsCyan Lente ATS System Architecture Cyan Lente ATS kan uitgevoer word met 'n verspreide architure. Veelvuldige bedieners kan aansluit by 'n groep aan die werklading Server deel kan wees 'n enkele bediener byvoorbeeld of veelvuldige kinders na 'n bediener cluster te vorm. Kliënt (CSTW) kan koppel aan verskeie bedieners in die dieselfde groep en monitor alle strategieë uit te voer in die dieselfde groep. Jy kan soveel bedieners en kliënte uit te voer as wat jy wil. Dit sal slegs beperk word deur jou hardeware. Cyan Lente ATS volg 'n gebeurtenis gedrewe stelsel wat bewys dat 'n suksesvolle model vir baie finansiële real time aansoeke kliënt-bediener kommunikasie word gedryf deur gebeure wees. Die meeste van die bediener kant komponent kommunikasie word gedryf deur gebeure. data Market, ouer orde bedrywighede, kind orde aksies ens is almal insette deur die gebeure. In die hart van die gebeure, Siaan Lente strategieraamwerk (CSF) maak die besluit en opdrag ander komponente om aksie te neem deur middel van gebeure. Regoor masjien gebeure word ondersteun deur JMS. Maar, het jy nie nodig om iets in JMS kodeer sedert CATS gebeurtenis stelsel het hulle reeds toegedraai mooi. Cyan Lente ATS is gebou op die top van die volgende sagteware pakkette. Hulle is almal gratis en soliede open source sagteware. Cyan Lente ATS - Open Source Algorithmic Trading SoftwareAlgorithmic Trading Stelselvereistes Tans ek neem 'n klas oor sagteware argitekture. Vir hierdie klas Elke student kies 'n stelsel, definieer sy argitektoniese vereistes en ontwerp 'n oplossing in staat te bevredig daardie vereistes. Ek verkies 'n algoritmiese handel stelsel as gevolg van die tegnologiese uitdaging en omdat ek lief finansiële markte. Algoritmiese handel stelsels (TGT's) gebruik berekeningsalgoritmes te handel besluite te neem, stuur bestellings en bestuur bestellings na voorlegging. In onlangse jare TGT het gewild geword en tans verantwoordelik is vir die meerderheid van die ambagte sit deur middel van internasionale handel. Daar word onderskei tussen geprogrammeer handel en algoritmiese handel. Geprogrammeer handel behels die opbreek van groot markte bestellings in pakkies kleiner aandele. In hierdie artikel, is geprogrammeer handel beskou as 'n sekuriteit vereiste van 'n TGT. Algoritmiese handel stelsels bekendstelling Praat oor die algemeen, is daar vyf tipes markdeelnemers: kleinbeleggers, eiendom handelaars, mark makers, koop-kant instellings, en verkoop-kant instellings. TGT is die meeste gebruik word deur eiendom koop-kant instellings, maar hierdie dinamiese verander. Algoritmiese handel as 'n diens (ATAAS) maak algoritmiese handel toeganklik vir die kleinhandel belegger (sien bylaag). In hierdie artikel word die argitektoniese vereistes vir 'n TGT wat gebruik word deur 'n eie buy-side instelling. Op die top mees vlak, ats het drie funksies: maak handel besluite te neem, te skep handel bestellings, en bestuur die bestellings na voorlegging. Onder hierdie is daar 'n magdom meer gedetailleerde funksionele vereistes, waarvan sommige kan tevrede wees met die argitektuur. Sagteware-argitektuur bekendstelling Baie debat rondom nog die definisie van wat 'n sagteware-argitektuur is. In die konteks van hierdie artikel, is sagteware argitektuur gedefinieer as die infrastruktuur waarbinne aansoek komponente verskaffing gebruiker funksies kan gespesifiseer word, ontplooi, en uitgevoer word. 'N sagteware stelsel moet voldoen aan die funksionele en nie-funksionele vereistes. Funksionele vereistes spesifiseer die funksies van die stelsels komponente. Nie funksionele vereistes maatreëls waardeur die stelsel prestasie word gemeet spesifiseer. 'N sagteware stelsel wat aan die funksionele vereistes voldoen, nie noodwendig voldoen aan die gebruiker verwagtinge bv ats dat ambagte kan dien, maar nie in 'n tydige wyse, sou finansiële verliese veroorsaak. Die sagteware-argitektuur bied basies 'n infrastruktuur wat die nie funksionele vereistes voldoen, en waarbinne komponente wat funksionele vereistes voldoen kan word ontplooi, en uitgevoer word. Algoritmiese handel stelsel vereistes kan dus breedweg verdeel word in funksionele en nie-funksionele vereistes. Funksionele vereistes Onder die make handel besluite boonste vlak vereiste is daar drie vereistes hoë vlak: Kry markdata - aflaai, filter, en gestruktureerde en ongestruktureerde data te stoor. Gestruktureerde data sluit real time mark data van Reuters of Bloomberg oorgedra met behulp van 'n protokol bv Op te los. Ongestruktureerde data sluit nuus en sosiale media data. Definieer handel strategie - spesifiseer nuwe handelsmerk reëls en strategieë. Trading reël bestaan ​​uit 'n aanduiding, 'n ongelykheid, en 'n numeriese waarde bv PE verhouding LT 10. Trading reëls is gestruktureer in 'n besluit boom tot 'n handel strategie (hieronder geïllustreer) definieer. Analiseer sekuriteite teen handel strategie - vir elke sekuriteit, data verkry en te filter dit deur die handel strategie te bepaal watter sekuriteit te koop. Verder: vir elke oop posisie, bepaal watter sekuriteit te verkoop. Let wel: hierdie vereiste kan wissel. Onder die skep handel bestellings boonste vlak vereiste is daar twee vereistes hoë vlak: Kry handel inligting - vir elke besluit, kry die sekuriteit simbool, prys, hoeveelheid, ens Skep handel orde - vir elke besluit, spesifiseer 'n tipe orde en voeg handel inligting . Daar is ses orde tipes: lank, kort, mark, beperking, ophou, en voorwaardelike. Onder die bestellings te bestuur boonste vlak vereiste is daar drie vereistes hoë vlak: Bestuur hangende bestellings - vir elke bestelling, bekragtig en bevestig dat orde Route / stuur bestellings - roete elke einde 'n ruil, donker poel, of makelaars Bestuur voorgelê bestellings - track status van elke voorgelê orde, indien bestelling ooreenstem dan 'n oop posisie te skep. As bevel nie ooreenstem dan stop daardie volgorde. Hierdie diagram wys hoe 'n handel strategie kan gedefinieer word as 'n besluit boom van handel reëls Nie-funksionele vereistes Daar is baie nie funksionele vereistes wat verhandel off tussen mekaar bv verhoogde prestasie kom dikwels teen 'n verhoogde totale koste van eienaarskap. Nie-funksionele algoritmiese vereistes handel stelsel sluit, Scalability - is die vermoë van 'n stelsel om te gaan en uit te voer onder 'n verhoogde of die uitbreiding van werklading. Ats moet skaalbare met betrekking tot die aantal data voed in prosesse wees, aantal beurse hy handel dryf op, en die sekuriteite dit kan handel. Prestasie - is die hoeveelheid werk uitgevoer deur 'n stelsel in vergelyking met die tyd en hulpbronne wat nodig is om daardie werk te doen. Ats moet vinnige reaksie tye (terug na die mark) en 'n hoë verwerking en netwerk deurset. Modifiability - is die gemak waarmee die stelsel kan verander. is die akkuraatheid en betroubaarheid van 'n stelsel om korrekte uitsette te produseer vir die insette wat hulle ontvang - ats moet maklik aanpas handel strategieë en dataverwerking betroubaarheid beskik. Omdat foute en foute in 'n TGT kan lei tot groot verliese en boetes, betroubaarheid is van kardinale belang. Sien die Knight kapitaal debakel vir bewyse hiervan. Auditability - is die gemak waarmee die stelsel kan geoudit. Onlangse hoëprofielsake TGT going oontdaam TGT gesit in die kollig vir ouditfirmas. Hulle moet dus ouditeerbare beide vanuit 'n finansiële, nakoming, en IT oogpunt. Security - is die veiligheid van 'n organisasie teen kriminele aktiwiteite soos terrorisme, diefstal, of spioenasie. Omdat handel strategieë is eiendom en verteenwoordig waardevolle intellektuele eiendom moet hulle verseker. Verder om die TGT's te beskerm teen gejag, moet bestellings word verborge behulp geprogrammeer handel strategieë. Fouttoleransie - is die vermoë van 'n stelsel om voort te gaan behoorlik na 'n fout of versuim bedryf. Dit is soortgelyk aan betroubaarheid, behalwe dat die TGT moet voortgaan om betroubaar te wees, selfs nadat 'n fout om finansiële verliese te vermy. Interoperabiliteit - is die gemak waarmee die stelsel in staat is om te werk met 'n wye verskeidenheid van verwante stelsels. Dit is belangrik vir 'n TGT wat nodig mag wees om saam met orde bestuurstelsels, portefeuljebestuur stelsels, risikobestuurstelsels, rekeningkundige stelsels, en selfs bankstelsels. Oorsig van argitektoniese ruimte Die argitektoniese ruimte is die stel van dienste deur die argitektuur wat deur komponente verteer hul funksionele en nie funksionele vereistes te voldoen. 'N Meer volledige uiteensetting van hierdie argitektoniese ruimte is beskikbaar in die gedetailleerde vereistes dokument. Op 'n hoë-vlak die volgende dienste sal moet word deur die argitektuur: 'n modifiable data pre-verwerking omgewing - wat verskeie verwerking eenhede ondersteun - wat verskeie data strome, filters vir irrelevant data, en tydelike data skeiding 'n verspreide verwerking omgewing ondersteun (clusters), real-time monitering van prestasie, 'n boodskap georiënteerde kommunikasie raamwerk, skedulering van tydelike datastelle, load balancing, en data replikasie Individuele verwerking eenhede - wat in-geheue toue ondersteun, en komplekse gebeurtenis verwerking (op tydelike data) 'n stoor area netwerk (SAN) - wat tydelike data samevoeging, deurlopende bevraagteken, en aan te meld (vir oudit roetes) 'n data herstel (DR) omgewing ondersteun - replica van die San en orde bestuurstelsel 'n integrasie omgewing - wat 'n standaard API vir komponente en verbind ontbloot interne en eksterne komponente met mekaar 'n bevel bestuurstelsel - wat konkurrente insette strome, passiewe ontslag en vrag-balansering, suur kriteria op bestellings, 'n ouditspoor ondersteun, en word herhaal 'n stelsel gebruik omgewing - wat verskeie gebruikers profiele ondersteun en ontbloot 'n ten volle beheer front-end vir die algoritmiese handel stelsel Toegang en integrasie vereistes Toegang vereistes te beskryf maniere waarop gebruikers kan toegang tot die stelsels komponente. 'N algoritmiese handel stelsel moet drie interfaces bloot: 'n koppelvlak tot nuwe handelsmerk reëls, handel strategieë te definieer, en databronne n back-end-koppelvlak vir systeembeheerders om trosse te voeg en instel van die argitektuur en 'n lees-alleen oudit koppelvlak vir die beheer van dit beheer en gebruiker toegang regte. Voorvereistes vir die integrasie tussen komponente en eksterne stelsels genoem integrasie vereistes. Die algoritmiese handel stelsel moet ondersteun lêer gebaseer integrasie, boodskap gebaseer integrasie, en databasis-integrasie. As sodanig, moet die volgende vereistes moet voldoen die argitektuur: Databasis integrasie - ondersteuning ODBC, JDBC, ADO, en XQC lêer gebaseer integrasie - ondersteun CSV, XML, en into lêers Boodskap gebaseer integrasie - ondersteuning te los. Vinnig. en FIXatdl Argitektoniese beperkings Die blou kolle wys die fisiese plekke waar netwerk latency geminimaliseer en die rooi kolle wys die fisiese ligging van groot finansiële ruil. Met die oog op die uitvoering van die algoritmiese handel stelsel te maksimeer, moet 'n mens die stelsel huis in plekke wat netwerk latency te verminder. Bron: MIT oop pers: dspace. mit. edu/handle/1721.1/6285 Argitektoniese beperkings is faktore wat die prestasie van die argitektuur aan bande gebou. Die twee beperkinge Ek sal hier noem is fisiese netwerk beperkinge, en regulatoriese beperkings. Fisiese netwerk beperkinge is op 'n stelsel geplaas word as gevolg van swak telekommunikasie netwerke. Om hierdie beperking die stelsel gebou moet word waar netwerk latency geminimaliseer versag. Nog 'n manier om die netwerk beperkinge te versag is om saam te spoor die algoritmiese stelsel handel met die mark ruil. Dit het gesê die besluit om saam te spoor stel addisionele verwerking en ruimte beperkings. Regulatoriese beperkings bekendgestel deur middel van wette en regulasies, wat meestal land en spesifieke ruil. Dit is 'n toenemend belangrike faktor in die ontwerp en implementering van 'n algoritmiese handel stelsel omdat algoritmiese handel is besig om meer gereguleerde ná die 2010 flits ongeluk. Praat oor die algemeen, moet 'n TGT minstens aan die die SEC s reëls met betrekking tot stelsel nakoming en integriteit (SCI), die EMEA riglyne vir algoritmiese handel stelsels, die ISO 9000 algoritmiese handel standaarde (AT9000), en die internasionale finansiële verslagdoeningstandaarde (IFRS) . Gevolgtrekking Algorithmic handel stelsel architecture is bemoeilik deur die streng nie funksionele vereistes verwag van die stelsel en die wye verskeidenheid van regulatoriese en voldoeningsvereistes regerende outomatiese handel. As gevolg van hierdie kompleksiteite, moet deeglike oorweging gegee word aan die ontwerp en implementering van die stelsel-argitektuur. In die ontwerp van 'n oop bron algoritmiese handel argitektuur hoop ek om daarop te wys die argitektoniese vereistes wat dikwels by die aanvang van die ontwerp van sulke stelsels is oor die hoof gesien. Die wat in hierdie dokument vereistes is onwaarskynlik volledig te wees en sal noodwendig ontwikkel met verloop van tyd. Die tweede paaiement van hierdie artikel sluit my ontwerp vir 'n sagteware-argitektuur aan die bogenoemde vereistes voldoen. Vir meer inligting oor algoritmiese handel, voel asseblief vry om my te kontak. Om 'n afskrif van my verslag af te laai kliek asseblief hier. Vir 'n volledige lys van bronne sien asseblief die verslag bylaag ATAAS diensverskaffers sluit in, maar is nie beperk tot: Quantopian - gebruikers definieer kwantitatiewe handel strategieë in Python en kan back-toets hulle. Gebruikers kan ook die strategieë uit te voer op lewendige markte. Quantopian het onlangs 'n 6,7 miljoen dollar belegging om hul dienste uit te brei. EquaMetrics - met behulp van RIZM gebruikers visueel te bou nuwe algoritmiese handel strategieë, back-toets dié strategieë, en uit te voer die strategieë op lewendige markte. EquaMetrics onlangs aangekondig nuwe befondsing vir RIZM ter waarde van 4,5 miljoen dollar. Makelaars - sommige makelaars toelaat handelaars om handel bots wat hul handel strategieë outomaties uit te voer te skep. TagsBest Programmering taal vir Algorithmic Trading Systems Deur Michael Saal-Moore op 26 Julie 2013 Een van die mees algemene vrae wat ek ontvang in die QS Koevert is Wat is die beste programmeertaal vir algoritmiese handel. Die kort antwoord is dat daar geen beste taal. Strategie parameters, prestasie, modulariteit, ontwikkeling, veerkragtigheid en koste moet al oorweeg. In hierdie artikel sal uiteensetting van die nodige komponente van 'n algoritmiese handel stelsel argitektuur en hoe besluite oor die implementering invloed op die keuse van taal. Eerstens, sal die belangrikste komponente van 'n algoritmiese handel stelsel in ag geneem word, soos die navorsing gereedskap, portefeulje-optimaliseerder, risikobestuurder en uitvoering enjin. Daarna sal verskillende handel strategieë ondersoek word en hoe hulle invloed op die ontwerp van die stelsel. In die besonder die frekwensie van die saak en die waarskynlike handel volume sal beide bespreek word. Sodra die handel strategie gekies is, is dit nodig om argitek die hele stelsel. Dit sluit in die keuse van hardeware, die bedryfstelsel (s) en stelsel veerkragtigheid teen seldsame, potensieel katastrofiese gebeure. Terwyl die argitektuur oorweeg word, moet daar behoorlik ag gegee word aan prestasie - beide om die navorsing gereedskap sowel as die lewendige uitvoering omgewing. Wat is die handel stelsel probeer om te doen voordat jy besluit op die beste taal waarmee 'n outomatiese handel stelsel is dit nodig om die vereistes te definieer skryf. Is die stelsel gaan suiwer uitvoering gebaseer Sal die stelsel vereis dat 'n risikobestuur of portefeulje konstruksie kursus sal die stelsel vereis dat 'n hoë-prestasie backtester Vir die meeste strategieë die handel stelsel kan verdeel word in twee kategorieë wees: Navorsing en sein generasie. Navorsing handel oor evaluering van 'n strategie prestasie oor historiese data. Die proses van evaluering van 'n handel strategie oor data voor mark staan ​​bekend as back testing. Die grootte van data en algoritmiese kompleksiteit sal 'n groot impak op die rekenaarmatige intensiteit van die backtester het. CPU spoed en samelopendheid is dikwels die beperkende faktore in die optimalisering van uitvoering navorsing spoed. Sein generasie is gemoeid met die opwekking van 'n stel van handel seine van 'n algoritme en sulke bestellings stuur na die mark, gewoonlik deur 'n makelaar. Vir sekere strategieë 'n hoë vlak van prestasie vereis. I / O kwessies soos netwerk bandwydte en latency is dikwels die beperkende faktor in die optimalisering van die uitvoering stelsels. So die keuse van tale vir elke komponent van jou hele stelsel kan heel anders wees. Tipe, frekwensie en volume van Strategie Die tipe algoritmiese strategie in diens sal 'n aansienlike impak op die ontwerp van die stelsel het. Dit sal nodig wees om te oorweeg die markte verhandel word, die konneksie na eksterne data verskaffers, die frekwensie en volume van die strategie, die kompromis tussen gemak van ontwikkeling en verbetering van die prestasie, sowel as enige persoonlike hardeware, insluitend mede geleë persoonlike bedieners, GPU's of FPGAs wat nodig mag wees. Die tegnologie keuses vir 'n lae-frekwensie Amerikaanse aandele strategie sal grootliks verskil van dié van 'n hoë-frekwensie statistiese arbitrage strategie handel oor die termynmark wees. Voor die keuse van taal baie data verskaffers moet geëvalueer alledaagse n strategie aan die hand. Dit sal nodig wees om verbinding met die verkoper, struktuur van enige APIs, tydigheid van die data, bergingsvereistes en veerkragtigheid te oorweeg in die lig van 'n ondernemer gaan af. Dit is ook wys om 'n vinnige toegang tot verskeie verskaffers in besit te neem Verskeie instrumente almal hul eie stoor eienaardighede, voorbeelde van wat insluit verskeie ENKELE simbole vir aandele en verval datums vir Toekomsnavorsing (nie aan enige spesifieke OTC data te noem). Dit moet ingereken in die platform ontwerp. Frekwensie van strategie is waarskynlik een van die grootste oorsake van hoe die tegnologie stapel sal gedefinieer word nie. Strategieë in diens data meer dikwels as fyn of tweedens bars vereis betekenisvolle ag met betrekking tot prestasie. 'N Strategie oorskry tweedens bars (bv merk data) lei tot 'n prestasiegedrewe ontwerp as die primêre vereiste. Vir 'n hoë frekwensie strategieë 'n aansienlike bedrag van die mark data sal moet word gestoor en geëvalueer. Sagteware soos HDF5 of KDB word algemeen gebruik vir hierdie rolle. Met die oog op die uitgebreide volumes van data wat nodig is vir HFT aansoeke te verwerk, moet 'n groot skaal new backtester en uitvoering stelsel gebruik word. C / C (moontlik met 'n paar assembler) is geneig om die sterkste taal kandidaat. Ultrahoëfrekwensie strategieë sal ongetwyfeld vereis persoonlike hardeware soos FPGAs, ruil mede-plek en kernal / netwerk koppelvlak tuning. Navorsing Systems Research stelsels tipies behels 'n mengsel van interaktiewe ontwikkeling en outomatiese script. Die voormalige vind dikwels plaas in 'n IDE soos Visual Studio, Matlab of R Studio. Laasgenoemde behels uitgebreide numeriese berekeninge oor talle parameters en data punte. Dit lei tot 'n taalkeuse verskaffing van 'n eenvoudige omgewing te toets kode, maar bied ook voldoende prestasie om strategieë oor verskeie parameter dimensies evalueer. Tipiese Ides in hierdie ruimte sluit Microsoft Visual C / C, wat uitgebreide ontfouting nuts,-kode voltooiing vermoëns bevat (via IntelliSense) en eenvoudige oorsigte van die hele projek stapel (via die databasis ORM, LINQ) Matlab. wat ontwerp is vir 'n uitgebreide numeriese lineêre algebra en gevectoriseerd bedrywighede, maar in 'n interaktiewe konsole wyse R Studio. wat vou die R statistiese taal konsole in 'n volwaardige IO Eclipse IDE vir Linux Java en C en semi-eiendom Ides soos Enthought Canopy vir Python, wat data-analise biblioteke soos Numpy sluit. Scipy. scikit-leer en pandas in 'n enkele interaktiewe (konsole) omgewing. Vir numeriese back testing, al die bogenoemde tale is geskik, maar dit is nie nodig om 'n GUI / IDE gebruik as die kode in die agtergrond sal uitgevoer word. Die eerste oorweging in hierdie stadium is dat van die uitvoering spoed. A saamgestel taal (soos C) is dikwels nuttig as die back testing parameter dimensies is groot. Onthou dat dit nodig versigtig vir sulke stelsels te wees is as wat die saak gevolge het verduidelik tale soos Python dikwels gebruik van 'n hoë-prestasie biblioteke soos Numpy / pandas vir die back testing stap maak, ten einde 'n redelike mate van mededingendheid te behou met saamgestel ekwivalente. Uiteindelik is die wat gekies is vir die back testing taal sal bepaal word deur spesifieke algoritmiese behoeftes sowel as die verskeidenheid van biblioteke beskikbaar in die taal (meer op wat hieronder). Tog kan die taal wat gebruik word vir die backtester en navorsing omgewings heeltemal onafhanklik van dié wat in die portefeulje konstruksie, risikobestuur en uitvoering komponente, soos gesien sal word. Portefeulje Konstruksie en Risikobestuur Die portefeulje konstruksie en risikobestuur komponente word dikwels oor die hoof gesien deur kleinhandel algoritmiese handelaars. Dit is byna altyd 'n fout. Hierdie gereedskap verskaf die meganisme waardeur kapitaal sal bewaar word. Hulle het nie net probeer om die aantal riskant verbintenis te verlig, maar ook hulself te verminder kansellasies van die ambagte, die vermindering van transaksiekoste. Gesofistikeerde weergawes van hierdie komponente kan 'n beduidende invloed op die gehalte en consistentcy van winsgewendheid het. Dit is maklik om 'n stabiele strategieë as die portefeulje konstruksie meganisme en risikobestuurder skep kan maklik aangepas word om verskeie stelsels te hanteer. So moet hulle in aanmerking kom essensiële komponente aan die begin van die ontwerp van 'n algoritmiese handel stelsel. Die werk van die portefeulje konstruksie stelsel is om 'n stel van gewenste ambagte te neem en te produseer die stel van die werklike ambagte wat kansellasies te verminder, blootstelling aan verskeie faktore (soos sektore, bateklasse, wisselvalligheid ens) in stand te hou en te optimaliseer die toekenning van kapitaal na verskeie strategieë in 'n portefeulje. Portefeulje konstruksie verminder dikwels 'n lineêre algebra probleem (soos 'n matriks faktorisering) en vandaar prestasie is hoogs afhanklik van die doeltreffendheid van die numeriese lineêre algebra implementering beskikbaar. Die volgende stap is om te bespreek hoe programmeertale algemeen geklassifiseer. Michael Saal-Moore Mike is die stigter van QuantStart en is betrokke by die kwantitatiewe finansiële sektor vir die afgelope vyf jaar, in die eerste plek as 'n quant ontwikkelaar en later as 'n quant handelaar konsultasie vir verskansingsfondse.