Hadoop Handelssystem

Im, das lustiges Lernen über Hadoop und die verschiedenen Projekte um ihn hat und gegenwärtig 2 verschiedene Strategien Im denkend über zum Aufbau eines Systems, zum einer großen Ansammlung der Markttickdaten zu speichern, Im gerade erst begonnen mit HadoopHDSF und HBase aber hoffend, dass jemand mir helfen kann Pflanze ein System Saatgut, das ich nicht haben, um Junk später mit diesen Technologien. Unten ist ein Überblick über meine System-und Anforderungen mit einigen Abfrage-und Datennutzung Anwendungsfälle und zuletzt meine aktuellen Denken über den besten Ansatz aus der kleinen Dokumentation habe ich gelesen. Es ist eine offene Frage und Ill gern wie jede Antwort, die aufschlussreich ist und akzeptieren die beste, fühlen sich frei, zu einem oder allen der Punkte unten kommentieren. - Duncan Krebs Systemvoraussetzungen - In der Lage sein, den Datenspeicher für historische Back-Tests von Systemen, historische Daten Charting und zukünftige Data Mining nutzen. Sobald sie gespeichert sind, sind die Daten immer schreibgeschützt, ein schneller Datenzugriff ist erwünscht, aber kein Muss bei der Rückprobe. Statisches Schema - Sehr einfach, möchte ich 3 Arten von Nachrichten aus dem Feed zu erfassen: Timestamp einschließlich Datum, Tag, Zeit Quote einschließlich Symbol, Zeitstempel, fragen, askSize, Gebot, BidSize, Volumen. (Ungefähr 40 Spalten von Daten) Handel einschließlich Symbol, Zeitstempel, Preis, Größe, Austausch. (Über 20 Spalten von Daten) Data Insert Use Cases - entweder aus einem Live-Markt Strom von Daten oder Lookup über Broker API Data Query Use Cases - Nachstehend wird gezeigt, wie ich meine Daten logisch abfragen möchte. Erhalten Sie mir alle Zitate, Trades, Timestamps für GOOG auf 9222014 Holen Sie mich alle Trades für GOOG, FB vor 912014 UND NACH 512014 Holen Sie sich die Anzahl der Trades für diese 50 Symbole für jeden Tag in den letzten 90 Tagen. Der Heilige Gral - Kann MapReduce für Anwendungsfälle wie diese unten verwendet werden. Erzeugen von Metadaten aus den Rohdaten über verteilte Agenten. Beispiel: Schreiben Sie einen Job, der das durchschnittliche Handelsvolumen in einem Intervall von 1 Minute für alle Bestände und alle in der Datenbank gespeicherten Sitzungen berechnet. Erstellen Sie den Job, um einen Agenten für jede Aktie zu haben, die ich sage, welche Aktie und Session dieser Wert für diesen Wert berechnen soll. (Ist dies, was MapReduce tun kann.) Auf dem Klassenpfad der Agenten kann ich meinen eigenen Benutzungscode hinzufügen, damit der obige Anwendungsfall zB seinen Wert in ein zentrales Repo oder einen Messaging-Server veröffentlichen kann Ich kann einen Agenten als OSGI-Bundle bereitstellen Erstellen Sie verschiedene Arten von Agenten für verschiedene Arten von Metriken und Scores, die ausgeführt werden jeden Morgen vor dem Pre-Market-Handel Hochfrequenz-Trading Im auch interessiert, wenn jemand kann einige Erfahrungen mit Hadoop im Rahmen der Hochfrequenz-Handelssysteme zu teilen. Nur bekommen in diese Technologie mein ursprünglicher Sinn ist Hadoop kann für die Speicherung und Verarbeitung großer Mengen von historischen Tick-Daten groß sein, wenn jemand diese für Echtzeit-Handel nutzt. Ich bin daran interessiert, mehr zu lernen - Duncan Krebs Nach meinem Verständnis von Ihren Anforderungen , Wäre Hadoop wirklich gute Lösung, um Ihre Daten zu speichern und führen Sie Ihre Abfragen auf sie mit Hive. Speicherung: Sie können die Daten in Hadoop in einer Verzeichnisstruktur speichern wie: Innerhalb des Stundenordners können die Daten zu dieser Stunde des Tages liegen. Ein Vorteil der Verwendung einer solchen Struktur ist, dass Sie externe Tabellen in Hive über diese Daten mit Ihren Partitionen auf Jahre, Monate, Tage und Stunden erstellen können. Etwas wie folgt: Kommen Sie zu den Abfragen Teil, sobald Sie die Daten im oben genannten Format gespeichert haben, können Sie problemlos einfache Abfragen. Holen Sie mich alle Zitate, Trades, Timestamps für GOOG auf 9222014 Holen Sie mich alle Trades für GOOG, FB vor 912014 und nach 512014 Sie können alle solche Aggregation Abfragen einmal an einem Tag und verwenden Sie die Ausgabe zu kommen mit den Metriken vor Pre-Market Handel. Da Hive intern führt mapreduce diese Abfragen werden nicht sehr schnell. Um schnellere Ergebnisse zu erhalten, können Sie einige der Speicher-Projekte wie Impala oder Spark. Ich habe mich Impala verwendet, um Abfragen auf meinem Bienenstock Tabellen laufen und ich habe eine wesentliche Verbesserung der Laufzeit für meine Fragen (rund 40x) gesehen. Auch Sie wouldnt Notwendigkeit, irgendwelche Änderungen an der Struktur der Daten vorzunehmen. Daten Einsatz Anwendungsfälle. Sie können Werkzeuge wie Flume oder Kafka für das Einfügen von Daten in Echtzeit auf Hadoop (und damit auf die Bienenstock-Tabellen) verwenden. Flume ist linear skalierbar und kann auch bei der Verarbeitung von Ereignissen bei der Übertragung helfen. Insgesamt kann eine Kombination aus mehreren großen Datentechnologien eine wirklich anständige Lösung für das von Ihnen vorgeschlagene Problem bieten, und diese Lösung würde auf riesige Datenmengen skalieren. Algorithmische Trading-Systemarchitektur Bisher habe ich in diesem Blog über die Konzeptarchitektur eines intelligenten Algorithmus geschrieben Handelssystem sowie die funktionalen und nicht-funktionalen Anforderungen eines produktionsalgorithmischen Handelssystems. Seitdem habe ich eine Systemarchitektur entworfen, von der ich glaube, dass sie diese architektonischen Anforderungen erfüllen kann. In diesem Beitrag werde ich beschreiben die Architektur nach den Richtlinien der ISOIECIEEE 42010 Systeme und Software Engineering Architektur Beschreibung Standard. Nach dieser Norm muss eine Architekturbeschreibung enthalten: Mehrere standardisierte architektonische Ansichten (z. B. in UML) enthalten und die Rückverfolgbarkeit zwischen Entwurfsentscheidungen und architektonischen Anforderungen beibehalten Softwarearchitekturdefinition Es gibt noch keinen Konsens darüber, was eine Systemarchitektur ist. Im Rahmen dieses Artikels wird sie als die Infrastruktur definiert, innerhalb der Anwendungskomponenten, die funktionalen Anforderungen genügen, spezifiziert, implementiert und ausgeführt werden können. Funktionale Anforderungen sind die erwarteten Funktionen des Systems und seiner Komponenten. Nicht funktionale Anforderungen sind Maßnahmen, durch die die Qualität des Systems gemessen werden kann. Ein System, das seine funktionalen Anforderungen voll erfüllt, kann die Erwartungen nicht erfüllen, wenn nicht funktionale Anforderungen unbefriedigt bleiben. Um dieses Konzept zu veranschaulichen, betrachten Sie das folgende Szenario: ein algorithmisches Handelssystem, das Sie gerade gekauft haben, macht ausgezeichnete Handelsentscheidungen, ist aber völlig inoperabel mit den Organisationen Risikomanagement und Buchhaltungssysteme. Würde dieses System Ihren Erwartungen entsprechen Konzeptionelle Architektur Eine konzeptionelle Sicht beschreibt hochrangige Konzepte und Mechanismen, die im System auf höchster Granularität existieren. Auf dieser Ebene folgt das algorithmische Handelssystem einer ereignisgesteuerten Architektur (EDA), die über vier Schichten aufgebrochen ist, und zwei architektonische Aspekte. Für jede Schicht - und Aspektreferenz werden Architekturen und Muster verwendet. Architektonische Muster sind bewährte, generische Strukturen, um spezifische Anforderungen zu erfüllen. Architektonische Aspekte sind Querschnittsaufgaben, die sich über mehrere Komponenten erstrecken. Ereignisgetriebene Architektur - eine Architektur, die Ereignisse erzeugt, erkennt, konsumiert und reagiert. Ereignisse umfassen Echtzeitbewegungen, komplexe Ereignisse oder Trends und Handelsereignisse, z. B. Einreichung einer Bestellung. Dieses Diagramm veranschaulicht die konzeptionelle Architektur des algorithmischen Handelssystems Referenzarchitekturen Um eine Analogie zu verwenden, ähnelt eine Referenzarchitektur den Blaupausen für eine tragende Wand. Dieses Blau-Druck kann für mehrfache Gebäudeentwürfe wiederverwendet werden, unabhängig davon, welches Gebäude errichtet wird, da es einen Satz von allgemein auftretenden Anforderungen erfüllt. Ähnlich definiert eine Referenzarchitektur eine Vorlage, die generische Strukturen und Mechanismen enthält, die verwendet werden können, um eine konkrete Softwarearchitektur zu konstruieren, die spezifischen Anforderungen genügt. Die Architektur für das algorithmische Handelssystem verwendet eine raumbasierte Architektur (SBA) und einen Model View Controller (MVC) als Referenzen. Gute Vorgehensweisen wie der Betriebsdaten-Speicher (ODS), das Extrakt-Transformations - und Belastungsmuster (ETL) und ein Data Warehouse (DW) werden ebenfalls verwendet. Modellansicht-Controller - ein Muster, das die Darstellung von Informationen von der Benutzerinteraktion mit ihr trennt. Raumbasierte Architektur - spezifiziert eine Infrastruktur, in der lose gekoppelte Verarbeitungseinheiten miteinander über einen gemeinsamen assoziativen Speicher mit dem Namen Space interagieren (siehe unten). Strukturansicht Die Strukturansicht einer Architektur zeigt die Komponenten und Unterkomponenten des algorithmischen Handelssystems. Es zeigt auch, wie diese Komponenten auf physische Infrastruktur eingesetzt werden. Die in dieser Ansicht verwendeten UML-Diagramme umfassen Komponentendiagramme und Bereitstellungsdiagramme. Im Folgenden finden Sie eine Übersicht der Implementierungsdiagramme des algorithmischen Handelssystems und der Verarbeitungseinheiten in der SBA-Referenzarchitektur sowie zugehörige Komponentendiagramme für die einzelnen Schichten. Architectural Tactics Nach dem Software Engineering Institute ist eine architektonische Taktik ein Mittel zur Befriedigung einer Qualitätsanforderung durch Manipulation eines Aspekts eines Qualitätsattributmodells durch architektonische Designentscheidungen. Ein einfaches Beispiel, das in der algorithmischen Handelssystemarchitektur verwendet wird, ist, einen operativen Datenspeicher (ODS) mit einer kontinuierlichen Abfragekomponente zu manipulieren. Diese Komponente würde das ODS kontinuierlich analysieren, um komplexe Ereignisse zu identifizieren und zu extrahieren. Folgende Taktiken werden in der Architektur verwendet: Das Disruptormuster im Ereignis - und Auftragswarteschlange Gemeinsamer Speicher für die Ereignis - und Auftragswarteschlangen Ununterbrochene Abfragesprache (CQL) auf dem ODS Datenfilterung mit dem Filterentwurfsmuster auf eingehenden Daten Vermeidungsalgorithmen auf allen Eingehende und ausgehende Verbindungen Active Queue Management (AQM) und explizite Staubenachrichtigung Rohstoffrechenressourcen mit Kapazitäten für Upgrade (skalierbar) Aktive Redundanz für alle Single Points of Fail Indexierung und optimierte Persistenzstrukturen im ODS Planen Sie regelmäßige Datensicherungs - und Bereinigungsskripte für ODS Transaktionshistorie auf allen Datenbanken Prüfsummen für alle Aufträge, um Fehler zu erkennen Annotieren von Ereignissen mit Zeitstempeln, um veraltete Ereignisse zu überspringen Bestellen von Validierungsregeln zB Maximale Handelsmengen Automatisierte Händlerkomponenten verwenden eine Speicher-Datenbank für die Analyse Zweistufige Authentifizierung für Benutzeroberflächen, die eine Verbindung zu den ATs herstellen Verschlüsselung auf Benutzerschnittstellen und Verbindungen zu den ATs Observer-Entwurfsmuster für das MVC, um Ansichten zu verwalten Die obige Liste sind nur ein paar Design Entscheidungen, die ich bei der Gestaltung der Architektur identifiziert habe. Es ist nicht eine vollständige Liste der Taktiken. Da das System entwickelt wird, sollten zusätzliche Taktiken auf mehreren Ebenen der Granularität eingesetzt werden, um funktionale und nicht-funktionale Anforderungen zu erfüllen. Unten sind drei Diagramme, die das Disruptor-Designmuster, das Filterentwurfsmuster und die kontinuierliche Abfragekomponente beschreiben. Verhaltensansicht Diese Ansicht einer Architektur zeigt, wie die Komponenten und Ebenen miteinander interagieren sollen. Dies ist hilfreich bei der Erstellung von Szenarien zum Testen von Architekturentwürfen und zum Verständnis des Systems von Ende zu Ende. Diese Ansicht besteht aus Sequenzdiagrammen und Aktivitätsdiagrammen. Aktivitätsdiagramme, die den internen Prozess der algorithmischen Handelssysteme zeigen und wie Händler mit dem algorithmischen Handelssystem interagieren sollen, sind nachfolgend dargestellt. Technologien und Rahmenbedingungen Der letzte Schritt beim Entwerfen einer Softwarearchitektur besteht darin, mögliche Technologien und Rahmenbedingungen zu identifizieren, die zur Verwirklichung der Architektur genutzt werden könnten. Grundsätzlich ist es sinnvoll, bestehende Technologien auszuschöpfen, sofern sie sowohl funktionale als auch nicht funktionale Anforderungen adäquat erfüllen. Ein Framework ist eine realisierte Referenzarchitektur, z. B. JBoss ist ein Framework, das die JEE-Referenzarchitektur realisiert. Die folgenden Technologien und Frameworks sind interessant und sollten bei der Implementierung eines algorithmischen Handelssystems berücksichtigt werden: CUDA - NVidia verfügt über eine Reihe von Produkten, die eine hochleistungsfähige Computational Finance Modellierung unterstützen. Man kann bis zu 50x Performance-Verbesserungen in der Ausführung von Monte Carlo Simulationen auf der GPU anstelle der CPU erreichen. Apache River - River ist ein Tool-Kit zur Entwicklung verteilter Systeme. Es wurde als Rahmen für den Aufbau von Anwendungen auf der Grundlage der SBA-Muster Apache Hadoop - für den Fall, dass pervasive Logging ist eine Anforderung, dann die Verwendung von Hadoop bietet eine interessante Lösung für die Big-Data-Problem. Hadoop kann in einer Clusterumgebung eingesetzt werden, die CUDA-Technologien unterstützt. AlgoTrader - eine Open-Source-algorithmische Handelsplattform. AlgoTrader könnte an Stelle der automatisierten Händlerkomponenten eingesetzt werden. FIX Engine - eine eigenständige Anwendung, die die Financial Information Exchange (FIX) - Protokolle einschließlich FIX, FAST und FIXatdl unterstützt. Obwohl es sich nicht um eine Technologie oder ein Framework handelt, sollten Komponenten mit einer API (Application Programming Interface) aufgebaut werden, um die Interoperabilität des Systems und seiner Komponenten zu verbessern. Fazit Die vorgeschlagene Architektur wurde entwickelt, um sehr allgemeine Anforderungen für algorithmische Handelssysteme zu erfüllen. Im Allgemeinen werden algorithmische Handelssysteme durch drei Faktoren kompliziert, die bei jeder Implementierung variieren: Abhängigkeiten von externen Unternehmen und Tauschsystemen Herausforderung an nicht funktionale Anforderungen und Entwicklung von architektonischen Zwängen Die vorgeschlagene Softwarearchitektur müsste daher im Einzelfall von Fall zu Fall angepasst werden Um spezifische organisatorische und regulatorische Anforderungen zu erfüllen sowie regionale Zwänge zu überwinden. Die algorithmische Handelssystemarchitektur sollte nur als Referenz für Einzelpersonen und Organisationen betrachtet werden, die ihre eigenen algorithmischen Handelssysteme entwerfen wollen. Für eine vollständige Kopie und Quellen verwendet, laden Sie bitte eine Kopie meines Berichts. Vielen Dank.