Architectures    
  • ​Introduction

    Aucune technologie ne permet de résoudre tous les types de problèmes posés.

    Certaines architectures et solutions permettent de résoudre des problèmes complexes mais vont se retrouver surdimensionnées pour des problématiques plus simples.

  • ​Hadoop

    Définition 

    Hadoop est un framework qui va permettre le traitement de données massives sur un cluster allant de une à plusieurs centaines de machines.

    Hadoop est écrit en Java et a été créé par Doug Cutting et Michael Cafarella en 2005 (après avoir créé le moteur de recherche Lucene, Doug travaillait alors pour Yahoo sur son projet de crawler web Nutch).

    Hadoop va gérer la distribution des données au coeur des machines du cluster, leurs éventuelles défaillances mais aussi l’agrégation du traitement final.

    L’architecture est de type « Share nothing » : aucune donnée n’est traitée par deux noeuds différents même si les données sont réparties sur plusieurs noeuds (principe d’un noeud primaire et de noeuds secondaires). 

    Hadoop est composé de quatre éléments : 

    • Hadoop Common : ensemble d’utilitaires utilisés par les autres éléments,
    • Hadoop Distributed File System (HDFS) : un système de fichiers distribué pour le stockage persistant des données,
    • Hadoop YARN : un framework de gestion des ressources et de planification des traitements,
    • Hadoop MapReduce v2 : un framework de traitements distribués basé sur YARN. 

    HDFS est un système de fichiers Java utilisé pour stocker des données structurées ou non sur un ensemble de serveurs.

    C’est un système distribué, extensible et portable développé par le créateur d’Hadoop inspiré du système développé par Google (GoogleFS).

    Écrit en Java, il a été conçu pour stocker de très gros volumes de données sur un grand nombre de machines équipées de disques durs locaux.

    HDFS s’appuie sur le système de fichier natif de l’OS pour présenter un système de stockage unifié reposant sur un ensemble de disques et de systèmes de fichiers hétérogènes.

    MapReduce est un framework de traitements parallélisés, créé par Google pour son moteur de recherche web.

    C’est un framework qui permet la décomposition d’une requête importante en un ensemble de requêtes plus petites qui vont produire chacune un sous ensemble du résultat final : c’est la fonction Map.

    L’ensemble des résultats est traité (agrégation, filtre) : c’est la fonction Reduce.

    MapReduce est idéal pour les traitements batchs, mais il n’est pas itératif par défaut.

    Un cas d’utilisation très répandu actuellement est le “Data Lake”. 

    DATA LAKE HADOOP

    Data Lake

    Synthèse

    Points forts 

    • distribution des traitements au plus près de la donnée Hadoop (parallélisation),
    • reprise automatique sur erreurs,
    • coût de stockage très concurrentiel,
    • écosystème très important.

    Inconvénients

    • performance (par rapport à NoSQL, Grille de données, …),
    • fait pour traiter de très gros volume de données. 
  • ​Traitements de type Batch

    Définition

    Une architecture de type batch permet de traiter un ensemble de données en entrée jusqu’à épuisement de la source.

    Tant que des données seront présentes les traitements vont se poursuivre et l’on aura un résultat cohérent et accessible uniquement à la fin des traitements.

    Afin d’éviter cet effet tunnel il est possible de découper les données en entrée et c’est là que la notion incrémentale est importante.

    Elle va permettre de prendre en compte les nouvelles données sans la nécessité de retraiter l’ensemble des données déjà traitées. Un parfait exemple de traitement Big Data de type Batch est Map Reduce dans sa version Hadoop.

    D’autres frameworks peuvent aussi implémenter des traitements de type Batch :

    • Apache Flink,
    • Apache Spark,
    • Apache Tez.

    Les données sont d’abord sélectionnées par un traitement principal et souvent unique.

    Les données sont distribuées entre différents noeuds afin d’être traitées.

    Une fois les données traitées par l’ensemble des noeuds un traitement réalise les opérations globales:

    • tri,
    • agrégation,
    • Etc.

    Synthèse

    Points forts 

    • simplicité de mise en oeuvre.

    Inconvénients

    • temps de traitement,
    • les données arrivées en cours de traitement ne sont pas prises en compte. 

     ARCHITECTURE BATCH

    Architecture Batch

    ARCHITECTURE BATCH INCRÉMENTALE

    Architecture batch incrementale

  • ​Traitements temps réel

    Définition

    On parle d’architecture temps réel ou streaming par opposition aux architectures de type batch.

    Il n’est pas nécessaire d’attendre la fin des données en entrée pour émettre un résultat.

    La notion de temps réel est toute relative et dépend du contexte : millisecondes, secondes ou encore minutes.

    On distingue les solutions de type micro-batch des solutions de streaming Micro-batch :

    • un résultat est produit toutes les n secondes.

    Streaming :

    • chaque entrée est traitée immédiatement et produit un résultat.

    Apache Spark est par exemple une solution de micro-batch alors que Storm et Flink sont des solutions de streaming.

    Synthèse

    Points forts 

    • temps de traitement modulable,
    • performances (Améliore les temps de traitements),
    • simplicité de mise en oeuvre,
    • peut être la base de solutions évolutives.

    Inconvénients

    • fusion des vues pour produire un résultat plus complet,
    • ne concerne que le traitement et doit donc être complété d’autres solutions (stockage, interrogation, …). 

    ARCHITECTURE TEMPS RÉEL

    Architecture temps réel

     

  • ​Architecture LAMBDA

    Définition

    L’architecture Lambda a été imaginée par Nathan Marz et James Warren afin de résoudre des problématiques complexes mélangeant temps réel et batchs.

    L’architecture Lambda permet de stocker et de traiter de larges volumes de données (batch) tout en intégrant dans les résultats des batchs les données les plus récentes.

    Conservation des principes du Big Data :

    • scalabilité,
    • tolérance aux pannes, ...

    Une architecture Lambda est composée de trois couches: 

    • couche batch (Batch Layer) :
      • stockage de l’ensemble des données 
      • traitements massifs et réguliers afin de produire des vues consultables par les utilisateurs,
      • la fréquence des traitements ne doit pas être trop importante afin de minimiser les taches de fusion des résultats afin de constituer les vues.
    • couche temps réel (Speed Layer) : 
      • ne traite que les données récentes (flux), 
      • calcul des vues incrémentales qui vont compléter les vues batch afin de fournir des données plus récentes,
      • suppression des vues temps réel obsolètes (postérieures à un traitement batch).
    • couche de service (Serving Layer) : 
      • permet de stocker et d’exposer aux clients les vues créées par les couches batch et temps réel,
      • aussi capable de calculer dynamiquement ces vues, 
      • n’importe quelle base NoSQL peut convenir.

    L’architecture Lambda est générique mais complexe dans le nombre de composants mis en oeuvre.

    Il n’y a pas de solutions dédiées à cette architecture mais une multitude : 

    • stockage : NoSQL surtout mais aussi JMS, Kafka, HDFS,
    • couche Batch : Hadoop MapReduce, Spark, Flink, …
    • couche Temps réel : Storm, Spark, Flink, Samza, Tez, ...
    • couche de service : Druid, Cassandra, Hive, HBase, ElasticSearch, ...

    Il existe toutefois des projets complets implémentant une architecture Lambda :

    • Générique : Twitter Summingbird (https://github.com/twitter/summingbird)
    • Dédiée au machine learning : Cloudera Oryx 2 (http://oryx.io/) 

    Architecture LAMBDA

    Synthèse

    Points forts 

    • on conserve les données brutes afin de pouvoir les retraiter au besoin,
    • la vision fournie aux clients est la plus fraîche possible,
    • solution à tout faire,
    • indépendant des technologies.

    Inconvénients

    • la logique métier est implémentée deux fois (dans la filière temps réel et dans la filière batch),
    • plus de frameworks à maîtriser,
    • il faut deux sources différentes des mêmes données (fichiers, web services),
    • il existe des solutions plus simples lorsque le besoin est moins complexe, l’évolutivité des solutions Big Data permettra dans la plupart des cas de migrer vers une architecture Lambda lorsque le besoin l’exigera.

    L’architecture Lambda est utilisée par des entreprises comme Metamarkets ou Yahoo.

  • ​Architecture KAPPA

    L’idée de l’architecture Kappa a été formulée par Jay Kreps (LinkedIn).

    L’architecture Kappa est née en réaction à l’architecture Lambda et à sa complexité.

    Elle est née d’un constat simple :

    • la plupart des solutions de traitement sont capables de traiter à la fois des batch et des flux,
    • l’architecture Kappa permet donc de simplifier l’architecture Lambda en fusionnant les couches Temps réel et Batch

    Elle apporte une autre évolution par rapport à l’architecture Lambda : 

    Le système de stockage des données est plus restreint et doit être un système de fichiers de type log et non modifiable (tel que Kafka).

    Kafka ou un autre système permet de conserver les messages pendant un certain temps afin de pouvoir les retraiter.

    De fait, et encore plus que l’architecture Lambda, l’architecture Kappa ne permet pas le stockage permanent des données.

    Elle est plus dédiée à leur traitement. Quoique plus restreinte, l’architecture Kappa laisse une certaine liberté dans le choix des composants mis en oeuvre :

    • stockage : Kafka, ...
    • traitements : Storm, Spark, Flink, Samza, Tez, ...
    • couche de service : Druid, Cassandra, Hive, HBase, ElasticSearch,… 

    ARCHITECTURE KAPPA 

    architecture Kappa

    Synthèse

    Points forts 

    • solution à tout faire,
    • indépendant des technologies,
    • plus simple que l’architecture Lambda.

    Inconvénients

    • pas de séparation entre les besoins,
    • montée en compétence.

    L’architecture Kappa est utilisée par des entreprises comme Linkedin. 

     

  • ​Architecture SMACK

    L’architecture SMACK (pour Spark Mesos Akka Cassandra Kafka) est assez différente des architectures Lambda ou Kappa puisqu’elle est composée d’une liste de solutions.

    Il faut donc bien comprendre les avantages et faiblesse des solutions avant de valider l’implémentation d’un cas d’utilisation.

    Kafka est parfois remplacé par Kinesis sur le cloud (Amazon AWS)

    Il est tout à fait possible d’implémenter une architecture Lambda ou Kappa avec ces solutions mais aussi adopter une architecture plus simple.

    Choix de solutions matures, répondant aux exigences du Big Data :

    • Spark : Framework de traitement des données 

                     > Batch et streaming,

    • Mesos : Gestion des ressources du cluster 

                     > gestion des ressources du cluster (CPU/RAM), haute disponibilité grâce à Zookeeper,

    • Akka : Implémentation du paradigme acteurs pour la JVM 

                      > ingestion des données dans Kafka,

    • Cassandra : Solution NoSQL 

                     > stockage des données brutes mais aussi pour l’analyse des données,

    • Kafka : Stockage des événements 

                     > les événements de mise à jour sont stockés dans Kafka afin d’assurer leur persistance.

    Certaines de ces solutions sont officiellement supportées par Mesos (Spark, Kafka) par contre l’intégration de Cassandra nécessite de s’appuyer sur des projets tiers comme ceux de Mesosphere (http://mesosphere.github.io/cassandra-mesos/)

    Exemple d’implémentation de l’architecture SMACK

    ARCHITECTURE SMACK

    Architecture Smack

    Synthèse

    Points forts

    • un minimum de solutions capables de traiter un très grand nombre de problématiques,
    • solutions matures du Big Data,
    • scalabilité des solutions,
    • solution de gestion unique (Mesos),
    • compatible batchs, temps réel, Lambda, ... 

    Inconvénients

    • intégration de nouveaux besoins et donc de nouveaux frameworks,
    • architecture complexe.

    L’architecture SMACK est utilisée par des entreprises comme TupleJump ou ING.

  • ​Architecture Acteurs

    Définition 

    Le modèle d’acteurs est un modèle de programmation concurrente, dans lequel la charge de travail est répartie entre des entités s’exécutant en parallèle, les acteurs. C’est un modèle dans lequel il n’y a pas d’état partagé, les acteurs sont isolés et l’information ne peut circuler que sous forme de messages. 

    Ce modèle a été développé par Ericsson (1973) pour construire des systèmes télécoms hautement concurrents et disponibles (à l’origine lié au framework Erlang).

    Le but est de fournir une abstraction pour les développeurs et la gestion des verrous et les threads de la programmation concurrente. 

    Les acteurs reçoivent ces messages et ne peuvent réagir qu’en manipulant les données dans le message (effectuer un calcul ou une transformation sur la donnée), en envoyant un message à d’autres acteurs ou en créant de nouveaux acteurs.

    La philosophie adoptée en termes de tolérance de panne pour ces systèmes est «let it crash». En effet, les acteurs sont des éléments légers, qu’il est facile d’instancier et de relancer en cas de crash (du fait qu’ils ne partagent pas leur état).

    Pour cela, Akka impose une supervision afin de pouvoir gérer la mort prématurée d’acteurs, et ce dans une hiérarchie de supervision : tout nouvel acteur est supervisé par son parent. Cette supervision permet la création de systèmes qui s’auto-réparent.

    De plus les acteurs sont purement asynchrones et peuvent être relocalisés de manière transparente, y compris dans une autre JVM (ce qui permet la création d’un véritable système distribué sur un cluster).

    Un acteur possède les caractéristiques suivantes : 

    • il possède un état interne qui peut évoluer au cours du temps, 
    • il traite séquentiellement des messages stockés dans une queue,
    • il peut émettre des messages asynchrones à d’autres entités,
    • utilisation de messages immuables,
    • non partage d’état entre les acteurs (par contre il peut y avoir une dépendance entre les acteurs : traitements successifs, sous routine, etc. 

    Les acteurs fournissent un cadre qui simplifie les problèmes de concurrence à traiter par le développeur.

    Tolérance à l’erreur : philosophie de type « Let It Crash ».

    Un acteur particulier nommé Superviseur est en charge du bon fonctionnement des autres acteurs. Il peut redémarrer un ou plusieurs acteurs selon la stratégie :

    • for one : seul l’acteur levant une exception est redémarré,
    • one for all : tous les acteurs supervisés sont redémarrés, cette stratégie est utilisée dans le cas de dépendances entre acteurs.

    Il peut exister une arborescence de superviseurs avec un superviseur par domaine et un superviseur principal.

    ARBORESCENCE DE SUPERVISEURS

    planche schéma.png

    Synthèse 

    Points forts 

    • gestion native du multithreading,
    • solutions matures et performantes (Akka).

    Inconvénients

    • architecture complexe.

     

  • ​Architecture Microservices

    Définition

    L’architecture microservices est souvent décrite comme l’architecture correcte de la SOA (“SOA done right”), je préfère utiliser le terme de Container-Oriented Architecture. Ce n’est pas une architecture complète et spécifique au Big Data.

    Exposé par James Lewis et Martin Fowler, les principes fondamentaux en sont les suivants :

    • un service ne traite qu’un périmètre restreint et clairement défini de fonctionnalités,
    • chaque service est développé avec le langage et la base de données les plus adaptés pour répondre efficacement,
    • un service doit être sans état,
    • chaque service est autonome, s’exécute sur son propre serveur embarqué.

     

    Le boom des microservices est du à Netflix en 2010 en réponse aux problèmes engendrées par une architecture service traditionnelle (que l’on nomme par opposition au micro services : monolithes).

    En effet les monolithes posent les problèmes suivants :

    • dépendance technologique de tous les services 
      • stack technique, 
      • hardware,
    • planning de déploiement partagé entre tous les services,
    • SLA identique pour tous les services,
    • si la charge d’un seul service augmente tous les services sont impactés,
    • taille importante des équipes projets, ... 

    A l’opposé dans les microservices, chacun de ces services doit pouvoir exécuter une partie unique et spécifique de l’application, et être déployés indépendamment des autres services.

    De même pour éviter les problèmes des gros projets (taille des équipes, inertie, …), il suffit de n’avoir que des petits projets. 

    Il ne s’agit pas de séparer les gros projets en sous équipes mais bien de projets indépendants : chacun a son organisation, son calendrier, sa base de code et ses données.

    Le découpage se fait par domaine métier, en groupant les services et les types de données qui ont des liens forts, et en les séparant quand ils sont suffisamment indépendants.

    L’architecture microservices est inspirée des technologies suivantes (et de leur maturité actuelle):

    • architecture orientée service,
    • mouvement DevOps,
    • maturité des containers et de la virtualisation,
    • NoSQL pour une mise en oeuvre et déploiement simplifiés des solutions de stockage. 

    Des grands principes :

    • scalabilité,
    • expose des services avec un couplage lâche entre eux,
    • pas de dépendance entre les services (Chaque service à son serveur web, son datastore, …),
    • chaque service est hébergé et administré indépendamment. 

    Techniquement les microservices font la part belle aux web services (REST / JSON).

    Testabilité

    Le fait de décomposer l’application en multiples sous applications complexifie les tests d’intégrations qui sont maintenant obligatoires avec cette architecture même si chaque service est théoriquement indépendant d’un point de vue métier. 

    Cela concerne essentiellement les services transverses (sécurité, frontal web, load balancing, transactions distribuées (Cf. point suivant, …).

    Gestion des transactions

    Si jamais une transaction est nécessaire entre deux services, il faut une transaction distribuée avec la complexité que cela induit.

    Alternativement on peut implémenter des transactions de compensation afin d’éviter ces transactions distribuées.

    Toutefois la meilleure pratique consiste à définir des services transactionnellement indépendants ou ne pas implémenter de transactions (sachant que la plupart des DataStores du Big Data ne les supportent pas). 

    ARCHITECTURE MONOLITHE ET ARCHITECTURE MICROSERVICES

    Monolithic et microservices architectures

    Synthèse

    Points forts

    • scalabilité (Elasticité),
    • découplage, ...

    Inconvénients

    • Testabilité
    • Gestion des transactions
  • ​Indexation

    Définition

    Le stockage et l’analyse des données ont souvent été deux besoins séparés et couvert par deux solutions différentes.

    Objectifs des systèmes d’analyse des données :

    • recherche en quasi temps réel,
    • performances,
    • navigation dans les données via les facettes, recherches par coordonnées géographiques,
    • capacités d’analyse poussées via les facettes et le langage de requêtage.

    Les systèmes de type SGBD-R ou DataWareHouse sont capables de répondre à ces exigences mais ils vont souffrir de certains maux :

    • la capacité d’analyse est limitée (SGBD-R),
    • scalabilité horizontale (SGBD-R et DWH),
    • nécessite des données structurées ( SGBD-R et DWH),
    • coût (SGBD-R et DWH), ...

    Récemment nous avons vu l’émergence de systèmes capables de répondre à ces deux challenges : il s’agit de systèmes d’indexation de nouvelle génération tel qu’ElasticSearch.

    Ces systèmes sont à la fois des solutions NoSQL pour le stockage et des moteurs d’indexation pour l’analyse des données.

    ElasticSearch a été spécialement conçu pour :

    • indexer de très gros volumes de données, 
    • assurer une forte montée en charge, 
    • une grande tolérance aux pannes. 

    Des caractéristiques qui en font une solution Big Data.

    Ces solutions s’affranchissent du besoin de schéma des données et vont stocker les informations au format brut afin d’offrir la possibilité de les réindexer au besoin.

    Toutefois le système d’indexation est rarement la source de référence des données, les données sont souvent issues d’un autre système qui va pousser les données au fur et à mesure. 

    Synthèse

    Points forts

    • rapidité,
    • simplicité de mise en œuvre.

    Inconvénients

    • consommation mémoire importante,
    • nécessite du paramétrage fin pour les fortes charges.
  • ​Architecture Data Lake

    Définition

    L’architecture “Lac de données” est un concept récent (2011) qui n’a réellement été rendu possible qu’avec l’apparition de systèmes capables de stocker des données non structurées.

    On doit la paternité de ce terme à James Dixon, CTO de Pentaho.

    Cette architecture est la conséquence directe des challenges du Big Data :

    • une volumétrie exponentielle de données,
    • des données sous exploitées,
    • des données aux formats divers et non connu par avance.

    En plus de cela intervient la notion de coût de stockage qui doit rester contenu.

    Un lac de données est un lieu de stockage universel dans lequel on peut mettre n’importe quel type de donnée, dans le format le plus proche possible de la source.

    Il diffère donc des approches classiques de type Data Warehouse qui impose une structuration de la donnée au moment de l’écriture (“Schema on write”). Au moment de l’intégration des données, on trouve aussi différents traitements (qualité, filtrage, agrégation).

    Une fois intégrée, la donnée est donc figée dans un Data Warehouse.

    A contrario dans un Data Lake, la donnée est stockée dans un format brute (souvent celui de la source) et ne subie aucune transformation.

    La donnée est donc brute et l’on va la “travailler” au moment de son utilisation (“Schema on read”), ce qui passe par un transfert des données dans un autre système.

    C’est un atout de cette architecture étant donné que l’on ne connaît pas a priori les évolutions des sources de données et donc leur format.

    Le concept de Data Lake impose donc une séparation claire des responsabilités, le Data Lake n’est en charge que du stockage des données, pas de leur traitement.

    Les données sont mises à disposition pour des traitements de type :

    • transformation
    • mise en qualité, 
    • indexation,
    • analyse, ...

    Cas d’utilisation :

    • analytics,
    • vision 360,
    • détection de fraude, ...

    Parmi les solutions les plus fréquemment utilisées on trouve Hadoop et plus particulièrement HDFS et HBase.

    Les avantages natif d’Hadoop dans ce cas d’utilisation sont le coût de stockage, la tolérance à la panne, la disponibilité de la plateforme et surtout son évolutivité.

    Synthèse

    Points forts

    • séparation entre stockage et exploitation de la donnée,
    • coût de stockage réduit,
    • disponibilité,
    • évolutivité.

    Inconvénients

    • ne gère que le stockage,
    • gouvernance des données obligatoire afin de suivre l’utilisation des données.
  • ​Critères de sélection d’une architecture

    Le choix d’une architecture est en général difficile et le Big Data n’échappe pas à la règle.

    Dans le cadre du Big Data cela est rendu encore plus difficile à cause de certaines caractéristiques techniques :

    • volumétries mises en oeuvre,
    • besoins temps réel,
    • les évolutions constantes des solutions,
    • on pose souvent les bases d’une architecture technique sans connaître tous les besoins.

    et de certaines caractéristiques fonctionnelles : 

    • un des points attendus du Big Data est de réduire le Time To Market, ce qui laisse peu de temps pour repenser ou faire évoluer l’architecture.

    Ainsi on peut soit se retrouver avec une architecture “jetable” (celle qui correspond parfaitement aux besoins exprimés) ou à l’opposé une architecture qui dans un premier temps s’avèrera trop complexe par rapport aux besoins réels (et qui anticipera les futurs besoins).

    L’idéal est évidemment le compromis entre ces deux extrêmes, une architecture Big Data devra être retenue en ayant en tête ces exigences contradictoires :

    • être évolutive,
    • faciliter son administration et la montée en compétences des équipes.

    Le tableau suivant fait le lien entre une architecture, les critères de sélection principaux et les cas d’utilisation.

    Architecture  Critère principal Cas d’utilisation
    Hadoop

    Stocker de la donnée à un coût faible

    Data Lake
    Lambda

    Construire une vision complète des données

    Chaîne de traitement/valorisation de la donnée

    Kappa

    Fournir une vision fraîche des données

    Données métier à destination des utilisateurs

    SMACK

    Traiter de la donnée à un coût faible

    Analyse des données (Machine Learning)

     

ECRIVEZ NOUS SI VOUS AVEZ UNE QUESTION SUR CE CHAPITRE
TéléchArgez-gratuitement-le-liVre-blAncTéléchArgez-gratuitement-le-liVre-blAncTéléchArgez-gratuitement-le-liVre-blAnc
Pdf 11.39Mo
loading
POSEZ-NOUS VOTRE QUESTION
loading