알고리즘 트레이딩 시스템에서 가장 좋은 프로그래밍 언어?

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

우선, 알고리즘 거래 시스템의 주요 구성 요소는 연구 도구, 포트폴리오 최적화기, 리스크 관리자 및 실행 엔진과 같은 것이 고려됩니다. 그 후 다른 거래 전략과 시스템의 설계에 어떤 영향을 미치는지 조사됩니다. 특히 거래 빈도와 예상 거래량은 모두 논의됩니다.

거래 전략이 선택되면 전체 시스템을 설계해야합니다. 여기에는 하드웨어, 운영 체제 (들) 의 선택 및 드문, 잠재적으로 재앙적인 이벤트에 대한 시스템 회복력이 포함됩니다. 구조가 고려되는 동안, 연구 도구와 라이브 실행 환경 모두 성능에 적절한 관심을 기울여야합니다.

무역 체계 는 무엇 을 시도 하고 있습니까?

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

리서치는 역사적 데이터에 대한 전략 성능 평가와 관련이 있습니다. 이전 시장 데이터에 대한 거래 전략을 평가하는 과정은 백테스팅으로 알려져 있습니다. 데이터 크기와 알고리즘 복잡성은 백테스터의 계산 강도에 큰 영향을 미칩니다. CPU 속도와 동시성은 종종 연구 실행 속도를 최적화하는 데 제한 요소입니다.

신호 발생은 알고리즘에서 일련의 거래 신호를 생성하고 일반적으로 브로커십을 통해 그러한 명령을 시장에 전송하는 것과 관련이 있습니다. 특정 전략에는 높은 수준의 성능이 필요합니다. 네트워크 대역폭 및 지연 시간과 같은 I / O 문제는 종종 실행 시스템을 최적화하는 데 제한 요소입니다. 따라서 전체 시스템의 각 구성 요소에 대한 언어 선택은 상당히 다를 수 있습니다.

전략의 종류, 빈도 및 규모

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

낮은 주파수 미국 주식 전략의 기술 선택은 선물 시장에서 거래하는 높은 주파수 통계적 중재 전략과 크게 다를 것입니다. 언어를 선택하기 전에 많은 데이터 공급자가 평가되어야합니다.

공급업체와의 연결성, API 구조, 데이터의 시기적절성, 저장 요구 사항 및 공급자가 오프라인 상태가 될 때 탄력성을 고려하는 것이 필요합니다. 또한 여러 공급업체에 신속하게 액세스하는 것이 현명합니다! 다양한 도구는 모두 자체 스토리지 특이성을 가지고 있습니다. 그 예로는 주식 및 선물의 만료 날짜 (특정 한 OTC 데이터를 언급하지 않고). 이것은 플랫폼 설계에 고려되어야합니다.

전략의 빈도는 기술 스택이 어떻게 정의 될지에 대한 가장 큰 동력 중 하나가 될 가능성이 있습니다. 분별 또는 두 번째 바보다 더 자주 데이터를 사용하는 전략은 성능과 관련하여 상당한 고려가 필요합니다.

두 번째 바 (즉, 틱 데이터) 를 초과하는 전략은 주요 요구 사항으로 성능 기반의 설계로 이어집니다. 고주파 전략에는 상당한 양의 시장 데이터가 저장되고 평가되어야합니다. HDF5 또는 kdb +와 같은 소프트웨어는 이러한 역할을 위해 일반적으로 사용됩니다.

HFT 애플리케이션에 필요한 방대한 양의 데이터를 처리하기 위해서는 광범위하게 최적화된 백테스터와 실행 시스템을 사용해야 한다. C/C++ (가능한 일부 어셈블러와 함께) 는 가장 강력한 언어 후보로 보인다. 초고 주파수 전략은 거의 확실하게 FPGA, 교환 공동 위치 및 커널/네트워크 인터페이스 튜닝과 같은 사용자 지정 하드웨어가 필요할 것이다.

연구 시스템

연구 시스템은 일반적으로 인터랙티브 개발과 자동 스크립팅의 혼합을 포함합니다. 전자는 종종 비주얼 스튜디오, MatLab 또는 R 스튜디오와 같은 IDE 내에서 이루어집니다. 후자는 수많은 매개 변수 및 데이터 포인트에 대한 광범위한 수치 계산을 포함합니다. 이것은 코드를 테스트하기 위해 직접적인 환경을 제공하는 언어 선택으로 이어지지만 여러 매개 변수 차원에서 전략을 평가하는 데 충분한 성능을 제공합니다.

이 공간의 전형적인 IDE는 광범위한 디버깅 유틸리티, 코드 완료 기능 (Intellisense를 통해) 및 전체 프로젝트 스택의 간단한 개요 (ORM, LINQ 데이터베이스를 통해) 를 포함하는 Microsoft Visual C ++ / C #; 광범위한 수치 선형 대수학 및 벡터화 연산을 위해 설계된 MatLab, 그러나 대화형 콘솔 방식으로; R Studio, 완전한 IDE로 Rstatistical 언어 콘솔을 포장; Java Linux 및 C ++을위한 Eclipse IDE; 및 하나의 대화형 (콘솔) 환경에서 NumPy, SciPy, scikit-learn 및 pandas와 같은 데이터 분석 라이브러리를 포함하는 Python을위한 Enthought Canopy와 같은 반 독자적인 IDE입니다.

숫자 백테스팅을 위해 위의 모든 언어는 적합하지만 코드가 백그라운드에서 실행되기 때문에 GUI / IDE를 사용하는 것이 필요하지 않습니다. 이 단계에서 주요 고려 사항은 실행 속도입니다. 컴파일 된 언어 (C ++와 같은) 는 백테스팅 매개 변수 차원이 크면 종종 유용합니다. 그런 경우 그러한 시스템에 조심해야합니다!

파이썬과 같은 해석 언어는 종종 컴파일 된 동등한 것과 합리적인 수준의 경쟁력을 유지하기 위해 백테스팅 단계에 NumPy / panda와 같은 고성능 라이브러리를 사용합니다. 궁극적으로 백테스팅을 위해 선택한 언어는 특정 알고리즘 요구 사항뿐만 아니라 언어에서 사용할 수있는 라이브러리 범위 (아래에 더 자세히 설명합니다.) 에 의해 결정됩니다. 그러나 백테스터 및 연구 환경에 사용되는 언어는 건설 포트폴리오, 위험 관리 및 실행 구성 요소에서 사용되는 언어와 완전히 독립 할 수 있습니다.

포트폴리오 구성 및 위험 관리

포트폴리오 구축 및 위험 관리 구성 요소는 소매 알고리즘 트레이더에 의해 종종 간과됩니다. 이것은 거의 항상 실수입니다. 이러한 도구는 자본이 보존 될 메커니즘을 제공합니다. 그들은 위험 베팅의 수를 완화 할뿐만 아니라 거래 비용을 줄여 거래 자체의 분산을 최소화합니다.

이러한 구성 요소의 정교한 버전은 수익성의 품질과 일관성에 상당한 영향을 줄 수 있습니다. 포트폴리오 구축 메커니즘과 리스크 관리자가 여러 시스템을 처리하기 위해 쉽게 수정 될 수 있으므로 전략의 안정성을 만드는 것은 간단합니다. 따라서 알고리즘 거래 시스템의 설계 초기에는 필수 구성 요소로 간주되어야합니다.

포트폴리오 구성 시스템의 임무는 원하는 거래의 집합을 가져와 실제 거래의 집합을 생성하여 분산을 최소화하고, 다양한 요인 (예를 들어 부문, 자산 클래스, 변동성 등) 에 대한 노출을 유지하며 포트폴리오의 다양한 전략에 자본의 할당을 최적화하는 것입니다.

포트폴리오 구축은 종종 선형 대수학 문제 (매트릭스 인수분해) 로 줄어들며 따라서 성능은 사용 가능한 수치 선형 대수학 구현의 효과에 크게 의존합니다. 일반적인 라이브러리에는 C ++를위한 uBLAS, LAPACK 및 NAG가 포함됩니다. MatLab는 또한 광범위하게 최적화된 행렬 연산을 보유하고 있습니다. 파이썬은 그러한 계산을 위해 NumPy / SciPy를 사용합니다. 자주 재균형 된 포트폴리오는 거래 시스템을 가로막지 않기 위해 이 단계를 수행하기 위해 컴파일 된 (그리고 잘 최적화 된!) 행렬 라이브러리가 필요합니다.

리스크 관리는 알고리즘 거래 시스템의 또 다른 매우 중요한 부분이다. 리스크는 여러 가지 형태로 나타날 수 있다: 변동성 증가 (특정 전략에서 바람직하다고 볼 수 있음에도 불구하고!), 자산 클래스 간의 상관관계 증가, 상대방 채무불이행, 서버 정전, 블랙 스완 이벤트 및 거래 코드에서 발견되지 않은 버그, 몇 가지 명명하기 위해.

리스크 관리 구성 요소는 과도한 변동성과 자산 클래스 간의 상관관계의 효과와 거래 자본에 대한 그 후의 영향을 예측하기 위해 노력합니다. 종종 이것은 몬테 카를로 스트레스 테스트와 같은 통계 계산의 집합으로 줄어듭니다. 이것은 파생물 가격 엔진의 계산 요구 사항과 매우 유사하며 CPU에 묶여있을 것입니다. 이러한 시뮬레이션은 매우 병렬화 가능하며 어느 정도 문제에서 하드웨어를 던질 수 있습니다.

집행 시스템

실행 시스템의 임무는 포트폴리오 구축 및 리스크 관리 구성 요소에서 필터링 된 거래 신호를 수신하고 브로커 또는 다른 시장 접근 수단으로 전송하는 것입니다. 소매 알고리즘 거래 전략의 대다수에서는 API 또는 FIX 연결을 인터랙티브 브로커와 같은 브로커와 연결합니다. 언어를 결정할 때 주요 고려 사항은 API의 품질, API에 대한 언어 래퍼의 사용 가능성, 실행 빈도 및 예상 미끄러움입니다.

API의 품질은 API의 문서화, 제공되는 성능, 액세스 할 수있는 독립 소프트웨어가 필요한지 또는 헤드리스 방식으로 게이트웨이가 설정 될 수 있는지 (즉, GUI가 없습니다) 를 의미합니다. 인터랙티브 브로커의 경우 트레이더 워크스테이션 도구는 API에 액세스하기 위해 GUI 환경에서 실행되어야합니다. 한 번은 Amazon 클라우드 서버에 데스크톱 우분투 버전을 설치해야했습니다.

대부분의 API는 C ++ 및 / 또는 Java 인터페이스를 제공합니다. 일반적으로 C #, 파이썬, R, 엑셀 및 MatLab에 대한 언어 특정 래퍼를 개발하는 것은 커뮤니티에 달려 있습니다. 추가 플러그인 (특히 API 래퍼) 을 사용하는 모든 추가 플러그인 (특히 API 래퍼) 에 버그가 시스템에 침투할 가능성이 있음을 유의하십시오. 항상 이러한 종류의 플러그인을 테스트하고 적극적으로 유지 관리하도록하십시오. 가치있는 측정은 최근 몇 달 동안 코드베이스에 얼마나 많은 새로운 업데이트가 있었는지 보는 것입니다.

실행 주파수는 실행 알고리즘에서 가장 중요합니다. 수백 개의 주문이 매 분에 전송 될 수 있으므로 성능이 중요합니다. 성능이 좋지 않은 실행 시스템을 통해 미끄러짐이 발생하여 수익성에 극적인 영향을 미칠 것입니다.

C++/Java와 같은 정적 타입 언어 (아래 참조) 는 일반적으로 실행에 최적이지만 개발 시간, 테스트 및 유지보수 용이성에 대한 타협이 있습니다. 파이썬과 페럴과 같은 동적 타입 언어는 일반적으로 충분히 빠르다. 항상 구성 요소가 모듈 방식으로 설계되었는지 확인하십시오.

건축 계획 및 개발 과정

상거래 시스템의 구성 요소, 그 빈도 및 부피 요구 사항은 위에서 논의되었지만 시스템 인프라는 아직 다루어지지 않았습니다. 소매 거래자 또는 작은 펀드에서 일하는 사람들은 아마도 많은 모자를 착용 할 것입니다. 알파 모델, 리스크 관리 및 실행 매개 변수 및 시스템의 최종 구현을 다루어야합니다. 특정 언어에 깊이 들어가기 전에 최적의 시스템 아키텍처의 설계가 논의 될 것입니다.

염려 를 분리 함

시작부터 결정해야 할 가장 중요한 결정 중 하나는 거래 시스템의 관심사를 어떻게 분리해야 하는가입니다. 소프트웨어 개발에서 이것은 본질적으로 거래 시스템의 다양한 측면을 분리 된 모듈 구성 요소로 어떻게 분리해야하는지 의미합니다.

각 컴포넌트에서 인터페이스를 노출함으로써 외부 의존성 코드를 수정하지 않고 성능, 신뢰성 또는 유지보수를 지원하는 다른 버전으로 시스템의 일부를 쉽게 교환 할 수 있습니다. 이것은 그러한 시스템에 대한 "최고의 관행"입니다. 낮은 주파수에서의 전략에는 그러한 관행이 권장됩니다. 초고 주파수 거래에 대한 규칙서는 더욱 높은 성능을 위해 시스템을 조정하는 비용으로 무시해야합니다. 더 단단하게 결합 된 시스템이 바람직할 수 있습니다.

알고리즘 거래 시스템의 구성 요소 지도를 만드는 것은 그 자체로 기사 가치가 있습니다. 그러나 최적의 접근법은 역사적 및 실시간 시장 데이터 입력, 데이터 저장, 데이터 액세스 API, 백테스터, 전략 매개 변수, 포트폴리오 구축, 위험 관리 및 자동화 실행 시스템에 대한 별도의 구성 요소가 있는지 확인하는 것입니다.

예를 들어, 사용 중인 데이터 스토어가 현재 낮은 성능을 보인다면, 심지어 상당한 수준의 최적화에서도 데이터 섭취 또는 데이터 액세스 API에 최소한의 재작업으로 교체 할 수 있습니다. 백테스터와 후속 구성 요소에 관해서는 차이가 없습니다.

분리된 컴포넌트의 또 다른 장점은 전체 시스템에서 다양한 프로그래밍 언어를 사용할 수 있다는 것입니다. 컴포넌트의 통신 방법이 언어 독립적이라면 단일 언어로 제한 할 필요가 없습니다. TCP/IP, ZeroMQ 또는 다른 언어 독립적 인 프로토콜을 통해 통신하는 경우이 될 것입니다.

구체적인 예로, 수 크루싱 성능을 위해 C++로 작성된 백테스팅 시스템의 경우를 고려하면 포트폴리오 관리자와 실행 시스템은 SciPy와 IBPy를 사용하여 파이썬으로 작성됩니다.

성능 고려

성능은 대부분의 거래 전략에서 중요한 고려 사항입니다. 높은 주파수 전략에서는 가장 중요한 요소입니다. 성능은 알고리즘 실행 속도, 네트워크 지연, 대역폭, 데이터 I / O, 동시 / 병렬성 및 확장과 같은 광범위한 문제를 다루고 있습니다. 이 분야 각각은 큰 교과서에 의해 개별적으로 다루어집니다. 따라서이 기사는 각 주제의 표면을 긁을 것입니다. 건축과 언어 선택은 이제 성능에 대한 영향 측면에서 논의 될 것입니다.

컴퓨터 과학의 아버지 중 한 명인 도널드 의 주장에 따르면, "이미 최적화는 모든 악의 근원이다". 이것은 거의 항상 사실입니다. 고주파 거래 알고리즘을 구축하는 경우를 제외하고! 낮은 주파수 전략에 관심이있는 사람들에게 일반적인 접근법은 가능한 가장 간단한 방법으로 시스템을 구축하고 병목이 나타나기 시작하면 최적화하는 것입니다.

프로파일링 도구는 병목이 발생하는 곳을 결정하는 데 사용됩니다. 프로파일은 MS 윈도우 또는 리눅스 환경에서 위에 나열된 모든 요인에 대해 만들 수 있습니다. 이를 위해 많은 운영 체제 및 언어 도구가 있으며 제3자 유틸리티도 있습니다. 언어 선택은 이제 성능의 맥락에서 논의 될 것입니다.

C++, Java, Python, R 및 MatLab 모두 기본 데이터 구조와 알고리즘 작업을 위한 고성능 라이브러리를 포함하고 있다. C++는 표준 템플릿 라이브러리를 포함하고 있으며, 파이썬은 NumPy/SciPy를 포함하고 있다. 이러한 라이브러리에서 일반적인 수학 작업이 발견되며 새로운 구현을 작성하는 것은 거의 유익하지 않다.

한 가지 예외는 고도로 사용자 정의 하드웨어 아키텍처가 필요하고 알고리즘이 독점 확장 프로그램을 광범위하게 사용하는 경우입니다. 그러나 종종 바퀴의 재발견은 거래 인프라의 다른 부분을 개발하고 최적화하는 데 더 잘 사용할 수 있는 시간을 낭비합니다. 개발 시간은 특히 단독 개발자의 맥락에서 매우 귀중합니다.

지연은 종종 실행 시스템의 문제입니다. 연구 도구가 일반적으로 동일한 기계에 위치하고 있기 때문입니다. 전자의 경우, 실행 경로에서 여러 지점에서 지연이 발생할 수 있습니다. 데이터베이스 (디스크 / 네트워크 지연), 신호가 생성되어야합니다 (운영 시스템, 커널 메시징 지연), 전송 된 거래 신호 (NIC 지연) 및 처리 된 주문 (교환 시스템 내부 지연).

더 높은 주파수 작업을 위해 커널 최적화와 네트워크 전송 최적화에 친숙하게 익숙해질 필요가 있습니다. 이것은 깊은 영역이며 문서의 범위를 훨씬 뛰어넘습니다. 그러나 UHFT 알고리즘이 원하는 경우 필요한 지식의 깊이를 인식하십시오!

캐싱은 양적 거래 개발자의 툴킷에서 매우 유용합니다. 캐싱은 데이터의 잠재적인 정체성을 희생하여 더 높은 성능의 액세스를 허용하는 방식으로 자주 액세스되는 데이터를 저장하는 개념을 의미합니다. 디스크 지원 관계 데이터베이스에서 데이터를 가져다가 메모리에 넣을 때 웹 개발에서 일반적인 사용 사례가 발생합니다. 데이터에 대한 후속 요청은 데이터베이스에 도달하지 않아서 성능 향상이 중요 할 수 있습니다.

거래 상황에서는 캐시가 매우 유용할 수 있다. 예를 들어, 전략 포트폴리오의 현재 상태는 재균형될 때까지 캐시에 저장될 수 있어, 거래 알고리즘의 각 루프에 대해 목록을 재생할 필요가 없다. 이러한 재생은 높은 CPU 또는 디스크 I/O 동작일 가능성이 있다.

그러나 캐시는 자체적인 문제도 없습니다. 캐시 저장소의 휘발성 특성으로 인해 캐시 데이터의 재생은 동시에 인프라에 상당한 수요를 줄 수 있습니다. 또 다른 문제는 새 캐시 복사본의 여러 세대가 매우 높은 부하로 수행되며 캐스케이드 실패로 이어집니다.

동적 메모리 할당은 소프트웨어 실행에서 비용이 많이 드는 작업이다. 따라서 높은 성능 거래 응용 프로그램이 프로그램 흐름 중에 메모리가 어떻게 할당되고 배분되는지 잘 아는 것이 필수적입니다. 자바, C # 및 파이썬과 같은 최신 언어 표준은 모두 자동 쓰레기 수집을 수행합니다. 이는 객체가 범위를 벗어날 때 동적으로 배분된 메모리의 배분을 의미합니다.

쓰레기 수집은 오류를 줄이고 가독성을 높이기 때문에 개발 과정에서 매우 유용합니다. 그러나 특정 고주파 거래 전략에는 종종 최적의 수준이 아닙니다. 이러한 경우에도 사용자 지정 쓰레기 수집이 종종 바람직합니다. 예를 들어 자바에서는 쓰레기 수집기와 힙 구성을 조정하여 HFT 전략에 높은 성능을 얻을 수 있습니다.

C++는 네이티브 쓰레기 수집기를 제공하지 않으므로 객체 구현의 일부로 모든 메모리 할당 / 할당을 처리해야합니다. 잠재적으로 오류가 발생할 수 있지만 특정 응용 프로그램에 대상이 힙에 어떻게 나타나는지 정밀하게 제어하는 것이 매우 유용합니다. 언어를 선택할 때 쓰레기 수집기가 어떻게 작동하는지 연구하고 특정 사용 사례에 최적화 할 수 있는지 수정 할 수 있는지 확인하십시오.

알고리즘 트레이딩 시스템에서의 많은 연산은 병렬화될 수 있다. 이것은 동시에 여러 개의 프로그래밍 연산을 수행하는 개념을 가리킨다. 즉, 병렬. 이른바 embarrassingly parallel 알고리즘에는 다른 단계로부터 완전히 독립적으로 계산할 수 있는 단계가 포함된다. 몬테카를로 시뮬레이션과 같은 특정 통계 연산은 다른 경로에 대한 지식 없이 각각의 무작위 추첨과 후속 경로 연산이 계산될 수 있기 때문에 embarrassingly parallel 알고리즘의 좋은 예이다.

다른 알고리즘은 부분적으로만 병렬화 될 수 있다. 유체역학 시뮬레이션은 계산 영역을 분할할 수 있는 그러한 예이지만 궁극적으로 이러한 영역은 서로 통신해야 하며 따라서 연산은 부분적으로 순차적이다. 병렬화 가능한 알고리즘은 Amdahl의 법칙에 의해 적용되며, 이는 NN 별도의 프로세스에 (예를 들어 CPU 코어 또는 스레드에서) 노출될 때 병렬화 된 알고리즘의 성능 증가에 이론적 상한 한계를 제공한다.

병렬화는 프로세서 클럭 속도가 침체되면서 최적화 수단으로 점점 더 중요해졌습니다. 새로운 프로세서는 병렬 계산을 수행 할 수있는 많은 코어를 포함하고 있기 때문입니다. 소비자 그래픽 하드웨어 (주로 비디오 게임) 의 상승은 매우 동시 작업을 위해 수백 개의 코어를 포함하는 그래픽 처리 장치 (GPU) 의 개발로 이어졌습니다. 이러한 GPU는 이제 매우 저렴합니다. Nvidia의 CUDA와 같은 높은 수준의 프레임워크는 학계와 금융 분야에서 널리 채택되었습니다.

이러한 GPU 하드웨어는 일반적으로 양적 금융의 연구 측면에만 적합하며, 다른 더 전문적인 하드웨어 (현장 프로그래밍 가능한 게이트 어레이 (FPGAs) 를 포함하여) 는 (U) HFT를 위해 사용됩니다. 오늘날 대부분의 현대 랭게이지는 일정 수준의 동시 / 멀티 스레딩을 지원합니다. 따라서 모든 계산이 일반적으로 다른 것으로 독립되기 때문에 백테스터를 최적화하는 것이 간단합니다.

소프트웨어 엔지니어링 및 운영에서 확장성은 더 큰 요청, 더 높은 프로세서 사용 및 더 많은 메모리 할당의 형태로 지속적으로 증가하는 부하를 처리하는 시스템의 능력을 의미합니다. 알고리즘 거래에서 전략은 더 많은 자본을 수용하고 여전히 일관된 수익을 창출 할 수 있다면 확장 할 수 있습니다. 거래 기술은 더 큰 거래량과 증가된 지연 시간을 견딜 수 있다면 병목없이 확장됩니다.

시스템들은 확장할 수 있도록 설계되어야 하지만, 병목이 발생할 곳을 미리 예측하는 것은 종종 어렵다. 엄격한 로깅, 테스트, 프로파일링 및 모니터링은 시스템을 확장할 수 있도록 크게 도움이 될 것이다. 언어 자체는 종종 "무 확장성"으로 묘사된다. 이것은 일반적으로 단단한 사실보다는 잘못된 정보의 결과이다. 확장성을 확인해야 하는 것은 언어가 아니라 전체 기술 스택이다. 분명히 특정 언어는 특정 사용 사례에서 다른 언어보다 더 높은 성능을 가지고 있지만, 한 언어는 모든 의미에서 다른 언어보다 결코 "더 나은"가 아니다.

규모를 관리하는 한 가지 방법은 위에서 언급했듯이 관심사를 분리하는 것입니다. 시스템에서 스파이크 (즉, 거래의 무리를 유발하는 갑작스러운 변동성) 를 처리 할 수있는 능력을 추가로 도입하기 위해 메시지 큐 아키텍처 (message queuing architecture) 를 만드는 것이 유용합니다. 이것은 단순히 구성 요소들 사이에 메시지 큐 시스템을 배치하여 특정 구성 요소가 많은 요청을 처리할 수 없다면 주문이 더더 쌓여있는 것을 의미합니다.

요청이 손실되는 대신 메시지가 처리 될 때까지 단순히 스택에 보관됩니다. 이것은 특히 실행 엔진에 거래를 보내는 데 유용합니다. 엔진이 무거운 지연 상태에서 고통받는 경우 거래를 백업합니다. 무역 신호 생성기와 실행 API 사이의 대기열은 잠재적 인 거래 미끄러짐의 희생으로이 문제를 완화합니다. 존경받는 오픈 소스 메시지 대기열 브로커는 RabbitMQ입니다.

하드웨어 및 운영 체제

당신의 전략을 실행하는 하드웨어는 당신의 알고리즘의 수익성에 상당한 영향을 미칠 수 있다. 이것은 고주파 트레이더에 한정된 문제가 아니다. 하드웨어와 운영 체제에서 잘못된 선택은 가장 불리한 순간에 기계 충돌 또는 재부팅으로 이어질 수 있다. 따라서 당신의 응용 프로그램이 어디에 거주할지 고려할 필요가 있다. 선택은 일반적으로 개인 데스크톱 기계, 원격 서버, 클라우드 제공자 또는 교환 공동 위치 서버 사이에서이다.

데스크톱 기계는 설치 및 관리가 간단하며, 특히 윈도우 7/8, 맥 OSX 및 우분투와 같은 최신 사용자 친화적인 운영 체제와 함께. 데스크톱 시스템은 몇 가지 중요한 단점을 가지고 있습니다. 그러나 가장 중요한 것은 데스크톱 기계에 설계된 운영 체제의 버전은 재부팅 / 패치를 필요로 할 가능성이 높다는 것입니다.

가정 (또는 로컬 오피스) 환경에서 하드웨어를 사용하는 것은 인터넷 연결 및 전력 가동 시간 문제로 이어질 수 있습니다. 데스크톱 시스템의 주요 장점은 비교 가능한 속도의 원격 전용 서버 (또는 클라우드 기반 시스템) 의 비용의 일부에 상당한 컴퓨팅 마력 구매가 가능하다는 것입니다.

전용 서버 또는 클라우드 기반 기계는 데스크톱 옵션보다 종종 더 비싸지만 자동 데이터 백업, 더 직접적으로 가동 시간 및 원격 모니터링을 보장 할 수있는 능력과 같은 더 중요한冗余 인프라를 허용합니다. 운영 체제의 원격 로그인 기능을 사용할 수있는 능력이 필요하기 때문에 관리하기가 더 어렵습니다.

윈도우에서는 일반적으로 GUI 원격 데스크톱 프로토콜 (RDP) 을 통해 수행된다. 유닉스 기반 시스템에서는 명령 줄 보안 셸 (SSH) 을 사용한다. 유닉스 기반 서버 인프라는 거의 항상 명령 줄 기반이며 즉시 GUI 기반 프로그래밍 도구 (MatLab 또는 Excel와 같은) 를 사용할 수 없게 만든다.

공동 위치 서버는 자본 시장에서 사용되는 표현으로 거래 알고리즘의 지연 시간을 줄이기 위해 거래소 내에 위치한 전용 서버입니다. 알파를 생성하기 위해 낮은 지연에 의존하는 특정 고주파 거래 전략에 절대적으로 필요합니다.

하드웨어 선택과 프로그래밍 언어 선택의 마지막 측면은 플랫폼 독립성입니다. 코드가 여러 다른 운영 체제에서 실행될 필요가 있습니까? 코드는 인텔 x86/x64과 같은 특정 유형의 프로세서 아키텍처에서 실행되도록 설계되었습니까? 또는 ARM에서 제조한 RISC 프로세서에서 실행될 수 있습니까? 이러한 문제는 구현되는 전략의 빈도와 유형에 크게 의존 할 것입니다.

회복력 과 시험

알고리즘 거래에서 많은 돈을 잃는 가장 좋은 방법 중 하나는 탄력성이없는 시스템을 만드는 것입니다. 이것은 중개사 파산, 갑작스러운 과도한 변동성, 클라우드 서버 공급자의 지역 전체 다운타임 또는 전체 거래 데이터베이스의 실수 삭제와 같은 드문 사건에 노출되었을 때 시스템의 내구성을 의미합니다. 잘못 설계된 아키텍처로 몇 초 이내에 수익을 제거 할 수 있습니다. 디버깅, 테스트, 로깅, 백업, 높은 가용성 및 모니터링과 같은 문제를 시스템의 핵심 구성 요소로 고려하는 것이 절대적으로 중요합니다.

합리적으로 복잡한 사용자 지정 양적 거래 응용 프로그램에서 개발 시간의 적어도 50%가 디버깅, 테스트 및 유지보수에 소비 될 가능성이 있습니다.

거의 모든 프로그래밍 언어는 연관된 디버거를 탑재하거나 존경받는 타사 대안을 보유하고 있습니다. 본질적으로 디버거는 코드 경로에 임의의 브레이크 포인트를 삽입하여 프로그램을 실행할 수 있습니다. 이는 시스템의 상태를 조사하기 위해 임시로 실행을 중지합니다. 디버깅의 주요 장점은 알려진 충돌 지점 이전에 코드의 행동을 조사 할 수 있다는 것입니다.

디버깅은 프로그래밍 오류를 분석하는 도구 상자에 필수적인 구성 요소입니다. 그러나 C ++ 또는 Java와 같은 컴파일 된 언어에서 더 널리 사용됩니다. 파이썬과 같은 해석 된 언어는 LOC가 적고 말투가 덜하기 때문에 종종 더 쉽게 디버깅 할 수 있습니다. 이러한 경향에도 불구하고 파이썬은 정교한 디버깅 도구인 pdb와 함께 배송됩니다. 마이크로소프트 비주얼 C ++ IDE는 광범위한 GUI 디버깅 유틸리티를 보유하고 있으며, 명령 줄 리눅스 C ++ 프로그래머에게는 gdb 디버거가 있습니다.

소프트웨어 개발에서 테스트는 동작을 시뮬레이션하고 여러 코드 경로를 평가하기 위해 코드베이스 내의 특정 기능, 방법 및 객체에 알려진 매개 변수 및 결과를 적용하는 과정을 의미합니다. 시스템에서 동작이 올바르게 이루어지는 것을 보장하는 데 도움이됩니다. 더 최근의 패러다임은 테스트 구동 개발 (TDD) 으로 알려져 있으며, 테스트 코드가 구현되지 않은 지정된 인터페이스에 대해 개발됩니다. 실제 코드베이스가 완료되기 전에 모든 테스트가 실패합니다. 코드가 공백을 채우기 위해 작성됨에 따라 테스트는 결국 모두 통과되며 그 시점에서 개발이 중단되어야합니다.

TDD는 성공적으로 수행하기 위해서는 광범위한 초기 사양 설계와 건강한 수준의 규율이 필요합니다. C ++에서 Boost는 단위 테스트 프레임워크를 제공합니다. 자바에서는 동일한 목적을 달성하기 위해 JUnit 라이브러리가 있습니다. 파이썬은 표준 라이브러리의 일부로 unittest 모듈을 가지고 있습니다. 다른 많은 언어는 단위 테스트 프레임워크를 보유하고 있으며 종종 여러 옵션이 있습니다.

생산 환경에서 정교한 로깅은 절대적으로 필수적입니다. 로깅은 평면 파일 또는 데이터베이스에 시스템의 실행 행동에 관한 다양한 정도의 심각성을 가진 메시지를 출력하는 과정을 의미합니다. 로그는 예상치 못한 프로그램 실행 시간 행동을 사냥 할 때 공격의 첫 번째 라인입니다. 불행히도 로깅 시스템의 결함은 사실 후에만 발견되는 경향이 있습니다. 아래에서 논의 된 백업과 마찬가지로 로깅 시스템은 시스템이 설계되기 전에 적절한 고려를 받아야합니다.

마이크로소프트 윈도우와 리눅스 모두 광범위한 시스템 로깅 기능과 함께 제공되며 프로그래밍 언어는 대부분의 사용 사례를 다루는 표준 로깅 라이브러리와 함께 제공되는 경향이 있습니다. 이는 종종 성능 향상 또는 오류 감소에 대한 아이디어를 초래할 수 있기 때문에 나중에 분석하기 위해 로깅 정보를 중앙 집중시키는 것이 현명합니다. 이는 거의 확실히 거래 수익에 긍정적 인 영향을 줄 것입니다.

시스템 로깅은 과거에 일어난 일에 대한 정보를 제공하지만, 애플리케이션의 모니터링은 지금 무슨 일이 일어나고 있는지에 대한 통찰력을 제공 할 것입니다. 모니터링을 위해 시스템의 모든 측면을 고려해야합니다. 디스크 사용량, 사용 가능한 메모리, 네트워크 대역폭 및 CPU 사용량과 같은 시스템 수준의 메트릭은 기본 부하 정보를 제공합니다.

비정상적 인 가격/용량, 갑작스러운 급속한 인출 및 각종 분야/시장에서의 계정 노출과 같은 거래 메트릭 또한 지속적으로 모니터링되어야 합니다. 또한 특정 메트릭이 위반되면 알림을 제공하는 임계 시스템을 도입해야 하며, 메트릭의 심각성에 따라 알림 방법 (e-mail, SMS, 자동 전화) 을 높여야 합니다.

시스템 모니터링은 종종 시스템 관리자 또는 운영 관리자의 영역입니다. 그러나, 단일 거래 개발자로서, 이러한 메트릭은 더 큰 설계의 일부로 설정되어야합니다. 모니터링에 대한 많은 솔루션이 있습니다: 독점, 호스팅 및 오픈 소스, 특정 사용 사례에 대한 메트릭의 광범위한 사용자 정의를 허용합니다.

백업 및 높은 가용성은 거래 시스템의 주요 관심사가어야 합니다. 다음 두 가지 질문을 고려하십시오: 1) 시장 데이터 및 거래 역사의 전체 생산 데이터베이스가 삭제되면 (백업없이) 연구 및 실행 알고리즘이 어떻게 영향을 받습니까? 2) 거래 시스템이 장기간 중단되면 (열린 위치와 함께) 계정 자금과 지속적인 수익성이 어떻게 영향을 받습니까? 이 두 가지 질문에 대한 답은 종종 숙고적입니다!

데이터 백업 및 데이터 복원을 테스트하는 시스템을 구축하는 것이 필수적입니다. 많은 개인이 복원 전략을 테스트하지 않습니다. 안전 환경에서 충돌 후 복구가 테스트되지 않으면 최악의 순간에 복원이 가능할 것이라는 보장은 무엇입니까?

마찬가지로, 높은 가용성은 처음부터 baked in 해야 합니다. 과잉 인프라 (또한 추가 비용으로) 는 항상 고려되어야 합니다, 다운타임의 비용은 이러한 시스템의 지속적인 유지 보수 비용을 훨씬 초과 할 가능성이 있기 때문에. 나는이 주제에 너무 깊이 들어가지 않을 것입니다. 그것은 큰 영역이기 때문에, 그러나 귀하의 거래 시스템에 주어진 첫 번째 고려 사항 중 하나임을 확인하십시오.

언어 선택

이제 사용자 지정 고성능 알고리즘 거래 시스템을 개발할 때 발생하는 다양한 요소에 대해 상당한 세부 사항이 제공되었습니다. 다음 단계는 프로그래밍 언어가 일반적으로 분류되는 방법에 대해 논의하는 것입니다.

타입 시스템

거래 스택을 위한 언어를 선택할 때 타입 시스템을 고려할 필요가 있다. 알고리즘 트레이딩에 관심 있는 언어는 정적 또는 동적 타입이다. 정적 타입 언어는 컴파일 과정에서 타입의 검사 (예를 들어 정수, 플로이트, 사용자 정의 클래스 등) 를 수행한다. 이러한 언어에는 C++와 자바가 포함된다. 동적 타입 언어는 런타임에서 대부분의 타입 검사를 수행한다. 이러한 언어는 파이썬, 펄 및 자바스크립트를 포함한다.

알고리즘 트레이딩 엔진과 같은 매우 수치적인 시스템에서는 컴파일 시간에 타입 검사가 매우 유용할 수 있는데, 이는 다른 경우 수치 오류로 이어질 수 있는 많은 버그를 제거할 수 있기 때문이다. 그러나 타입 검사는 모든 것을 포착하지 않으며, 예상치 못한 작업을 처리해야 하는 필요성 때문에 예외 처리가 필요한 부분이다. 동적 언어 (즉 동적으로 타입이 된 언어) 는 종종 컴파일 타임 타입 검사로 포착 될 실행 시간 오류로 이어질 수 있다. 이러한 이유로, TDD (위 참조) 및 단위 테스트의 개념이 발생했으며, 올바르게 수행되면 컴파일 타임 검사만으로보다 더 많은 안전을 제공합니다.

정적 타입 언어의 또 다른 장점은 컴파일러가 단순히 타입 (그리고 따라서 메모리 요구 사항) 이 컴파일 시간에 알려져 있기 때문에 동적 타입 언어에 사용할 수 없는 많은 최적화를 할 수 있다는 것입니다. 실제로 많은 동적 타입 언어의 비효율성은 특정 객체가 실행 시간에 타입 검사되어야한다는 사실에서 비롯되며 이는 성능 타격을 가져옵니다. NumPy/SciPy와 같은 동적 언어의 라이브러리는 배열 내에서 타입을 강제함으로써이 문제를 완화합니다.

오픈 소스 또는 사유?

알고리즘 트레이딩 개발자에게 제공되는 가장 큰 선택 중 하나는 독점 (상업) 또는 오픈 소스 기술을 사용하는지 여부입니다. 두 접근 방식 모두에 장단점이 있습니다. 언어의 지원 정도, 언어를 둘러싼 커뮤니티의 활동, 설치 및 유지 보수의 편의성, 문서의 품질 및 라이선스 / 유지 보수 비용을 고려해야합니다.

마이크로소프트.NET 스택 (비주얼 C++, 비주얼 C# 포함) 과 MathWorks MatLab은 사용자 정의 알고리즘 거래 소프트웨어를 개발하는 두 가지 더 큰 독점 선택입니다. 두 도구 모두 금융 공간에서 중요한 "전투 테스트"를 수행했으며, 전자는 투자 은행 거래 인프라를위한 지배적 인 소프트웨어 스택을 구성하고 후자는 투자 펀드 내에서 양적 거래 연구에 많이 사용됩니다.

마이크로소프트와 매스워크스는 모두 각 제품에 대한 광범위한 고품질 문서를 제공합니다. 또한 각 도구를 둘러싼 커뮤니티는 두 가지에 대한 활성 웹 포럼으로 매우 크습니다..NET 소프트웨어는 C ++, C # 및 VB와 같은 여러 언어와 연계된 통합을 허용하며 LINQ를 통해 SQL 서버 데이터베이스와 같은 다른 마이크로소프트 제품과 쉽게 연결됩니다. 매트랩은 또한 거의 모든 양적 연구 도메인에 대한 많은 플러그인 / 라이브러리 (어떤 무료, 어떤 상업적) 를 보유하고 있습니다.

또한 단점도 있다. 소프트웨어의 어느 하나와 함께 비용은 단독 거래자에게는 중요하지 않다 (마이크로소프트는 비주얼 스튜디오의 엔트리 레벨 버전을 무료로 제공합니다). 마이크로소프트 도구는 서로 잘 하지만 외부 코드와 잘 통합되지 않습니다. 비주얼 스튜디오는 또한 마이크로소프트 윈도우에서 실행되어야하며, 이는 최적의 튜닝을 가진 동등한 리눅스 서버보다 훨씬 낮은 성능이라고 할 수 있습니다.

매트랩은 또한 높은 성능의 알고리즘 거래에 적합한 몇 안 되는 중개 업체 중 하나인 인터랙티브 브로커스 API를 둘러싼 좋은 래퍼와 같은 몇 가지 주요 플러그인이 부족합니다. 독점 제품과의 주요 문제는 소스 코드의 가용성 부족입니다. 이것은 초고 성능이 정말로 필요한 경우 두 도구 모두 훨씬 덜 매력적이라는 것을 의미합니다.

오픈 소스 툴은 오랫동안 업계 수준에 속해있다. 대체 자산 공간의 대부분은 오픈 소스 리눅스, MySQL/PostgreSQL, 파이썬, R, C++ 및 자바를 고성능 생산 역할에서 광범위하게 사용합니다. 그러나, 그들은이 영역에 국한되는 것은 아닙니다. 특히 파이썬과 R에는 상상할 수있는 거의 모든 유형의 데이터 분석을 수행하기 위해 풍부한 수치 라이브러리가 포함되어 있으며, 종종 컴파일 된 언어와 비교 가능한 실행 속도에 따라 특정 경고가 있습니다.

해석 언어의 주요 장점은 개발 시간의 속도입니다. 파이썬과 R는 광범위한 라이브러리 때문에 유사한 기능을 달성하기 위해 훨씬 적은 코드 라인 (LOC) 을 필요로합니다. 또한, 그들은 종종 상호 작용 콘솔 기반 개발을 허용하여 반복 개발 프로세스를 빠르게 줄입니다.

개발자로서의 시간은 매우 가치 있고 실행 속도는 종종 그렇지 않다는 점을 감안하면 (HFT 공간에서 제외하면) 오픈 소스 기술 스택에 광범위한 고려를 할 가치가 있습니다. 파이썬과 R는 상당한 개발 커뮤니티를 보유하고 있으며 인기에 따라 매우 잘 지원됩니다. 문서화가 훌륭하고 버그 (적어도 코어 라이브러리) 는 희귀합니다.

오픈 소스 도구는 종종 전용 상업 지원 계약의 부족으로 고통 받고 덜 용납적인 사용자 인터페이스가있는 시스템에서 최적의 실행을합니다. 전형적인 리눅스 서버 (우분투와 같은) 는 종종 완전히 명령 줄 지향적입니다. 또한 파이썬과 R는 특정 실행 작업에 느릴 수 있습니다. 실행 속도를 향상시키기 위해 C ++와 통합하는 메커니즘이 있지만 여러 언어 프로그래밍에 대한 경험이 필요합니다.

독점 소프트웨어는 의존성/버전화 문제로부터 자유롭지 않지만, 그러한 환경에서 잘못된 라이브러리 버전을 다루어야 하는 것은 훨씬 덜 일반적입니다. 리눅스 같은 오픈 소스 운영 체제는 관리하기가 더 어려울 수 있습니다.

나는 여기에 내 개인적인 의견을 모험하고 내가 오픈 소스 기술로 내 모든 거래 도구를 구축한다고 말할 것입니다. 특히 나는 사용: 우분투, MySQL, 파이썬, C ++ 및 R. 성숙, 커뮤니티 크기, 문제가 발생하면 깊이 파는 능력 및 낮은 총 비용 소유 (TCO) 는 독점적인 GUI의 단순성과 더 쉬운 설치보다 훨씬 더 중요합니다. 그런 것을 말하면서, 마이크로소프트 비주얼 스튜디오 (특히 C ++) 는 환상적인 통합 개발 환경 (IDE) 이며, 나는 또한 강력히 추천 할 것입니다.

배터리 포함?

이 섹션의 헤더는 언어의 out of the box 기능을 가리킨다 - 어떤 라이브러리가 포함되어 있으며 얼마나 좋은가? 이것은 성숙한 언어가 더 새로운 변종에 비해 장점이있는 곳입니다. C++, Java 및 파이썬 모두 이제 네트워크 프로그래밍, HTTP, 운영 체제 상호 작용, GUI, 정규 표현식 (regex), 반복 및 기본 알고리즘에 대한 광범위한 라이브러리를 보유하고 있습니다.

C++는 많은 고성능 데이터 구조와 알고리즘을 무료로 포함하고 있는 표준 템플릿 라이브러리로 유명하다. 파이썬은 대부분 자체 표준 라이브러리를 통해 거의 다른 유형의 시스템/프로토콜 (특히 웹) 과 통신할 수 있는 것으로 알려져 있다. R에는 수많은 통계 및 경제학 도구가 내장되어 있으며, MatLab는 모든 수치 선형 대수학 코드 (예를 들어 포트폴리오 최적화 및 파생물 가격 결정에서 찾을 수 있다) 에 대해 극도로 최적화되어 있다.

표준 라이브러리 이외에도 C++는 Boost 라이브러리를 사용하며, 이는 표준 라이브러리의 부족 부분을 채우게 된다. 사실, Boost의 많은 부분들이 TR1 표준으로 만들어졌고, Lambda 표현식 및 동시성 등의 네이티브 지원을 포함하여 C++11 스펙에서 사용할 수 있다.

파이썬은 고성능 NumPy/SciPy/Pandas 데이터 분석 라이브러리 조합을 가지고 있으며, 알고리즘 거래 연구에 널리 인정받았습니다. 또한 MySQL++ (MySQL/C++), JDBC (Java/MatLab), MySQLdb (MySQL/Python) 및 psychopg2 (PostgreSQL/Python) 와 같은 주요 관계 데이터베이스에 액세스하기 위해 고성능 플러그인이 있습니다. 파이썬은 RPy 플러그인을 통해 R와 통신 할 수도 있습니다!

초기 연구 및 설계 단계에서 거래 시스템의 종종 간과되는 측면은 브로커 API와의 연결입니다. 대부분의 API는 C ++ 및 자바를 원생적으로 지원하지만 일부는 직접 또는 C ++ API에 커뮤니티가 제공하는 래퍼 코드로 C # 및 파이썬을 지원합니다. 특히 IBPy 플러그인을 통해 인터랙티브 브로커에 연결할 수 있습니다. 높은 성능이 필요한 경우 브로커는 FIX 프로토콜을 지원합니다.

결론

이제 명백한 것처럼, 알고리즘 거래 시스템에 대한 프로그래밍 언어의 선택은 간단하지 않으며 깊은 생각을 필요로합니다. 주요 고려 사항은 성능, 개발 용이성, 탄력성 및 테스트, 관심의 분리, 친밀성, 유지 보수, 소스 코드 사용 가능성, 라이선스 비용 및 라이브러리의 성숙성입니다.

분리 된 아키텍처의 장점은 요구 사항이 변경되면 거래 스택의 다른 측면에 대해 언어를 플러그 할 수 있다는 것입니다. 거래 시스템은 진화하는 도구이며 모든 언어 선택이 함께 진화 할 가능성이 있습니다.

더 많은