거래 시스템의 아키텍처

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

이전에이 블로그에서 지적 알고리즘 트레이딩 시스템의 개념적 아키텍처와 생산 알고리즘 트레이딩 시스템의 기능적 및 비 기능적 요구 사항에 대해 작성했습니다. 그 이후로 필자는 이러한 아키텍처 요구 사항을 충족시킬 수 있다고 믿는 시스템 아키텍처를 설계했습니다. 이 글에서는 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은 내가 속한 양적 헤지 펀드 다. 우리는 기계 학습을 사용하여 시장을 이기고 시도합니다.

IT 전문가 및 기타 전문가를위한 실용적인 주제.

고정 프로토콜 FAQ가 게시됩니다.

9 월 26 일 Fixed Income Trading System Architecture 워크샵.

Fixed Income Instruments Fixed Income Trading의 개요 Fixed Income Markets의 브로커 / 딜러 회사의 요구 사항 브로커 / 딜러의 Fixed Income Trading System의 요구 사항 / 특징 Fixed Income Trading Platform의 아키텍처 다양한 구성 요소 및 역할 사용 된 주요 기술 및 공급 업체 제품.

관련 게시물.

위험 관리 USA 2016 & # 8211; 위험 데이터 문제 & # 038; 빅 데이터 플랫폼 솔루션.

My Book & Derivatives Managing Contracts & # 8221; 출시 됨.

팩토링 개념이란 무엇입니까?

2 개의 댓글.

[[# 8230;] Fixed Income Trading System Architecture [& # 8230;]

Hi Khader, 귀하의 웹 블로그는 훌륭합니다. 그것을 지켜라. 그것의.

도움이됩니다. 우리는 여기서 다시 계속 될 것입니다. 정보가 필요해. 어떤 SQL.

분석 역할은에 대한 보안 마스터를 구성하는 사람을 수행합니다.

회사 (eg. Fixed Income) 실행? 레코드가있는 데이터베이스 테이블이 필요합니다.

그 안에있는 이름과 필드 이름과 SQL 문. 서둘러주세요.

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

내 책 "관리 파생 계약"이 발표되었습니다.

시작하기 : 완전 자동 거래 시스템 구축.

지난 6 개월 동안 자동화 된 거래 시스템의 전체 기술 스택을 구축하는 프로세스에 중점을 두었습니다. 나는 많은 어려움을 겪었으며 백 테스팅 (Vectorised and Event driven)의 두 가지 다른 방법에 대해 많은 것을 배웠다. 이벤트 중심의 백 테스터 (backteter driven backteter)를 구축하기위한 여정에서, 전략을 수립하고 백 테스트하고 실제 실행을 실행하는 데 필요한 전체 기술 스택에 가까워졌습니다.

문제를 해결할 때 가장 큰 문제는 지식 부족이었습니다. 나는 기술을 구축하기위한 소개 나 나를 인도 할 블로그를 여러 곳에서 보았다. 나는 오늘 당신과 공유 할 몇 가지 자료를 찾았습니다.

초보자 용 :

양적 거래에 익숙하지 않은 독자를 위해 저는 Ernie P. Chan의 책 "Quantitative Trading : 자신의 알고리즘 거래 비즈니스를 구축하는 방법"을 추천 할 것입니다. 이 책은 기본입니다. 그것은 실제로 제가 양적 거래에서 읽은 첫 번째 책입니다. 그리고 심지어는 매우 기초적 이었지만, 당신이 취해야 할 몇 가지주의 사항이 있습니다.

페이지 81-84에서 Ernie는 소매 수준에서 시스템 아키텍처를 반자동 및 완전 자동화 전략으로 분리하는 방법에 대해 씁니다.

일주일에 몇 번 거래를하려면 반자동 시스템이 적합합니다. Ernie는 Matlab, R 또는 심지어 Excel을 사용하도록 권장합니다. 나는 모든 3 개의 플래트 홈을 사용하고 이것은 나의 통보이다 :

Skip Matlab은 많은 돈이 들고 대학 연구실에서만 액세스 할 수 있습니다. 블로그 나 책과 같은 교육 자료가 많이 없기 때문에 Matlab을 사용하여 전략을 코딩하는 법을 배울 수 있습니다. R에는 전략 수립 방법을 배우기 위해 사용할 수있는 수많은 리소스가 있습니다. 주제를 다루는 내가 가장 좋아하는 블로그는 : Ilya Kipnis가 운영하는 QuantStratTradeR입니다. Microsoft Excel은 프로그래밍 경험이없는 경우 시작할 것입니다. 반자동 거래를 위해 Excel을 사용할 수는 있지만 전체 기술 스택을 구축 할 때는이 트릭을 수행하지 않습니다.

반자동 프레임 워크 81 페이지.

완전히 자동화 된 거래 시스템은 실시간 데이터 피드를 기반으로 거래를 자동으로 배치하려는 경우에 적합합니다. 나는 C #으로 광산을 코딩했으며, QuantConnect는 C #을 사용하고, QuantStart는 파이썬으로 그것을 구축하고, Quantopian은 파이썬을 사용하며, HFT는 C ++을 사용합니다. 자바 또한 인기가 있습니다.

완전히 자동화 된 거래 프레임 워크 84.

1 단계 : 머리를 시작하십시오.

QuantInsti가 제공하는 알고리즘 트레이닝의 이그 제 큐 티브 프로그램을 수행하십시오. 방금 강좌를 시작했는데 첫 번째 강의는 시스템 아키텍처에 관한 것입니다. 제가 여기서 시작했다면 약 3 개월의 연구를 저축했을 것입니다. 강의를 통해 각 구성 요소가 수행해야하는 작업에 대한 자세한 설명뿐 아니라 필요한 각 구성 요소를 살펴 보았습니다. 아래는 프레젠테이션에서 사용 된 슬라이드 중 하나의 스크린 샷입니다.

다른 자동 거래 시스템을 평가할 때도이 일반 프레임 워크를 사용할 수 있습니다.

글쓰기를 할 때 나는 강의 3 주 밖에 안 남았지 만, 개업의가 폴란드어로 정량적 헤지 펀드의 시작으로 바뀔 수있는 완전히 자동화 된 거래 전략을 세울 수있을 것이라고 확신합니다. .

참고 : 과정은 기술 스택을 구축하는 데 초점을 맞추지 않습니다.

2 단계 : 기본 이벤트 기반 백 테스터를 코딩합니다.

Michael Hallsmore의 블로그 퀀텀 스타트 & amp; "성공적인 알고리즘 거래"

이 책에는 강력한 이벤트 기반 백 테스터 (backtester)로 작성된 섹션이 있습니다. 그는 언어 선택, 여러 가지 유형의 백 테스팅, 이벤트 기반 백 테스팅의 중요성 및 백 테스터 코딩 방법을 설명하는 여러 장을 통해 독자를 안내합니다.

Michael은 객체 지향 디자인에 필요한 다양한 클래스에 독자를 소개합니다. 그는 또한 독자들에게 증권 마스터 데이터베이스를 구축하도록 가르친다. QuantInsti의 시스템 아키텍처가 어떻게 적용되는지 확인할 수 있습니다.

참고 : 그의 책 "Successful Algorithmic Trading"을 구입해야하며, 그의 블로그는 너무 많은 정보를 남기지 않습니다.

3 단계 : TuringFinance로 돌아갑니다.

EPAT 프로그램 "Successful Algorithmic Trading"읽기 & amp; 원하는 다른 언어로 백 테스터 코딩.

TuringFinance라는 블로그로 이동하여 "Algorithmic Trading System Architecture"라는 제목의 기사를 읽어야합니다. 작성자 : Stuart Gordon Reid. 그는 ISO / IEC / IEEE 42010 시스템의 가이드 라인과 소프트웨어 엔지니어링 아키텍처 설명 표준을 따르는 아키텍처에 대해 설명합니다.

이 게시물은 매우 기술적이며 자신의 아키텍처에 통합시켜야한다는 훌륭한 아이디어가 있습니다.

그의 게시물에서 찍은 스크린 샷.

4 단계 : 오픈 소스 거래 시스템을 연구합니다.

4.1) Quantopian.

콴토 피안 (Quantopian)이이 목록에 추가되어야한다는 것은 말할 것도없이, 나는 (언어 선택 때문에) 자신의 플랫폼을 사용하는 데 많은 시간을 투자하지 않았다는 말을 부끄럽게 여긴다. 콴토 피안은 많은 특혜를 가지고 있지만, 내게 가장 많이 돋보이는 것은 다음과 같습니다.

배우기 쉬운 Python 많은 데이터 세트에 무료로 액세스 할 수 있습니다. 커다란 지역 사회와 대회 저는 그들이 QuantCon을 호스트하는 방법을 좋아합니다!

콴토 피안 (Quantopian)은이 분야의 시장 선두 주자로 퀀트 (Quants)에서 사랑 받고 있습니다! 그들의 오픈 소스 프로젝트는 Zipline이라는 코드 명으로되어 있는데, 이것에 대해서는 조금 있습니다 :

"Zipline은 IDE에서 역기를 작동시키는 오픈 소스 엔진입니다. Github에서 코드 저장소를보고 프로젝트에 끌어 오기 요청을 제공 할 수 있습니다. 도움을 구하고 토론을 쉽게 할 수있는 Google 그룹이 있습니다. "

다음은 해당 설명서에 대한 링크입니다.

4.2) QuantConnect.

QuantConnect에 익숙하지 않은 사용자를 위해 완전한 오픈 소스 알고리즘 거래 엔진을 제공합니다. 여기에 링크가 있습니다.

코드를보고 연구하고 & amp; 그들에게 칭찬을 베풀어 라. 그들은 콴토 피안 경쟁자입니다.

이 기회를 빌어 퀀 커넥트 (QuantConnect) 팀이 뇌를 고르도록하고 그들이 제공하는 뛰어난 서비스에 감사 드리고 싶습니다.

다음은 해당 설명서에 대한 링크입니다.

끝 맺는 말:

나는이 안내서가 지역 사회 구성원들에게 도움이되기를 바랍니다. 6 개월 전 우리 시스템을 코딩하기 시작했을 때이 통찰력이 있었으면 좋겠습니다.

나는 지역 사회에 손을 내밀어 "좋은 알고리즘 트레이딩 코스는 무엇을 알고 있습니까?"라고 묻습니다. 주제를보고 순위를 매길 수있는 글을 쓰고 싶습니다. 이 게시물에 추가하고자하는 완전 자동화 된 거래 시스템을 구축하기위한 권장 사항이 있습니까?

이 공유:

이 항목을 공유하십시오.

너도 좋아할거야.

멋진 기사. 나는 약 6 개월 전에 그것을 가지고 있었으면 좋겠다. 저는 C # 프로그래머이기 때문에 QuantConnect를 사용합니다. 린 (Lean)과 백 테스트 (Back Test)를 로컬에서 다운로드 할 수 있다는 것이 매우 편리하다는 것을 알았습니다. 코드를 뒤적 거리는 것도 가치가 있습니다. 또한 그들은 Tradier와 1 달러 거래를했습니다. 그것은 많은 도움이됩니다. 나는 Tradier의 확산과 처형에 관해서 두드러지지 않습니다. IB가 더 좋을 수도 있습니다.

내가 언급 한 과정을 살펴 보겠습니다.

Quantocracy 또는 RBlogger는 언급하지 않았습니다. 둘 다 매우 귀중한 자원입니다.

백 테스트의 결과를 차트로 나타 내기 위해 당신은 무엇을 사용합니까? OnData 이벤트에서 OHLC와 인디케이터 값을 csv에 기록하고 결과를 차트로 표시하는 데 Excel을 사용하는 것이 정말 지쳤습니다. 차트 파일 패키지를 데이터 파일로 가리키고 그냥 가져 가려고합니다.

틱 스트림 공급 업체가 있습니까?

이벤트 중심 시스템에 대한 한 가지 생각이 있습니다. 이벤트 문제는 비동기적이고 잠복 적이라는 것입니다. 그것은 당신이 중개업에 관여하자 마자 피할 수없는 것처럼 보입니다. 그래서 저는 기능적 프로그래밍의 원칙에 따라 더 많은 스트리밍 시스템을 꿈꿔 왔습니다.

& # 8211; 진드기 또는 바 스트림을 숨 깁니다.

& # 8211; 표시기 계산, 분석 또는 ML 실행 등의 프로세스를 통해 실행하십시오.

& # 8211; 신호를 다시 받으십시오.

& # 8211; 실행을 위해 브로커에게 보냅니다.

그런 다음 별도의 스트림으로

& # 8211; 브로커로부터 응답을받습니다.

물론 문제는 국가입니다. 무역을하기에 충분한 여유가 있습니까? 내 포트폴리오에는 무엇이 있습니까? 그것은 어떻게 실행되고 있습니까? 일반적으로 브로커 API는 해당 내용을 확인하기 위해 쿼리 할 수 ​​있지만 시간이 오래 걸리고 비동기입니다. 나는 또한 Rx 확장을보고있다. 그렇게하면 시스템은 관찰 가능한 패턴을 통해 시스템의 변화에 ​​대응할 수 있습니다.

이벤트는 마우스 클릭에 좋습니다. 대용량 트랜잭션 처리에는 그리 좋지 않습니다.

이것은 내가 자기 물건으로 가져간 접근법과 정확하게 같습니다. 본질적으로 저는 정상적인 & # 8217; 브로커 (IB API)와 대화 할 수있는 이벤트 인 작은 부분을 감싸는 프로그램. 이제 국가 문제에 대해. 두 가지 선택이 있습니다. 브로커에서 상태를 가져 오거나, 다시 채울 때 내부적으로 업데이트를 저장합니다. 즉, 귀하가 귀하의 주를 알고있을 때나, 두 가지 주 원천이 충돌 할 가능성이있는 경우 (잘못된 데이터 또는 지연)를 의미합니다. 이 부분은 얼마나 빨리 거래를 하느냐에 달려 있습니다. 정말로 빨리 거래하고 나서 상태 충돌이 있거나 일시적으로 상태가 불투명하다면 일시 중지하는 것이 아니라 상태를 알지 않고 계속 진행하는 것보다 낫습니다. 데이터베이스 & # 8216; 잠금 & # 8217;을 사용합니다. 이것에 대처하는 패러다임.

거의 모든 질문에 대해 Reactive Extension (Rx)에 답이 가깝습니다.

Rx가 Ticks에서 Candles로가는 것은 사소한 일입니다.

양초에서 지시약으로가는 것은 쉽지 않습니다.

다른 지표로부터 지표를 작성하는 것은 쉬운 일이 아닙니다.

지표에서 위치를 작성하는 것은 쉬운 일이 아닙니다.

포지션으로부터 (시간이 지남에 따라 유지되는) 포지셔닝을 작성하는 것은 사소한 일입니다.

위험 모델을 시뮬레이션하는 것은 간단합니다.

테스트 또는 라이브 거래는 라이브 스트림의 데이터 또는 시뮬레이션 된 데이터베이스 데이터 재생 사이를 결정하는 것입니다.

실행은 간단합니다.

구현은 C #에서 F #, JavaScript에서 C ++까지 거의 모든 코드에서 가능합니다.

순전히 기능적인 Rx가 GPU에 대규모 parallalizable이기 때문에 최적화는 빨리된다.

물론 연속 최적화의 효과를 최적화하고 백 테스트에 다시 넣는 것은 중요하지 않지만 어쨌든 중요하지 않다는 것을 감안할 때, 나는 그 슬라이드를 😉

순전히 기능적 (또는 그것에 가깝다) Rx가 내 의견으로는이 문제의 인프라를 해결할 수있는 유일한 방법이다.

나는 거래하고자하는 시스템을 안다. 나는 이미 알고있는 누군가를 프로그래밍하거나 배울 필요가 없다. 그렇다면 누가 시스템을 사용하여 누가 그것을 사용하고 자동화 할지를 결정할 수 있습니다. 그것을 자동화함으로써, 나는 그것을보고 싶지 않다는 것을 의미합니다. 결과를 일주일에 한 번 훑어보고 내주의를 기울이지 않고 거래가 진행됩니다. 2016 년에 많은 노력을 기울여 규칙을 수립하고 이러한 규칙을 내 중개인에게 적용해야한다는 것이 이상하다는 생각이 들었습니다.

콴토 피안 (Quantopian)에 가입 한 다음 커뮤니티 내의 누군가를 찾고 전략을 수립 할 것을 제안합니다. 그들은 IB 중개인 플랫폼에서 귀하를 위해 그것을 구축하고 완전히 자동화 할 수 있습니다.

그래도 당신이 그것을주의 깊게 감시해야한다고 생각하지만, 단지 잊어 버리는 것이 아닙니다.

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 ​​레이어가 실시간 피드 & amp; 예측 분석에 필요한 쿼리와 관련된 배치 뷰를 보유하고있는 동일한 서비스 계층의 전술적 뷰를 생성합니다.

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

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

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

이 공유:

소식 탐색.

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

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