Algoritmisk Trading System Architecture. Tidigare på den här bloggen har jag skrivit om den konceptuella arkitekturen i ett intelligent algoritmiskt handelssystem, liksom de funktionella och icke-funktionella kraven i ett produktionsalgoritmiskt handelssystem. Sedan dess har jag utformat en systemarkitektur som jag tror kunde uppfylla dessa arkitektoniska krav I det här inlägget kommer jag att beskriva arkitekturen enligt riktlinjerna för ISO IEC IEEE 42010-system och programvaruarkitekturens beskrivningsstandard Enligt denna standard måste en arkitekturbeskrivning innehålla. Konfigurera flera standardiserade arkitektoniska synpunkter, t. ex. i UML och. Maintain spårbarhet mellan design beslut och arkitektoniska krav. Software arkitektur definition. Det finns fortfarande ingen överenskommelse om vad en systems arkitektur är. I denna artikel definieras den infrastruktur inom vilken applikationskomponenter som uppfyller funktionella krav kan specificeras, implementeras och exekveras Funktionskrav är systemets förväntade funktioner och dess komponenter. Icke-funktionella krav är åtgärder genom vilka systemets kvalitet kan mätas. Ett system som fullt ut uppfyller sina funktionskrav kan fortfarande misslyckas att uppfylla förväntningarna om icke-funktionella krav lämnas otillfredsställd För att illustrera detta koncept överväga följande scenario ett algoritmiskt handelssystem som du just köpt byggt gör bra handelsbeslut, men är helt oföränderligt med organisationerna riskhantering och redovisningssystem Skulle detta system uppfylla dina förväntningar. Konceptuell arkitektur. En konceptuell visa beskriver högnivåkoncept och mekanismer som finns i systemet på högsta nivå av granularitet På den här nivån följer det algoritmiska handelssystemet en händelsesdriven arkitektur EDA uppdelad i fyra lager och två arkitektoniska aspekter För varje lager och aspektreferensarkitekturer och mönster ar e används Arkitektoniska mönster är beprövade, generiska strukturer för att uppnå specifika krav Arkitektoniska aspekter är tvärgående problem som spänner över flera komponenter. Eventyrad arkitektur - en arkitektur som producerar, upptäcker, konsumerar och reagerar på händelser Händelser inkluderar realtidsmarknadsrörelser, komplexa händelser eller trender och handelshändelser, t. ex. att skicka en beställning. Detta diagram illustrerar den konceptuella arkitekturen i det algoritmiska handelssystemet. Referensarkitekturer. För att använda en analogi, liknar en referensarkitektur en ritning för en bärande vägg. Detta blåtryck kan återanvändas för flera byggnadsdesigner oberoende av vilken byggnad som byggs, eftersom den uppfyller en uppsättning vanliga krav. På liknande sätt definierar en referensarkitektur en mall som innehåller generiska strukturer och mekanismer som kan användas för att konstruera en konkret mjukvaruarkitektur som uppfyller specifika krav Arkitekturen för den algoritmiska tr addering-systemet använder en rymdbaserad arkitektur SBA och en modellvisningskontroll MVC som referenser Goda metoder såsom operativdatabutiken ODS, extraktransformationen och laddningen ETL-mönstret och ett datalager DW används också. Modelleringsregulator - ett mönster som separerar representationen av information från användarens interaktion med det. Spacebaserad arkitektur - specificerar en infrastruktur där löst kopplade behandlingsenheter interagerar med varandra genom ett gemensamt associativt minne som kallas utrymme som visas nedan. Space-based arkitektonisk konceptuell vy Modell Visa Controller original bild. Strukturvyn. Strukturvyn av en arkitektur visar komponenterna och delkomponenterna i det algoritmiska handelssystemet. Det visar också hur dessa komponenter distribueras på fysisk infrastruktur. UML-diagrammen som används i denna vy inkluderar komponentdiagram och installationsdiagram. Nedan visas galleriet av installationsdiagrammen för det övergripande algoritmiska handelssystemet och p processorer i SBA-referensarkitekturen samt relaterade komponentdiagram för var och en av skikten. Algoritmiskt handelssystem med hög nivåutbyggnadsdiagram SBA-bearbetningsenheter Distributionsschema Orderbehandlingsskiktskomponentdiagram Automatiserad komponentdiagram för databehandlingshantering Datakälla och förbehandlingsskikt komponentdiagram MVC-baserad användargränssnittskomponentdiagram. Architectural Tactics. According to software engineering institute är en arkitektonisk taktik ett sätt att uppfylla ett kvalitetskrav genom att manipulera en del aspekter av en kvalitetsattributmodell genom arkitektoniska designbeslut. Ett enkelt exempel som används i den algoritmiska handeln systemarkitektur manipulerar en operativ datalager ODS med en kontinuerlig frågekomponent Denna komponent analyserar kontinuerligt ODS för att identifiera och extrahera komplexa händelser Följande taktik används i arkitekturen. Disruptormönstret i händelse - och beställningskön. Delat minne för händelse - och beställningskön. Kontinuerligt frågande språk CQL på ODS. Data som filtrerar med filterdesignmönstret på inkommande data. Konstruktion undviker algoritmer på alla inkommande och utgående anslutningar. Aktivköhantering AQM och explicit information om överbelastning av modifieringsmoditet med kapacitet för uppgradering skalbar. Active redundans för alla enskilda punkter av misslyckande. Indexation och optimerade persistensstrukturer i ODS. Schedule regelbunden säkerhetskopiering av data och rengöringsskript för ODS. Transaction-historier på alla databaser. Checksums för alla beställningar för att upptäcka fel. Anteckna händelser med tidsstämplar till Hoppa över vanliga händelser. Ordervalideringsregler, t. ex. maximala handelsmängder. Automatiserade handlarekomponenter använder en in-memory-databas för analys. Tvåstegsautentisering för användargränssnitt som ansluter till ATs. Encryption på användargränssnitt och anslutningar till ATs. Observer-designmönstret för MVC för att hantera visningar. Ovanstående lista är bara några designbeslut som jag identifierade under arkitekturens design Det är inte en komplett lista över taktik När systemet utvecklas bör ytterligare taktik användas över flera nivåer av granularitet för att uppfylla funktionella och icke-funktionella krav Nedan finns tre diagram som beskriver disruptor designmönstret, filterdesignmönster, och den kontinuerliga frågekomponenten. Kontinuerlig Querying-komponentdiagram Disruptor-designmönster Klassdiagramkälla Filterdesignmönsterklassdiagram. Behavioural View. This syn på en arkitektur visar hur komponenterna och lagren ska interagera med varandra Detta är användbart vid skapande av scenarier för testning av arkitektur mönster och för att förstå systemet från slutet till slutet Denna uppfattning består av sekvensdiagram och aktivitetsdiagram Aktivitetsdiagram som visar det interna processen för algoritmiska handelssystemets interna process och hur handlarna ska interagera med det algoritmiska handelssystemet visas nedan. End-to-end-algoritmisk handel process. Teknik och ramverk. Det sista steget i utformningen av en programvaruarkitektur är att identifiera potentiella teknologier och ramar som kan användas för att realisera arkitekturen. Som en allmän princip är det bättre att utnyttja befintlig teknik, förutsatt att de tillräckligt uppfyller både funktionella och icke-funktionella krav En ram är en realiserad referensarkitektur, t. ex. JBoss är en ram som realiserar JEE-referensarkitekturen. Följande tekniker och ramar är intressanta och bör beaktas vid implementering av ett algoritmiskt handelssystem. CUDA - NVidia har ett antal produkter som stöder högt prestanda beräkningsmodellmodellering Det går att uppnå upp till 50x prestandaförbättringar när det gäller att köra Monte Carlo-simuleringar på GPU istället för CPU. Apache River - River är ett verktygssats som används för att utveckla distribuerade system. Det har använts som ramverk för att bygga applikationsbaserade på SBA-mönstret. Apache Hadoop - i e utlopp som en genomgripande loggning är ett krav, då användningen av Hadoop erbjuder en intressant lösning på det stora dataproblemet Hadoop kan distribueras i en grupperad miljö som stöder CUDA-teknologier. AlgoTrader - en öppen källalgoritmisk handelsplattform AlgoTrader kan eventuellt utnyttjas i plats för de automatiserade handlaren komponenter. FIX Engine - en fristående applikation som stöder Financial Information Exchange FIX-protokollet, inklusive FIX, FAST och FIXatdl. Även om ingen teknik eller ramverk, bör komponenter byggas med API för applikationsprogrammeringsgränssnitt för att förbättra driftskompatibiliteten av systemet och dess komponenter. Den föreslagna arkitekturen har utformats för att tillfredsställa mycket generiska krav som identifieras för algoritmiska handelssystem. Generellt sett kompliceras algoritmiska handelssystem av tre faktorer som varierar med varje implementering. Dämpningar på externa företag och utbytessystem. Utgående icke-funktionella krav and. Ev oljande arkitektoniska begränsningar. Den föreslagna mjukvaruarkitekturen skulle därför behöva anpassas från fall till fall för att uppfylla specifika organisatoriska och regelbundna krav samt att övervinna regionala hinder. Den algoritmiska handelssystemarkitekturen bör ses som enbart en referenspunkt för individer och organisationer som vill utforma sina egna algoritmiska handelssystem. För en fullständig kopia och källor används, ladda ner en kopia av min rapport tack. Specialfunktion Online Trading Infrastructure En framgångsrik handelsarkitektur. Online-utbyten underlättar snabbare transaktioner genom att tillhandahålla online handel portaler och mäklarhus lätt och flexibilitet Här ser vi på kärninfrastrukturen för NSE, BSE och några handelsportaler av Soutiman Das Gupta. Som utlovats av tekniker visionärer och prognosgrupper under det senaste decenniet har Internet verkligen öppnat nya vägar för att bedriva affärer Börser över hela världen gör nu en bu lk av sin verksamhet online via sina mäklare och partners, ett stort skifte från den traditionella metoden I utvecklade länder är nästan alla valutatransaktioner genomförda online Trenden har långsamt hämtat sig i Indien och två av de största börserna, NSE och NSE Bombaybörsen BSE har genomfört onlinehandel framgångsrikt någon gång nu. Varför sena indiska utbyten och förmedlingshus har varit långsamma för att flytta sina transaktioner online Det här har varit främst på grund av regeringens regler Det var första förseningen att fastställa specifikationer för att skapa sluten användare Grupper CUGs Problemet löstes mellan DoT och finansdepartementet omkring 1998 och snart handlar portaler om och uppstod. Sambandet var kanske den viktigaste tekniska faktorn Kostnaden för hyrda linjer och VSAT-länkar har traditionellt varit mycket hög och tillförlitligheten hos länkarna har varit låga Det tog också lång tid att beställa länkarna som man var tvungen att göra ansökan och vänta i några veckor för länken att vara igång. Andra problem som säkerhet, och kostnader för säkerhetskopiering och återhämtning var också avskräckande. Tack vare upplösningen av lagstiftningsfrågor har Indien inte längre några problem med anslutning och bandbredd Med privata aktörers inträde i bredbandsscenariot och regeringen som öppnar telekomsektorn är dessa frågor nästan obefintliga. Säkerhetslösningar och - tjänster som finns tillgängliga på marknaden har mognat och det kostar inte ett bra paket längre för att göra det enkelt backup lösning på plats. Anatomi av en online-utbyte. Onlinehandel innebär stora volymer av data som transageras varje dag. Bara som ett exempel på BSE var den genomsnittliga dagliga omsättningen 2001-2002 april-mars Rs 1244 10 crore och antalet genomsnittliga dagliga trades var Rs 5 17 lakh. Added till detta finns stränga RBI regler som gör det obligatoriskt för företagen att lagra minst 7 års transaktions - och finansiell data. Design behöver alltid vara säker, överflödig och ha tillräcklig säkerhetskopiering och återställningsprocesser. Lagring För så stora mängder av kritiska data är det naturligt att distribuera nätverksbaserat lagringsutrymme som NAS eller SAN. Säkerhetssäkerhet är en viktig och integrerad En del av designarkitekturen Hårdvaru - och programvaruelementen bör byggas kring en lagrad säkerhetsarkitektur och bör hållas på plats med en väl dokumenterad säkerhetspolitik. Tillgänglighet Ideellt bör nätutbyten ha fem års tillgänglighet. Användning Det är svårt att distribuera ut - of-the-box-applikationer i utbyten, eftersom varje har en unik arkitektur baserad på faktorer som operationsflöde, handelsvolymer, antal medlemmar, antal användare och antal platser. Arkitektur NSE har implementerat NIBIS NSEs Internet Based Information System för realtid spridning av handelsinformation via Internet och NEAT en klient-server-baserad applikation för att hjälpa sin verksamhet. BSE har implementerat ett OnLine Trading System BOLT o na Tandem-plattformen som har en tvåstegsarkitektur Det hävdar att kunna stödja upp till 2 miljoner affärer per dag. Klicka på bilden för större bild. Indiska utbyten NSE och BSE är bland de största börserna i landet De hanterar mycket stora dagliga handelsvolymer, stödja stora mängder datatrafik och ha ett mycket stort landsomfattande nätverk. Volymen i båda börserna är enorma Den genomsnittliga dagliga omsättningen inom kapitalmarknadssegmentet på NSE ligger runt Rs 2300 crore och i derivatsegmentet runt Rs 1300 crore Den genomsnittliga dagliga trafikvolymen är cirka en miljon trades per dag inom kapitalmarknadssegmentet och cirka 50 000 trades per dag i derivatsegmentet Det finns cirka 13 000 registrerade användare i båda segmenten och i genomsnitt cirka 9500 användare är inloggade i en tid. Vid BSE var den genomsnittliga dagliga omsättningen 2001-2002 april-mars Rs 1244 10 crore och antalet dagliga dagligdagar var Rs 5 17 lakhwork design. Oftast sagt, o nline-utbyte måste alltid vara säker, överflödig och ha tillräckliga backup - och återställingsprocesser GM Shenoy, VP, NSE-IT, talar om designfilosofin för hans online-utbyte. Det grundläggande designmålet var att tillhandahålla rättvist, lika och transparent tillgång på alla våra landsbygdsområden En viktig aspekt var att tillhandahålla anslutning till våra handelsmedlemmar så snart som möjligt. Telekomsektorn är ganska liberal idag Bakom 1993 var tekniken mognad och dyr. Hyrda linjer kostar nästan tio gånger så mycket som det gör det idag Satellitteknik var en välsignelse eftersom det möjliggjorde snabbare utbyggnad än hyrda linjer NSE har nu landets största VSAT-nätverk med över 3000 VSAT-enheter och förväntar sig att växa till mer än 4000 VSATs snart-element. En titt på massiva handelsvolymer och trafikvolym är tillräckligt bevis på systemets kritiska karaktär Det gör en skakning för att tänka på de förväntade förlusterna om tio minuters driftstopp när daglig handel passerar Rs 3000 crore Net arbetselement som lagring, säkerhet, säkerhetskopiering och återställningsprocesser, tillgänglighet och de olika applikationerna måste noggrant planeras och beställas. Då måste man följa stränga RBI-föreskrifter för att lagra minst 7 års transaktions - och finansiella data. Storlek För så stora mängder kritiska data är det naturligt att distribuera nätverksbaserat lagringsutrymme som NAS eller SAN NSE implementerar en SAN eftersom det känns att dess datamängder har blivit fenomenalt. Säkerhet Detta bör vara en viktig och integrerad del av designarkitekturen. Hårdvaru - och programvaruelementen bör byggas runt en skiktad säkerhetsarkitektur. Den bör hållas på plats med en väl dokumenterad säkerhetspolitik. Säger säger att säkerhet är det viktigaste elementet i nätverket Alla applikationer har byggts med en medveten inställning till säkerhet. Säkerhetspolitiken är tätt integrerad och granskas regelbundet för att inte lämna något utrymme för kompromiss Alla applikationer och operativsystem är härdade periodiskt för s avety. Backup och återhämtning Detta har uppstått som en av de viktiga aspekterna av kontinuitet när nätutbyten utformades för några år sedan, kanske inte mycket fokus läggs på denna aspekt, som det är idag Men det är inte svårt att lägga till affärs kontinuitetsprocesser till ett befintligt nätverk. Shenoy säger Som ett backup till vårt VSAT-nätverk har ett markbaserat handelsnät deployerats i mitten av 2000. Vi har mer än 850 terminaler som förbinder våra rikstäckande lokaler. Vi är den enda börsen i landet ska ha en helt överflödig affärs kontinuitetsplats i Chennai. Tillgången Ideellt bör nätutbyten ha fem års tillgänglighet Utbyten brukar föredra att vara värd för sin infrastruktur internt och inte använda tjänsterna från ett externt datacentrum. NSE påstår att uppetiden uppnås större än 99 9 Detta beror främst på internt formulerade förfaranden och kontinuerlig granskning av SLAs med hårdvaruleverantörer, säger Shenoy. Applications Det är svårt att distribuera ut - boxapplikationerna i utbyten, eftersom alla har en unik arkitektur baserad på faktorer som operationsflöde, handelsvolymer, antal medlemmar, antal användare och antal platser. Programmen som handel, clearing, riskhantering, övervakning, indexberäkning , notering, medlemskap och konton kan utvecklas internt eller av externa mjukvaruutvecklare. De stora två arkitekturerna NSE och BSE, de stora två börserna, tror på att uppdatera och uppgradera sina teknologisystem för att fortsätta leverera enligt åtaganden och löften till dess medlemmar, partners och kunder. NSE-arkitektur - NEAT NSE har distribuerat NIBIS NSEs Internetbaserade informationssystem för realtidspridning av handelsinformation över Internet och NEAT en klient-serverbaserad applikation för att hjälpa sin verksamhet. NEAT lagrar all handel information i en minnesdatabas vid serveränden för att uppnå minsta svarstid och maximal tillgänglighet för användare för handeln Serverprogramvaran körs på en feltolerant STRATUS mainframe och klientprogramvaran körs på Windows-datorer. Telekommunikationsnätverket använder X 25-protokollet och är ryggraden i det automatiserade handelssystemet Varje handelsmedlem handlar på NSE med andra medlemmar via en dator i handeln medlemmens kontor. Handelsmedlemmarna på segmentet Wholesale Debt Market är kopplade till den centrala datorn vid NSE genom dedikerade 64 Kbps-hyrda linjer och VSAT-terminaler. Dessa hyrda linjer multiplexeras med dedikerade 2 MB optiska fiberlänkar. WDM-deltagarna ansluter till handelssystemet via uppringningslänkar. Utbytet använder RISC-baserade Unix-servrar från Digital och HP för backoffice-behandling. Program som Oracle 7 och SQL Oracle Forms 4 5 frontändar används för utbytesfunktionerna. BSE-arkitektur - BOLT BSE har implementerat en OnLine Trading System BOLT den 14 mars 1995 Det fungerar på en Tandem S74016-plattform som körs på 16 processorer Tandem Himalaya S74016-maskinerna fungerar som backend till mor e än 8000 Trader Workstations nätverk på Ethernet, VSAT och Managed Leased Data Network MLDN Systemen hävdar att hantera upp till två miljoner affärer per dag. BOLT har en två-tiers arkitektur Traders arbetsstationer är anslutna direkt till backend-servern som fungerar som en kommunikationsserver och en central handelsmotor CTE Andra tjänster som informationsspridning, indexberäkning och positionsövervakning tillhandahålls också av systemet En transaktionsövervakningsanläggning i Tandem-arkitekturen hjälper till att hålla dataintegriteten genom non-stop SQL. Med hjälp av MTNL, BSE har upprättat ett MLDN-nätverk som omfattar 300 2 Mbps-linjer och 1500 64 Kbps-linjer som ansluter alla regionala börser och kontor i Mumbai. Tillgång till marknadsrelaterad information via affärsverkstäderna är väsentlig för marknadsaktörerna att agera i realtid och ta omedelbara beslut BOLT har kopplats ihop med olika informationsleverantörer som Bloomberg, Bridge och Reuters Market info rmation matas till nyhetsbyråer i realtid Utbytet planerar att förbättra kapaciteten ytterligare för att ha ett integrerat tvåvägs informationsflöde. Onlinemarknadsportaler Onlinehandel är den investeringsaktivitet som sker via Internet utan den fysiska införandet av mäklaren An slutanvändares investerare måste registrera sig med en online-handelsportal som och investeraren får således en överenskommelse med företaget att handla i olika värdepapper enligt de villkor som anges i avtalet eftersom servrarna i online-handelsportalen är anslutna alla tiden till börserna och utsedda banker är orderhantering gjord i realtid. Investerare kan också få uppdateringar om handeln och kontrollera status för sina beställningar, antingen via e-post eller via gränssnittet. Portal design Harish Malhotra, chefsekreterare , Motilal Oswal Securities Limited, säger att portalen ska vara enkel att navigera, full av användbar och relevant information som är tillgänglig Label med det lägsta antalet klick och bör anpassas Men en väldigt viktig aspekt är att systemen borde kunna koppla direkt till det i nätutbytena utan inkompatibilitetsproblem. använder 128-bitars kryptering aktiverat Secure Socket Layer SSL för att säkerställa att informationen som överförs via Internet är säker och inte kan nås av en tredje part. Användare ges vanligtvis alternativ för att länka sina bankkonton, dematkonton och mäklarkonton till en enda gränssnitt Det finns också ett enda fönster för alla utbyten och en enda skärm för den fullständiga orderrutemekanismen. Hårdvaran som används består av webb - och applikationsservrar, switchar, routrar, brandväggar och säkerhetsanordningar och specialiserade apparater. använder Compaq-servrar för applikationer och databaser, Cisco-routrar och Checkpoint-brandväggar. Systemen har anpassats av sitt inbyggda team. Handelsapplikationerna är outsourcade. Vi har också offline-lagring som säkerhetskopieras regelbundet på olika platser, säger Harish. Portal-framgång. framgången för en handelsportal kommer definitivt att bero på sin bukett av tjänster för en slutanvändare. De flesta portaler tar ut en liten registreringsavgift och mäklare baserat på olika förhållanden. Men det är viktigt för organisationen att fokusera på kundcentrerade tjänster och leveransmodeller till faktiskt njuta av mest uppmärksamhet. Hög frekvens handelssystem design och process management. High Frequency Trading System design och process management. Advisor Roy E Welsch. System för systemdesign och management. Publisher Massachusetts Institute of Technology. Date utfärdat 2009.Trading företag nuförtiden är högt beroende av datautvinning, datormodellering och mjukvaruutveckling Finansanalytiker utföra många liknande uppgifter till dem inom mjukvaru - och tillverkningsindustrin Men finansbranschen har ännu inte helt antagit standardiserade systemtekniska ramverk och processhanteringsmetoder som har lyckats inom mjukvaru - och tillverkningsindustrin. Många av de traditionella metoderna för produktdesign, kvalitetskontroll, systematisk innovation och kontinuerlig förbättring inom teknikområdet kan tillämpas på finansfältet. Denna avhandling visar hur kunskapen som förvärvats från ingenjörsdiscipliner kan förbättra design och processhantering av högfrekventa handelssystem. Högfrekventa handelssystem är beräkningsbaserade Dessa system är automatiska eller halvautomatiska mjukvarusystem som är inherent komplexa och kräver en hög grad av design precision. Utformningen av ett högfrekvent handelssystem kopplar flera fält, inklusive kvantitativ finansiering, systemdesign och mjukvaruutveckling. I finansbranschen där matematik Ationalteorier och handelsmodeller är relativt välskattade. Förmågan att implementera dessa mönster i verklig handelspraxis är ett av de viktigaste inslagen i ett värdepappersföretags konkurrenskraft. Förmågan att omvandla investeringsideer till högpresterande handelssystem effektivt och effektivt kan ge en investering fasta en stor konkurrensfördel cont Denna avhandling ger en detaljerad studie som består av högfrekventa handelssystemdesign, systemmodellering och principer och processhantering för systemutveckling. Särskild vikt läggs vid backtesting och optimering, vilka anses vara de viktigaste delarna i att bygga en handelssystem Denna forskning bygger systemtekniksmodeller som styr utvecklingsprocessen. Det använder också experimentella handelssystem för att verifiera och validera principer som behandlas i detta avhandling. Slutligen sluts i denna avhandling att systemstekniska principer och ramverk kan vara nyckeln till framgång för att implementera högfrekvent handel eller kvantitativa investeringssystem. Thesis S M - Massachusetts Institute of Technology, System Design och Management Program, 2009 Katalogiserad från PDF-version av avhandling Inkluderar bibliografiska referenser p 78-79.Keywords System Design och Management Program.
No comments:
Post a Comment