전자 거래 시스템 아키텍처

전자 거래 자습서.

주식과 상품 거래는 전신과 전화는 말할 것도없고 컴퓨터의 발명보다 먼저 나온다. 사전 기술, 조기 교환은 밀 구매자 및 밀 판매자와 같이 공동 관심사가있는 지역 사업가의 비공식 모임이었습니다. 시간이 지남에 따라 참가자들은 일반적인 규칙과 규정을 고안하여 더 공식적이고 조직화되었습니다. 결국 공개적 외침이 진화되었습니다 - 교환기의 거래 플로어에 대한 정보를 전달하기 위해 구두 입찰과 손 신호가 사용되는 시스템.

1969 년 Instinet (원래 Institutional Networks로 지명)은 미국 기관이 기밀로 서로 거래장을 건너 뛰고 직접 거래 할 수있는 최초의 자동화 시스템을 출시했습니다. 나스닥은 2 년 후인 1971 년 현장에 등장했다. 처음에는 브로커 - 딜러가 다른 회사가 제공하는 가격을 볼 수있게 해주는 자동 견적 시스템이었다. 그러나 거래는 여전히 전화로 처리되었다.

몇 년 후, 뉴욕 증권 거래소는 브로커가 주문을 바닥에있는 전문가에게 직접 전달할 수있는 지정 주문 처리 (DOT) 시스템을 만들었습니다. 1984 년 차세대 SuperDOT가 등장하여 한 번에 최대 10 만 주를 바닥으로 보낼 수있었습니다.

결국 나스닥은 자동 거래 시스템 인 SOES (Small Order Execution System)를 제안했으며 다른 거래소도 곧이를 따랐다.

개방적인 외침은 오늘날에도 여전히 제한된 정도로 사용되고 있지만, 오류가 거의없고 실행이 빨라지고 효율성이 향상된 전자 시스템으로 거의 대체되었습니다. 전자 거래는 금융 세계를 지배하며, 투자자와 거래자가 어떻게 작동 하는지를 이해하는 데 도움이 될 수 있습니다. 시작을 돕기 위해 전자 거래 (거래 및 주요 기술 포함)를 간략하게 살펴보십시오.

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

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

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

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

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

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

개념적 아키텍처입니다.

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

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

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

참조 아키텍처.

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

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

구조보기.

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

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

건축 전술.

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

이벤트 및 순서 큐의 장애 패턴 이벤트 및 순서 큐의 공유 메모리 ODS의 CQL (Continuing Query Language) 수신 데이터의 필터 디자인 패턴을 사용한 데이터 필터링 모든 수신 및 송신 연결의 정체 방지 알고리즘 활성 큐 관리 (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은 내가 속한 양적 헤지 펀드 다. 우리는 기계 학습을 사용하여 시장을 이기고 시도합니다.

Vamsi Talks Tech.

Vamsi Chemitiganti의 Big Data, Cloud 및 & amp; 미들웨어 기술은 업계의 과제를 해결합니다. 매주 금요일 또는 일요일에 게시됩니다 (I 'm very busy). 모든 의견은 전적으로 내 자신입니다. 독자가 비싼 컨설턴트에게 돈을 쓸 필요가 없도록이 블로그를 작성합니다.

실제 세계 무역 플랫폼의 설계 및 아키텍처 (2/3)

이 기사는 대형 거래 운영 및 비즈니스 문제로 직면 한 비즈니스 문제에 대해 이야기하는 세 편의 시리즈 중 두 번째 기사입니다. 자본 시장 분야의 인프라. 이 게시물은 Big Data 기술을 사용하는 실제 참조 아키텍처에 대해 설명하며 실제로 더 기술적입니다. 이 시리즈의 마지막 부분에서는이 분야의 혁신적인 혁신을위한 비즈니스 권장 사항에 중점을 둡니다.

자본 시장과 발행자 수가 증가하는 세계화로 인해 다양한 금융 상품과 자산 (주식, 채권, 파생 상품, 상품 등) 및 장소 (NYSE, NASDAQ, CME, Dark Pools)에 걸쳐 복잡성이 증가하고 있습니다. 기타.). 그 축소 마진 & amp; 규제 압력으로 인해 구매자 측 플레이어는 기존 비즈니스 프로세스 & amp; 시스템 통합은 현재 이들을 더욱 투명하고 효율적이며 민첩하게 만들기 위해 노력하고 있습니다.

캐피털 마켓 (Capital Markets) 관점의 비즈니스 동인 (이 3 부 시리즈의 첫 번째 게시물에서 언급했듯이)

1. 기존 거래 인프라를 재 설계하여보다 통합적이고 느슨하게 결합되고 효율적으로 운영되도록합니다.

2. 주식, 외환, ETF 및 상품 등 다양한 자산 클래스에 대해 본질적으로 정량적 인 복잡한 거래 전략을 자동화합니다.

3. 새로운 & amp; (시장 데이터, 위치 데이터, M & A 데이터, 거래 데이터 등)뿐만 아니라 빠른 데이터 소스 (소셜 미디어, 센서 데이터, 클릭 스트림 날짜)를 제공합니다. 순수한 속도는 지금까지만 회사를 얻을 수 있습니다.

4. 분석을 유도하는 데 관심이있는 모바일 클라이언트의 범위를 수용 할 수 있도록 기존 거래 시스템을 재구성합니다. 예를 들어 시장 구조 정보와 진드기 데이터를 결합하여 특정 시점에 특정 증권이 하락하거나 급등하는 이유와 동일한 이유 (예 : 파생 상품과의 기관 매매 또는 주식 거래 연결된 거래)

5. 상인을 돕는 것은 지속적인 경쟁 우위를 창출 할 수 있도록 알고리즘을 생성하고 커스터마이징하는 것입니다.

시간의 필요성은 데이터, 속도, 민첩성 및 서비스 지향 아키텍처의 효율적인 사용을 토대로 구축 된 유연한 거래 플랫폼을 설계하는 데 필요한 엔터프라이즈 아키텍처 기능을 제공하는 것입니다. 오픈 소스의 선택은 모듈화되고 유연한 아키텍처를 허용하므로 단계적으로 수정하고 채택 할 수 있습니다. 당신이 곧 보게 될 것입니다.

거래 플랫폼은 구매 측의 포트폴리오 관리자로부터 오는 주문 실행, 주문 관리 & amp; 실행 프로세스를 모니터링하고 다양한 장소에 전자 액세스를 제공합니다. 판매 측면에서 고객 주문 처리 및 거래 포지션 관리에 대한 지원을 제공해야합니다.

다음 비즈니스 요구 사항은 구매 / 판매 거래 기능을 제공하는 시스템에서 충족되어야합니다.

아키텍처는 프론트, 미드 & amp; 단순하고 복잡한 룰 기반 및 알고리즘 방식의 무역 전략을 지원하는 백 오피스 거래 기능 개발 수명주기 & amp; 백 테스팅 및 위 전략의 실제 구현 측면에서 완벽한 컷오프. 짧은 지원에서 반복적이고 DevOps 기반 방법론. 목표는 출발을 개발하는 사람들이 가장 생산적인 방식으로 가장 광범위한 자산 클래스에서 모델을 테스트 할 수 있도록하는 것입니다. 모바일 기술을 지원하는 무역 관리를위한 매우 직관적 인 무역 및 지장 사용자 인터페이스. 이는 매끄러운 사용자 경험을 보장하는 데 중요합니다. 비즈니스 모델 거래를 서비스로 지원하십시오. & # 8211; 개방형 API를 통해 유틸리티로 판매 될 수있는 가능성이있는 하이브리드 & amp; 확장형 배포 모델 핵심 비즈니스 기능을 제공하는 서비스는 필요에 따라 베어 메탈에서 VM, Docker 컨테이너 또는 개인용 또는 공용 클라우드에 전개 할 수 있어야합니다. 핵심 요구 사항은 오픈 소스 소프트웨어 및 상품을 사용하는 것입니다. 복잡한 워크 플로우 (CEP)와 비즈니스 워크 플로우 (BPMN 표준을 이상적으로 지원)에 대한 지원이 제공되므로 예측 분석을 지원하는 규칙 기반 거래 모델 (선언적)을 지원해야합니다. 표기법) 전 세계의 다양한 외부 참여자와의 통합 지원. 플랫폼은 진정으로 교환 및 지원을 지원하는 측면에서 글로벌해야합니다. 제품 (FOREX, 다른 시간대에 걸쳐 영업) FIX를 기본으로 다양한 금융 상품 및 형식 지원 주문 캡처, 거래 및 교차 지원 제공 측면 시장 주문을 교차 판매 할 수있는 기능 제공 (두 가지 주문이 모두 감지되는 경우) 시스템에서) 자동 route 및 계정, 수량 및 실시간 시장 데이터를 기반으로 주문 실행 적용 가능한 다른 복잡한 주문 라우팅 요구 사항 지원 마지막으로 볼륨이 커짐에 따라 자동 확장이 가능할 정도로 높은 확장 성을 지원합니다. 주문 입력 및 재해 복구를 위해 밀리 초 및 잘 정의 된 SLA의 바람직한 대기 시간을 갖는 대량의 거래 / 초를 수용 할 수 있습니다.

애플리케이션 계층에서 & # 8211; SOA 기반 접근 방식이 핵심 - 모든 핵심 비즈니스 기능이 SOA 서비스 또는 마이크로 서비스로 모델링 됨 모든 시장 참여자를 상호 연결하는 ESB / 메시지 계층 선택 개방형 메시징 표준 - 선택되는 전송 프로토콜로 선택된 AMQP (사전 메시지 대기열 프로토콜) 성능 및 산업상의 이유로 금융 및 증권 거래소의 IT 인프라 비용을 최적화하기위한 기존 아키텍처는 독점 공급 업체 및 기존 프로토콜로 인해 혼란스러워졌습니다. AMQP는 은행 및 벤더 (JP Morgan 및 Red Hat, VMWare 등)의 컨소시엄이 개발했으며 금융 서비스 백본 메시징을위한 언어로 사용됩니다. 현재는 의료에서 ​​제조, IoT (Across verticals)에 이르는 광범위한 산업에 배치됩니다. AMQP를 사용하면 잠금 기능과 값 비싼 브리지 기술을 피할 수 있습니다. 또한 NYSE와 같은 조직은 OpenMAMA와 같은 기술 개발을 선도해 왔습니다. OpenMAMA는 이벤트 기반 메시징을 지원하는 공급 업체의 불가지론적인 미들웨어 API를 제공하려고합니다. 예를 들어 시장 데이터 공급 업체가 따옴표 & amp; 업계 표준 플랫폼을 통해 거래하면서 플랫폼에서 가치 기반 서비스를 구축 할 수 있습니다. 우리의 의도는 개방형 표준을 기반으로 아키텍처를 입증하는 것입니다. AMQP를 통해 실행되는 FIX (Financial Information Exchange)는 주요 비즈니스 교환 프로토콜이됩니다. Apache Kafka 또는 메시징 계층 또는 서비스 버스로 선택된 Fuse ESB A BRMS (Business Rules Mgmt System )는 규칙, CEP 및 BPM을 단일 우산 아래에 제공합니다. 이 계층에는 주문 관리, 라우팅, 교차, 일치를위한 규칙에 대한 정의와 런타임이 포함됩니다. 메모리 데이터 그리드 또는 메모리 영역의 스파크를 사용하는 메모리 분석 데이터 계층은 Apache Hadoop 플랫폼을 기반으로하며 람다 아키텍처 (Nathan Marz가 개발)를 기반으로 설계되었습니다. 이에 대한 자세한 내용은 아래 섹션을 참조하십시오.

그림 1 - 거래 플랫폼을위한 참조 아키텍처.

위에 묘사 된 거래 플랫폼 아키텍처의 주요 구성 요소는 & # 8211;

주문 관리 시스템 - 사용자 인터페이스가있는 풍부한 양방향 포털을 표시합니다. 고객은 전화를 통해 중개인을 호출하거나 전자로 주문합니다. 이러한 주문은 OMS로 전달됩니다. OMS는 주문을 받고, 적절한 매칭을 수행하고, 비즈니스 규칙 / 복잡한 이벤트를 기반으로 최적의 애비뉴와 가격을 결정한 다음이를 적절한 마켓 플레이스로 라우트하여 채워 넣습니다. 시장 데이터 유통 서비스는 시장 데이터 제공 업체 (예 : 블룸버그, Thomson Reuters 등)와 OMS에 정기적 인 업데이트를 보내 어떤 시장 데이터가 OMS의 참조 점이되는지, 즉 동일한 시장 데이터가 우선 순위를 갖는 여러 소스에서 사용 가능한지에 대한 규칙을 규정합니다. 또한 연결은 FIX 게이트웨이를 통해 배포에 설정됩니다 서비스. 비즈니스 규칙 접근 방식은 비즈니스 규칙을 사용하여 선언적 논리를 활용하여 작고 빠르며 이해하기 쉬운 거래 논리를 구축 할 수있게함으로써 BPM에 또 다른 차원을 추가합니다. 예를 들어 거래 플랫폼, 모기지 인수 프로그램 등 시장 상황에 따라 비즈니스 규칙 변경 및 구매 / 판매 요청이 만족되는 비즈니스 프로세스가 이루어지는 분야가 있습니다. 복잡한 이벤트 처리 (CEP) & # 8211; 이벤트라는 용어 자체는 자주 오버로드되며 사용되는 컨텍스트에 따라 여러 가지 다른 것을 참조하는 데 사용될 수 있습니다. 우리의 거래 플랫폼에서는 판매 작업이 실행될 때 여러 액터에서 볼 수있는 도메인의 상태 변경이 발생합니다. 예를 들어 작업의 가치와 일치하도록 변경된 유가의 가격, 개인의 소유자 판매자로부터 구매자로 바뀌는 거래 자산, 판매자와 구매자의 계좌 잔액, 계좌 이체 및 인출 등이 포함됩니다. 이러한 이벤트의 구름을 가로 채고 비즈니스 프로세스를 적용하여 이에 대응하고 대응하는 것이 민첩한 거래 플랫폼. 데이터 관리 계층은 보안 마스터, 고객 마스터, 홀딩 및 계정 / 제품 마스터 등과 같은 정보 저장소에 걸쳐 있습니다. 이 계층은 데이터 관리를 처리해야합니다.

그림 2 - 무역 규칙 모델링.

시스템의 데이터 흐름은 아래 그림과 같이 표현 될 수 있습니다.

그림 3 - 전반적인 거래 프로세스 흐름.

SOA (또는 마이크로 서비스) 아키텍처를 채택하려는 의도는 성능 측정, 무역 감시, 위험 분석, 옵션 가격 책정 등과 같은 경량 비즈니스 서비스를 점진적으로 연결하는 것입니다.

데이터 아키텍처는 Nathan Marz가 개발 한 람다 시스템을 기반으로합니다. 람다 아키텍처는 문제를 임의의 데이터에 대해 실시간으로 계산하는 문제를 배치 레이어, 서빙 레이어 및 속도 레이어의 세 가지 레이어로 분해합니다 .

그림 4 - 데이터 프로세스 흐름 (소스 VoltDB)

매우 높은 일반 수준에서 데이터 아키텍처에는 3 가지 구성 요소가 있습니다.

배치 레이어 & # 8211; 시장 데이터, 소셜 미디어 데이터, 참조 데이터, 위치 데이터 등을 끊임없이 섭취하고, 저장하고 처리하며, Speed ​​Layer 프로세스의 실시간 피드 & amp; 예측 분석에 필요한 쿼리와 관련된 배치 뷰를 보유하고있는 동일한 서비스 계층의 전술적 뷰를 생성합니다.

Lambda Architecture는 복잡한 비즈니스 프로세스에 완벽하게 적합한 낮은 대기 시간 (예 : 몇 초에서 몇 시간)으로 실행해야하는 복잡한 비동기 변환을 기반으로 구축 된 애플리케이션을 대상으로합니다.

비용 효과 - 오픈 소스 스택은 메인 프레임 또는 독점 기술로 구축 된 레거시 시스템에 비해 비용을 거의 50 % 절감합니다. 데이터 거버넌스 & # 8211; Hadoop 스택이 효율적으로 제공합니다. 확장 성 - 아키텍처에서 높은 수준의 확장 성 제공 혁신적 - 가장 강력한 아키텍처 및 최첨단 기술을 기반으로 구축 배치 - 다양한 배치 아키텍처, 온 프레미스 또는 클라우드 지원로드 증가하는 볼륨을 처리하기 위해 균형 조정 지원 기능이 내장되어있어 워크 플로 모니터링에 대한 지원은 물론 비즈니스 규칙에 대한 가시성을 제공합니다.

오픈 소스를 기반으로 구축 된 뉴 에이지 거래 플랫폼은 물리적, 가상, 모바일 및 클라우드 환경에 배치 될 수있을뿐만 아니라 보완적인 패러다임을 포함합니다. 통합, 비즈니스 규칙 및 CEP (complex event processing) 기능을 통해 운영 효율성, 새로운 비즈니스 모델, 향상된 위험 관리 기능을 추가 할 수 있습니다. 궁극적으로 높은 수준의 수익성.

이 공유:

소식 탐색.

회신을 남겨주 답장을 취소하십시오.

안녕하세요 Chemitiganti-San. 우수하고 통찰력있는 직업. Tokio & # 038에서 혁신 워크숍을 진행할 때도 Trading Architecture 주제를 다루실 수 있습니까? 8 월 서울?

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

현재 소프트웨어 아키텍처에 관한 강의를 듣고 있습니다. 이 수업에서는 각 학생이 시스템을 선택하고 건축 요구 사항을 정의하며 이러한 요구 사항을 충족 할 수있는 솔루션을 설계합니다. 기술적 인 문제 때문에 그리고 금융 시장을 사랑하기 때문에 알고리즘 거래 시스템을 선택했습니다. 알고리즘 거래 시스템 (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은 내가 속한 양적 헤지 펀드 다. 우리는 기계 학습을 사용하여 시장을 이기고 시도합니다.