Algo 거래 시스템 아키텍처

시스템 구조.

AlgoTrader의 아키텍처는 다음과 같은 구성 요소로 구성됩니다.

AlgoTrader Server는 그 위에 실행되는 모든 전략에 대한 인프라를 제공합니다. AlgoTrader 서버는 주요 Esper Complex Event Processing (CEP) 엔진을 보유하고 있습니다. 모든 도메인 모델 개체와 해당 데이터베이스에서의 지속성을 담당합니다. 라이브 및 히스토리 시장 데이터를 처리하기 위해 다양한 시장 데이터 어댑터를 사용할 수 있습니다. 다른 실행 브로커와 교환을위한 다른 최종 어댑터에서 명령을 내리고 실행을 담당합니다.

AlgoTrader Server는 백 테스트, 매개 변수 최적화, 분석, 실행 관리, 위험 관리, 보고, 조정 및 헤징을위한 비즈니스 구성 요소도 제공합니다.

AlgoTrader Server의 상단에는 몇 가지 전략을 배치 할 수 있습니다. 전략은 순수하게 Java로 코딩되거나 Java와 Esper 코드의 조합으로 코딩 될 수 있습니다. Esper 기반 전략은 전용 Esper CEP 엔진을 사용합니다. 전략은 시간 기반 시장 데이터 분석 및 신호 생성을 위해 임의의 수의 SQL과 유사한 Esper 문을 배포 할 수 있습니다. Esper 문은 Java로 코딩 된 주문 배치 또는 위치 닫기와 같은 많은 수의 절차 작업을 호출 할 수 있습니다. Esper 문과 Java 코드의 결합은 세계 최고 수준의 접근 방식을 제공합니다.

시스템의 관리 및 모니터링을 위해 다른 GUI 클라이언트가 존재합니다. AlgoTrader HTML5 Frontend는 차트, 주문, 포지션 & amp; 시장 데이터. Eclipse 또는 IntelliJ IDE는 전략 개발에 사용됩니다. EsperHQ 클라이언트는 Esper CEP 엔진을 관리합니다.

생산적인 설치 및 배치를 위해 AlgoTrader는 Docker를 사용합니다.

최근 뉴스.

Swisscom Startup Challenge의 5 명의 수상자 중 AlgoTrader.

강력한 기능을 갖춘 AlgoTrader 4.0을 소개합니다.

AlgoTrader는 스위스 국립 Fintech 팀 2017의 일원입니다.

판권 소유.

소셜 링크.

하단 주소.

스위스 전화 : +41 44 291 14 85 :

1. aws. amazon로 이동하여 & # 8220; 콘솔에 로그인 & # 8221;을 클릭하십시오. (아래 스크린 샷 참조)

2. 아직 Amazon AWS 계정이없는 경우 "Create AWS Account"를 클릭하여 등록 절차를 수행하십시오.

3. Amazon AWS Console에 로그인하면 사용자 이름 아래의 화면 오른쪽 상단에있는 메뉴에서 "내 계정"을 선택하십시오.

4. 다음 화면에서 "계정 설정"아래에 표시된 12 자리 Amazon ID가 표시됩니다.

귀하와 귀하가 소프트웨어 사용에 대한 별도의 서면 라이센스 계약을 체결하지 않는 한, 최종 사용자 사용권 계약 (& # 8220; 계약서 # 8221;)은 귀하의 소프트웨어 사용을 관장합니다.

라이센서는 귀하가 본 계약서에 포함 된 모든 조건을 수락한다는 조건하에 만 소프트웨어의 사용을 기꺼이 허가합니다. 본 계약에 서명하거나 소프트웨어를 다운로드, 설치 또는 사용함으로써 귀하는 본 계약을 이해하고 해당 조항을 모두 수락 함을 나타냅니다. 귀하가 본 계약서의 모든 조건을 수락하지 않으면, 라이센서는 귀하에게 소프트웨어의 사용권을 허여하지 않으며 소프트웨어를 다운로드, 설치 또는 사용할 수 없습니다.

1. 라이센스 부여.

에이. 평가 사용 및 개발 사용 라이센스. 라이센스 계약자는 본 계약의 조건을 준수 함을 조건으로, 본 계약 기간 동안 소프트웨어를 내부적으로 사용하기 위해 재 라이센스 할 권리가없는 비 독점적이고 양도 불가능한 개인 라이센스를 귀하에게 부여합니다 평가 사용 및 개발 사용. 라이센서가 제공 한 제 3 자 소프트웨어 제품 또는 모듈 (있는 경우)은 소프트웨어와 함께 사용할 수 있으며 제 3 자에 의해 제공된 이용 약관을 수락 할 수 있습니다. 라이센스가 종료되면 소프트웨어 사용을 중지하고 모든 인스턴스를 제거해야합니다. 여기에 명시 적으로 부여되지 않은 모든 권리는 사용 허가자가 보유합니다. 개발자는 소프트웨어 또는 그 파생물 (개발자의 내부 사업 목적 포함)의 상업적 사용을해서는 안됩니다. 직접 또는 간접 고객에게 소프트웨어 또는 개발자 응용 프로그램을 복사하여 어떤 형태로든 재배포하는 것은 금지됩니다.

비. 생산 사용 라이센스. 해당 라이센스 요금 지불을 포함하여 본 계약의 조건을 준수하는 것을 조건으로, 라이센스 부여자는 본 계약 기간 동안 라이센스를 재 라이센스 할 수있는 비 독점적이고 양도가 불가능한 라이센스를 귀하에게 부여합니다. : (a) 귀하의 내부 사업 목적으로 만 소프트웨어를 사용하고 복제하십시오 (& # 8220; 제작 사용); (b) 백업용으로 만 소프트웨어의 합리적인 사본을 만들 수 있습니다. 이러한 라이센스는 라이센스 비용을 지불 한 특정 수의 CPU (CPU에 의해 라이센스가 부여 된 경우) 또는 Java Virtual Machine 인스턴스 (가상 시스템 별 라이센스 인 경우)로 제한됩니다. 더 많은 수의 CPU 또는 Java Virtual Machine 인스턴스에서 소프트웨어를 사용하려면 추가 라이센스 비용을 지불해야합니다. 라이센서가 제공 한 제 3 자 소프트웨어 제품 또는 모듈 (있는 경우)은 본 소프트웨어와 함께 사용할 수 있습니다.

기음. 기타 권리 없음. 소프트웨어에 대한 귀하의 권리와 사용은 본 제 1 항에서 명시 적으로 부여 된 권리로 제한됩니다. 귀하는 소프트웨어를 다른 용도로 사용하지 않습니다. 본 절에서 명시 적으로 라이센스가 부여 된 경우를 제외하고, 라이센스 부여자는 암시 적, 금반언 적 또는 다른 방법으로 귀하에게 다른 권리 또는 라이센스를 부여하지 않습니다. 여기에 명시 적으로 부여되지 않은 모든 권리는 라이센스 제공자 또는 공급 업체가 보유합니다.

2. 제한.

섹션 1에서 명시 적으로 제공된 경우를 제외하고, 귀하는 다음을 수행하지 않습니다 : (a) 소프트웨어의 수정, 번역, 분해, 파생물 작성 또는 소프트웨어 복사; (b) 어떤 형태로든 소프트웨어에 대한 권리를 다른 사람에게 임대, 대여, 양도, 배포 또는 부여하는 행위. (c) 제 3 자에 의한 소프트웨어의 제공, 공개, 공개 또는 사용을 허용하거나 사용을 허가하는 행위 (d) 소프트웨어 또는 그 일부에서 실행되는 벤치 마크 또는 성능 테스트 게시 또는 (e) 소프트웨어의 소유권 표시, 레이블 또는 표시를 제거하는 행위. 귀하는 독립 실행 형 또는 OEM (Original Equipment Manufacturer)을 기준으로 소프트웨어를 배포 할 수 없습니다.

3. 소유권.

양 당사자간에, 본 소프트웨어는 그 안에있는 모든 지적 재산권을 포함하여 라이센서의 독점적 인 자산이며, 계속 유지됩니다.

에이. 귀하가 섹션 1 (a)에 명시된 라이센스 하에서 소프트웨어를 사용하는 경우 본 계약은 평가 또는 개발 기간 동안 유효합니다.

비. 귀하가 제 1 조 (b) 항에 명시된 라이센스에 따라 소프트웨어를 사용하는 경우, 본 계약은 (a) 연간 가입 라이센스로 구입 한 경우 1 년 동안 또는 (b) 영구적으로 영구 라이선스. 연간 구독 라이센스는 한 달 전에 사전 통지없이 해지되지 않는 한 1 년까지 자동으로 갱신됩니다. 본 계약은 귀하가 본 계약 기간을 위반할 경우 통지없이 자동 종료됩니다. 계약이 해지되면 즉시 소프트웨어 사용을 중지하고 소유하거나 통제하는 소프트웨어의 모든 복사본을 폐기해야합니다.

5. 지원 서비스.

지원 서비스를 포함하여이 라이센스를 구입 한 경우 유지 보수 릴리스 (업데이트 및 업그레이드), 전화 지원 및 웹 기반 지원이 포함됩니다.

에이. 인가 권자는보고 된 오류를 해결하거나 우회하기 위해 고안된 업데이트를 제공하기 위해 상업적으로 합당한 노력을 기울일 것입니다. 이러한 오류가 유지 보수 릴리스에서 수정 된 경우, 라이센스 사용자는 해당 유지 보수 릴리스를 설치하고 구현해야합니다. 그렇지 않은 경우 업데이트는 영구적 인 업데이트가 포함 된 유지 보수 릴리스를 사용할 수있을 때까지 사용하기 위해 임시 수정, 절차 또는 루틴의 형태로 제공 될 수 있습니다.

비. 라이센스 계약 기간 동안 라이센스 제공자는 라이센스 제공자가 그러한 유지 보수 릴리스를 일반적으로 고객에게 제공 할 수있는 시점에서 라이센스 사용자에게 유지 보수 릴리스를 제공해야합니다. 제품 오퍼링이 업그레이드인지 또는 신제품인지 기능인지 여부에 대한 질문이 있으면 라이센서의 의견은 일반적으로 최종 사용자 고객을위한 새로운 제품이나 기능으로 제품 오퍼링을 취급한다는 조건하에 우선합니다 .

기음. 라이센서의 지원 서비스 제공 의무는 다음 조건에 달려있다. (a) 라이센시와 상담 한 후에 라이센스 사용자는 실수를 바로 잡기 위해 합리적인 노력을 기울인다. (b) 라이센스 사용자는 라이센스 부여 자의 사이트 또는 라이센스 사용자 사이트로의 원격 액세스를 통해 오류를 정정 할 수있는 충분한 정보와 자원은 물론 인력, 하드웨어 및 기타 추가 항목에 대한 액세스 권한을 라이센스 제공자에게 제공합니다 오류 발견과 관련된 소프트웨어; (c) 라이센스 사용자는 모든 유지 보수 릴리스를 즉시 설치합니다. (d) 라이센스 사용자는 제품을 작동시키는 데 필요한 모든 장비, 통신 인터페이스 및 기타 하드웨어를 조달, 설치 및 유지 보수합니다.

디. 라이센서는 다음과 같은 상황에서 지원 서비스를 제공 할 의무가 없다. (a) 제품이 변경, 수정 또는 손상된 경우 (라이센서의 직접 감독하에있는 경우는 제외). (b) 오류는 라이센스 사용자의 합당한 통제를 벗어난 과실, 하드웨어 오작동 또는 기타 원인으로 인해 발생합니다. (c) 오류는 라이센스 제공자를 통해 라이센스가 부여되지 않은 제 3 자 소프트웨어로 인해 발생합니다. (d) 라이센스 사용자는 유지 보수 릴리스를 설치 및 구현하지 않아 제품이 라이센스 부여자가 지원하는 버전입니다. 또는 (e) 라이센스 사용자가 만기일 때 라이센스 비용 또는 지원 서비스 비용을 지불하지 않은 경우. 또한 라이센스 제공자는 제품을 기반으로 고객 자신이 작성한 소프트웨어 코드에 대해 지원 서비스를 제공 할 의무가 없습니다.

이자형. 갑은 재량에 따라 제품의 지속적인 지원이 경제적으로 실용적이지 않다고 결정한 경우 갑옷 판매자 서비스를 중단 할 수있는 권리를 보유합니다. 인가 권자는 그러한 지원 서비스 중단을 서면으로 적어도 3 개월 전에 서면으로 통지하고 영향을받는 제품에 대해 선급금을 지불 한 미 지불 지원 서비스 수수료를 환불합니다. 라이센스 취득자는 제품이 지원되는 제 3 자 플랫폼 (소프트웨어, JVM, 운영 체제 또는 하드웨어를 포함하되 이에 국한되지 않음)의 모든 버전을 지원하거나 유지할 의무가 없습니다. 제품 및 기본 타사 플랫폼 및 (ii) 최초로 대체 된 후 6 개월 동안 제품 및 운영 체제의 직전 버전 두 개. 갑은 일정 기간이 만기가 된 후 30 일 이내에 갑이 계약에 따라 갑에게 지불 할 금액을 지불하지 않는 경우 지원 서비스의 수행을 중지 할 권리를 보유합니다.

6. 보증.

에이. 인가자는 소프트웨어를 설치 한 날로부터 90 일 동안 소프트웨어가 해당 문서에 명시된 기능 사양에 따라 중요한 모든 측면에서 수행 될 수 있음을 보증합니다. 그러한 보증을 위반 한 경우, 공급 권자는 선택에 따라 소프트웨어를 수정하거나 해당 소프트웨어를 무료로 교체해야합니다. 전술 한 내용은 귀하의 유일하고 독점적 인 구제책이며 라이센서의 이러한 보증 위반에 대한 단독 책임입니다. 위에 명시된 보증은 귀하의 이익을 위해서만 만들어집니다. 보증은 (a) 소프트웨어가 항상 설치 지침에 따라 올바르게 설치되고 사용 된 경우에만 적용됩니다. (c) 최신 업데이트가 소프트웨어에 적용되었습니다. (c) 라이센스 부여 자나인가 자의인가 된 대리인이 아닌 사람이 소프트웨어를 수정, 변경 또는 추가하지 않은 경우.

7. 면책 조항.

제 6 조 (a) 항에 의거하여 제공된 경우를 제외하고, 라이센스 제공자는 상품성, 특정 목적에 대한 적합성 및 비 침해에 대한 묵시적인 보증을 포함하여 명시 적이거나 묵시적인 모든 보증을 명시 적으로 부인하며, 상품성 및 특정 목적에의 적합성에 대한 묵시적 보증 무역. 구두 또는 서면 상 허가받지 않은 조언이나 정보는 본 계약서에 명시 적으로 기술되지 않은 보증을 제공하지 않습니다.

라이센스 부여자는 소프트웨어 제품이 귀하의 요구 사항을 충족 시키거나 귀하의 특정 사용 조건 하에서 작동한다는 보증을하지 않습니다. 인가자는 소프트웨어 제품의 작동이 안전하고 오류가 없으며 중단이 없음을 보증하지 않습니다.

소프트웨어 제품이 보안 및 중단없는 요구 사항을 충족하는지 여부를 결정해야합니다. 귀하는 귀하의 요구 사항을 충족시키기 위해 소프트웨어 제품의 고장으로 인해 초래 된 모든 손실에 대한 전적인 책임과 모든 책임을집니다. 라이센서는 컴퓨터 또는 정보 저장 장치의 데이터 손실에 대해 어떠한 경우에도 책임을지지 않습니다.

8. 책임의 제한.

책임의 모든 원인과 책임의 모든 이론에 근거하여 귀하에 대한 라이센스 제공자의 총 책임은 귀하가 소프트웨어 라이센스 제공자에게 지불 한 라이센스 비용을 한도로 초과하지 않을 것입니다. 어떠한 경우에도 라이센서는 특수한, 우발적 인, 우발적 인, 우발적 인, 징벌 적 또는 필연적 인 손해 (사용, 데이터, 사업 또는 이익의 손실 포함) 또는이 제품과 관련하여 발생하거나이를 대신하여 발생하는 대체 제품의 비용을 책임지지 않습니다 계약 또는 사용 또는 성능에 대한 책임을지지 않으며, 그러한 책임은 계약, 보증, 불법 행위 (태만 포함), 엄격한 책임 또는 기타 방법에 근거하거나 그러한 손실의 가능성에 대해 면허가 부여되었는지 여부에 관계없이 손해. 상기 제한은 본 계약서에 명시된 제한된 구제책이 본질적인 목적을 달성하지 못한 것으로 판명 된 경우에도 적용되고 적용됩니다. 해당 관할 지역에서 라이센스 보유자가 묵시적 보증을 부인할 수있는 범위 내에서이 부인은 허용되는 최대 범위 내에서 유효해야합니다.

본 계약의 조항이 유효하지 않거나 집행이 불가능할 경우 본 계약의 나머지 조항이 완전히 효력을 유지합니다. 적용 가능한 법률에 의해 명시 적 또는 묵시적 제한이 허용되지 않는 한, 이러한 명시 적 또는 묵시적 제한은 해당 적용 법률에서 허용하는 최대한의 범위까지 계속 유효합니다.

본 계약은 본 계약 내용과 관련하여 당사자 간의 완전하고 독점적 인 계약으로, 본 계약 내용과 관련하여 이전 계약, 의사 소통 및 이해 (구두 및 구두)를 대체합니다. 본 계약의 당사자는 독립적 인 계약자이며 다른 당사자를 구속하거나 다른 당사자를 대신하여 의무를 부담 할 권한도 없습니다. 일방 당사자가 본 계약에 따른 권리를 행사하거나 집행하지 않는 한 그러한 권리의 포기로 간주되지 않습니다. 구매 주문서 나 기타 주문서에 포함 된 조건은 본 계약의 조건과 일치하지 않거나 추가적으로 라이센스 제공자에 의해 거절되며 무효로 간주됩니다.

본 계약은 법률 원칙의 충돌과 상관없이 스위스 법률에 따라 해석되고 해석됩니다. 양 당사자는 본 계약과 관련하여 발생하는 분쟁의 해결을 위해 스위스 취리히에 위치한 법원의 배타적 인 관할권 및 재판 지에 동의합니다.

10. 정의.

& # 8220; 평가 사용 & # 8221; 은 귀하의 프로덕션 용도로 의도 된 새로운 응용 프로그램에 대한 평가 및 평가판 용도로만 소프트웨어를 사용함을 의미합니다.

& # 8220; 프로덕션 사용 & # 8221; 란 내부 업무 용도로만 소프트웨어를 사용하는 것을 의미합니다. 생산 사용에는 ASP, VAR, OEM, 배포자 또는 대리점 계약의 일부로 소프트웨어를 공유하거나 배포하는 작업을 포함하여 재 라이센스, 재판매 또는 배포를 위해 소프트웨어를 복제 할 수있는 권리가 포함되지 않습니다.

& # 8220; 소프트웨어 & # 8221; 라 함은 라이센스 제공자의 소프트웨어 및 라이센스 자에 포함 된 모든 구성 요소, 문서 및 예를 의미합니다.

& # 8220; 오류 & # 8221; (a) 제품이 설명서에 명시된 사양을 준수하지 않아 제품 사용 불가 또는 사용 제한으로 이어지는 경우 및 / 또는 (b) 새로운 절차가 필요한 문제, 추가 정보 및 / 또는 제품 개선 요구 사항에 대해 설명합니다.

& # 8220; 유지 관리 릴리스 & # 8221; 는 5 항에 정의 된 표준 지원 서비스에 따라 라이센스 사용자가 사용할 수 있도록 업그레이드 및 제품 업데이트를 의미합니다.

& # 8220; 업데이트 & # 8221; 은 제품을 만들거나 추가 할 때 오류를 수정하는 소프트웨어 수정 또는 추가 또는 제품의 정상적인 작동에서 관찰 될 때 오류가 라이센스 사용자에게 미치는 실질적인 악영향을 제거하는 절차 또는 루틴을 의미합니다.

& # 8220; 업그레이드 & # 8221; 은 새로운 기능을 추가하거나 제품의 용량을 늘리기 위해 일반적으로 지원 서비스 기간 중 최종 사용자 고객에게 라이센스 제공자가 릴리스 한 제품의 개정판을 의미합니다. 업그레이드에는 신제품 출시 또는 별도의 요금이 부과 될 수있는 기능 추가가 포함되지 않습니다.

알고리즘 트레이딩 시스템 아키텍처.

이전에이 블로그에서 지적 알고리즘 트레이딩 시스템의 개념적 아키텍처와 생산 알고리즘 트레이딩 시스템의 기능적 및 비 기능적 요구 사항에 대해 작성했습니다. 그 이후로 필자는 이러한 아키텍처 요구 사항을 충족시킬 수 있다고 믿는 시스템 아키텍처를 설계했습니다. 이 글에서는 ISO / IEC / IEEE 42010 시스템의 지침과 소프트웨어 엔지니어링 아키텍처 설명 표준을 따르는 아키텍처에 대해 설명합니다. 이 표준에 따르면 아키텍처 설명은 다음과 같아야합니다.

여러 표준화 된 아키텍처 뷰 (예 : UML) 및 설계 결정과 아키텍처 요구 사항 간의 추적 가능성 유지.

소프트웨어 아키텍처 정의.

시스템 아키텍처가 무엇인지에 대해서는 아직 합의가 이루어지지 않았습니다. 이 기사의 맥락에서 기능 요구 사항을 충족시키는 응용 프로그램 구성 요소를 지정, 배포 및 실행할 수있는 인프라로 정의됩니다. 기능 요구 사항은 시스템 및 해당 구성 요소의 예상 기능입니다. 비 기능 요구 사항은 시스템의 품질을 측정 할 수있는 방법입니다.

비 기능 요구 사항이 만족스럽지 않으면 기능 요구 사항을 완전히 만족시키는 시스템은 기대에 미치지 못할 수 있습니다. 이 개념을 설명하기 위해 다음 시나리오를 고려하십시오. 방금 구입했거나 구축 한 알고리즘 거래 시스템이 우수한 거래 결정을 내리지 만 조직의 위험 관리 및 회계 시스템과 완전히 작동하지 않습니다. 이 시스템이 귀하의 기대에 부응합니까?

개념적 아키텍처입니다.

개념적보기는 높은 수준의 세분화 수준에서 시스템에 존재하는 고급 개념과 메커니즘을 설명합니다. 이 수준에서 알고리즘 트레이딩 시스템은 4 개의 레이어와 두 가지 아키텍처 측면에서 분리 된 이벤트 기반 아키텍처 (EDA)를 따릅니다. 각 레이어 및 aspect 참조 아키텍처 및 패턴이 사용됩니다. 건축 패턴은 특정 요구 사항을 달성하기위한 입증 된 일반 구조입니다. 건축 측면은 여러 구성 요소에 걸쳐있는 교차 절단 문제입니다.

이벤트 중심 아키텍처 - 이벤트를 생성, 감지, 소비 및 반응하는 아키텍처입니다. 이벤트에는 실시간 시장 이동, 복잡한 이벤트 또는 트렌드, 거래 이벤트가 포함됩니다. 주문 제출.

이 다이어그램은 알고리즘 거래 시스템의 개념적 아키텍처를 보여줍니다.

참조 아키텍처.

비유를 사용하기 위해 기준 아키텍처는 내 하중 벽에 대한 청사진과 유사합니다. 이 청사진은 공통적으로 발생하는 요구 사항을 충족시키기 때문에 어떤 건물이 건설되고 있는지에 관계없이 여러 건물 설계에 재사용 할 수 있습니다. 마찬가지로 참조 아키텍처는 특정 요구 사항을 만족하는 구체적인 소프트웨어 아키텍처를 구성하는 데 사용할 수있는 일반 구조 및 메커니즘을 포함하는 템플릿을 정의합니다. 알고리즘 거래 시스템의 아키텍처는 공간 기반 아키텍처 (SBA)와 모델 뷰 컨트롤러 (MVC)를 참조로 사용합니다. 운영 데이터 저장소 (ODS), 추출 변환 및로드 (ETL) 패턴 및 데이터웨어 하우스 (DW)와 같은 우수 사례도 사용됩니다.

모델보기 컨트롤러 - 정보의 표현과 사용자의 상호 작용을 구분하는 패턴입니다. 공간 기반 아키텍처 - 느슨하게 연결된 처리 장치가 공간이라고하는 공유 연관 메모리 (아래 참조)를 통해 서로 상호 작용하는 인프라를 지정합니다.

구조보기.

아키텍처 구조 뷰는 알고리즘 거래 시스템의 구성 요소와 하위 구성 요소를 보여줍니다. 또한 이러한 구성 요소가 물리적 인프라에 어떻게 배치되는지를 보여줍니다. 이 뷰에 사용 된 UML 다이어그램에는 구성 요소 다이어그램과 배포 다이어그램이 포함됩니다. 다음은 SBA 참조 아키텍처의 전체 알고리즘 트레이딩 시스템 및 처리 단위의 배포 다이어그램과 각 계층의 관련 구성 요소 다이어그램 갤러리입니다.

자동화 된 상인 / 이벤트 처리 구성 요소 다이어그램 데이터 소스 및 사전 처리 계층 구성 요소 다이어그램 MVC 기반 사용자 인터페이스 구성 요소 다이어그램.

건축 전술.

소프트웨어 엔지니어링 연구소에 따르면 아키텍처 전술은 아키텍처 설계 결정을 통해 품질 속성 모델의 일부 측면을 조작하여 품질 요구 사항을 충족시키는 수단입니다. 알고리즘 거래 시스템 아키텍처에서 사용되는 간단한 예제는 연속적인 쿼리 구성 요소로 운영 데이터 저장소 (ODS)를 '조작'하는 것입니다. 이 구성 요소는 복합 이벤트를 식별하고 추출하기 위해 ODS를 지속적으로 분석합니다. 아키텍처에서 사용되는 전술은 다음과 같습니다.

이벤트 및 순서 큐의 장애 패턴 이벤트 및 순서 큐의 공유 메모리 ODS의 CQL (지속적인 쿼리 언어) 수신 데이터의 필터 디자인 패턴을 사용한 데이터 필터링 모든 수신 및 송신 연결의 정체 방지 알고리즘 활성 큐 관리 (AQM ) 및 명시 적 정체 통지 업그레이드 용량을 갖춘 상용 컴퓨팅 리소스 (확장 가능) 모든 단일 실패 지점에 대한 능동 중복 ODS의 인덱싱 및 최적화 된 지속성 구조 ODS에 대한 정기적 인 데이터 백업 및 정리 스크립트 일정 계획 모든 데이터베이스의 트랜잭션 내역 모든 오류를 탐지하는 명령 타임 스탬프가있는 이벤트에 주석 처리하여 '부실'이벤트를 건너 뜁니다. 최대 거래량 자동화 된 상인 구성 요소는 분석을 위해 메모리 내 데이터베이스를 사용합니다. AT에 연결하는 사용자 인터페이스의 2 단계 인증 사용자 인터페이스 및 AT 연결에 대한 암호화 MVC가보기를 관리하기위한 관찰자 디자인 패턴.

위의 목록은 아키텍처 설계 중 확인한 몇 가지 설계 결정 사항입니다. 그것은 전술의 완전한 목록이 아니다. 시스템이 개발됨에 따라 기능적 및 비 기능적 요구 사항을 충족시키기 위해 여러 가지 수준의 세분화 된 수준에서 추가적인 전술을 사용해야합니다. 다음은 장애 요인 디자인 패턴, 필터 디자인 패턴 및 연속 쿼리 구성 요소를 설명하는 세 가지 다이어그램입니다.

행동 적 견해.

이 아키텍처보기는 구성 요소와 계층이 서로 상호 작용하는 방법을 보여줍니다. 이는 아키텍처 설계를 테스트하고 시스템을 종단 간으로 이해하기위한 시나리오를 작성할 때 유용합니다. 이 뷰는 시퀀스 다이어그램과 활동 다이어그램으로 구성됩니다. 알고리즘 트레이딩 시스템의 내부 프로세스와 트레이더가 알고리즘 트레이딩 시스템과 상호 작용하는 방법을 보여주는 활동 다이어그램은 아래와 같습니다.

기술 및 프레임 워크.

소프트웨어 아키텍처 설계의 마지막 단계는 아키텍처를 실현하는 데 사용할 수있는 잠재적 기술 및 프레임 워크를 식별하는 것입니다. 일반적인 원칙으로서 기존 기술의 기능적 및 비 기능적 요구 사항을 적절하게 충족시키는 경우 더 나은 방법을 사용하는 것이 좋습니다. 프레임 워크는 구현 된 참조 아키텍처이다. JBoss는 JEE 참조 아키텍처를 구현하는 프레임 워크입니다. 알고리즘 트레이딩 시스템을 구현할 때 다음 기술과 프레임 워크가 흥미롭고 고려되어야합니다.

CUDA - NVidia는 고성능 전산 금융 모델링을 지원하는 많은 제품을 보유하고 있습니다. CPU 대신 GPU에서 몬테카를로 시뮬레이션을 실행할 때 성능을 최대 50 배 향상시킬 수 있습니다. Apache River - River는 분산 시스템을 개발하는 데 사용되는 툴킷입니다. 이것은 SBA 패턴 인 Apache Hadoop을 기반으로 애플리케이션을 구축하기위한 프레임 워크로 사용되었습니다. 퍼베이시브 로깅이 필수 인 경우 Hadoop을 사용하면 큰 데이터 문제에 대한 흥미로운 솔루션을 제공합니다. Hadoop은 CUDA 기술을 지원하는 클러스터 환경에 배치 될 수 있습니다. AlgoTrader - 오픈 소스 알고리즘 거래 플랫폼. AlgoTrader는 자동화 된 상인 구성 요소의 위치에 잠재적으로 배치 될 수 있습니다. FIX 엔진 - FIX, FAST 및 FIXatdl을 포함한 FIX (Financial Information Exchange) 프로토콜을 지원하는 독립 실행 형 응용 프로그램입니다.

기술이나 프레임 워크는 아니지만 시스템과 구성 요소의 상호 운용성을 향상시키기 위해 API (Application Programming Interface)로 구성 요소를 구축해야합니다.

결론.

제안 된 아키텍처는 알고리즘 거래 시스템에서 확인 된 매우 일반적인 요구 사항을 충족 시키도록 설계되었습니다. 일반적으로 알고리즘 거래 시스템은 각 구현마다 다른 세 가지 요소로 복잡합니다.

외부 엔터프라이즈 및 Exchange 시스템에 대한 종속성 비 기능 요구 사항에 대한 도전과 진화하는 아키텍처 제약.

따라서 제안 된 소프트웨어 아키텍처는 특정 조직 및 규정 요구 사항을 충족시키고 지역 제약 조건을 극복하기 위해 사례별로 적용해야합니다. 알고리즘 거래 시스템 아키텍처는 자신의 알고리즘 거래 시스템을 설계하고자하는 개인 및 조직을위한 참고서 일뿐입니다.

사용 된 전체 사본 및 출처는 내 보고서 사본을 다운로드하십시오. 고맙습니다.

이전 이야기.

알고리즘 트레이딩 시스템 요구 사항.

다음 이야기.

Particle Swarm Optimization을 이용한 포트폴리오 최적화.

멋진 개관과 아키텍처에 대한 좋은 출발. 당신의 결론은 적절한 것이었고, 알고리즘 거래 소프트웨어 시스템이 관련성을 유지하기 위해 지속적인 백 테스트 및 조정이 필요한 이유를 지적했습니다. 좋은 읽을 거리!

2016 년 2 월 1 일

상품 또는 고정 수입의 데이터가 부정확하거나 수신 속도가 느린 경우 모델은 특히 Black Swann 이벤트의 공간에서 계산하기가 어려울 수 있습니다.

이 기사를 주셔서 대단히 감사합니다. 1990 년대 후반부터 AI에 대해 생각해 봤는데 마침내 기술과 API가 일반적으로 제공됩니다. 기사와 블로그는 이전 연도의 꿈을 실현하는 첫 걸음을 내딛는 데 큰 도움이됩니다. 당신의 추가 벤처에 많은 감사와 행운을 빕니다!

귀하의 진전 상황을 계속 알려 주시기 바랍니다. 나는 아주 흥미 롭다. 고맙습니다.

댓글을 제출하십시오.

답장 취소.

Turing Finance를 팔로우하십시오.

Turing 금융 메일 링리스트.

Turing Finance의 친구들.

Quantocracy는 매일 매일 게시되는 새로운 분석에 대한 링크가있는 최고의 양적 금융 블로그 수집기입니다.

NMRQL은 내가 속한 양적 헤지 펀드 다. 우리는 기계 학습을 사용하여 시장을 이기고 시도합니다.

알고리즘 트레이딩 시스템 요구 사항.

현재 소프트웨어 아키텍처에 관한 강의를 듣고 있습니다. 이 수업에서는 각 학생이 시스템을 선택하고 건축 요구 사항을 정의하며 이러한 요구 사항을 충족 할 수있는 솔루션을 설계합니다. 기술적 인 문제 때문에 그리고 금융 시장을 사랑하기 때문에 알고리즘 거래 시스템을 선택했습니다. 알고리즘 거래 시스템 (AT)은 계산 알고리즘을 사용하여 제출 결정 후 거래 결정, 주문 제출 및 주문 관리를 수행합니다. 최근 몇 년 동안 AT는 인기를 얻었으며 현재 국제 교류를 통해 거래되는 대부분의 거래를 설명합니다. 프로그래밍 된 거래와 알고리즘 거래는 구분됩니다. 프로그램 된 거래는 큰 시장 주문을 더 작은 주식으로 분해하는 것을 포함합니다. 이 기사에서 프로그래밍 된 거래는 AT의 보안 요구 사항으로 간주됩니다.

알고리즘 트레이딩 시스템 도입.

일반적으로 말하자면, 소매 투자자, 독점 상인, 시장 제작자, 매수 측 기관 및 매도 측 기관의 5 가지 유형의 시장 참여자가 있습니다. AT는 독점적 인 구매 측 기관에서 가장 많이 사용되지만 역동적 인 변화를 보이고 있습니다. 알고리즘 서비스 거래 (ATAAS)는 알고리즘 투자를 소매 투자자가 이용할 수 있도록합니다 (부록 참조). 이 기사에서는 독점적 인 구매 측 기관에서 사용하는 AT의 아키텍처 요구 사항에 대해 설명합니다. 최상위 수준에서 AT는 세 가지 기능을 수행합니다. 즉, 거래 결정을 내리고, 거래 주문을 작성하며, 제출 후 해당 주문을 관리합니다. 이것들 아래에 더 많은 상세한 기능적 요구 사항들이 있으며, 그 중 일부는 아키텍처에 의해 만족 될 수 있습니다.

소프트웨어 아키텍처 소개.

많은 논쟁이 소프트웨어 아키텍처의 정의를 둘러싼 다. 이 기사의 맥락에서 소프트웨어 아키텍처는 사용자 기능을 제공하는 응용 프로그램 구성 요소를 지정, 배포 및 실행할 수있는 인프라로 정의됩니다. 소프트웨어 시스템은 기능적 및 비 기능적 요구 사항을 충족시켜야합니다. 기능 요구 사항은 시스템 구성 요소의 기능을 지정합니다. 비 기능 요구 사항은 시스템 성능을 측정하는 기준을 지정합니다. 기능적 요구 사항을 만족하는 소프트웨어 시스템은 여전히 ​​사용자 기대치를 충족시키지 못할 수 있습니다. 적시에 거래를 제출할 수있는 AT는 재정적 손실을 초래할 수 있습니다. 소프트웨어 아키텍처는 기본적으로 비 기능 요구 사항을 만족하는 인프라를 제공하며, 기능 요구 사항을 충족하는 구성 요소를 배포하고 실행할 수 있습니다. 따라서 알고리즘 거래 시스템 요구 사항은 기능적 요구 사항과 비 기능적 요구 사항으로 크게 나눌 수 있습니다.

기능 요구 사항.

'거래 의사 결정'최상위 요구 사항 아래에는 세 가지 고급 요구 사항이 있습니다.

시장 데이터 얻기 - 구조화 및 비정형 데이터를 다운로드, 필터링 및 저장합니다. 구조화 된 데이터에는 프로토콜을 사용하여 전송 된 로이터 또는 블룸버그의 실시간 시장 데이터가 포함됩니다. 고치다. 비정형 데이터에는 뉴스 및 소셜 미디어 데이터가 포함됩니다. 거래 전략 정의 - 새로운 거래 규칙 및 전략을 지정합니다. 거래 규칙은 지표, 부등식 및 숫자 값으로 구성됩니다. "PE 비"& lt; 10. 거래 규칙은 거래 전략을 정의하기위한 의사 결정 트리로 구성됩니다 (아래 그림 참조). 거래 전략에 따라 증권 분석 - 각 보안에 대해 데이터를 얻고 거래 전략을 통해 필터링하여 구매할 보안을 결정합니다. 또한 각 공개 포지션에 대해 매도 할 보안을 결정하십시오. 참고 :이 요구 사항은 다를 수 있습니다.

'거래 주문 생성'최상위 요구 사항 아래에는 두 가지 고급 요구 사항이 있습니다.

거래 정보를 얻으십시오 - 각 결정에 대해 보안 기호, 가격, 수량 등을 얻으십시오. 거래 주문 작성 - 각 결정에 대해 주문 유형을 지정하고 거래 정보를 추가하십시오. 장기, 단기, 시장, 한도, 중지 및 조건부의 6 가지 주문 유형이 있습니다.

'주문 관리'최상위 요구 사항 아래에는 세 가지 고급 요구 사항이 있습니다.

보류중인 주문 관리 - 각 주문에 대해 주문 확인, 확인 및 주문 확인 - 주문을 교환소, 다크 풀 또는 중개인에게 전달합니다. 제출 된 주문 관리 - 제출 된 각 주문의 상태를 추적하고 주문이 일치하면 열린 위치를 만듭니다. . 주문이 일치하지 않으면 주문을 중단하십시오.

이 다이어그램은 거래 전략을 거래 규칙의 의사 결정 트리로 정의 할 수있는 방법을 보여줍니다.

비 기능 요구 사항.

예를 들어 서로간에 교환되는 많은 비 기능 요구 사항이 있습니다. 성능 향상은 총 소유 비용 (TCO) 증가로 이어집니다. 비 기능적 알고리즘 거래 시스템 요구 사항에는 다음이 포함됩니다.

확장 성 - 시스템이 증가하거나 확장되는 작업 부하를 처리하고 수행 할 수있는 능력입니다. AT는 프로세스의 데이터 피드 수, 거래하는 교환 수 및 거래 할 수있는 증권의 수에 따라 확장 가능해야합니다. 성과 - 시스템이 수행하는 작업량과 작업에 필요한 시간 및 자원을 비교 한 것입니다. AT는 빠른 응답 시간 (시장으로 돌아 가기)과 높은 처리 및 네트워크 처리량을 가져야합니다. 수정 가능성 - 시스템을 쉽게 변경할 수 있습니다. AT는 쉽게 수정할 수있는 거래 전략 및 데이터 처리가 있어야합니다. 신뢰성 - 시스템이받은 입력에 대해 올바른 결과를 산출하기위한 정확성과 의존성입니다. AT의 오류 및 버그로 인해 막대한 손실과 벌금이 발생할 수 있으므로 안정성이 중요합니다. 이것에 대한 증거는 기사 수도의 전함을보십시오. 감사 기능 - 시스템을 감사 할 수있는 용이성입니다. 최근 AT & T의 건방진 사례가 감사 기관에 AT의 주목을 받았다. 따라서 재무, 컴플라이언스 및 IT 관점에서 감사 가능해야합니다. 보안 - 테러, 도난 또는 간첩과 같은 범죄 행위에 대한 조직의 안전. 거래 전략은 독점적이며 귀중한 지적 재산이기 때문에 반드시 확보해야합니다. 또한 AT를 사냥으로부터 보호하기 위해 프로그래밍 된 거래 전략을 사용하여 주문을 난독 화해야합니다. 내결함성 (Fault Tolerance) - 시스템이 오류 또는 실패 후에도 올바르게 작동 할 수있는 기능입니다. 이는 재무 적 손실을 피하기 위해 AT가 오류 발생 후에도 안정적이어야한다는 점을 제외하면 신뢰성과 유사합니다. 상호 운용성 (Interoperability) - 시스템이 다양한 범위의 관련 시스템에서 작동 할 수있는 용이성입니다. 이는 주문 관리 시스템, 포트폴리오 관리 시스템, 위험 관리 시스템, 회계 시스템, 심지어는 은행 시스템과의 인터페이스가 필요한 AT의 경우 중요합니다.

아키텍처 범위 개요.

아키텍처 범위는 기능적 및 비 기능적 요구 사항을 충족하기 위해 구성 요소에서 사용하는 아키텍처에서 지원하는 서비스 집합입니다. 이 아키텍처 범위에 대한 자세한 분석은 자세한 요구 사항 문서를 참조하십시오. 고급 수준에서 다음 서비스를 아키텍처에서 제공해야합니다.

다중 데이터 스트림, 관련없는 데이터에 대한 필터 및 임시 데이터 파티셔닝을 지원하는 수정 가능한 데이터 사전 처리 환경 다중 처리 장치 (클러스터), 실시간 성능 모니터링, 메시지 지향 통신 프레임 워크, 스케줄링을 지원하는 분산 처리 환경 시간적 데이터 집합, 로드 밸런싱 및 데이터 복제를 지원하는 메모리 (SAN) - 임시 데이터 집계, 연속 쿼리 및 로깅을 지원하는 SAN (저장 영역 네트워크) (감사 추적 용) 데이터 복구 (DR) 환경 - SAN 및 주문 관리 시스템 복제 구성 요소에 대한 표준 API를 제공하고 내부 및 외부 구성 요소를 서로 연결하는 통합 환경 - 동시 입력 스트림을 지원하는 주문 관리 시스템 , 수동 리던던시 및로드 밸런싱, 주문에 대한 ACID 기준, 감사 내역 및 복제본 cated 시스템 사용 환경 - 여러 사용자 프로필을 지원하고 완벽하게 관리되는 프론트 엔드를 알고리즘 거래 시스템에 노출합니다.

액세스 및 통합 요구 사항.

액세스 요구 사항은 사용자가 시스템 구성 요소에 액세스 할 수있는 방법을 설명합니다. 알고리즘 거래 시스템은 세 가지 인터페이스, 즉 새로운 거래 규칙, 거래 전략 및 데이터 소스를 정의하는 인터페이스, 시스템 관리자가 클러스터를 추가하고 아키텍처를 구성 할 수있는 백엔드 인터페이스. IT 통제 및 사용자 액세스 권한을 확인하기위한 읽기 전용 감사 인터페이스가 있습니다. 구성 요소와 외부 시스템을 통합하기위한 사전 요구 사항을 통합 요구 사항이라고합니다. 알고리즘 거래 시스템은 파일 기반 통합, 메시지 기반 통합 및 데이터베이스 통합을 지원해야합니다. 따라서 다음 요구 사항을 아키텍처에서 만족해야합니다.

데이터베이스 통합 - ODBC, JDBC, ADO 및 XQC 지원 파일 기반 통합 - CSV, XML 및 JSON 파일 지원 메시지 기반 통합 - FIX, FAST 및 FIXatdl 지원.

건축상의 제약.

파란색 점은 네트워크 대기 시간이 최소화되는 실제 위치를 표시하고 빨간색 점은 대규모 금융 거래의 실제 위치를 나타냅니다. 알고리즘 거래 시스템의 성능을 극대화하려면 네트워크 대기 시간을 최소화하는 위치에 시스템을 배치해야합니다. 출처 : MIT 공개 보도 자료 : dspace. mit. edu/handle/1721.1/6285.

아키텍처 제약은 구축되는 아키텍처의 성능을 제한하는 요소입니다. 여기서 언급 할 두 가지 제약은 물리적 네트워크 제약과 규제 제약입니다. 열악한 통신 네트워크로 인해 물리적 네트워크 제약이 시스템에 가해집니다. 이 제약 조건을 완화하려면 네트워크 대기 시간을 최소화해야하는 시스템을 구축해야합니다. 네트워크 제약을 완화하는 또 다른 방법은 알고리즘 거래 시스템을 시장 거래소와 함께 배치하는 것입니다. 이미 말한 바에 따르면, 공동 위치 결정은 추가 처리 및 공간 제약을 도입합니다.

규제의 제약은 법과 규정을 통해 도입됩니다. 알고리즘 트레이딩 시스템은 2010 년 플래시 사고 이후 더 많은 규제가 이루어지기 때문에 알고리즘 트레이딩 시스템의 설계 및 구현에서 점점 더 중요한 요소가되었습니다. 일반적으로 AT는 시스템 준수 및 무결성 (SCI), EMEA 알고리즘 트레이딩 시스템 지침, ISO 9000 알고리즘 거래 표준 (AT9000) 및 국제 재무보고 표준 (IFRS)에 관한 SEC의 규칙을 준수해야합니다. .

결론.

알고리즘 트레이딩 시스템 아키텍처는 시스템에서 기대되는 엄격한 비 기능 요구 사항과 자동화 된 거래를 규제하는 광범위한 규제 및 규정 준수 요구 사항으로 인해 복잡합니다. 이러한 복잡성으로 인해 시스템 아키텍처의 설계 및 구현을 신중하게 고려해야합니다. 오픈 소스 알고리즘 거래 아키텍처를 설계 할 때 이러한 시스템을 설계 할 때 종종 간과되는 아키텍처 요구 사항을 지적하고자합니다. 이 문서에서 확인 된 요구 사항은 완벽하지 않으며 필연적으로 시간이 지남에 따라 발전 할 것입니다. 이 기사의 두 번째 기사에서는 위에서 언급 한 요구 사항을 충족하는 소프트웨어 아키텍처에 대한 설계를 포함합니다. 알고리즘 거래에 대한 자세한 내용은 언제든지 저에게 연락하십시오.

보고서 사본을 다운로드하려면 여기를 클릭하십시오. 출처 전체 목록은 보고서를 참조하십시오.

ATAAS 서비스 제공 업체는 다음을 포함하지만 이에 국한되지 않습니다.

Quantopian - 사용자는 Python으로 양적 거래 전략을 정의하고이를 다시 테스트 할 수 있습니다. 사용자는 실제 시장에서 이러한 전략을 실행할 수도 있습니다. Quantopian은 최근에 그들의 서비스를 확장하기 위해 670 만 달러의 투자를 받았습니다. EquaMetrics - RIZM 사용자는 시각적으로 새로운 알고리즘 거래 전략을 수립하고, 해당 전략을 다시 테스트하고, 실제 시장에서 전략을 실행합니다. EquaMetrics는 최근 450 만 달러 상당의 RIZM에 대한 새로운 기금을 발표했습니다. 중개업 - 일부 중개인은 거래자가 자신의 거래 전략을 자동으로 실행하는 거래용 로봇을 만들 수 있습니다.

이전 이야기.

신경망을 이용한 BRICs 경제 예측.

다음 이야기.

알고리즘 트레이딩 시스템 아키텍처.

댓글을 제출하십시오.

답장 취소.

Turing Finance를 팔로우하십시오.

Turing 금융 메일 링리스트.

Turing Finance의 친구들.

Quantocracy는 매일 새로운 분석에 대한 링크가있는 최고의 양적 금융 블로그 수집기입니다.

NMRQL은 내가 속한 양적 헤지 펀드 다. 우리는 기계 학습을 사용하여 시장을 이기고 시도합니다.

QuantStart.

빠르게 성장하는 소매점 퀀텀 트레이더 커뮤니티를 지원하는 Quantcademy 개인 회원 포털에 가입하십시오. 당신은 당신의 가장 중요한 퀀트 트레이딩 질문에 대답 할 준비가되어있는 지식이 풍부하고 마음이 맞는 퀀트 트레이더 그룹을 찾을 수 있습니다.

퀀트 트레이딩에 관한 나의 eBook을 확인해보십시오. 여기서 저는 파이썬 툴로 수익성 높은 체계적인 트레이딩 전략을 만드는 법을 가르쳐드립니다.

Python 및 R을 사용하여 시계열 분석, 기계 학습 및 베이지안 통계를 사용하는 고급 거래 전략에 관한 새로운 전자 책을 살펴보십시오.

2013 년 7 월 26 일 Michael Halls-Moore 작성

QS mailbag에서받는 가장 자주 묻는 질문 중 하나는 "알고리즘 트레이딩을위한 최고의 프로그래밍 언어는 무엇입니까?"입니다. 짧은 대답은 "최상의"언어가 없다는 것입니다. 전략 매개 변수, 성능, 모듈성, 개발, 탄력성 및 비용을 모두 고려해야합니다. 이 기사는 알고리즘 트레이딩 시스템 아키텍처의 필수 구성 요소와 구현에 관한 결정이 언어 선택에 미치는 영향을 설명합니다.

첫째, 리서치 툴, 포트폴리오 옵티 마이저, 리스크 관리자 및 실행 엔진과 같은 알고리즘 트레이딩 시스템의 주요 구성 요소가 고려됩니다. 이후에 서로 다른 트레이딩 전략을 검토하고 이들이 시스템의 설계에 어떻게 영향을 주는지에 대해 조사 할 것입니다. 특히 거래 빈도와 거래량에 대해 모두 논의 할 것입니다.

거래 전략이 선택되면 전체 시스템을 설계해야합니다. 여기에는 희소하고 잠재적으로 치명적인 이벤트에 대한 하드웨어, 운영 체제 및 시스템 탄력성의 선택이 포함됩니다. 아키텍처가 고려되는 동안 연구 도구뿐 아니라 실제 실행 환경에 대해서도 성능에 대한 적절한 고려가 이루어져야합니다.

무역 시스템은 무엇을하려고합니까?

자동화 된 거래 시스템을 작성하는 "최상의"언어를 결정하기 전에 요구 사항을 정의해야합니다. 시스템이 순전히 실행 기반이 될 것입니까? 시스템에 위험 관리 또는 포트폴리오 구성 모듈이 필요합니까? 시스템에 고성능 백 테스터가 필요합니까? 대부분의 전략에서 거래 시스템은 연구 및 신호 생성이라는 두 가지 범주로 나눌 수 있습니다.

연구는 과거 데이터에 대한 전략 성과 평가와 관련이 있습니다. 이전 시장 데이터에 대한 거래 전략을 평가하는 프로세스를 백 테스팅 (backtesting)이라고합니다. 데이터 크기와 알고리즘 복잡성은 백 테스터의 계산 강도에 큰 영향을 미칩니다. CPU 속도와 동시성은 종종 연구 실행 속도를 최적화하는데있어 제한 요소입니다.

신호 생성은 알고리즘으로부터 일련의 거래 신호를 생성하고 그러한 주문을 보통 중개를 통해 시장에 보내는 것과 관련이 있습니다. 특정 전략의 경우 높은 수준의 성과가 요구됩니다. 네트워크 대역폭 및 대기 시간과 같은 I / O 문제는 종종 실행 시스템 최적화의 제한 요소입니다. 따라서 전체 시스템의 각 구성 요소에 대한 언어 선택은 상당히 다를 수 있습니다.

유형, 빈도 및 전략의 양.

채택 된 알고리즘 전략의 유형은 시스템 설계에 상당한 영향을 미칩니다. 거래되는 시장, 외부 데이터 공급 업체와의 연결성, 전략의 빈도 및 양, 개발 용이성과 성능 최적화 간의 균형, 공동 배치 된 사용자 지정을 포함한 모든 사용자 지정 하드웨어를 고려해야합니다 서버, GPU 또는 FPGA가 필요합니다.

저주파 미국 주식 전략의 기술 선택은 선물 시장에서 거래하는 고주파 통계적 재정 거래 전략의 기술 선택과 크게 다를 것입니다. 언어를 선택하기 전에 많은 데이터 공급 업체가 현재 진행중인 전략과 관련이 있는지 평가해야합니다.

오프라인 상태에서 공급 업체와의 연결, API의 구조, 데이터의 적시성, 저장소 요구 사항 및 복원력을 고려해야합니다. 또한 여러 공급 업체에 신속하게 액세스 할 수있는 것이 현명합니다. 다양한 계측기에는 모두 자신 만의 스토리지 쿼크가 있으며, 여기에는 주식에 대한 여러 시세 표시와 선물에 대한 만료일이 포함됩니다 (특정 OTC 데이터는 말할 것도 없습니다). 이를 플랫폼 설계에 고려해야합니다.

전략의 빈도는 기술 스택 정의 방법의 가장 큰 동인 중 하나 일 수 있습니다. 미세하거나 두 번째 막대보다 자주 데이터를 사용하는 전략은 성과와 관련하여 중요한 고려 사항이 필요합니다.

두 번째 막대 (예 : 틱 데이터)를 초과하는 전략은 주요 요구 사항으로 실적 중심의 디자인을 유도합니다. 고 빈도 전략의 경우 상당량의 시장 데이터를 저장하고 평가해야합니다. HDF5 또는 kdb +와 같은 소프트웨어가 일반적으로 이러한 역할에 사용됩니다.

HFT 응용 프로그램에 필요한 대량의 데이터를 처리하려면 광범위하게 최적화 된 백 테스터 및 실행 시스템을 사용해야합니다. C / C ++ (일부 어셈블러 사용 가능)이 가장 강력한 언어 후보가 될 가능성이 큽니다. 초고주파 전략에는 FPGA, 교환기 위치 및 커널 / 네트워크 인터페이스 튜닝과 같은 맞춤형 하드웨어가 거의 필요합니다.

연구 시스템.

연구 시스템에는 대개 대화 형 개발과 자동화 된 스크립팅이 혼합되어 있습니다. 전자는 종종 Visual Studio, MatLab 또는 R Studio와 같은 IDE 내에서 발생합니다. 후자는 수많은 매개 변수와 데이터 포인트에 대한 광범위한 수치 계산을 포함합니다. 따라서 코드를 테스트 할 수있는 간단한 환경을 제공하는 언어 선택이 가능하지만 여러 매개 변수 차원에서 전략을 평가하는 데 충분한 성능을 제공합니다.

이 분야의 일반적인 IDE에는 광범위한 디버깅 유틸리티, "Intellisense"를 통한 코드 완성 기능 및 데이터베이스 ORM, LINQ를 통한 전체 프로젝트 스택의 간단한 개요가 포함 된 Microsoft Visual C ++ / C #, 광범위한 수치 선형 대수 및 벡터화 연산을 위해 설계된 대화식 콘솔 방식의 MatLab; R Studio는 R 통계 언어 콘솔을 본격적인 IDE에 랩핑합니다. Linux 용 Eclipse IDE Java 및 C ++; and semi-proprietary IDEs such as Enthought Canopy for Python, which include data analysis libraries such as NumPy, SciPy, scikit-learn and pandas in a single interactive (console) environment.

For numerical backtesting, all of the above languages are suitable, although it is not necessary to utilise a GUI/IDE as the code will be executed "in the background". The prime consideration at this stage is that of execution speed. A compiled language (such as C++) is often useful if the backtesting parameter dimensions are large. Remember that it is necessary to be wary of such systems if that is the case!

Interpreted languages such as Python often make use of high-performance libraries such as NumPy/pandas for the backtesting step, in order to maintain a reasonable degree of competitiveness with compiled equivalents. Ultimately the language chosen for the backtesting will be determined by specific algorithmic needs as well as the range of libraries available in the language (more on that below). However, the language used for the backtester and research environments can be completely independent of those used in the portfolio construction, risk management and execution components, as will be seen.

Portfolio Construction and Risk Management.

The portfolio construction and risk management components are often overlooked by retail algorithmic traders. This is almost always a mistake. These tools provide the mechanism by which capital will be preserved. They not only attempt to alleviate the number of "risky" bets, but also minimise churn of the trades themselves, reducing transaction costs.

Sophisticated versions of these components can have a significant effect on the quality and consistentcy of profitability. It is straightforward to create a stable of strategies as the portfolio construction mechanism and risk manager can easily be modified to handle multiple systems. Thus they should be considered essential components at the outset of the design of an algorithmic trading system.

The job of the portfolio construction system is to take a set of desired trades and produce the set of actual trades that minimise churn, maintain exposures to various factors (such as sectors, asset classes, volatility etc) and optimise the allocation of capital to various strategies in a portfolio.

Portfolio construction often reduces to a linear algebra problem (such as a matrix factorisation) and hence performance is highly dependent upon the effectiveness of the numerical linear algebra implementation available. Common libraries include uBLAS, LAPACK and NAG for C++. MatLab also possesses extensively optimised matrix operations. Python utilises NumPy/SciPy for such computations. A frequently rebalanced portfolio will require a compiled (and well optimised!) matrix library to carry this step out, so as not to bottleneck the trading system.

Risk management is another extremely important part of an algorithmic trading system. Risk can come in many forms: Increased volatility (although this may be seen as desirable for certain strategies!), increased correlations between asset classes, counter-party default, server outages, "black swan" events and undetected bugs in the trading code, to name a few.

Risk management components try and anticipate the effects of excessive volatility and correlation between asset classes and their subsequent effect(s) on trading capital. Often this reduces to a set of statistical computations such as Monte Carlo "stress tests". This is very similar to the computational needs of a derivatives pricing engine and as such will be CPU-bound. These simulations are highly parallelisable (see below) and, to a certain degree, it is possible to "throw hardware at the problem".

Execution Systems.

The job of the execution system is to receive filtered trading signals from the portfolio construction and risk management components and send them on to a brokerage or other means of market access. For the majority of retail algorithmic trading strategies this involves an API or FIX connection to a brokerage such as Interactive Brokers. The primary considerations when deciding upon a language include quality of the API, language-wrapper availability for an API, execution frequency and the anticipated slippage.

The "quality" of the API refers to how well documented it is, what sort of performance it provides, whether it needs standalone software to be accessed or whether a gateway can be established in a headless fashion (i. e. no GUI). In the case of Interactive Brokers, the Trader WorkStation tool needs to be running in a GUI environment in order to access their API. I once had to install a Desktop Ubuntu edition onto an Amazon cloud server to access Interactive Brokers remotely, purely for this reason!

Most APIs will provide a C++ and/or Java interface. It is usually up to the community to develop language-specific wrappers for C#, Python, R, Excel and MatLab. Note that with every additional plugin utilised (especially API wrappers) there is scope for bugs to creep into the system. Always test plugins of this sort and ensure they are actively maintained. A worthwhile gauge is to see how many new updates to a codebase have been made in recent months.

Execution frequency is of the utmost importance in the execution algorithm. Note that hundreds of orders may be sent every minute and as such performance is critical. Slippage will be incurred through a badly-performing execution system and this will have a dramatic impact on profitability.

Statically-typed languages (see below) such as C++/Java are generally optimal for execution but there is a trade-off in development time, testing and ease of maintenance. Dynamically-typed languages, such as Python and Perl are now generally "fast enough". Always make sure the components are designed in a modular fashion (see below) so that they can be "swapped out" out as the system scales.

Architectural Planning and Development Process.

The components of a trading system, its frequency and volume requirements have been discussed above, but system infrastructure has yet to be covered. Those acting as a retail trader or working in a small fund will likely be "wearing many hats". It will be necessary to be covering the alpha model, risk management and execution parameters, and also the final implementation of the system. Before delving into specific languages the design of an optimal system architecture will be discussed.

Separation of Concerns.

One of the most important decisions that must be made at the outset is how to "separate the concerns" of a trading system. In software development, this essentially means how to break up the different aspects of the trading system into separate modular components.

By exposing interfaces at each of the components it is easy to swap out parts of the system for other versions that aid performance, reliability or maintenance, without modifying any external dependency code. This is the "best practice" for such systems. For strategies at lower frequencies such practices are advised. For ultra high frequency trading the rulebook might have to be ignored at the expense of tweaking the system for even more performance. A more tightly coupled system may be desirable.

Creating a component map of an algorithmic trading system is worth an article in itself. However, an optimal approach is to make sure there are separate components for the historical and real-time market data inputs, data storage, data access API, backtester, strategy parameters, portfolio construction, risk management and automated execution systems.

For instance, if the data store being used is currently underperforming, even at significant levels of optimisation, it can be swapped out with minimal rewrites to the data ingestion or data access API. As far the as the backtester and subsequent components are concerned, there is no difference.

Another benefit of separated components is that it allows a variety of programming languages to be used in the overall system. There is no need to be restricted to a single language if the communication method of the components is language independent. This will be the case if they are communicating via TCP/IP, ZeroMQ or some other language-independent protocol.

As a concrete example, consider the case of a backtesting system being written in C++ for "number crunching" performance, while the portfolio manager and execution systems are written in Python using SciPy and IBPy.

Performance Considerations.

Performance is a significant consideration for most trading strategies. For higher frequency strategies it is the most important factor. "Performance" covers a wide range of issues, such as algorithmic execution speed, network latency, bandwidth, data I/O, concurrency/parallelism and scaling. Each of these areas are individually covered by large textbooks, so this article will only scratch the surface of each topic. Architecture and language choice will now be discussed in terms of their effects on performance.

The prevailing wisdom as stated by Donald Knuth, one of the fathers of Computer Science, is that "premature optimisation is the root of all evil". This is almost always the case - except when building a high frequency trading algorithm! For those who are interested in lower frequency strategies, a common approach is to build a system in the simplest way possible and only optimise as bottlenecks begin to appear.

Profiling tools are used to determine where bottlenecks arise. Profiles can be made for all of the factors listed above, either in a MS Windows or Linux environment. There are many operating system and language tools available to do so, as well as third party utilities. Language choice will now be discussed in the context of performance.

C++, Java, Python, R and MatLab all contain high-performance libraries (either as part of their standard or externally) for basic data structure and algorithmic work. C++ ships with the Standard Template Library, while Python contains NumPy/SciPy. Common mathematical tasks are to be found in these libraries and it is rarely beneficial to write a new implementation.

One exception is if highly customised hardware architecture is required and an algorithm is making extensive use of proprietary extensions (such as custom caches). However, often "reinvention of the wheel" wastes time that could be better spent developing and optimising other parts of the trading infrastructure. Development time is extremely precious especially in the context of sole developers.

Latency is often an issue of the execution system as the research tools are usually situated on the same machine. For the former, latency can occur at multiple points along the execution path. Databases must be consulted (disk/network latency), signals must be generated (operating syste, kernal messaging latency), trade signals sent (NIC latency) and orders processed (exchange systems internal latency).

For higher frequency operations it is necessary to become intimately familiar with kernal optimisation as well as optimisation of network transmission. This is a deep area and is significantly beyond the scope of the article but if an UHFT algorithm is desired then be aware of the depth of knowledge required!

Caching is very useful in the toolkit of a quantitative trading developer. Caching refers to the concept of storing frequently accessed data in a manner which allows higher-performance access, at the expense of potential staleness of the data. A common use case occurs in web development when taking data from a disk-backed relational database and putting it into memory. Any subsequent requests for the data do not have to "hit the database" and so performance gains can be significant.

For trading situations caching can be extremely beneficial. For instance, the current state of a strategy portfolio can be stored in a cache until it is rebalanced, such that the list doesn't need to be regenerated upon each loop of the trading algorithm. Such regeneration is likely to be a high CPU or disk I/O operation.

However, caching is not without its own issues. Regeneration of cache data all at once, due to the volatilie nature of cache storage, can place significant demand on infrastructure. Another issue is dog-piling , where multiple generations of a new cache copy are carried out under extremely high load, which leads to cascade failure.

Dynamic memory allocation is an expensive operation in software execution. Thus it is imperative for higher performance trading applications to be well-aware how memory is being allocated and deallocated during program flow. Newer language standards such as Java, C# and Python all perform automatic garbage collection , which refers to deallocation of dynamically allocated memory when objects go out of scope .

Garbage collection is extremely useful during development as it reduces errors and aids readability. However, it is often sub-optimal for certain high frequency trading strategies. Custom garbage collection is often desired for these cases. In Java, for instance, by tuning the garbage collector and heap configuration, it is possible to obtain high performance for HFT strategies.

C++ doesn't provide a native garbage collector and so it is necessary to handle all memory allocation/deallocation as part of an object's implementation. While potentially error prone (potentially leading to dangling pointers) it is extremely useful to have fine-grained control of how objects appear on the heap for certain applications. When choosing a language make sure to study how the garbage collector works and whether it can be modified to optimise for a particular use case.

Many operations in algorithmic trading systems are amenable to parallelisation . This refers to the concept of carrying out multiple programmatic operations at the same time, i. e in "parallel". So-called "embarassingly parallel" algorithms include steps that can be computed fully independently of other steps. Certain statistical operations, such as Monte Carlo simulations, are a good example of embarassingly parallel algorithms as each random draw and subsequent path operation can be computed without knowledge of other paths.

Other algorithms are only partially parallelisable. Fluid dynamics simulations are such an example, where the domain of computation can be subdivided, but ultimately these domains must communicate with each other and thus the operations are partially sequential. Parallelisable algorithms are subject to Amdahl's Law, which provides a theoretical upper limit to the performance increase of a parallelised algorithm when subject to $N$ separate processes (e. g. on a CPU core or thread ).

Parallelisation has become increasingly important as a means of optimisation since processor clock-speeds have stagnated, as newer processors contain many cores with which to perform parallel calculations. The rise of consumer graphics hardware (predominently for video games) has lead to the development of Graphical Processing Units (GPUs), which contain hundreds of "cores" for highly concurrent operations. Such GPUs are now very affordable. High-level frameworks, such as Nvidia's CUDA have lead to widespread adoption in academia and finance.

Such GPU hardware is generally only suitable for the research aspect of quantitative finance, whereas other more specialised hardware (including Field-Programmable Gate Arrays - FPGAs) are used for (U)HFT. Nowadays, most modern langauges support a degree of concurrency/multithreading. Thus it is straightforward to optimise a backtester, since all calculations are generally independent of the others.

Scaling in software engineering and operations refers to the ability of the system to handle consistently increasing loads in the form of greater requests, higher processor usage and more memory allocation. In algorithmic trading a strategy is able to scale if it can accept larger quantities of capital and still produce consistent returns. The trading technology stack scales if it can endure larger trade volumes and increased latency, without bottlenecking .

While systems must be designed to scale, it is often hard to predict beforehand where a bottleneck will occur. Rigourous logging, testing, profiling and monitoring will aid greatly in allowing a system to scale. Languages themselves are often described as "unscalable". This is usually the result of misinformation, rather than hard fact. It is the total technology stack that should be ascertained for scalability, not the language. Clearly certain languages have greater performance than others in particular use cases, but one language is never "better" than another in every sense.

One means of managing scale is to separate concerns, as stated above. In order to further introduce the ability to handle "spikes" in the system (i. e. sudden volatility which triggers a raft of trades), it is useful to create a "message queuing architecture". This simply means placing a message queue system between components so that orders are "stacked up" if a certain component is unable to process many requests.

Rather than requests being lost they are simply kept in a stack until the message is handled. This is particularly useful for sending trades to an execution engine. If the engine is suffering under heavy latency then it will back up trades. A queue between the trade signal generator and the execution API will alleviate this issue at the expense of potential trade slippage. A well-respected open source message queue broker is RabbitMQ.

Hardware and Operating Systems.

The hardware running your strategy can have a significant impact on the profitability of your algorithm. This is not an issue restricted to high frequency traders either. A poor choice in hardware and operating system can lead to a machine crash or reboot at the most inopportune moment. Thus it is necessary to consider where your application will reside. The choice is generally between a personal desktop machine, a remote server, a "cloud" provider or an exchange co-located server.

Desktop machines are simple to install and administer, especially with newer user friendly operating systems such as Windows 7/8, Mac OSX and Ubuntu. Desktop systems do possess some significant drawbacks, however. The foremost is that the versions of operating systems designed for desktop machines are likely to require reboots/patching (and often at the worst of times!). They also use up more computational resources by the virtue of requiring a graphical user interface (GUI).

Utilising hardware in a home (or local office) environment can lead to internet connectivity and power uptime problems. The main benefit of a desktop system is that significant computational horsepower can be purchased for the fraction of the cost of a remote dedicated server (or cloud based system) of comparable speed.

A dedicated server or cloud-based machine, while often more expensive than a desktop option, allows for more significant redundancy infrastructure, such as automated data backups, the ability to more straightforwardly ensure uptime and remote monitoring. They are harder to administer since they require the ability to use remote login capabilities of the operating system.

In Windows this is generally via the GUI Remote Desktop Protocol (RDP). In Unix-based systems the command-line Secure SHell (SSH) is used. Unix-based server infrastructure is almost always command-line based which immediately renders GUI-based programming tools (such as MatLab or Excel) to be unusable.

A co-located server, as the phrase is used in the capital markets, is simply a dedicated server that resides within an exchange in order to reduce latency of the trading algorithm. This is absolutely necessary for certain high frequency trading strategies, which rely on low latency in order to generate alpha.

The final aspect to hardware choice and the choice of programming language is platform-independence. Is there a need for the code to run across multiple different operating systems? Is the code designed to be run on a particular type of processor architecture, such as the Intel x86/x64 or will it be possible to execute on RISC processors such as those manufactured by ARM? These issues will be highly dependent upon the frequency and type of strategy being implemented.

Resilience and Testing.

One of the best ways to lose a lot of money on algorithmic trading is to create a system with no resiliency . This refers to the durability of the sytem when subject to rare events, such as brokerage bankruptcies, sudden excess volatility, region-wide downtime for a cloud server provider or the accidental deletion of an entire trading database. Years of profits can be eliminated within seconds with a poorly-designed architecture. It is absolutely essential to consider issues such as debuggng, testing, logging, backups, high-availability and monitoring as core components of your system.

It is likely that in any reasonably complicated custom quantitative trading application at least 50% of development time will be spent on debugging, testing and maintenance.

Nearly all programming languages either ship with an associated debugger or possess well-respected third-party alternatives. In essence, a debugger allows execution of a program with insertion of arbitrary break points in the code path, which temporarily halt execution in order to investigate the state of the system. The main benefit of debugging is that it is possible to investigate the behaviour of code prior to a known crash point .

Debugging is an essential component in the toolbox for analysing programming errors. However, they are more widely used in compiled languages such as C++ or Java, as interpreted languages such as Python are often easier to debug due to fewer LOC and less verbose statements. Despite this tendency Python does ship with the pdb, which is a sophisticated debugging tool. The Microsoft Visual C++ IDE possesses extensive GUI debugging utilities, while for the command line Linux C++ programmer, the gdb debugger exists.

Testing in software development refers to the process of applying known parameters and results to specific functions, methods and objects within a codebase, in order to simulate behaviour and evaluate multiple code-paths, helping to ensure that a system behaves as it should. A more recent paradigm is known as Test Driven Development (TDD), where test code is developed against a specified interface with no implementation. Prior to the completion of the actual codebase all tests will fail. As code is written to "fill in the blanks", the tests will eventually all pass, at which point development should cease.

TDD requires extensive upfront specification design as well as a healthy degree of discipline in order to carry out successfully. In C++, Boost provides a unit testing framework. In Java, the JUnit library exists to fulfill the same purpose. Python also has the unittest module as part of the standard library. Many other languages possess unit testing frameworks and often there are multiple options.

In a production environment, sophisticated logging is absolutely essential. Logging refers to the process of outputting messages, with various degrees of severity, regarding execution behaviour of a system to a flat file or database. Logs are a "first line of attack" when hunting for unexpected program runtime behaviour. Unfortunately the shortcomings of a logging system tend only to be discovered after the fact! As with backups discussed below, a logging system should be given due consideration BEFORE a system is designed.

Both Microsoft Windows and Linux come with extensive system logging capability and programming languages tend to ship with standard logging libraries that cover most use cases. It is often wise to centralise logging information in order to analyse it at a later date, since it can often lead to ideas about improving performance or error reduction, which will almost certainly have a positive impact on your trading returns.

While logging of a system will provide information about what has transpired in the past, monitoring of an application will provide insight into what is happening right now . All aspects of the system should be considered for monitoring. System level metrics such as disk usage, available memory, network bandwidth and CPU usage provide basic load information.

Trading metrics such as abnormal prices/volume, sudden rapid drawdowns and account exposure for different sectors/markets should also be continuously monitored. Further, a threshold system should be instigated that provides notification when certain metrics are breached, elevating the notification method (, SMS, automated phone call) depending upon the severity of the metric.

System monitoring is often the domain of the system administrator or operations manager. However, as a sole trading developer, these metrics must be established as part of the larger design. Many solutions for monitoring exist: proprietary, hosted and open source, which allow extensive customisation of metrics for a particular use case.

Backups and high availability should be prime concerns of a trading system. Consider the following two questions: 1) If an entire production database of market data and trading history was deleted (without backups) how would the research and execution algorithm be affected? 2) If the trading system suffers an outage for an extended period (with open positions) how would account equity and ongoing profitability be affected? The answers to both of these questions are often sobering!

It is imperative to put in place a system for backing up data and also for testing the restoration of such data. Many individuals do not test a restore strategy. If recovery from a crash has not been tested in a safe environment, what guarantees exist that restoration will be available at the worst possible moment?

Similarly, high availability needs to be "baked in from the start". Redundant infrastructure (even at additional expense) must always be considered, as the cost of downtime is likely to far outweigh the ongoing maintenance cost of such systems. I won't delve too deeply into this topic as it is a large area, but make sure it is one of the first considerations given to your trading system.

Choosing a Language.

Considerable detail has now been provided on the various factors that arise when developing a custom high-performance algorithmic trading system. The next stage is to discuss how programming languages are generally categorised.

Type Systems.

When choosing a language for a trading stack it is necessary to consider the type system . The languages which are of interest for algorithmic trading are either statically - or dynamically-typed . A statically-typed language performs checks of the types (e. g. integers, floats, custom classes etc) during the compilation process. Such languages include C++ and Java. A dynamically-typed language performs the majority of its type-checking at runtime. Such languages include Python, Perl and JavaScript.

For a highly numerical system such as an algorithmic trading engine, type-checking at compile time can be extremely beneficial, as it can eliminate many bugs that would otherwise lead to numerical errors. However, type-checking doesn't catch everything, and this is where exception handling comes in due to the necessity of having to handle unexpected operations. 'Dynamic' languages (i. e. those that are dynamically-typed) can often lead to run-time errors that would otherwise be caught with a compilation-time type-check. For this reason, the concept of TDD (see above) and unit testing arose which, when carried out correctly, often provides more safety than compile-time checking alone.

Another benefit of statically-typed languages is that the compiler is able to make many optimisations that are otherwise unavailable to the dynamically - typed language, simply because the type (and thus memory requirements) are known at compile-time. In fact, part of the inefficiency of many dynamically-typed languages stems from the fact that certain objects must be type-inspected at run-time and this carries a performance hit. Libraries for dynamic languages, such as NumPy/SciPy alleviate this issue due to enforcing a type within arrays.

Open Source or Proprietary?

One of the biggest choices available to an algorithmic trading developer is whether to use proprietary (commercial) or open source technologies. 두 방법 모두 장단점이 있습니다. It is necessary to consider how well a language is supported, the activity of the community surrounding a language, ease of installation and maintenance, quality of the documentation and any licensing/maintenance costs.

The Microsoft stack (including Visual C++, Visual C#) and MathWorks' MatLab are two of the larger proprietary choices for developing custom algorithmic trading software. Both tools have had significant "battle testing" in the financial space, with the former making up the predominant software stack for investment banking trading infrastructure and the latter being heavily used for quantitative trading research within investment funds.

Microsoft and MathWorks both provide extensive high quality documentation for their products. Further, the communities surrounding each tool are very large with active web forums for both. The software allows cohesive integration with multiple languages such as C++, C# and VB, as well as easy linkage to other Microsoft products such as the SQL Server database via LINQ. MatLab also has many plugins/libraries (some free, some commercial) for nearly any quantitative research domain.

There are also drawbacks. With either piece of software the costs are not insignificant for a lone trader (although Microsoft does provide entry-level version of Visual Studio for free). Microsoft tools "play well" with each other, but integrate less well with external code. Visual Studio must also be executed on Microsoft Windows, which is arguably far less performant than an equivalent Linux server which is optimally tuned.

MatLab also lacks a few key plugins such as a good wrapper around the Interactive Brokers API, one of the few brokers amenable to high-performance algorithmic trading. The main issue with proprietary products is the lack of availability of the source code. This means that if ultra performance is truly required, both of these tools will be far less attractive.

Open source tools have been industry grade for sometime. Much of the alternative asset space makes extensive use of open-source Linux, MySQL/PostgreSQL, Python, R, C++ and Java in high-performance production roles. However, they are far from restricted to this domain. Python and R, in particular, contain a wealth of extensive numerical libraries for performing nearly any type of data analysis imaginable, often at execution speeds comparable to compiled languages, with certain caveats.

The main benefit of using interpreted languages is the speed of development time. Python and R require far fewer lines of code (LOC) to achieve similar functionality, principally due to the extensive libraries. Further, they often allow interactive console based development, rapidly reducing the iterative development process.

Given that time as a developer is extremely valuable, and execution speed often less so (unless in the HFT space), it is worth giving extensive consideration to an open source technology stack. Python and R possess significant development communities and are extremely well supported, due to their popularity. Documentation is excellent and bugs (at least for core libraries) remain scarce.

Open source tools often suffer from a lack of a dedicated commercial support contract and run optimally on systems with less-forgiving user interfaces. A typical Linux server (such as Ubuntu) will often be fully command-line oriented. In addition, Python and R can be slow for certain execution tasks. There are mechanisms for integrating with C++ in order to improve execution speeds, but it requires some experience in multi-language programming.

While proprietary software is not immune from dependency/versioning issues it is far less common to have to deal with incorrect library versions in such environments. Open source operating systems such as Linux can be trickier to administer.

I will venture my personal opinion here and state that I build all of my trading tools with open source technologies. In particular I use: Ubuntu, MySQL, Python, C++ and R. The maturity, community size, ability to "dig deep" if problems occur and lower total cost ownership (TCO) far outweigh the simplicity of proprietary GUIs and easier installations. Having said that, Microsoft Visual Studio (especially for C++) is a fantastic Integrated Development Environment (IDE) which I would also highly recommend.

Batteries Included?

The header of this section refers to the "out of the box" capabilities of the language - what libraries does it contain and how good are they? This is where mature languages have an advantage over newer variants. C++, Java and Python all now possess extensive libraries for network programming, HTTP, operating system interaction, GUIs, regular expressions (regex), iteration and basic algorithms.

C++ is famed for its Standard Template Library (STL) which contains a wealth of high performance data structures and algorithms "for free". Python is known for being able to communicate with nearly any other type of system/protocol (especially the web), mostly through its own standard library. R has a wealth of statistical and econometric tools built in, while MatLab is extremely optimised for any numerical linear algebra code (which can be found in portfolio optimisation and derivatives pricing, for instance).

Outside of the standard libraries, C++ makes use of the Boost library, which fills in the "missing parts" of the standard library. In fact, many parts of Boost made it into the TR1 standard and subsequently are available in the C++11 spec, including native support for lambda expressions and concurrency.

Python has the high performance NumPy/SciPy/Pandas data analysis library combination, which has gained widespread acceptance for algorithmic trading research. Further, high-performance plugins exist for access to the main relational databases, such as MySQL++ (MySQL/C++), JDBC (Java/MatLab), MySQLdb (MySQL/Python) and psychopg2 (PostgreSQL/Python). Python can even communicate with R via the RPy plugin!

An often overlooked aspect of a trading system while in the initial research and design stage is the connectivity to a broker API. Most APIs natively support C++ and Java, but some also support C# and Python, either directly or with community-provided wrapper code to the C++ APIs. In particular, Interactive Brokers can be connected to via the IBPy plugin. If high-performance is required, brokerages will support the FIX protocol.

결론.

As is now evident, the choice of programming language(s) for an algorithmic trading system is not straightforward and requires deep thought. The main considerations are performance, ease of development, resiliency and testing, separation of concerns, familiarity, maintenance, source code availability, licensing costs and maturity of libraries.

The benefit of a separated architecture is that it allows languages to be "plugged in" for different aspects of a trading stack, as and when requirements change. A trading system is an evolving tool and it is likely that any language choices will evolve along with it.

양적 거래 시작하기?

QuantStart 목록을 구독해야하는 3 가지 이유 :

1. 퀀트 트레이딩 레슨.

계량 거래를 시작하는 데 도움이되는 힌트와 팁으로 가득한 무료 10 일간 코스에 즉시 액세스 할 수 있습니다!

2. 모든 최신 내용.

매주 나는 퀀트 스타트에서 모든 활동의 포장을 보내드릴 것입니다. 그래서 당신은 결코 다시 글을 놓치지 않을 것입니다.

현실감 넘치는 퀀 트레이딩 팁.