diff --git a/config.yaml b/config.yaml index d6321fd37f92321f46ba3d8224729782b260bc72..4a8ceef97e140d05ece66379153f58adfdbd1e49 100644 --- a/config.yaml +++ b/config.yaml @@ -9,7 +9,7 @@ surname: Nicolas keywords: [Thèse, Bachelor, Nicolas, Paschoud, HEPIA] orientation: Logiciels et systèmes complexes year: 2020 -sensei: Joël Cavat +sensei: Cavat Joël / Albuquerque Paul mandator: Aucun frontLogoSourceURL: http://svn.apache.org/repos/asf/kafka/site/logos/originals/png/ dedicasse: Dédicace à l'équipe diff --git a/figs/create/frontend-colors.png b/figs/create/frontend-colors.png index 95f589cc739853d037dfa0739ac3c3b3df987636..087931dd5b28109d353b9460f6e71cf64da7c1a3 100644 Binary files a/figs/create/frontend-colors.png and b/figs/create/frontend-colors.png differ diff --git a/figs/create/frontend-global.png b/figs/create/frontend-global.png index 5d0d86b5b85758b3c3d51c5af24ab9ff7c46b13e..4a7e7835d728b1a710b05fc2aa2132e12a14935f 100644 Binary files a/figs/create/frontend-global.png and b/figs/create/frontend-global.png differ diff --git a/figs/data/extrait-BTCUSD.png b/figs/data/extrait-BTCUSD.png new file mode 100644 index 0000000000000000000000000000000000000000..6a4d68e146024281a1d72420a9aab0b7e95a3152 Binary files /dev/null and b/figs/data/extrait-BTCUSD.png differ diff --git a/figs/data/random-profit-fake500.png b/figs/data/random-profit-fake500.png new file mode 100644 index 0000000000000000000000000000000000000000..c9a006da9e275d906fc9390edd0cab159fa74986 Binary files /dev/null and b/figs/data/random-profit-fake500.png differ diff --git a/text/a-preface.md b/text/a-preface.md index 4fa5b7e42b65be76b6fcff0e524e664bbb813406..a58d0464a502edb5553563eb125352125c5b70fd 100644 --- a/text/a-preface.md +++ b/text/a-preface.md @@ -8,14 +8,41 @@ Remerciements aussi à Mr. Florian Secretan qui m'a créé une stratégie de tra Merci à Mr. Théo Pirkl pour le template qu'il nous a mis à disposition pour la rédaction de nos travaux. # Enoncé du sujet {-} +\begin{center} +\textbf{\Large{Orientation : Logiciels et systèmes complexes}} +\end{center} -< Insérez ici la page d’énoncé complété et signé par l’enseignant-e responsable (cf. feuille de style fournie) > -(obligatoire) +**Descriptif :** + +L'objectif du projet est de mettre à disposition une architecture distribuée à une communauté d'utilisateurs souhaitant réaliser leurs propres algorithmes décisionnels. L'architecture devra être décentralisée et permettre une communication asynchrone et non bloquante. Une API mettra à disposition les fonctionnalités et l'abstraction nécessaire à la réalisation d'agents. Plusieurs algorithmes devront être mis en œuvre pour prouver que l'utilisation de l'API est intuitive. Les stratégies à étudier seront l'IA symbolique (gofai) avec la logique floue, décisions aléatoires et algorithmes naïfs, l'apprentissage supervisé et non supervisé avec un algorithme génétique. Ce projet se focalise sur les traitements numériques, l’architecture logicielle et la mise à disposition d'API afin de permettre la comparaison de différentes stratégies d’IA. La réalisation proposera un toolkit aux personnes intéressées au développement d'algorithmes décisionnels. + +**Travail demandé :** + +Dans les limites du temps disponible, les tâches suivantes seront abordées : +\begin{itemize} +\item Mise en œuvre d'un cluster Kafka pour la communication et la persistance des données +\item Récupération des données OHLC et asks/bids spécifiques à l'analyse boursière +\item Transformation des données pour proposer des signaux existants (moyennes glissantes, bandes de Bollinger, RSI, ...) +\item Mise à disposition d'une API ou DSL pour la réalisation de ses propres algorithmes +\item Mise en œuvre d'algorithmes de recommandation d'achat ou de vente d'actions +\item Visualisation des performances de n'importe quel agent en temps réel +\item Possibilité de gérer un portefeuille existant +\end{itemize} + + + +\begin{tabular}{ p{3cm} p{1cm} p{1cm} p{6cm} } + \multicolumn{1}{l}{Candidat :}& & & \multicolumn{1}{l}{Professeur-e(s) responsable(s) :}\\ + \multicolumn{1}{l}{\textbf{Nicolas PASCHOUD}} & & & \multicolumn{1}{l}{\textbf{Cavat Joël / Albuquerque Paul}} \\ + \multicolumn{1}{l}{Filière d'études : ITI} & & & \multicolumn{1}{l}{Travail de Bachelor soumis à une convention de stage en} \\ + \multicolumn{1}{l}{} & & & \multicolumn{1}{l}{entreprise : non} \\ + \multicolumn{1}{l}{} & & & \multicolumn{1}{l}{Travail soumis à un contrat de confidentialité : non} \\ +\end{tabular} # Résumé {-} -La quantité de données voyageant à travers internet se faisant de plus en plus grande, apprendre à maîtriser des flux de données se fait de plus en plus important. Le monde de la finance est l'un des domaines où l'on trouve des quantités de données important. En effet, la quantité d'informations qui voyagent entre les acteurs des marchés est gigantesque et grandit d'année en année de par l'accès faciliter à ces marchés au grand publique. -Sur les marchés seuls une petite partie des entités active s'avère être des intelligences artificielles très basique qui jouent le rôle de stabilisateurs. Bien que très basique, ces IA ont un impact sur les marchés. Il est cependant parfois compliquer pour un humain d'analyser différentes données relatant un marché en un temps raisonnable. Les ordinateurs ont en revanche cette capactié de traitement, bien programmé, un algorithme pourrait possiblement être aussi efficace, voir plus, qu'un humain. -Pour valider une telle théorie, il faut trouver une nouvelle approche aux traitements de données et de flux de données. Développer de nouveaux outils performant et simple afin de tester un grand nombre d'algorithme. Un outil de gestion qui permet de gérer ces algorithmes et de visualiser leur performance. Offrir un tel outil est l'objectif de ce projet, proposer une API et des outils de gestion d'acteurs. Cette API offrira la possibilité de créer des algorithmes de trading en traitant les informations d'une manière différente et innovante. L'objectif de l'API est de permettre au développeur de ce focaliser sur la création d'intelligence artificielle. Elle permet à ces IA d'être exécutée sans avoir à se soucier du processus de déployement qui est offert par l'API. +La quantité de données qui voyagent à travers internet est colossale. Les marchés financiers sont parmis les plus gros générateurs de données. +Sur les marchés, seule une petite partie des acteurs s'avère être des intelligences artificielles très basiques qui jouent le rôle de stabilisateurs. Ces IA ont un impact sur les marchés et permettent de les stabiliser. Il est parfois compliqué pour un humain d'analyser les différentes données d'un marché en un temps raisonnable. Les ordinateurs ont en revanche cette capacité de traitement et un algorithme pourrait être aussi efficace, voir meilleur qu'un humain. +Pour valider une telle théorie une grande quantité d'algorithmes devront être réalisés. Pour ce faire, il faut utiliser des outils innovants qui repensent la manière dont les flux de données sont traités. En se basant sur ces principes, des outils doivent être développés, permettant la création rapide d'algorithmes de quelconque complexité. Offrir un tel outil est l'objectif de ce projet, proposer une API et des outils de gestion permettant de créer et gérer des stratégies de trading. Cette API offrira la possibilité de créer des algorithmes de trading en traitant les informations d'une manière différente et innovante. Elle permettra au développeur de se focaliser sur la création d'intelligences artificielles en lui offrant une infrastructure sur laquelle il pourra exécuter ces algorithmes sans avoir à se soucier de la complexité de déploiement. \begin{figure} \vspace{.25cm} @@ -26,7 +53,7 @@ Pour valider une telle théorie, il faut trouver une nouvelle approche aux trait \end{figure} \begin{tabular}{ p{3cm} p{1cm} p{1cm} p{6cm} } \multicolumn{1}{l}{Candidat :}& & & \multicolumn{1}{l}{Professeur-e(s) responsable(s) :}\\ - \multicolumn{1}{l}{\textbf{Nicolas PASCHOUD}} & & & \multicolumn{1}{l}{\textbf{Joël Cavat}} \\ + \multicolumn{1}{l}{\textbf{Nicolas PASCHOUD}} & & & \multicolumn{1}{l}{\textbf{Cavat Joël / Albuquerque Paul}} \\ \multicolumn{1}{l}{Filière d'études : ITI} & & & \multicolumn{1}{l}{Travail de Bachelor soumis à une convention de stage en} \\ \multicolumn{1}{l}{} & & & \multicolumn{1}{l}{entreprise : non} \\ \multicolumn{1}{l}{} & & & \multicolumn{1}{l}{Travail soumis à un contrat de confidentialité : non} \\ diff --git a/text/c-introduction.md b/text/c-introduction.md index f3c02e377f743ed0863a41af436dcc53c1eafec6..59e310646ee1b18b8707a6a075c2824d0a03b69c 100644 --- a/text/c-introduction.md +++ b/text/c-introduction.md @@ -1,31 +1,38 @@ \pagenumbering{arabic} # Introduction {-} -La quantité de flux financiers qui voyagent à travers internet étant très grande, il est difficile de traiter chaque information. Aujourd'hui dans le trading, le trader qui gagne est celui qui a accès aux informations et qui les traitent avant les autres. Afin de traiter de telles quantités de données et offrir une vision globale du marché, les technologies du domaine de l'informatique peuvent être utiles et offrir un avantage certain à celui qui les maîtrise correctement. +La quantité de flux financiers qui voyagent à travers internet étant très grande, il est difficile de traiter chaque information. Aujourd'hui dans le trading, le trader qui gagne est celui qui a accès aux informations et qui les traite avant les autres. Afin de traiter de telles quantités de données et offrir une vision globale du marché, les technologies du domaine de l'informatique peuvent offrir un avantage certain à celui qui les maîtrise correctement. Il faut cependant utiliser les bonnes technologies, celles capables de traiter de grandes quantités d'informations en des temps très courts. + +*(Une amorce. Elle permet d'accrocher l'intérêt du lecteur. L'introduction donne ensuite une vision générale du projet.)* ## Motivations {-} -L'objectif de ce projet est de concilier traitement de flux de données, architectures distribuées et intelligences artificielles afin d'offrir une plateforme de développement d'algorithme. L'objectif de cette plateforme sera d'offrir un service sur lequel il sera possible de tester, déployer et analyser des stratégie de trading informatiques. +L'objectif de ce projet est de concilier traitement de flux de données, architectures distribuées et intelligences artificielles afin d'offrir une plateforme de développement d'algorithmes. L'objectif de cette plateforme sera d'offrir un service sur lequel il sera possible de tester, déployer et analyser des stratégies de trading de différentes complexités. + +*(Pourquoi je fais ça)* ## Problématique {-} -Pour mettre à disposition une telle plateforme il faudra utiliser des technologies puissantes qui répondent à ces besoins spécifiques. +Pour mettre à disposition une telle plateforme il faudra utiliser des technologies puissantes qui répondent à des besoins spécifiques. Ces outils devront être capables de traiter des flux de données importants. Leur capacités à être distribués est un point crucial afin de permettre à ces stratégies d'être exécutées en continu. Le critère de distribution est important car il permet de garantir l'exécution même en cas de panne. -J'expliquerai ici la situation d'aujourd'hui; notre capacité à obtenir des informations à très grande vitesse, -l'ultraconnectivité, le paradoxe humain-machine et les problèmes qui en résultent. +*(J'expliquerai ici la situation d'aujourd'hui; notre capacité à obtenir des informations à très grande vitesse, l'ultraconnectivité, le paradoxe humain-machine et les problèmes qui en résultent.)* ## Présentation du projet {-} -Ce projet a pour but d'offrir une API aux développeurs qui souhaitent développer, tester et déployer des intelligences artificielles autour du domaine de la finance et plus particulièrement du trading. L'API offre la possibiliter de récupérer des données boursières stockée dans une base de données distante et de les traiter. Ce traitement pourra se faire de manière simple grâce à des outils innovant et facile d'utilisation. +Ce projet a pour but de mettre à disposition des utilisateurs une API ainsi qu'une architecture distribuée leur permettant de développer, tester et comparer des stratégies de trading. La plateforme mettra à disposition, différentes données boursières provenant de différents actifs grâce au système de stockage distribué Kafka développé par la fondation Apache Software. L'ensemble de l'API est développé à l'aide des libriaires Akka développées par Lightbend. Ces librairies permettent de créer des applications hautement concurentes, distribuées, résilientes basées sur un système de messagerie. Kafka aura pour but de distribuer les données aux agents Akka déployés sur un cluster. + +*(Une présentation en quelques lignes du projet, ce qu'il permet de faire.)* ## Approche méthodologique {-} -Afin de traiter les énormes quantités de données générées par les marchés une nouvelle approches doit être faites. Le concept de programmation de stream processing à été mis en avant pour ce projet. Ce concept de programmation permet de traiter des flux de données en théorie infinis. +L'ensemble du système est imaginé et conçu autour des concepts de traitement de flux de données numériques et des systèmes distribués. -## Structure du projet {-} -Ce projet mets à disposition des une API permettant de créer et tester des algorithmes de trading de quelconque complexiter. Grâce à une architecture distribuée et une manière simple de gérer les flux de données grâce aux librairies AKKA, le développeur peut créer ses algorithmes et les déployés sur un cluster de machines. Ce cluster permet aux algorithmes de fonctionner en tout temps grâce à un support de la monter en charge et la résistance à la panne. +*(Quelle a été ma façon d'amener la solution que je propose dans ce projet.)* -Cette API mets à disposition des sources de données boursières stocker dans une base de données. Pour faciliter le développement, des indicateurs boursiers son à disposition du développeur pour lui permettre de faire ces algorithmes de trading. +## Structure du projet {-} +Le produit final est une API ainsi qu'une plateforme sur laquelle il est possible de créer et déployer des stratégies de trading. Grâce à une architecture distribuée et une manière simple de gérer les flux de données à l'aide des librairies AKKA, le développeur peut créer ses algorithmes et les déployers sur un cluster facilement. Ce cluster permet aux algorithmes de fonctionner en tout temps grâce à un support de la montée en charge et une forte tolérance aux pannes. -Pour faciliter le développement et diminuer la quantité de travail que l'utilisateur doit accomplir, il n'a qu'une seule fonction à programmer. Le déploiement des stratégie ainsi que leur exécution est géré par l'API. +Le service stocke et met à disposition des données boursières de différents actifs financiers. Ces données sont facilement récupérables grâce à l'API. Certains indicateurs techniques réputés sont à disposition des utilisateurs afin de manipuler les données facilement. -*(Quels sont les modules, les unités organisationelles de chaque système et sous-système, un glossaire général)* +Pour faciliter le développement et diminuer la quantité de travail que l'utilisateur doit accomplir, il n'y a qu'une seule fonction à programmer. Le déploiement des stratégies ainsi que leur exécution est géré par l'API et l'infrastructure. +*(Quels sont les modules, les unités organisationelles de chaque système et sous-système, +un glossaire général.)* \pagebreak \ No newline at end of file diff --git a/text/d-sujet.md b/text/d-sujet.md index a91c47610c8da6be0291d85b038fdddcea3d8c65..7a9757f115674f5cc30f776de1da3d0aff88a595 100644 --- a/text/d-sujet.md +++ b/text/d-sujet.md @@ -21,6 +21,8 @@ Il existe différents marchés sur lesquel différent types d'actifs sont échan Tous ces marchés ont leurs spécificités et les actifs échangés sur ces marché sont tous différents. Le service fournira les données de seulement trois de ces marchés. +\newpage + ### Le marché des changes {-} Le marché des changes est l’un des marchés les plus importants dans le monde de la finance. Sur ce marché sont échangées les monnaies du monde entier. Il est d’une importance cruciale car les monnaies sont le cœur même de l’économie. Ce sont des marchés stable afin d'offrir aux pays et acteurs de leurs économies (ménages, entreprises) la possibilité d'investir de l'argent à l'étranger. Le marché des changes est le plus gros marché financier par volume echangé par jours et peut monter à une valeur de plus de 5 trillions de dollars en une journée. @@ -52,7 +54,7 @@ Le candlestick, ou chandelier japonais, est un élément graphique qui permet de On peut au travers de cet exemple se représenter plus facilement ce qu'il s'est passé sur cet actif durant les dernières 24 heures de trading. -Le volume échangé est une informations complémentaire à l'OHLC et apporte des données intéressante au trader. Elle représente la quantité de contrats ou d’actions échangées entre un acheteur et un vendeur durant une période de temps donnée. Par exemple, lorsque cinq transactions sont effectuées en l'espace de une minutes le volume sera égal à cinq. Différents indicateurs techniques se basent sur le volume pour déterminer l'évolution et les tendances d'un marché. +Le volume échangé est une informations complémentaire à l'OHLC et apporte des données intéressante au trader. Elle représente la quantité de contrats ou d’actions échangées entre un acheteur et un vendeur durant une période de temps donnée. Par exemple, lorsque cinq transactions sont effectuées en l'espace d'une minute, le volume sera égal à cinq. Différents indicateurs techniques se basent sur le volume pour déterminer l'évolution et les tendances d'un marché. ## L'analyse technique {-} L’analyse technique est, dans le domaine de la finance, l’étude du cours d’un actif. Cette étude passe par de l’analyse statistique se basant sur l’historique de prix et du volume échangé. Elle est à la base du trading et fournit aux traders des informations cruciales qui leurs permettent de prédire les tendances des marchés. Elle forme la base théorique et pratique du métier de trader. @@ -113,7 +115,7 @@ Une moyenne mobile indique au trader la moyenne du cours sur un certain nombre d Ce graphique présente deux moyennes mobiles, l'une sur 200 jours et l'autre sur 50 jours. La première est dites, de par le nombre de période choisi, longue et la secondes courte. Il est fréquent d'utiliser deux moyennes mobiles comme dans l'exemple ci-dessus car cela permet de voir ou la tendance va s'inverser. -Dans ce cas on aperçoit un point nommé "Golden cross". Ces points de croisement entre les différentes moyennes mobiles servent de declencheur et indique au trader la tendance du marché. +Dans ce cas on aperçoit un point nommé "Golden cross". Ces points de croisement entre les différentes moyennes mobiles servent de declencheur et indique au trader la tendance du marché et le type de mouvement à effectuer. La (+MACD_a) permet de repérer les points vers lesquels la tendance risque de s’accélérer. Elle est calculée sur de longues périodes (entre 12 et 26 jours). La MACD s’obtient en faisant la différence entre une EMA de 26 jours et une EMA de 12 jours. @@ -135,6 +137,7 @@ Les bandes de Bollinger est un outil réputé en tant qu'indicateur de volatilit Les trois bandes sont calculées à l’aide de (+MA_a). La bande centrale est une simple (+MA_a). En ce qui concerne les deux autres bandes, un simple décalage est appliqué au calcul de la moyenne afin d’avoir une zone de taille variable. Ce calcul permet d'afficher une zone de taille dynamique dans laquelle évolue le cours. Plus ces bandes s'éloignent les unes des autres, plus la volatilité est grande et plus il sera facile de faire du bénéfice rapidement. +\newpage \cimg{figs/bollinger.png}{scale=0.25}{Exemple de bande de Bollinger sur le cours BTC/EUR}{Source : trade.kraken.com \url{https://trade.kraken.com/fr-fr/markets/kraken/btc/eur/1m}, ref. URL08} Les bandes de Bollinger suivent donc le cours. Lorsque le cours est stable, les bandes se rapprochent et restent à distance égale les unes des autres. diff --git a/text/e-get-data.md b/text/e-get-data.md index 46741d577beb1acb1f860d4137d4388d71fbd6a9..3345d5e0b4c7d1dcfa7c9c383cdb135f9eb27508 100644 --- a/text/e-get-data.md +++ b/text/e-get-data.md @@ -1,38 +1,37 @@ # Récupération des données boursières {-} -Le service met à disposition des utilisateurs des informations boursière de différents acrifs. Pour pouvoir mettre à disposition de tel données, il faut les récupérer et les stocker. La récupération des données se fait via sources externe mettant à disposition des (+API_a) offrant un accès à ces données. Ces API mettent à disposition des données en continue ce qui permet de récupérer l'ensemble des ordres et activités qui ont lieu sur les marchés. +Le service met à disposition des utilisateurs des informations boursières de différents actifs. Pour pouvoir mettre à disposition de tels données, il faut les récupérer et les stocker. La récupération des données se fait via des sources externes mettant à disposition des (+API_a) offrant un accès à ces données. Ces API mettent à disposition des données en continue ce qui permet de récupérer l'ensemble des ordres et activités qui ont lieu sur les marchés. ## Order Book {-} -Un Order book est une liste électronique d'ordres d'achat et de vente d'un certain actif financier organisé en niveau de prix. Il répertorie l'ensemble des ordres d'achat ou de vente et permet d'identifier les acteurs du marché derrière chaque ordre. [@kenton_order_2020] +Un Order book est une liste électronique d'ordres d'achat et de vente d'un certain actif financier organisé en niveau de prix. Il répertorie l'ensemble des ordres d'achat et de vente et permet d'identifier les acteurs du marché derrière chaque ordre. [@kenton_order_2020] -\cimg{figs/order-book-kraken-btcusd.png}{scale=0.5}{Exemple d'order book sur la plateforme Kraken pour l'actif Bitcoin / Dollar}{Source : kraken.com \url{https://trade.kraken.com/fr-fr/charts/KRAKEN:BTC-USD}, ref. URL01} +\cimg{figs/order-book-kraken-btcusd.png}{scale=0.4}{Exemple d'order book sur la plateforme Kraken pour l'actif Bitcoin / Dollar}{Source : kraken.com \url{https://trade.kraken.com/fr-fr/charts/KRAKEN:BTC-USD}, ref. URL01} Ce book est très utile pour les traders et institutions ayant une certaine capacité de traitement des données. En effet, en identifiant les entités actives sur un marché, il est possible de reconnaître leurs comportements et donc de les contrer. C'est un avantage conséquent que de connaître les faits et gestes de ses adversaires, cela permet d'anticiper leurs actions afin de les contrer ou d'agir en même temps qu'eux. Les Order Book contiennent des informations précieuse mais difficile à traiter pour un humain. En ayant les bonnes informations, il est possible pour une intelligence artificielle d'apprendre le comportement d'une entité d'un marché et de faire des recommandations d'achat. ## Kraken {-} -Kraken est une plateforme de trading qui propose différents services en lien avec les crypto-monnaies. Le service principal de cette plateforme est le trading en temps réel des crypto-monnaies présentes sur la plateforme (Bitcoin, Ethereum, etc.). Pour les développeurs, Kraken propose une API ainsi qu’un WebSocket pour accéder directement aux fonctions de leur plateforme ainsi que les données des actifs. L' (+API_a) permet entre autres de récupérer l’historique des échanges pour une paire de monnaies donnée, l’historique de vos propres transactions, etc. Leur service permet aux utilisateurs de récupérer l’historique d’un actif. +Kraken est une plateforme de trading qui propose différents services en lien avec les crypto-monnaies. Le service principal de cette plateforme est le trading en temps réel des crypto-monnaies présentes sur la plateforme (Bitcoin, Ethereum, etc.). Pour les développeurs, Kraken propose une API ainsi qu’un WebSocket permettant d'accéder directement aux fonctionnalités de leur service ainsi qu'a l'historique de données OHLC des actifs. L' (+API_a) permet entre autres de récupérer l’historique des échanges pour une paire de monnaies donnée, l’historique de ses propres transactions, etc. -L' (+API_a) de Kraken met à disposition l’historique (+OHLC_a) d'un actif de crypto-monnaies. Il est possible de choisir l’intervalle de temps qui sépare chaque donnée. Les intervalles disponible sur le service sont 1, 5, 15, 30, 60, 240, 1440, 10080 et 21600 minutes. Il faut cependant faire attention, seul les 720 dernières entrées des actifs sont disponibles et cela est valable quelque soit l’intervalle de temps choisi. Il est donc nécessaire de régulièrement faire appel au service pour récupérer tout l’historique d’un actif sur l’intervalle de temps souhaité. +L' (+API_a) de Kraken met à disposition l’historique (+OHLC_a) d'un actif de crypto-monnaies. Il est possible de choisir l’intervalle de temps qui sépare chaque donnée. Les intervalles disponibles sur le service sont 1, 5, 15, 30, 60, 240, 1440, 10080 et 21600 minutes. Il faut cependant faire attention, seules les 720 dernières entrées des actifs sont disponibles et cela est valable quel que soit l’intervalle de temps choisi. Il est donc nécessaire de régulièrement faire appel au service pour récupérer tout l’historique d’un actif sur l’intervalle de temps souhaité. -Dans le cadre de ce projet et pour avoir le plus de données possible, l'intervalle de temps entre les informations de l'OHLC devra être le plus petit possible. Ici, le plus petit intervalle disponible est d’une minute. Il faudra donc mettre en place un système permettant de récupérer les données de manière régulière. +Afin d'offrir un ensemble de données complet et précis, l'intervalle de temps entre chaque l'OHLC devra être le plus petit possible. Ici, le plus petit intervalle disponible est d’une minute. Un service sera donc mis en place afin de récupérer de manière régulière l'ensemble des données. Voici la structure de données retournée par l'API \cimg{figs/kraken-api-ohlc.png}{scale=0.5}{Messages de retour de l'historique OHLC}{Source : kraken.com \url{https://www.kraken.com/features/api\#get-ohlc-data}, ref. URL10} -Dans ce message, on retrouve l'ensemble de la structure OHLC ainsi que le volume. Ces données subiront quelques transformations afin de correspondre à un format générique qui sera défini à la fin de ce chapitre. +Dans ce message, on retrouve l'ensemble de la structure OHLC ainsi que le volume. Ces données subiront quelques transformations afin de correspondre à un format générique défini à la fin de ce chapitre. -L'Order Book des marchés de Kraken sera lui récupéré via WebSocket. La structure de retour de leur API se présente sous cette forme. +L'Order Book des marchés de Kraken sera lui récupéré via WebSocket. La structure du message de retour se présente sous cette forme. -\cimg{figs/kraken-ws-ob.png}{scale=0.25}{Structure de message websocket pour l'Order Book Kraken}{Source : doc.kraken.com \url{https://docs.kraken.com/websockets/\#message-book}, ref. URL11} +\cimg{figs/kraken-ws-ob.png}{scale=0.25}{Structure de message WebSocket pour l'Order Book Kraken}{Source : doc.kraken.com \url{https://docs.kraken.com/websockets/\#message-book}, ref. URL11} On retrouve dans cette structure l'ensemble des Aks / Bid pour un certain prix et un certain volume. Tout comme les données OHLC, ces données subiront des modifications afin de pouvoir être stockées selon un format générique. ### Les limtes de l'API {-} -Comme chaque (+API_a) que l'on peut trouver sur internet, Kraken à ses propre règles en terme de limitations lors de l'accès à ses services. Les limites mise en place par le service ne sont pas contraignante. +Chaque (+API_a) que l'on peut trouver sur internet possède des règles de limitations d'appel au service fournit. Les limites mises en place par le service ne sont pas contraignantes. Les règles imposées par Kraken fonctionnent de la manière suivante. -Les limites imposées par Kraken fonctionnent de la manière suivante. Chaque utilisateur de l'(+API_a) a un compteur, il est initialisé à 0. Pour chaque appel à l'(+API_a), ce compteur va être incrémenté d’un chiffre allant de zéro à deux. Ce compteur est décrémenté, sans abonnement, d’un toutes les trois secondes et la limite à ne pas atteindre est de 15. Si cette limite est dépassée, l’utilisateur sera bloqué pendant 15 minutes. La récupération de l'historique OHLC ne coûte qu’un par appel. Mais il faudra faire attention à ne pas dépasser la limite car l’historique n’enregistre que les 720 dernières minutes du cours. Des abonnements payants sont proposés afin d’augmenter cette limite. ## Alphavantage {-} @@ -43,11 +42,11 @@ Alphavantage est un service mettant à disposition une (+API_a) permettant de r \item Le marché des crypto-monnaies \end{itemize} -A l’inverse de Kraken, Alphavantage permet par exemple de récupérer les informations de l’action TLSA (action de l’entreprise Tesla) ou encoe AAPL (action de l’entreprise Apple). Il est aussi possible de récupérer les informations du cours du franc suisse face au dollar ou du franc suisse face à l’euro. Leur (+API_a) même la possibilité de récupérer des indicateurs technique d'un actif donné. Alphavantage limite, tout comme Kraken, les appels à leur (+API_a). +A l’inverse de Kraken, Alphavantage permet par exemple de récupérer les informations de l’action TLSA (action de l’entreprise Tesla) ou encoe AAPL (action de l’entreprise Apple). Il est aussi possible de récupérer les informations du cours du franc suisse face au dollar ou du franc suisse face à l’euro. Leur (+API_a) offre même la possibilité de récupérer des indicateurs technique d'un actif donné. Alphavantage limite, tout comme Kraken, les appels à leur (+API_a). Leurs règles de limitaion sont plus simple que celle de Kraken. Le nombre d’appels est limité à 500 par jours et à cinq par minutes. Il est cependant possible d’augmenter ces limites via un abonnement payant. -L’API propose deux formats de retour : format (+JSON_a) et format (+CSV_a). Les données OHLC sur l'intervalle de une minute sont stockées pendant sept jours. Voici un exemple de données OHLC au format CSV retourné par leur service. +L’API propose deux formats de retour : le format (+JSON_a) et le format (+CSV_a). Les données OHLC sur l'intervalle de une minute sont stockées pendant sept jours. Voici un exemple de données OHLC au format CSV retourné par leur service. ```shell timestamp,open,high,low,close,volume @@ -58,13 +57,13 @@ timestamp,open,high,low,close,volume On retrouve dans ce message de retour l'ensemble des données permettant de créer la structure OHLC. En complément de l'OHLC, le volume est aussi retourné. -\pagebreak +\newpage ## Bitfinex {-} -Bitfinex est un marché d'échange de crypto-monnaies et de forex appartenant à iFinex Inc. Leur service met à disposition une API offrant un accès à leur plateforme de trading et les informations des marchés. +Bitfinex est un marché d'échange de crypto-monnaies et de forex appartenant à iFinex Inc. Leur service met à disposition une API offrant un accès à leur plateforme de trading et aux informations des marchés. Ce qui est intéressant avec Bitfinex, c'est l'historique de données. A l'inverse de Kraken et Alphavantage, il est possible de récupérer l'historique (+OHLC_a) sur une échelle de temps relativement grande tout en gardant un intervalle de temps de une minute. Il a été possible de remonter l'historique jusqu'à six mois en arrière tout en gardant la même granularité de temps entre les données OHLC. -Une API ainsi qu'un WebSocket sont mis à disposition des utilisateurs du leur service. L'API permet de récupérer l'historique de données sous format de tableau (+JSON_a). +Une API ainsi qu'un WebSocket sont mis à disposition des utilisateurs de leur service. L'API permet de récupérer l'historique de données sous la forme de tableau (+JSON_a). ```shell [ @@ -75,17 +74,18 @@ Une API ainsi qu'un WebSocket sont mis à disposition des utilisateurs du leur s ``` ## Pulling régulier des données {-} -La première étape dans le développement de ce projet, est la récupération de données boursières. En effet, comme vue dans les chapitre précédent dédié à la récupération de ces données, il est difficile d'obtenir un petit intervalle de temps séparant chacune d'entre elles. Pour pouvoir récupérer un maximum d'informations, un script de pulling de données permet de régulièrement faire appel aux API et stocker les données récentes. Ce script est exécuté de manière régulière grâce à l'utilitaire unix crontab. Crontab est un planificateur de tâche qui permet d'exécuter n'importe quel commande shell de manière régulière. +La première étape dans le développement de ce projet, est la récupération de données boursières. En effet, comme vue dans les chapitres précédents, il est difficile d'obtenir un petit intervalle de temps séparant chacune des données OHLC. Pour pouvoir récupérer un maximum d'informations, un script de pulling permet de régulièrement faire appel aux API et de stocker les données. Ce script est exécuté de manière régulière grâce à l'utilitaire unix crontab. Crontab est un planificateur de tâches qui permet d'exécuter n'importe quelle commande shell de manière régulière. -Afin de récupérer un maximum de données et pour s'assurer de n'en perde aucune, le planificateur execute le script de pulling toutes les quatres heures. Les données sont ensuite filtrée pour éviter de stocker les doublons. +Afin de récupérer un maximum de données et pour s'assurer de n'en perde aucune, le planificateur execute le script de pulling toutes les quatres heures. Les données sont ensuite filtrée pour éviter de stocker les doublons avant d'être stockées. ## Les données boursières en temps réel {-} -Parmis les trois plateformes de trading vu précédement, seules deux possèdent un accès au service via Websocket. Ce service est particulièrement intéressant car il permet de trader et d'accèder aux informations des marchés en temps réel. Les websocket sont directements connecter au service de stockage et récupèrent les données OHLC ainsi que l'Order Book. +Parmis les trois plateformes de trading vu précédement, seules deux possèdent un accès au service via Websocket. Ce service est particulièrement intéressant car il permet de trader et d'accèder aux informations des marchés en temps réel. Les WebSockets sont directements connecter au service de stockage et récupèrent les données OHLC ainsi que l'Order Book. -Les deux plateforme proposant un accès à leur service via websocket sont Karken et Bitfinex. Toutes deux offrent la possibilité de récupérer l'Order Book les données (+OHLC_a) en temps réel. +Les deux plateformes proposant un accès à leur service via websocket sont Karken et Bitfinex. Toutes deux offrent la possibilité de récupérer l'Order Book et les données (+OHLC_a) en temps réel. ## Synthèse {-} -Bien que ces API aient des différences notables dans la manière de structurer les données, elles ont en commun une seule et même structure : OHLC. De là, il est facile de définir un format de représentation standard commun à tout le service mis en place. Les données sont donc représenter au format CSV de la manière suivante : +Bien que ces API aient des différences notables dans la manière de structurer les données, elles ont en commun une seule et même structure : OHLC. De là, il est facile de définir un format de représentation standard commun à tout le service. Les données sont donc représentées au format CSV de la manière suivante : + \begin{center} `actif;timestamp;open;high;low;close;volume` \end{center} @@ -97,8 +97,8 @@ Quant aux données de l'order book, une structure au format CSV similaire à cel `asset:timestamp:[a | b]:price:volume` \end{center} -On retrouve dans cette structure les proposition de Ask ou Bid, le prix ainsi que le volume. +On retrouve dans cette structure les propositions de Ask ou Bid, le prix ainsi que le volume. Le troisième élément permet d'indiquer si il s'agit d'un Ask ou d'un Bid. -La structure ayant été définie, il est maintenant possible de récupérer et stocker les données (+API_a). Il faut cependant déployer un système de stockage permformant permettant le traitement de grande quantité d'informations à la fois +La structure ayant été définie, il est maintenant possible de récupérer et stocker les données (+API_a). Il faut cependant déployer un système de stockage performant permettant le traitement de grandes quantités d'informations. \pagebreak \ No newline at end of file diff --git a/text/f-stockage.md b/text/f-stockage.md index 663bfcd6dcfe5a4a34d3c1bda85cad581b4737c9..e2aab2e32c171c9f7b14c23126b7b517bc881089 100644 --- a/text/f-stockage.md +++ b/text/f-stockage.md @@ -1,16 +1,18 @@ # Stockage des données boursière {-} -Le logiciel utilisé afin de stocker et distribuer les données devra être capable de traiter, envoyer, et stocker de manière persistante de très grande quantité de données le plus rapidement possible. Ces critères sont importants car de grandes quantités d'informations sont générées par les marchés financiers. +Le logiciel utilisé afin de stocker et distribuer les données devra est capable de traiter, envoyer, et stocker de manière persistante de très grandes quantités de données en des temps très faibles. ## Présentation de Kafka {-} -Apache Kafka est une plateforme de streaming distribuée développé en Scala par LinkedIn avant d'être donnée à la Apache Software Foundation. Cette plateforme a la capacité d'être déployée en cluster sur une ou plusieurs machines à travers un ou plusieurs datacenter. Ceci offre à Kafka une grande tolérence aux pannes et de réplications des données. Il est capable de traiter des flux de données extrêmement grands sans latence. +Apache Kafka est une plateforme de streaming distribuée développé en Scala par LinkedIn avant d'être donnée à la Apache Software Foundation. Cette plateforme a la capacité d'être déployée en cluster sur une ou plusieurs machines à travers un ou plusieurs datacenter. Ceci offre à Kafka une grande tolérence aux pannes et de réplications des données. Il est capable de traiter des flux de données extrêmement grands sans avec une très faible latence. Voici quelque bénéfices de l'utilisation de kafka : + \begin{itemize} \item Tolérance aux pannes \item Faible latence \item Persistance \end{itemize} -Kafka met à disposition des développeurs cinq API permettant d'accéder au cluster afin de récupérer, produire des messages, connecter un service ou encore administrer celui-ci. +Kafka met à disposition des développeurs cinq API permettant d'accéder au cluster afin de récupérer, produire des messages, connecter un service ou encore administrer administrer le cluster. + \begin{itemize} \item Consumer API \item Producer API @@ -22,48 +24,49 @@ Kafka met à disposition des développeurs cinq API permettant d'accéder au clu Toutes ces API permettent au développeur de travailler aisément autour du cluster et de ses fonctionnalités. ## Fonctionnement de Kafka {-} -Kafka est un message-broker de type publish-subscribe, il a donc la possibilité de recevoir, envoyer ainsi que stocker des données. Pour ce faire, Kafka est basé sur le principe de Topics et de Logs. Ce sont des catégories dans lesquelles les données sont stockées. Ces topics au sein du cluster, sont distribués sur chaque noeud que l'on appelle Broker. Il est généralement déployé sur plusieurs machines distinctes ou encore dans des (+VM_a). +Kafka est un message-broker de type publish-subscribe, il a donc la possibilité de recevoir, envoyer ainsi que stocker des données. Pour ce faire, Kafka est basé sur le principe de Topics et de Logs. Les topics sont des catégories dans lesquelles les données sont stockées. Ces topics sont, au sein du cluster, distribués sur chaque noeud que l'on appelle Broker. Il est généralement déployé sur plusieurs machines distinctes ou encore dans des (+VM_a). ### Zookeeper {-} -Avant de rentrer dans les détails de fonctionnement de Kafka, il faut tout d'abord comprendre ce qu'est Zookeeper. Zookeeper est aussi un logiciel de la Apache Software Foundation, c'est un service de gestion de configuration pour système distribué. Il est indispensable au bon fonctionnement d'un cluster Kafka car il permet de garder un oeil sur chacun des noeuds et sur toutes les partitions de celui-ci. Un cluster Kafka ne pourrait donc pas fonctionner sans Zookeeper. +Avant de rentrer dans les détails de fonctionnement de Kafka, il faut tout d'abord comprendre ce qu'est Zookeeper. Zookeeper est aussi un logiciel de la Apache Software Foundation, c'est un service de gestion de configuration pour système distribué. Il est indispensable au bon fonctionnement d'un cluster Kafka car il permet de garder un oeil sur chacun des noeuds et sur toutes les partitions de celui-ci. Un cluster Kafka ne peut pas fonctionner sans Zookeeper. -Lors du déploiement d'un cluster Kafka, Zookeeper est le premier logiciel qu'il faut configurer. Cette configuration doit se faire avec le plus grand soin car sans lui le cluster ne fonctionnera pas. Il doit avoir connaissance de toutes les adresses IP des machines afin de synchroniser et élire la partition leader du topic au sein du cluster. +Lors du déploiement d'un cluster Kafka, Zookeeper est le premier logiciel qu'il faut configurer. Cette configuration doit se faire avec le plus grand soin car sans lui le cluster ne fonctionne pas. Il doit avoir connaissance de toutes les adresses IP des machines afin de synchroniser et élire les partitions leader de chaque topic. Chaque instance Zookeeper est identifiable à l'aide d'un identifiant unique. ### Topics, logs et partitions {-} -Kafka organise les données sous forme de topic. Un topic est une catégorie / rubrique dans laquelle les données y sont enregistrées. Il est identifié à l’aide d’un nom unique et il peut y en avoir autant que l’on souhaite au sein du cluster. A titre de comparaison, un topic est semblable à la table d’une base de données. Toutes les données relatant un sujet y sont enregistrées. +Kafka organise les données sous forme de topic. Un topic est une catégorie / rubrique dans laquelle les données y sont enregistrées. Il est identifié à l’aide d’un nom unique et il peut y en avoir autant que l’on souhaite. A titre de comparaison, un topic est semblable à la table d’une base de données. Toutes les données relatant un sujet y sont enregistrées. \cimg{figs/topics.png}{scale=0.5}{Exemple d'un topic Kafka au sein d'un seul broker}{Source : Réalisé par Paschoud Nicolas} -Chaque topic est constitué d’une ou plusieurs partitions chacune distribuée à travers les brokers du cluster. Les données sont publiées dans un topic mais distribuées de manière aléatoire entre les partitions. Les messages sont immutables et se suivent dans l'ordre de publication dans la partitions. Il est cependant possible d’ajouter une clé au message afin de les rassembler dans une partition spécifique. L’enregistrement dans les partitions à l’aide d’une même clé se fait de manière transparente par Kafka. Le cluster maintiens un log pour chaque partitions d'un topic dans lequel les données sont enregistrée, ce fichier log se trouve sur le disque de chacun des broker du cluster. +Chaque topic est constitué d’une ou plusieurs partitions, chacune distribuée à travers les brokers du cluster. Les données sont publiées dans un topic mais distribuées de manière aléatoire entre les partitions. L'ordre des messages dans la partition est immutable, chaque message se suit dans l'ordre de publication. Il est cependant possible d’ajouter une clé au message afin de les rassembler dans une partition spécifique. L’enregistrement dans les partitions à l’aide d’une même clé se fait de manière transparente par Kafka. Le cluster maintiens un fichier log pour chacune des partitions d'un topic dans lequel les données sont enregistrées, ce fichier log se trouve sur le disque de chacun des broker du cluster. \cimg{figs/topics-partitions.png}{scale=0.5}{Exemple d'un topic Kafka avec trois partitions}{Source : Réalisé par Paschoud Nicolas} -Chaque message publié dans le cluster se voit attribuer un identifiant unique appelé offset (celui-ci est différent de la clé fournie pour s’assurer que les messages se trouvent dans une même partition). L’offset est unique et n’est attribué qu’une seule fois. Il ne sera jamais associé une seconde fois à un message même si une suppression a lieu. Il est unique et spécifique à une partition, il ne fait sens qu’au sein de celle-ci. L’offset trois de la partition zéro n’est pas le même dans la partition une. +Chaque message publié dans le cluster se voit attribuer un identifiant unique appelé offset (celui-ci est différent de la clé fournie pour s’assurer que les messages se trouvent dans une même partition). L’offset est unique et n’est attribué qu’une seule fois. Il n'est jamais associé une seconde fois à un message même si une suppression a lieu. Il est unique et spécifique à une partition, il ne fait sens qu’au sein de celle-ci. L’offset trois de la partition zéro n’est pas le même dans la partition une. Il est important de noté que l'ordre de lecture des messages au sein d'une partition est garanti mais il ne l'est pas entre les partitions. Chaque message publié dans un topic est soumis à un politique de rétention. De base, celle-ci est fixée à deux semaines mais il est possible de la modifier. En modifiant la politique de rétention d'une certaine manière, il est possible d'indiquer à Kafka que l'on souhaite garder les messages sur une durée de temps infini [@kreps_its_2019]. ## Kafka Cluster {-} -Kafka est généralement déployé sur un cluster de machine ou de (+VM_a), ces machines peuvent se trouver dans des Datacenter différents. +Kafka est généralement déployé sur un cluster de machine ou de (+VM_a), mais ces machines peuvent se trouver dans des datacenter différents. + \cimg{figs/cluster.png}{scale=0.5}{Exemple de cluster et broker avec Consumer et Producer}{Source : Réalisé par Paschoud Nicolas} -Pour répondre à la propriété de tolérance aux pannes, il est possible d’ajouter un facteur de réplication sur les topics. Cela veut dire que les partitions seront répliquées n fois parmi les brokers du cluster. Une partition d’un topic peut donc se retrouver sur plusieurs brokers. Une fois la partition distribuée, un leader de partition est élu dans l’un des brokers. Cette partition à la lourde tâche de gérer les données lorsqu’une demande d’écriture ou de lecture est reçue. +Pour répondre à la propriété de tolérance aux pannes, il est possible d’ajouter un facteur de réplication sur les topics. Cela veut dire que les partitions seront répliquées n fois parmi les brokers du cluster. Une partition d’un topic peut donc se retrouver sur plusieurs brokers. Une fois la partition distribuée, un leader de partition est élu dans l’un des brokers, et elle a donc la lourde tâche de gérer les données lorsqu’une demande d’écriture ou de lecture est reçue. -\cimg{figs/broker-partition.png}{scale=0.5}{Exemple de cluster avec deux topic et un facteur de réplication de un}{Source : Réalisé par Paschoud Nicolas} +\cimg{figs/broker-partition.png}{scale=0.35}{Exemple de cluster avec deux topic et un facteur de réplication de un}{Source : Réalisé par Paschoud Nicolas} -\cimg{figs/leader-broker.png}{scale=0.5}{Exemple de cluster avec un topic ayant deux partitions. Facteur de réplication de deux et élection de la partition leader}{Source : Réalisé par Paschoud Nicolas} +\cimg{figs/leader-broker.png}{scale=0.35}{Exemple de cluster avec un topic ayant deux partitions. Facteur de réplication de deux et élection de la partition leader}{Source : Réalisé par Paschoud Nicolas} -Dans cet exemple, un cluster est constitué de trois broker. Dans ce cluster se trouve un topic ayant deux partitions. Ces deux partitions sont répliquées deux fois à travers les broker et l'un des deux réplicat est élu en tant que partition leader. +Dans cet exemple, un cluster est constitué de trois broker. Dans ce cluster se trouve un topic ayant deux partitions. Ces deux partitions sont répliquées deux fois à travers les broker et l'une des deux répliques est élue partition leader. Si l'un des broker venait à tomber, les autres membres du cluster eux continuent de tourner et de distribuer les données aux clients. Si le borker tombé contenait des partitions leader, un nouveau broker est élu leader. ### Accès au cluster depuis l'exterieur du réseau {-} -Pour pouvoir se connecter au cluster depuis l'extérieur, le client doit avoir les informations des brokers du cluster. -Etant un système distribué, un leader est élu et le client qui se connecte ne sait pas sur quel borker envoyer les données. Pour connaître l'adresse du broker responsable de la partition du topic désiré, il doit accéder à l'un des broker qui lui renverra les metadata concernant le leader [@moffatt_kafka_2019]. +Pour se connecter au cluster depuis l'extérieur, le client doit avoir les informations des brokers du cluster. +Etant un système distribué, un leader est élu et le client qui se connecte ne sait pas sur quel borker envoyer les données. Pour connaître l'adresse du broker responsable de la partition désirée, il doit accéder à l'un des broker qui lui renverra les metadata concernant le leader [@moffatt_kafka_2019]. Les `listeners` sont des port d'écoutes sur lesquels les brokers attendent des informations provenant des autres broker du cluster. -Les `advertised.listeners` sont des listeners à disposition des clients qui souhaitent se connecter depuis l'extérieur du réseau au cluster. Ces listeners permettront auc clients de récupérer les metadata des brokers leader des partitions requises. +Les `advertised.listeners` sont des listeners à disposition des clients qui souhaitent se connecter depuis l'extérieur du réseau au cluster. Ces listeners permettront aux clients de récupérer les metadatas des brokers des partitions souhaitées. Les `advertised.listeners` sont des points d'entrée et de sortie vers et depuis le cluster et offre un accès aux données depuis n'importe ou. ## Publier et consommer des messages {-} Kafka possède deux (+API_a) qui permettent d'accéder aux données du cluster : @@ -71,9 +74,11 @@ Kafka possède deux (+API_a) qui permettent d'accéder aux données du cluster : \item Producer API \item Consumer API \end{itemize} -Producer API permet de se connecter au cluster et de produire des messages dans un topic. Le Consumer lui à l'inverse du producer de récupérer les messages d'un topic. + +Producer API permet de se connecter au cluster et de produire des messages dans un topic. Le Consumer lui à l'inverse du producer, permet de récupérer les messages d'un topic. + \cimg{figs/producer-consumer.png}{scale=0.5}{Exemple de cluster avec consumer et producer pour le topic Bitcoin.}{Source : Réalisé par Paschoud Nicolas} -La méthode de traitement des données utilisée pour la consommation et production de données dans Kafka est faites à l'aide de stream de données. -Cette méthode de fonctionnement est particulièrement intéressante lorsque l'on consomme des données. En effet, lorsque l'on souhaite récupérer des données en temps réel le stream reste ouvert et le client connecté au topic reçoit les données au moment de leur publication. + +La méthode de traitement des données utilisée pour la consommation et production de données dans Kafka est faites à l'aide de stream de données. Cette méthode de fonctionnement est particulièrement intéressante car elle permet un transfert rapide des données sans attente. En effet, les données sont transmises en continu et la vitesse de transmission est dépendante de la vitesse de traitement effectué par la cible. Ce principe de fonctionnement est particulièrement intéressant lorsque l'on souhaite récupérer les données en temps réel. Lorsqu'une connexion avec le cluster est faites, elle peut rester ouverte et se mettre en attente de message. Dès qu'un message est publié, les données sont instantanément consommées par le client \pagebreak \ No newline at end of file diff --git a/text/g-akka.md b/text/g-akka.md index 63c221eb1a9c66f1b8d190fd50f3acd4f81a5933..42eaa82a1bf3c6bf5041a434a243641affc49d3a 100644 --- a/text/g-akka.md +++ b/text/g-akka.md @@ -1,8 +1,9 @@ # Comment traiter les flux de données {-} ## Akka {-} -La librairie AKKA développée et maintenue par Lightbend [^0], est utilisée afin de traiter des flux de données importants. Cette librairie est développée en Scala et tourne sur une (+JVM_a) (il est possible de développer en Java et en Scala). Akka met à disposition des développeurs des API permettants de créer des applications hautement concurentes, distribuées et réactives. +La librairie AKKA développée et maintenue par Lightbend [^0], est utilisée pour le traitement des flux de données et le déploiement d'acteurs. Cette librairie est développée en Scala et tourne sur une (+JVM_a) (il est possible de développer en Java et en Scala). Akka met à disposition des développeurs des API permettants de créer des applications hautement concurentes, distribuées et réactives. Il y a 12 API disponibles mais seulement quelques une d'entre elles sont utiles au développement : + \begin{itemize} \item Akka Actor \item Akka Streams @@ -13,30 +14,32 @@ Il y a 12 API disponibles mais seulement quelques une d'entre elles sont utiles ## Akka Stream {-} Un stream est un processus qui implique le déplacement et la modification de données d’une source vers un puits. Il est comparable à une chaîne de montage ou un robot effectue une opération sur chaque élément du flux. La librairie Akka Stream offre une abstraction haut niveau de ces principes. -### Source {-} +### Source et Puits{-} Une source est un opérateur à une sortie qui envois des données vers les récepteurs (sink) lorsque ceux-là sont prêts. L’envoi de données vers les opérateurs (sink) s’appel downstream. -### Sink {-} -Un sink, ou un puits, est un opérateur à une entrée qui accepte et reçoit des données de l’upstream. L’upstream est connecté au downstream d’une source et le puits peut ralentir la source si il n’est pas capable de traiter le flux dans les délais, cette action s’appelle back-pressure. +Un sink, ou un puits, est un opérateur à une entrée qui accepte et reçoit des données de l’upstream. L’upstream est connecté au downstream d’une source. + +Le downstream peut être ralentit par le sink si le temps de traitement des données ne peut pas être fait dans des délais résonnables. Ce processus de ralentissement est appelé back-pressure. ### Back-pressure {-} -La back-pressure est la manière qu’ont les consommateurs (sink) d’avertir les producteurs (source) qu’ils sont disponibles. La back-pressure permet d’avertir le producteur qu’il n’est pas capable faire le traitement dans les temps et qu’il doit donc ralentir l'envois de données. +La back-pressure est la manière qu’ont les consommateurs (sink) d’avertir les producteurs (source) qu’ils sont disponibles. Ce processus permet aussi d’avertir le producteur qu’il n’est pas capable faire le traitement dans les délais et qu’il doit donc ralentir l'envois de données. ### Flow {-} Un flow ou flux, possède une entrée et une sortie, et permet de connecter un upstream avec un downstream. Les données passant par le flux sont transférées de la source au puits en étant modifiées. Ces flow peuvent être connecter les uns aux autres, ils sont cummulable et cela permet de créer une "chaîne de montage" à travers laquelle les données sont traitées. Dans un exemple simple, un flow connecte une `Source` et un `Sink`. \cimg{figs/akka/akka-flow.png}{scale=0.5}{Exemple de flow de données entre une source et un puit}{Source : Réalisé par Paschoud Nicolas} - -L'ensemble des fonctionnalités offertent par la librairie, permettent de construire des applications de traitements de données performantes sans difficulté. Connecter les uns aux autres, ces outils permettent de créer des flux de données au travers des quels un ensemble de données brute est transformé. Un outils compris dans cette librairie permet de créer des flux de données sous forme de graph. +L'ensemble des fonctionnalités offertent par la librairie, permettent de construire des applications de traitements de données performantes sans difficulté. Connecter les uns aux autres, ces outils permettent de créer des flux de données au travers des quels un ensemble de données brute est transformé. L'un des outils les plus intéressant de cette librairie permet de créer des flux de données en les déssinants sous forme de graph. ## Akka Graph {-} Akka Graph est un outil compris dans la librairie Akka Stream. Cet outil permet de créer des graph de fonctions au travers desquels les données transitent. \cimg{figs/akka/exemple-graph.png}{scale=0.5}{Représentation d'un graph Akka de manière visuel}{Source : akka.io \url{https://doc.akka.io/docs/akka/current/stream/stream-graphs.html}, ref. URL13} + Cet exemple visuel peut se traduire aisément en graph Akka grâce à la syntaxe offerte par la librairie. Le code suivant représente le graph présenté précédemment. + ```scala // Entrée et sortie du graph val in = Source(1 to 10) @@ -55,34 +58,34 @@ ClosedShape Les fonctions `in` et `out` sont les entrées et sorties des données. L'entrée `in` est une `Source` contenant les valeurs de 1 à 10. La sortie `out` est un `Sink` qui n'applique aucun traitement aux données. -Les fonctions `bcast` et `merge` sont des fonctions très utiles qui permettent de séparer ou regrouper les données qui traverse le graph. -La fonction `bcast` offre deux canaux de sorties sur lesquelles les données en entrée sont publiées. -La fonction `merge` est l'opposé de `bcast`. elle prends plusieurs flux en entrée et un flux en sortie. Elle permet de regrouper les données en un seul flux distinct de données. +Les fonctions `bcast` et `merge` sont des fonctions qui permettent de séparer ou regrouper les données qui traverse le graph. +La fonction `bcast` transforme un canal en deux canaux de sorties sur lesquelles les données en entrée sont publiées. +La fonction `merge` est l'opposé de `bcast`, elle prend plusieurs flux en entrée et les transforme en un seul et unique flux de données. -Les quatre fonctions `f1`, `f2`, `f3` et `f4` ont pour rôle de modifier les données en appliquant une addition de 10 à chaque donnée passant à travers. +Les quatre fonctions `f1`, `f2`, `f3` et `f4` ont pour rôle de modifier les données en ajoutant 10 à chacune des données qui transitent. Toutes ces fonctions sont connectées les unes aux autres à l'aide de l'opérateur `~>` (le sens opposé existe aussi : `<~`). Dans cet exemple le graph est dit fermer, c'est à dire qu'il n'est pas possible de le récupérer pour l'utiliser, il s'exécute de lui même sans interagir avec d'autre `Source`, `Sink` ou `Flow` externe. Il est cependant possible de transformer ces graphs en `Source`, `Sink` et `Flow`. - -Cette fonctionnalité offerte par Akka Stream est à la base du fonctionnement de l'API. L'ensemble des fonctionalités offertent par l'API se basent et sont créer à l'aide de Graph Akka. +Cette fonctionnalité offerte par Akka Stream est à la base du fonctionnement de l'API. L'ensemble des fonctionnalités offertes sont créées à l'aide de Graph Akka. ## Akka Actor {-} -Akka Actors est un outil de la librairie Akka qui permet de programmer des acteurs. En informatique, un acteur est une primitive nécessaire à la programmation concurrente. Ces acteurs sont constitués d’un état et d’un comportement. Ils communiquent entre eux exclusivement par messages. En réponse à un message, un acteur peut effectuer du traitement, envoyer d’autre messages ou déployer d’autres acteurs. +Akka Actors est un outil de la librairie Akka qui permet de programmer des acteurs. En informatique, un acteur est une primitive de la programmation concurrente. Ces acteurs sont constitués d’un état et d’un comportement et communiquent entre eux exclusivement par messages. En réponse à un message, un acteur peut effectuer un traitement, envoyer d’autre messages ou déployer d’autres acteurs. Il faut voir une architecture d’acteurs comme une hiérarchie. Le premier acteur va vouloir distribuer son travail et le déléguer. Pour ce faire, celui-ci va déployer d’autres acteurs capables de faire ce travail. Ce processus se fera jusqu’à ce que les tâches à effectuer soient assez petites pour être faites en une seule fois. La modélisation de cette hiérarchie se fait généralement en raisonnant sur les messages qui seront traités, sur la manière dont une erreur sera gérée et quel sera le comportement normal de l’acteur. -Akka propose une abstraction de ce principe en mettant à disposition une librairie pour développer des systèmes concurrents et distribués basés sur ce principe. -ActorSystem est le système qui permet de gérer les acteurs au sein d’une application. Il permet de gérer leur configuration, les événements, les messages ne pouvant être délivrés, etc. Il est le superviseur d’acteurs au sein du système. +Akka propose une abstraction de ce principe en mettant à disposition une librairie de développement de systèmes concurrents et distribués basés sur ces principes. +ActorSystem est le système qui permet de gérer les acteurs au sein d’une application. Il supervise les acteurs en gérant leur configuration, les événements, les messages non délivrés, et toute autres activité qui peut se passer au sein du système. -\pagebreak +\newpage ## Akka Cluster et Cluster Sharding {-} -Akka Cluster est une librairie qui permet de gérer un ensemble d’ActorSystem. Cette librairie permet de faire abstraction d’un réseau de machines et offre ensuite la possibilité de déployer des acteurs à travers celui-ci. Cette librairie fournit un service permettant de regrouper les ActorSystem au sein d’un cluster afin de les gérer. -Cette librairie permettra par la suite de déployer un ensemble d’acteurs sur un grand nombre de machines pour entraîner des IA. Une fois entraînées elles seront mises en condition réelle et se brancheront sur une source de données en temps réel. +Akka Cluster est une librairie qui permet de déployer un cluster capable de gérer des acteurs. Cette librairie permet de faire abstraction d’un réseau de machines pour permettre le déploiement des acteurs sur celui-ci. Ce service permet de regrouper l'ensemble des acteurs au sein d’un cluster pour pouvoir les gérer et leur permettre de s'exécuter. +Elle permet de déployer un ensemble d’acteurs sur un grand nombre de machines afin de tester des (+IA_a). + \cimg{figs/arch-akka-cluster-details.png}{scale=0.5}{Exemple de cluster Akka avec quatre machines}{Source : Réalisé par Paschoud Nicolas} -Un cluster est constitué de noeuds. Un noeud est un membre logique d'un cluster et il peut y en avoir plusieur sur une seule machine et est défini par un tuple *hostname:port:uid*. Le cluster est un ensemble de noeuds rejoins via un système d'adhésion. Parmis cet ensemble de noeuds, un seul est désigné leader et a la tâche de gérer les transitions d'état et d'adhésion. +Un cluster est constitué de noeuds. Un noeud est un membre logique d'un cluster, il peut y en avoir plusieur sur une seule machine et est défini par un tuple *hostname:port:uid*. Le cluster est un ensemble de noeuds rejoins via un système d'adhésion. Parmis cet ensemble de noeuds, un seul est désigné leader et joue le rôle de gérant. Le leader gére les transitions d'état et d'adhésion des différents acteurs du cluster. Cluster Sharding permet de répartir les agents sur le cluster et offre la possibilité d'intéragir avec eux à l'aide de leur identifiant logique sans avoir à se soucier de leur emplacement physique. Dans ce contexte, les acteurs identifiés sont appelé entités. Les entités sont réparties sur plusieurs noeuds du cluster. Elles sont réparties mais il n'y a qu'une seule d'entre elle qui s'exécute. Lorsqu'un message est envoyé à une entité via son identifiant, le cluster se charge de délivrer le message au bon endroit, le développeur n'ayant pas connaissance de son emplacement physique. Si la machine sur laquelle une entité en cours d'exécution venait à tomber, l'une des autres entités présente sur le cluster prendra le relais. diff --git a/text/i-api.md b/text/i-api.md index ea65961c8bfbd5eec64b770668d8c7091f7368fb..2d5e45c5ba29b60d404ef412cdc98169c8147792 100644 --- a/text/i-api.md +++ b/text/i-api.md @@ -1,24 +1,25 @@ # Création de l'API {-} ## Idée générale {-} -L'objectif de cette (+API_a) est de permettre au développeur de créer des stratégies de trading. L'objectif est de viser la simpliciter en utilisant des graphes au travers desquels les données transitent. -L'utilisation de graphes simplifie le développement car cela permet de transposer une idée faite sur papier en code aisément. +L'objectif de cette (+API_a) est de permettre au développeur de créer des stratégies de trading. L'objectif est de viser la simplicité en utilisant des graphes au travers desquels les données transitent. +L'utilisation de graphes simplifie le développement car cela permet de transposer aisément une idée faite sur papier en code. \cimg{figs/soft/exemple-trader-basic.png}{scale=0.5}{Exemple d'un algorithme de trading aléatoire avec Akka Graph}{Source : Réalisé par Paschoud Nicolas} -Cet exemple représente une stratégie de trading aléatoire. Les données boursière transitent jusqu'à la sortie, `Sink[Transaction]`, en passant par des fonctions. Ces données, en passant par ces fonctions, sont modifiées et permettront de décider si il faut acheter ou vendre. +Cet exemple représente une stratégie de trading aléatoire. Les données boursière transites jusqu'à la sortie, `Sink[Transaction]`, en passant par des fonctions. Ces données, en passant par ces fonctions, sont modifiées et permettront de décider si il faut acheter ou vendre. -Les sources de données sont mise à disposition par le cluster Kafka et l'API offre un accès faciliter à ces données. Elle offre aussi un accès au cluster afin de publier les données dans un topic permettant la publication de statistiques d'un acteurs. +Les sources de données sont mises à disposition par le cluster Kafka et l'API offre un accès facilité à ces données. Elle offre aussi un accès au cluster afin de publier les données dans un topic permettant la publication de statistiques d'un acteur. -Cette manière de traiter les données ne sera pas seulement utile pour les trader, mais aussi pour développer des indicateurs techniques comme les (+MA_a), (+RSI_a), etc. L'API offre déjà quelques indicateurs mais aussi une interface sur laquelle se baser afin de créer son propre indicateur spécifique à la stratégie développée. +Cette manière de traiter les données ne sera pas seulement utile pour les traders, mais aussi pour développer des indicateurs techniques comme les (+MA_a), (+RSI_a), etc. L'API offre déjà quelques indicateurs mais aussi une interface sur laquelle se baser afin de créer son propre indicateur spécifique à la stratégie développée. -\pagebreak +\newpage ## Configuration des librairies Akka {-} -L'ensemble des libriaires mise à disposition par Akka doivent être configurées via le fichier `application.conf` qui se trouve dans le dossier `resources` de la hiérarchie du projet sbt. Ce fichier contient d'importante informations qui permettent aux outils Akka de fonctionner correctement et selon les désires de l'utilisateur. +L'ensemble des libriaires mises à disposition par Akka doivent être configurées via le fichier `application.conf` qui se trouve dans le dossier `resources` de la hiérarchie du projet sbt. Ce fichier contient d'importantes informations qui permettent aux outils Akka de fonctionner correctement et selon les désirs de l'utilisateur. Un fichier de configuration de base est présent au sein de chaque projet utilisant les librairie Akka. Il est cependant possible de le personnaliser avec ses propres paramètres. Les paramètres sont organisés par librairie au format (+HOCON_a). + ```shell akka { loglevel = "OFF" @@ -45,35 +46,37 @@ Pour faciliter la vie du développeur, la récupération de la configuration se Cette classe est utilisée par la suite afin de mettre à disposition du développeur des accès à Kafka. -\pagebreak +\newpage ## Les types de données {-} -Comme vu dans le chapitre sur la récupération et le stockage des données, seul deux types de données sont disponible. +Comme vu dans le chapitre sur la récupération et le stockage des données, seuls deux types de données sont disponibles. Le développeur créant sa stratégie de trading a à sa disposition deux types de données pour les actifs présents dans la base de données : `OHLC` et `AskBid`. Ce sont les deux types de données prises en entrée d'une stratégie. \cimg{figs/soft/soft-type.png}{scale=0.5}{Schéma UML des types de données de l'API}{Source : Réalisé par Paschoud Nicolas} -Grâce à l'interface `DataType`, il est possible d'ajouter de nouveau type de données selon les besoins de l'utilisateur. Il peut ainsi personnaliser ses stratégies en ajoutant de nouvelle façon de représenter les données. En revanche, les seuls données brut proposées par le système actuel sont `OHLC` et `AskBid`. Il devra donc appliquer des transformations afin de faire correspondre les données offertes à son format. +Grâce à l'interface `DataType`, il est possible d'ajouter de nouveaux type de données selon les besoins de l'utilisateur. Il peut ainsi personnaliser ses stratégies en ajoutant de nouvelles façons de représenter les données. En revanche, les seules données brutes proposées par le système actuel sont `OHLC` et `AskBid`. Il devra donc appliquer des transformations afin de faire correspondre les données offertes à son format. -L'interface sera utile de la même manière qu'expliquer précédemment lorsque de nouveaux type de données brut seront ajoutés à la base de données. +L'interface sera utile de la même manière qu'expliqué précédemment lorsque de nouveaux type de données brutes seront ajoutés à la base de données. -\pagebreak +\newpage ## Accès au cluster Kafka à l'aide d'Alpakka {-} ### Consommer les données {-} -Pour faciliter la consommation des données boursières provenant du cluster Kafka, la classe statique `KafkaConsummer` offre via son interface, des sources de données prête à être utilisée. Elle permet de récupérer une source de `DataType` (le type de données vu précédement). Ces sources vont récupérer les données d'actif qui se trouvent sur le cluster Kafka. +Pour faciliter la consommation des données boursières provenant du cluster Kafka, la classe statique `KafkaConsummer` offre via son interface, des sources de données prêtes à être utilisées. Elle permet de récupérer une source de `DataType` (le type de données vu précédement). Ces sources vont récupérer les données d'actifs qui se trouvent sur le cluster Kafka. \cimg{figs/soft/soft-consume-topic.png}{scale=0.5}{Schéma UML de la classe statique KafkaConsummer retournant des sources de données boursières}{Source : Réalisé par Paschoud Nicolas} Cinq fonctions permettent de récupérer des sources de données différentes. + \begin{itemize} \item Crypto-monnaies \item Forex \item Stock \item Order Book d'un actif -\item Statistiques des agents +\item Statistiques des acteurs \end{itemize} + Toutes ces fonctions publiques font appel à des fonctions privées permettant de se débarasser de la lourde tâche de récupération de la configuration Akka. Elles font exactement la même chose à la seule différence qu'elles catégorisent et nomment les consumer afin de les différencier. Chaque consumer Kafka doit avoir un nom et un groupe sans lesquels il ne peut pas consommer les données. Ils sont tous nommés de cette manière : \begin{center} Nom du client : consumerName-consumer-topicName @@ -82,7 +85,7 @@ Nom du client : consumerName-consumer-topicName Nom du groupe : consumerName-consumers \end{center} -Deux paramètres sont nécessaires afin d'obtenir une source de données : le nom du topic et la méthode de récupération. Les noms des topics sont présenter au chapitre [Organisation des topics pour la sauvegarde des données boursières](#organisation-des-topics-pour-la-sauvegarde-des-données-boursières). La méthode de récupération premet de savoir si l'ensemble de l'historique de données doit être récupéré ou non. +Deux paramètres sont nécessaires afin d'obtenir une source de données : le nom du topic et la méthode de récupération. Les noms des topics sont présentés au chapitre [Organisation des topics pour la sauvegarde des données boursières](#organisation-des-topics-pour-la-sauvegarde-des-données-boursières). La méthode de récupération premet de savoir si l'ensemble de l'historique de données doit être récupéré ou non. \cimg{figs/soft/soft-historique-type.png}{scale=0.75}{Schéma UML représentant le type de consommation d'une source de données}{Source : Schéma réalisé par Paschoud Nicolas} @@ -95,16 +98,16 @@ Cette approche permet de récupérer en une ligne de code une `Source` de donné val srcBTCEUR: Source[OHLC, NotUsed] = KafkaConsumer.cryptoConsumer(topic, Latest) srcBTCEUR.runWith(Sink.foreach(println)) ``` -Dans cet exemple, la source de données récupère les dernières informations boursière de l'actif **BTCEUR** minute par minute grâce au paramètre `Latest`. La source va ensuite être exécutée avec un `Sink` affichant chaque données. +Dans cet exemple, la source de données récupère les dernières informations boursières de l'actif **BTCEUR** minute par minute grâce au paramètre `Latest`. La source va ensuite être exécutée avec un `Sink` affichant chaque donnée. \newpage ### Produire des données {-} -A l'image de la consommation des données, la production des données fonctionne de la même manière. Un classe statique `KafkaProducer` offre via son interface une méthodes qui retourne un `Sink` pour produire des données. +La production des données fonctionne de la même manière que la production de données. Une classe statique `KafkaProducer` offre via son interface une méthode qui retourne un `Sink` pour produire des données. \cimg{figs/soft/soft-kafka-producer.png}{scale=0.75}{Schéma UML de la classe statique KafkaProducer}{Source : Réalisé par Paschoud Nicolas} -La méthode statique `produce` prenant en paramètre le nom du topic dans lequel les données vont être produitent, va retourner un `Sink[String, NotUsed]`. Ce sink est configuré de sorte à ce qu'il se connecte à Kafka et envois un message au topic lorsqu'une donnée est reçue. +La méthode statique `produce` prenant en paramètre le nom du topic dans lequel les données vont être produites, va retourner un `Sink[String, NotUsed]`. Ce sink est configuré de sorte à ce qu'il se connecte à Kafka et envoie un message au topic lorsqu'une donnée est reçue. ```scala val topic: String = "topicTest" @@ -118,9 +121,9 @@ La méthode statique `produce` prenant en paramètre le nom du topic dans lequel src.runWith(sink) ``` -Ici les données `Hello`, `World` et `!` seront produite dans le topic nommé `topicTest`. Les données produites doivent être sous forme de `String`. Les données sont produites dans l'ordre d'arrivée dans le `Sink`, une fois envoyée à Kafka, l'ordre d'écriture est immuable. +Ici les données `Hello`, `World` et `!` seront produites dans le topic nommé `topicTest`. Les données produites doivent être sous forme de `String`. Elles sont produites dans l'ordre d'arrivée dans le `Sink`, une fois envoyée à Kafka, l'ordre d'écriture est immuable. -\pagebreak +\newpage ## Développer un indicateur technique {-} L'utilisateur de l'API a accès à différents indicateurs techniques ainsi qu'une interface lui permettant d'en développer lui même. Ces indicateurs prennent des `DataType` en entrée et retourne n'importe quel type de données. L'indicateur peut être un `Flow` ou une `Source`, l'interface propose ces deux implémentations. @@ -128,6 +131,7 @@ L'utilisateur de l'API a accès à différents indicateurs techniques ainsi qu'u \cimg{figs/soft/soft-indicator.png}{scale=0.5}{Schéma UML de l'interface Indicator}{Source : Réalisé par Paschoud Nicolas} Cette interface permet à un développeur de créer ses propres indicateurs techniques. Certains indicateurs communs sont offerts par la librairie. + \begin{itemize} \item Moving Average ou MA \item Exponential Moving Average @@ -160,26 +164,26 @@ def asFlow(): Flow[OHLC, Double, NotUsed] = Flow.fromGraph(GraphDSL.create() { \newpage -Cet indicateur utilise un autre indicateur développer précédemment, la (+EMA_a). Le calcul de la (+MACD_a) est assez simple, il s'agit de la différence entre une EMA de 12 périodes et d'une EMA de 26 périodes. Les données entrent par la fonction `in` qui est du type `Broadcast` et permet de distribuer les données au graph. Ces données vont ensuite passée à travers les deux EMA, `EMA.asFlow(12)` et `EMA.asFlow(26)` puis transférées à la fonction `zip`. La fonction `zip` a pour objectif de rassembler les données des deux EMA pour pouvoir faire la soustraction nécessaire à l'obtention d'une MACD. Elle est la fonction de sortie du graph et c'est pour cette raison que les valeurs contenue dans la fonction `.out` sont passé en second paramètre de l'objet `FlowShape(in.in, zip.out)`. FlowShape a pour objectif de transformer le graph précédement construit en `Flow` au travers duquel n'importe quelles données du type `OHLC` vont être transfromées en `Double`. +Cet indicateur utilise un autre indicateur développé précédemment, la (+EMA_a). Le calcul de la (+MACD_a) est assez simple, il s'agit de la différence entre une EMA de 12 périodes et d'une EMA de 26 périodes. Les données entrent par la fonction `in` qui est du type `Broadcast` et permet de distribuer les données au graph. Ces données vont ensuite passer à travers les deux EMA, `EMA.asFlow(12)` et `EMA.asFlow(26)` puis être transférées à la fonction `zip`. La fonction `zip` a pour objectif de rassembler les données des deux EMA pour pouvoir faire la soustraction nécessaire à l'obtention d'une MACD. Elle est la fonction de sortie du graph et c'est pour cette raison que les valeurs contenue dans la fonction `.out` sont passé en second paramètre de l'objet `FlowShape(in.in, zip.out)`. FlowShape a pour objectif de transformer le graph précédement construit en `Flow` au travers duquel n'importe quelles données du type `OHLC` vont être transfromées en `Double`. ## Comment créer un trader {-} -### Les messages d'un acteur Trader {-} -Les acteurs comminuquent les uns avec les autres par messages. Un acteur est définit par les messages qu'il envoit et reçoit. +### Les messages d'un acteur {-} +Les acteurs communiquent les uns avec les autres par messages. Un acteur est définit par les messages qu'il envoie et reçoit. \cimg{figs/soft/soft-trader-messages.png}{scale=0.5}{Schéma UML de l'interface et des messages d'un acteur de type Trader}{Source : Réalisé par Paschoud Nicolas} -Ce sont les messages de base que n'importe quel trader utilise pour communiquer. `Start` et `Stop` permettent, comme leur nom l'indique, de démarrer ou arrêter un acteur. `BuyAll` permet d'effectuer une transaction sur le marché pour la totalité de la valeur du porte-monnaie. A l'inverse, `SellAll` permet de vendre l'ensemble des positions actuelles. Ces deux dernier messages peuvent être envoyer par l'utilisateur lorsque les marchés s'emballent et que le comportement de la stratégie est trop hasardeuse. +Ce sont les messages de base que n'importe quel trader utilise pour communiquer. `Start` et `Stop` permettent, comme leur nom l'indique, de démarrer ou arrêter un acteur. `BuyAll` permet d'effectuer une transaction sur le marché pour la totalité de la valeur du portefeuille qu'il possède. A l'inverse, `SellAll` permet de vendre l'ensemble des positions actuelles. Ces deux derniers messages peuvent être envoyés par l'utilisateur lorsque les marchés s'emballent et que le comportement de la stratégie est trop hasardeuse. ### L'interface Trader {-} -La partie la plus importante de l'API est la création d'acteurs. Afin de faciliter la création de ceux-ci, une interface nommée `Trader` offre à l'utilisateur toute les méthodes nécessaire au bon fonctionnement d'un acteur. Dans cette interface, la plupart des comportements de base sont déjà développé, et l'utilisateur n'a qu'une seule fonction à implémenter. +La partie la plus importante de l'API est la création d'acteurs. Afin de faciliter la création de ceux-ci, une interface nommée `Trader` offre à l'utilisateur toute les méthodes nécessaire au bon fonctionnement d'un acteur. Dans cette interface, la plupart des comportements de base sont déjà développées, et l'utilisateur n'a qu'une seule fonction à implémenter. \cimg{figs/soft/soft-trader.png}{scale=0.5}{Schéma UML de l'interface Trader}{Source : Réalisé par Paschoud Nicolas} La seule fonction que l'utilisateur a à développer est la méthode `strategy`. Cette méthode est exécutée par la méthode `run` déjà implémentée. #### La réception de messages {-} -Les comportements lors de la réception d'un message sont décrit dans la méthode `behave`. Il est possible de changer le comportement de cette méthode mais il est cependant conseillé de bien maîtriser la librairie Akka Actor avant de toucher quoi que ce soit. Lorsque l'acteur reçoit un message de type `Start`, la stratégie va être exécutée en utilisant la source de données passée en paramètre de la méthode `run`. +Les comportements lors de la réception d'un message sont décrits dans la méthode `behave`. Il est possible de changer le comportement de cette méthode mais il est cependant conseillé de bien maîtriser la librairie Akka Actor avant de toucher quoi que ce soit. Lorsque l'acteur reçoit un message de type `Start`, la stratégie va être exécutée en utilisant la source de données passée en paramètre de la méthode `run`. ```scala Behaviors.receiveMessage { @@ -192,7 +196,7 @@ Behaviors.receiveMessage { } ``` -Voici le comportement de l'acteur lors de la réception du message `Start`. Afin d'exécuter la stratégie, un stream est créer et exécuter à l'aide de la source de données et d'un sink de publications de statistiques dans Kafka. Avant d'atteindre le sink, les données vont passer par la stratégie `.via(strategy)` puis par un flow transformant les données de sortie de la stratégie en données statistiques. +Voici le comportement de l'acteur lors de la réception du message `Start`. Afin d'exécuter la stratégie, un stream est créé et exécuté à l'aide de la source de données et d'un sink de publications de statistiques dans Kafka. Avant d'atteindre le sink, les données vont passer par la stratégie `.via(strategy)` puis par un flow transformant les données de sortie de la stratégie en données statistiques. #### La stratégie {-} La méthode `strategy` est l'unique méthode qui n'est pas définie dans cette interface. C'est dans cette méthode que la stratégie de trading va être développée. La signature de cette méthode oblige l'utilisateur a créer un graph qui sera transformé en `Flow[T, Transaction, NotUsed]`. @@ -204,13 +208,30 @@ trait Trader [T <: DataType] Elle est bornée au type `DataType` ce qui veut dire qu'un trader maîtrise un type de donnée particulier comme `OHLC` et `AskBid` (voir chapitre [Les types de données](#les-types-de-données)). Lors de l'implémentation d'un nouvelle classe de type `Trader`, l'utilisateur devra préciser le type de données que la stratégie maîtrisera. -De manière globale, la logique derrière chaque méthode peut être modifier, celle de base permet en revanche de faciliter la vie de l'utilisateur en lui offrant le comportement minimum permettant l'exécution d'un acteur. Il est en revanche fortement conseillé de maîtriser les outils Akka et notamment Akka Actors avant de faire une quelconque modification. +De manière globale, la logique derrière chaque méthode peut être modifiée, celle de base permet en revanche de faciliter la vie de l'utilisateur en lui offrant le comportement minimum permettant l'exécution d'un acteur. Il est en revanche fortement conseillé de maîtriser les outils Akka et notamment Akka Actors avant de faire une quelconque modification. ## Mise en place du cluster Akka {-} -L'API permet de déployer et exécuter les acteurs directement sur un cluster. Ce cluster est déployé sur cinq machines virtuelles. Ces cinq machines virtuelles acceuilleront les acteurs déployés par le client et se chargera de délivrer les messages qui leurs sont dédiés. +L'API permet de déployer et exécuter les acteurs directement sur un cluster. Il est possible de le déployer sur plusieurs machines. Ces machines acceuillent les acteurs déployés par le client et se charge de délivrer les messages qui leurs sont dédiés. + +Le déploiement du cluster se fait à l'aide d'un programme développé dans l'API. Ce programme doit être configuré à l'aide des adresses IP de chacune des machines du cluster. + +```shell +cluster { + shutdown-after-unsuccessful-join-seed-nodes = 60s + + seed-nodes = [ + "akka://Distribia@ip:port", + "akka://Distribia@ip:port" + ] + } +``` + +Ces adresses vont permettrent à n'importe quel acteur de se connecter au cluster lors du processus d'exécution de la stratégie. Un fois configurer, le programme doit être exécuté sur chacun des noeuds. + ## Synthèse {-} -L'API développée pemet de travailler assez simplement sans grande connaissance des outils utilisé. Elle est modulable et générique ce qui permet une personnalisation de l'outil au désir de l'utilisateur. +L'API développée permet de travailler assez simplement sans grande connaissance des outils utilisés. Elle est modulable et générique ce qui permet une personnalisation de l'outil au désir de l'utilisateur. +Les graphs Akka ont permis de développer une API simple et permet de développer des stratégies rapidement sans difficulter \pagebreak \ No newline at end of file diff --git a/text/j-create.md b/text/j-create.md index a66ad1cdc5680ae1da165ae84ddf074bdcfd52e0..cb746d0ad1a8cf1f20b704d7173f7fc14e1bf833 100644 --- a/text/j-create.md +++ b/text/j-create.md @@ -8,7 +8,7 @@ Avant toute chose, l'interface ou trait en Scala, Trader est typé et borné. trait Trader [T <: DataType] ``` -Ici un exemple de création de la classe `TakeProfitStopLoss` qui implémentera une stratégie se basant sur des supports et résistances permettant d'eviter de grosse perte tout en faisant du bénéfice lorsque l'occasion se présente. +Ici un exemple de création de la classe `TakeProfitStopLoss` qui implémentera une stratégie se basant sur des supports et résistances permettant d'éviter de grosses pertes tout en faisant du bénéfice lorsque l'occasion se présente. ```scala class TakeProfitStopLoss ( @@ -20,12 +20,14 @@ class TakeProfitStopLoss ( ) extends Trader [OHLC] { ``` -Certaines valeurs n'ayant pas été défini dans la classe `Trader`, elles devront être définies dans l'implémentation. Ces valeurs sont `traderName`, `asset` et `startingMoney`. Celles-ci sont définies dans le constructeur en complément de `takeLoss` et `takeProfit` utiles à la stratégie. +Certaines valeurs n'ayant pas été définies dans la classe `Trader`, elles devront être définies dans l'implémentation. Ces valeurs sont `traderName`, `asset` et `startingMoney`. Celles-ci sont définies dans le constructeur en complément de `takeLoss` et `takeProfit` utiles à la stratégie. -La seules méthodes non définie étant `strategy`, l'utilisateur n'a que peu de travail d'implémentation à effectuer. La stratégie développée ici est assez basique mais peut sauver la vie au trader lorsqu'il n'a pas le temps de réagir. +La seules méthodes non définie étant `strategy`, l'utilisateur n'a que peu de travail d'implémentation à effectuer. La stratégie développée ici est assez basique mais peut sauver la vie du trader lorsqu'il n'a pas le temps de réagir. \cimg{figs/create/create-profit-loss.png}{scale=0.25}{Exemple de Take Profit Stop Loss sur le cours BTCUSD}{Source : Réalisé par Paschoud Nicolas} +\newpage + Sur cette image on trouve un (+TP_a) à 15% et un (+SL_a) à 5%. Cela veut dire que si le cours perd plus de 5% du prix d'entrée, un ordre de vente sera effectué afin de perdre le moins d'argent possible. A l'inverse, le (+TP_a) fixé à 15% permet de placer un ordre de vente si le cours prends plus de 15% de la valeur d'entrée. ```scala @@ -46,21 +48,23 @@ def strategy(): Flow[OHLC, Transaction, NotUsed] = { Cette implémentation de la méthode `strategy` correspond donc à la stratégie décrite précédement. En complément de la méthode `strategy`, la fonction `isProfit` qui permet de tester les conditions d'achat ou de vente en se basant sur le prix actuel. Elle permet d'effectuer une transaction ou non à l'aide d'une logique simple. Cette fonction prend un `Double` en entrée, c'est pour cela que les données `OHLC`, en entrée du graph `in`, sont transformées pour ne récupérer que le prix de fermeture `in ~> closePrice`. Le prix de fermeture est ensuite passé en entrée de la fonction `isProfit` qui ressemble à ça : +\newpage + ```scala def isProfit(): Flow[Double, Transaction, NotUsed] = Flow[Double].map(ticker => { - val cPrice = currentTransaction.price - if (currentTransaction.isEmpty) { + val cPrice = position.price + if (position.isEmpty) { println(s"Buying for $cPrice") - currentTransaction = buy(ticker, volumeToBuy) - currentTransaction + position = buy(ticker, volumeToBuy) + position } else if (ticker >= cPrice + (cPrice * takeProfit)) { println("Selling profit") - currentTransaction = sell(ticker, volumeToBuy) - currentTransaction + position = sell(ticker, volumeToBuy) + position } else if (ticker <= cPrice - (cPrice * takeLoss)) { println("Selling loss") - currentTransaction = sell(ticker, volumeToBuy) - currentTransaction + position = sell(ticker, volumeToBuy) + position } else { Buy.nothing(asset) } @@ -69,10 +73,10 @@ def isProfit(): Flow[Double, Transaction, NotUsed] = Flow[Double].map(ticker => Cette fonction vérifie pour chacun des prix si l'acteur se trouve dans une situtation de perte ou de profit. En cas de perte ou de gain, une vente est efféctuée. Cette fonction retourne une `Transaction` tout en mettant à jour la position actuelle. -Grâce à Akka Graph, il est très facile de créer un algorithme de trading. L'algorithme étant exécuter par les fonctions déjà présentent dans la librairie, l'utilisateur peut se concentrer sur sa stratégie et la développer très rapidement. +Grâce à Akka Graph, il est très facile de créer un algorithme de trading. L'algorithme étant exécuté par les fonctions déjà présentes dans la librairie, l'utilisateur peut se concentrer sur sa stratégie et la développer très rapidement. ## Exécuter un trader {-} -Une fois une stratégie développer, il faut pouvoir l'exécuter afin de valider sa performance. Grâce à la librairie, il n'y a aucun travail à faire, les fonctions d'exécution étant prête. La stratégie étant développée dans une classe, elle doit être instanciée afin de pouvoir l'exécuter. La stratégie décrite précédemment sera utilisée pour la démonstration. Ce trader va travailler sur l'historique entier de l'actif BTCUSD minute par minute. +Une fois une stratégie développée, il faut pouvoir l'exécuter afin de valider sa performance. Grâce à la librairie, il n'y a aucun travail à faire, les fonctions d'exécution étant prêtes. La stratégie étant développée dans une classe, elle doit être instanciée afin de pouvoir l'exécuter. La stratégie décrite précédemment sera utilisée pour la démonstration. Ce trader va travailler sur l'historique entier de l'actif BTCUSD minute par minute. ```scala val topic: String = "BTCUSD_m" @@ -81,19 +85,19 @@ val trader: TakeProfitStopLoss = new TakeProfitStopLoss(0.2, 0.4, topic, 10000, val ref = trader.run(src) ``` -Le trader est instancié avec des paramètres tel que, le *Stop Loss*, *Take Profit*, l'argent de base, le nom de l'actif ainsi que le nom de l'acteur qui pourra être utilisé pour accéder à ces statistiques. -Une fois la stratégie instanciée et configurée, la stratégie est exécutée à l'aide de la méthode `run` décrite dans l'interface `Trader`. Cette méthode a besoin d'une source de donnée pour être exécutée. Elle est récupérée de la même manière qu'avant, à l'aide de `KafkaConsumer`. +Le trader est instancié avec des paramètres tel que, le *Stop Loss*, *Take Profit*, le montant de base à investir, le nom de l'actif ainsi que le nom de l'acteur qui pourra être utilisé pour accéder à ses statistiques. +Une fois la stratégie instanciée et configurée, elle est exécutée à l'aide de la méthode `run` décrite dans l'interface `Trader`. Cette méthode a besoin d'une source de données pour être exécutée. Elle est récupérée de la même manière qu'avant, à l'aide de `KafkaConsumer`. -La méthode `run` va permettre de déployer l'acteur sur le cluster. +La méthode `run` permet de déployer l'acteur sur le cluster. ## Gestion des agents du cluster {-} -Ce chapitre présentera les outils dévloppés permettant de gérer les agents en cours d'exécution sur le cluster. Afin de visualiser les statistiques d'exécution de chaque agent, une interface sera mise en place. +Ce chapitre présente les outils développés permettant de gérer les agents en cours d'exécution sur le cluster. ### Publication des statistiques des agents {-} -Chaque agents en cours d'exécution publie à chaque transaction un ensemble d'information dans un topic nommé "statistics". Ce topic enregistre toutes les statistiques de tous les agents qui sont et ont été exécutés. +Chaque agent en cours d'exécution publie à chaque transaction un ensemble d'informations dans un topic nommé "statistics". Ce topic enregistre toutes les statistiques de tous les agents qui sont et ont été exécutés. -## Gérer les agents à l'aide d'une console {-} -Une console est mise à disposition du développeur qui souhaite accéder au cluster afin de gérer ces agents. Cette console offre de simple fonctionnalité leurs gestion. +### Gérer les agents à l'aide d'une console {-} +Une console est mise à disposition du développeur qui souhaite accéder au cluster afin de gérer ces agents. De simple fonctionnalités de gestions sont offertes par cette console. \begin{itemize} \item Stopper un agent @@ -107,32 +111,31 @@ Une console est mise à disposition du développeur qui souhaite accéder au clu \item Visualiser les statistiques d'un agent \end{itemize} -Le fonctionnement de la console est assez simple. Lorsque la commande d'arrêt est executée, un acteur est déployé sur le cluster afin d'envoyer le message d'arrêt à l'acteur désigné. Une fois le message délivré, l'acteur est aussi stoper et le controle reviens à l'utilisateur. Cette console peut se connecter au cluster Akka et au cluster Kafka en fonction du type de commande exécutée. +Le fonctionnement de la console est assez simple. Lorsque la commande d'arrêt est executée, un acteur est déployé sur le cluster afin d'envoyer le message d'arrêt à l'acteur désigné. Une fois le message délivré, l'acteur est aussi stoppé. Cette console peut se connecter au cluster Akka et au cluster Kafka en fonction du type de commande exécutée. -## Visualiser les acteurs via un frontend {-} -Dans un premier temps, le frontend permettra seulement de visualiser les statistiques de l'ensemble des agents se trouvant sur le cluster. Le frontend recevra les données via un WebSocket connecter à un serveur node. Ce serveur aura pour rôle de consommer les données statistiques publiées dans le topic `statistics` du cluster Kafka. Il triera et mettra à jour l'historique de données statistiques de chaque acteurs en fonction de leur état. +### Visualiser les acteurs via un frontend {-} +Dans un premier temps, le frontend permettra seulement de visualiser les statistiques de l'ensemble des agents se trouvant sur le cluster. Le frontend recevra les données via un WebSocket connecté à un serveur node. Ce serveur aura pour rôle de consommer les données statistiques publiées dans le topic `statistics` du cluster Kafka. Il triera et mettra à jour l'historique de données statistiques de chaque acteurs en fonction de leur état. \cimg{figs/create/create-node.png}{scale=0.5}{Architecture de déploiement du serveur node.js}{Source : Réalisé par Paschoud Nicolas} -### Présentation du frontend {-} -L'interface de visualisation des acteurs est assez simple. Ils sont présenter sous forme de liste de carte contenant l'ensemble des informations à savoir à leur sujet. +\newpage + +#### Présentation du frontend {-} +L'interface de visualisation des acteurs est assez simple. Ils sont présentés sous forme de liste de cartes contenant l'ensemble des informations d'un acteur. \cimg{figs/create/frontend-global.png}{scale=0.25}{Présentation du frontend}{Source : Réalisé par Paschoud Nicolas} Un système de filtrage permet d'afficher les agents selon leur état. Il est aussi possible de chercher les agents à l'aide de leur nom. -\cimg{figs/create/front-search.png}{scale=0.5}{Menu de recherche des acteurs sur le frontend}{Source : Réalisé par Paschoud Nicolas} +\cimg{figs/create/front-search.png}{scale=0.4}{Menu de recherche des acteurs sur le frontend}{Source : Réalisé par Paschoud Nicolas} + +\newpage Leur état est défini par la couleur de leur en-tête de carte. Rouge indique que l'acteur est arrêté, bleu indique qu'il est en cours d'exécution et jaune indique qu'il est en cours d'entrainement. -\cimg{figs/create/frontend-colors.png}{scale=0.5}{Exemple de couleurs pour définir l'état d'un acteur}{Source : Réalisé par Paschoud Nicolas} +\cimg{figs/create/frontend-colors.png}{scale=0.3}{Exemple de couleurs pour définir l'état d'un acteur}{Source : Réalisé par Paschoud Nicolas} ## Synthèse {-} -Les outils présentés sont facilement modifiable et personnalisable si l'utilisateur souhaite déployé le système sur sa propre infrastructure. Le serveur web n'a besoin que de l'addresse du cluster Kafka pour fonctionner correctement. - -\pagebreak - -# Conclusion {-} -Pour conclure, +Les outils présentés sont facilement modifiable et personnalisables si l'utilisateur souhaite déployer le système sur sa propre infrastructure. Le serveur web n'a besoin que de l'addresse du cluster Kafka pour fonctionner correctement. \pagebreak \ No newline at end of file diff --git a/text/k-comparaison.md b/text/k-comparaison.md new file mode 100644 index 0000000000000000000000000000000000000000..5ea7ba47d87eb0688a37baaeee470f8ae1f86ae4 --- /dev/null +++ b/text/k-comparaison.md @@ -0,0 +1,13 @@ +# Comparaison de performances {-} +Pour pouvoir tester et valider le l'API, différente stratégies de trading très basiques ont été implémentées. Elles ont permis de tester l'ensemble du système. Toutes ces stratégies ont été testées sur un jeux de 500 données tiré aléatoirement sur le cours du Bitcoin face au Dollar. + +\cimg{figs/data/extrait-BTCUSD.png}{scale=0.25}{Extrait du cours BTCEUR en date du dimanche 9 Août 2020 entre 10h28 et 18h51. Prix de fermeture}{Source : Données de la plateforme de trading kraken.com. Graphique réalisé par Paschoud Nicolas} + +## Pile ou face {-} +La stratégie la plus simple imaginable est bien évidemment une stratégie d'achat et de vente de manière aléatoire. Voici les résultats d'une exécution. + +\cimg{figs/data/random-profit-fake500.png}{scale=0.25}{Performance d'une stratégie de trading aléatoire}{Source : Résalisé par Paschoud Nicolas} + +Cette stratégie n'est pas très efficace car elle ne possède aucune logique. Pour chaque chandelier, l'algorithme a une chance sur deux d'acheter ou de vendre au prix courant. L'investissement de départ était de 15000 dollars, et a terminer sa course à 13800 dollars, soit une perte de prêt de 1200 dollars. + +\pagebreak \ No newline at end of file diff --git a/text/l-conclusion.md b/text/l-conclusion.md new file mode 100644 index 0000000000000000000000000000000000000000..e12d4588bfa437e3c6879de46525f0f0653cbd3d --- /dev/null +++ b/text/l-conclusion.md @@ -0,0 +1,21 @@ +# Conclusion {-} +Pour conclure, l'objectif final du projet était de mettre en place une API permettant à n'importe quel utilisateur de créer, tester puis déployer des stratégies de trading. L'API devait offrir un accès simplifié à une infrastructure distribuée sur laquelle différents types de données boursières sont stockées. L'infrastructure d'exécution des stratégies devait offrir une garantie de fonctionnement continu. Un outil de visualisation devait permettre d'afficher les performances des agents en cours d'exécution sur un cluster. +L'ensemble de ces fonctionnalités ont été développées et mises en place. L'API offre une manière très simple et élégante de créer des stratégies de trading et de les déployer sans difficultés. + +La réalisation de ce Bachelor m'a permis de comprendre ma manière de travailler et où il y avait un travail d'amélioration continue à faire. Une certaine quantité de temps a été perdue sur de simples problèmes qui n'impactaient en aucun cas l'avancement de l'ensemble du projet, mais sur lesquels je me suis obstiné. Mais un tel projet m'a permis de découvrir et utiliser des outils cloud performants qui sont utilisés par de grandes entreprises. Ils restent cependant difficiles à prendre en main, mais une fois les connaissances acquises, ils sont très agréables à utiliser. + +L'idée de base est très intéressante, innovante et offre de grands horizons d'opportunités. La structure générique du projet et sa facilité de manipulation, permettra plus tard de rajouter de nouvelles fonctionnalités comme le traitement de l'actualité, la génération d'arbres de dépendances entre les marchés. Ce sont des idées intéressantes qui permettront d'analyser les marchés à un échelle encore plus grande et offriront probablement de meilleures prédictions. + + + + +*1/La fonction de rappel doit rappeler les objectifs et dire précisément ce qui a été réalisé. Pense que l'introduction et la conclusion doivent pouvoir se lire sans consulter les chapitres du rapport.* + +*2/ La fonction de retour réflexif sur l'exercice ou bilan personnel est là pour que tu fasses le point sur les compétences acquises. Poser donc ici ce qui a été appris et plus globalement ce qui a été stimulant. Et ça se passe forcément dans les contraintes du projet et dans les difficultés rencontrées.* + +*3/ La fonction d'ouverture est faite pour ouvrir sur les perspectives de recherche, de réalisation, de comparaison, etc. à venir.* + + + + +\pagebreak \ No newline at end of file