Architecture de la solution et Déploiement Datachain Core : Generics Data & Handle Data
Datachain Core est mis à disposition sous forme de conteneur docker, permettant des déploiements simples mono-serveur, jusqu’à des architectures multi-serveurs hautement disponibles. L’objectif de cette page est de présenter :
-
L’architecture technique de la solution,
-
Les différents types de déploiement qui peuvent être mis en œuvre.
Architecture applicative de la solution
L’architecture ci-dessous présente la version minimale d’un déploiement, en mode autonome, ie sans utilisation de ressource externe.

Le tableau ci-dessous résume les flux internes entre les différents modules
Source | Cible | protocol | port | fonction |
---|---|---|---|---|
traefik |
web_ui |
http |
80 |
proxy vers les requetes à la web_ui |
web_ui |
backend |
http |
8089 |
proxy vers les requetes au backend |
backend |
spark |
http |
8090 |
Echanges de données avec spark |
backend |
redis |
redis |
6379 |
Echanges d’information asynchrone avec spark |
backend |
pg_all |
sql |
5432 |
Obtention de données applicatives et d’exposition |
backend |
keycloak |
http |
8080 |
Obtention de données d’authentification |
spark |
redis |
redis |
6379 |
Echanges d’informations asynchrone avec le backend |
spark |
pg_all |
sql |
5432 |
Génération de données d’exposition |
spark |
keycloak |
http |
8080 |
Obtention de données d’authentification (supprimé dans une prochaine version) |
keycloak |
pg_all |
sql |
5432 |
Obtention de données keycloak |
pg_migration |
pg_all |
sql |
5432 |
Migration de schéma et de données |
Focus sur le déploiement de Spark
Dans le cadre de la solution Datachain, le service Spark correspond au point d’entrée des calculs effectués par Datachain pour l’exécution des pipelines. Ce nœud nécessite donc une puissance CPU/mémoire adapté.
Différents cas de déploiement peuvent permettre de répondre à aux problématiques de performances/disponibilité du(es) nœud(s) Spark.
Le service Spark permet d’effectuer des traitements en parallèle sur les pipelines de traitements Datachain. Le mode utilisé dans ce cas est le mode FAIR de spark. Il peut cépendant rester en mode FIFO, ne traitant ainsi qu’une seule tache à la fois.
Les diagrammes suivants ne montrent que les diagrammes de déploiement des contextes Spark afin de faire un focus sur ceux-ci. Les autres éléments de la solution devront être déployés pour avoir une plateforme opérationnelle. |
Cas numéro 1 : Mono Serveur, Mono Service, avec scalabilité verticale
Le service est configuré avec une quantité de CPU et mémoire suffisante pour effectuer les traitements. En cas de besoin supplémentaire de ressources, il faut procéder à une augmentation des ressources physiques de la machine, et allouer ces nouvelles ressources au service existant. Potentiellement, le nombre de jobs à traiter en parallèle peut être augmenté.
Tous les projets utilisent le même service Spark. En cas de forte utilisation, il peut y avoir des contentions. Cette solution atteint ses limites lorsque les besoins en mémoire deviennent trop important pour tous les traitements en parallèle. Dans ce cas, le cas numéro deux peut-être utilisé.
-
Configuration dans ce cas : De 1cpu/1g ram à 60 cpu/60g ram.
-
Si la machine physique est dédiée au service Spark, alors il faudra veiller à laisser 1cpu/1g Ram au système hôte.
Cas numéro 2 : Mono Serveur, Multi Service

Plusieurs services spark sont déployés sur la même machine : ils peuvent partager le méme répertoire de données (HDFS), afin de partager ces données. Cela sera utile lorsqu’un projet peut indifféremment utiliser plusieurs de ces contextes.
Cas numéro 3 : Multi-Serveur, Mono/Multi Service

Un ou plusieurs services spark sont déployés sur plusieurs machines qui ne partagent pas de disque. Ce mode de déploiement peut permettre de déployer des contextes par BU (Business Unit) d’une organisation, chacune ayant un/des contextes spark dédié. Chaque BU dispose ainsi de sa propre puissance de calcul : ses jobs seront traités, même si une autre BU utilise ses ressources de manière très intensive.
Une seconde possibilité serait de répondre à un besoin de partager les développements/Production sur la même instance de Datachain. Les jobs des projets en développement peuvent être lancés sur des contextes de production, tandis que les jobs de production sont ordonnancés via Maestro sur le contexte de production. Une surcharge temporaire des contextes de développements ne grèverons pas les performances des contextes de production.
Cas numéro 4 : Multi-Serveur, Mono/Multi Service déployé sur un cluster Spark

Dans ce cas de figure, un cluster Spark/Hadoop est déployé sur un premier ensemble de machine. Ensuite, un ou plusieurs services Spark sont déployées, configurés pour utiliser le cluster spark/hadoop. Les jobs seront ainsi distribués sur les différentes machines du cluster.
Architecture technique
Configuration hardware requise
La configuration doit être définie en fonction de l’utilisation envisagée du progiciel. En effet, si les pipelines de traitement nécessitent beaucoup de calculs, alors il faudra adapter le nombre de CPU en conséquence. Si les volumes de données sont importants, il sera nécessaire d’adapter la mémoire et l’espace disque.
Type de configuration | Mémoire | CPU | Disque |
---|---|---|---|
Minimale |
8Go |
4 Coeurs |
50Go |
Standard |
16Go |
8 à 16 coeurs |
200Go |
Intense |
32Go |
16 à 32 coeurs |
500Go |
Très Intense |
64Go |
32 à 64 coeurs |
1To |
Etendu |
64Go et plus |
64 coeurs et plus |
1To et plus |
Dans le cadre de la mise en œuvre sur plusieurs machines, celles-ci doivent être reliées via un réseau GigaBit Ethernet, afin de garantir des performances optimales.
Utilisation des cœurs de processeur par le composant Spark
Lorsque qu’une demande d’exécution est envoyée à l’application Datachain, cela déclenche un ou plusieurs jobs sur le composant spark, qui va alors déterminer un plan d’exécution afin d’optimiser le traitement, en utilisant au mieux les ressources qui lui sont allouée. Les jobs soumis sont découpée en tache, qui peuvent être exécutée en parallèle. L’unité de traitement d’une tache par Spark et le cœur CPU. Ainsi, si un contexte Spark se voit alloué 3 cœurs maximum, il pourra réaliser 3 taches en parallèle au maximum. Le nombre de cœurs alloués au contexte Spark est donc un moyen d’améliorer les performances de l’application. |