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.

ArchitectureApplicativeSimple

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

sparkMonoServeur

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

sparkMultiServeur

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

sparkCluster

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.