Mise en œuvre    
  • ​Introduction

    Le Big Data à vocation à traiter des problématiques métiers complexes.

    Le Big Data déplace le centre d’intérêt des entreprises vers les données et la valeur qu’elles peuvent apporter à l’entreprise. Pour les entreprises les moins matures, l’exploitation de la donnée sera tout d’abord une dette :

    • coût de l’acquisition de données,
    • coût matériel, logicielle,
    • coût humain (recrutement, montée en compétences).

    Ce n’est qu’ensuite que le retour sur investissement pourra être possible. Il faut passer d’une entreprise pilotée par les projets à une entreprise pilotée par les données.

  • ​Principes d’une architecture Big Data

    Il n’existe pas un modèle d’architecture Big Data idéal adapté à tous les usages mais des grands principes.

    PRINCIPES D’UNE ARCHITECTURE BIG DATA

    principes d'une architecture big data

    Stockage

    Données immutables (P/R)

    Avoir des données immutables, c’est à dire permettre l’insertion de nouvelles données mais pas leur modification dans un datastore (fichier, table, ...).

    Ce principe peut paraître contre productif et très contraignant mais il simplifie la distribution des données et les performances en écritures. C’est le modèle adopté par Cassandra, par HDFS.

    Un autre avantage concerne la résilience du système aux fausses manipulations, aux bugs, ... Avec un système immutable les données précédentes sont toujours présentes et seules les nouvelles données sont impactées. En cas de problème on peut donc toujours restaurer la version n-1 des données.

    Soit ce principe est supporté par les solutions de stockage, soit il devra être implémenté (staging des données, CQRS, ...).

    Stockage distribué des données (R)

    Ce principe va assurer la disponibilité des données et la capacité du système à gérer les défaillances. Une même donnée va être répliquée plusieurs fois dans le système sur des nœuds différents. En général le respect de ce principe va intervenir au moment du choix de la solution de stockage et rarement au moment de l’implémentation.

    Dénormalisation des données (P)

    Dans le Big Data, la modélisation des données est très importante pour les raisons suivantes :

    • performances (redondance des données),
    • adaptation aux solutions utilisées.

    Un système de stockage plus souple ne signifie par pour autant une phase de modélisation raccourcie ou simplifiée. Il est courant de construire une vue spécifique à un besoin afin de garantir les performances.

    Modèle non relationnel (P)

    La plupart des solutions NoSQL ne supportent pas les relations pour des raisons de performances. Cela a évidemment un impact sur la phase de modélisation ainsi que sur la manière d’utiliser les systèmes de stockage. Cela dit toutes les architectures n’utilisent pas les systèmes NoSQL et l’utilisation de solutions relationnelles telles que les SGBD-R peut s’avérer plus pertinente dans certains cas.

    Modèle de données dynamique (M)

    L’évolution du modèle de données est un challenge difficile qui peut être traité avec les systèmes traditionnels. Les nouveaux systèmes de stockage simplifient ce besoin et favorisent l’évolutivité du modèle de données.

    Durée de vie des données automatique (M)

    Les nouveaux systèmes de stockage (NoSQL, grilles de données mémoire) permettent de gérer le cycle de vie des données de manière automatisé (en proposant un Time To Live). Les avantages sont nombreux :

    • réduction des tâches de maintenance (plus de script métier de purge des données),
    • réduction de la volumétrie de stockage,
    • le flot de suppression des données est continu et non plus discret (passage de batchs),
    • favorise le renouvellement et donc la pertinence des données.

    Traitements

    Parallélisation des traitements (P/S)

    Lorsque les traitements sont indépendants entre eux (du moins en partie) il est alors possible de les paralléliser (différents threads, différents nœuds). C’est le principe de nombreux algorithmes tels que MapReduce, ForkJoin, ...

    Les avantages :

    • Performances, les données sont traitées plus rapidement,
    • Évite la congestion d’un système en répartissant les efforts.

    Prendre en compte la topologie réseau (P/S)

    Cette capacité d’un système à prendre en compte la topologie réseau (Data Locality) lui permet de co-localiser données et traitements.

    Les données sont manipulées au plus près de leur stockage ce qui permet :

    • de répartir les traitements sur un cluster,
    • de minimiser les échanges réseaux.

    Traitements Asynchrones (P/S)

    La capacité d’un système à gérer l’asynchronisme (systèmes non bloquants) permet d’augmenter les performances d’un point de vue client en augmentant le nombre de requêtes.

    Failover/reprise automatique (S/R)

    Un système réparti, gérant nativement le failover, limite les interventions, et favorise grandement sa résilience à la panne. Il en résulte un système qui offre une garantie de service (SLA) plus importante.

    Pas de transactions (P/S)

    Les nouveaux systèmes de stockage (NoSQL, grilles de données mémoire) ne permettent pas toujours de gérer les transactions. Ce qui peut être vu comme un frein est un énorme avantage en termes de performance et de scalabilité.

    Toutefois cette particularité peut impacter la cohérence des données et suppose un effort supplémentaire dans la conception du modèle ainsi que sa prise en compte dans le système (transaction de compensation, ...)

    Architecture

    Solutions majoritairement open sources (C)

    Le retour sur investissement d’une architecture Big Data est un moteur important de sa mise en œuvre. L’utilisation de solutions open sources va permette de réduire les coûts de mise en œuvre mais aussi favoriser l’évolutivité de la plateforme en évitant les solutions propriétaires.

    Scalabilité horizontale (commodity hardware) (C/S)

    C’est à dire la capacité d’un cluster à augmenter sa puissance avec l’ajout de machines. Cela traduit la capacité d’un système à distribuer automatiquement les traitements et les données sur les ressources du cluster.

    Pas de SPOF (masterless) (P/S)

    Dans une architecture un Single Point Of Failure met à défaut plusieurs points importants :

    • résilience à la panne du système,
    • performances et scalabilité.

    Dans l’idéal, aucune défaillance d’un nœud ou d’un service ne met en défaut le bon fonctionnement du cluster. Cela suppose soit une architecture complètement décentralisée ou chaque nœud peut tenir n’importe quel rôle, soit la mise en œuvre de nœuds secondaires qui en cas de défaillance prendront le relais.

    Extensible (M)

    Bien évidemment personne ne peut prévoir quelles seront les normes, les cas d’usage, les solutions de demain. Il faut donc au maximum respecter les standards et normes actuelles (quelles soient réelles ou de facto) et éviter les formats et les normes propriétaires.

    Ce principe est important pour garantir l’évolutivité de la plateforme.

    Répétable/déployable sur tous les environnements (M/R)

    On verra par la suite l’importance des tests dans les environnements Big Data. Cela passe donc par des environnements représentatifs du comportement de la solution en production.

    Il faut donc s’assurer :

    • de disposer du même OS dans tous les environnements,
    • de disposer d’une architecture similaire (cluster notamment),
    • de disposer d’une configuration identique,
    • de disposer d’une volumétrie identique,
    • de ne pas être contraints par des problèmes de licences (un environnement d’intégration est-il soumis à une licence commerciale ?).

    Évidemment l’idéal est de s’appuyer sur des systèmes de containerisation comme Docker afin de s’assurer de la reproductibilité sur tous les environnements.

    Share nothing/Stateless (P/S)

    En terme de scalabilité et de résistance à la charge les architectures web stateless ont démontré de meilleures performances. Ce qui est vrai pour les architectures web l’est aussi pour les architectures Big Data. Le meilleur exemple est Kafka dont nous reparlerons.

    Push vers les référentiels secondaires (M)

    L’alimentation des référentiels secondaires tels que les moteurs d’indexation doit se faire par mode push. La source de référence (base NoSQL, Data Lake Hadoop, ...) est en charge de l’alimentation des référentiels secondaires. Cela peut être simplement géré par les possibilités de synchronisation des solutions utilisées.

    Avantages :

    • fraîcheur de la donnée,
    • contrôle de la chaîne d’alimentation.

    Récapitulatif

    PRINCIPES D’UNE ARCHITECTURE BIG DATA

    principe architecture reseau

  • ​Théorème CAP

    Le théorème CAP part d’une conjecture énoncée par le chercheur en informatique Eric Brewer (université de Berkeley) en 2000.

    En 2002, Seth Gilbert et Nancy Lynch du MIT publient une preuve formelle de la vérifiabilité de la conjecture de Brewer.

    Le théorème CAP dit qu’il est impossible sur un système informatique de calcul distribué de garantir en même temps les trois contraintes suivantes :

    • consistency : tous les nœuds du système voient exactement les mêmes données au même moment;
      • En cas d’écriture sur le noeud A, une lecture sur le noeud B renvoie la nouvelle valeur instantanément (ce qui exclut les architectures décentralisées).
    • availability : garantie que toutes les requêtes reçoivent une réponse (succès ou échec);
      • Tous les noeuds du cluster peuvent adresser les lectures et les écritures (ce qui exclut les architectures centralisées).
    • partition : aucune défaillance de tout ou partie des nœuds du cluster ne doit empêcher le système de répondre correctement. 
      • En cas de morcellement en sous-réseaux, chacun doit pouvoir fonctionner de manière autonome.

    D’après ce théorème, un système de calcul distribué ne peut garantir à un instant t que deux de ces contraintes mais pas les trois (t est important et ne supporte aucun délai même infinitésimal). On va donc retrouver trois catégories de solutions, avec chacune leurs points forts et leurs faiblesses qui doivent orienter votre choix en fonction du cas d’utilisation :

    • systèmes “CA”,
    • systèmes “CP”,
    • systèmes “AP”.

    NB : La tolérance à la partition est une composante essentielle des systèmes distribués, elle est donc de fait dans tous les systèmes distribués. Les systèmes de type “CA” sont tout de même évoqués car toutes les composantes d’une application n’ont pas vocation à être distribuées.

    Systèmes "CP"

    Ces systèmes vont privilégier la consistance plutôt que la disponibilité. Ils vont éviter à tout prix de retourner une donnée périmée (i.e. pas la dernière modification), ils vont préférer retourner une erreur. Si la donnée est présente sur n noeuds alors les n nœuds doivent être opérationnels.

    Les cas d’utilisation privilégiés de ces solutions sont les systèmes ou la valeur de la donnée est préférable à une haute disponibilité. Ils ne sont donc pas conseillés dans des systèmes de e-commerce par exemple mais conseillés pour un site bancaire ou de santé par exemple.

    Ex : MongoDB, HBase, Hazelcast

    Systèmes "AP"

    Ces systèmes vont plutôt privilégier la disponibilité plutôt que la cohérence même si le choix est souvent laissé au moment de la configuration du système (cohérence variable). Ces systèmes ne vont donc pas obligatoirement retourner la dernière valeur d’une donnée (en cause le temps de réplication de la valeur dans le cluster).

    Ce délai (appelé entropie) est souvent très faible (de l’ordre de la ms) mais il est bien réel.

    Ces systèmes sont donc à privilégier quand la disponibilité est la problématique principale (site marchand par exemple).

    Ex : Cassandra, Riak, CouchDB, Redis

    Systèmes "CA"

    On va trouver dans cette catégorie tous les systèmes de type maître/esclave ou non distribués. Les données ne sont pas répliquées ou le sont obligatoirement de manière synchrone.

    Les performances sont moins importantes que la fraîcheur et la disponibilité des données. Ces systèmes sont donc à éviter pour les systèmes temps réels. En cas de crash, l’indisponibilité peut être conséquente.

    Ex : Base de données, LDAP.

    THÉORÈME CAP

    Théorème CAP

  • ​Livraison/traitement des systèmes distribués

    Les systèmes de traitements distribués comme Spark ou Flink sont souvent catalogués selon les garanties de livraison/traitement des messages :

    Type de garantie Détails

    Exactly-once delivery/processing

    Chaque message est délivré/traité une et une seule fois

    At-least-once delivery/processing

    Chaque message peut être délivré/traité plusieurs fois

    At-most-once delivery/processing

    Chaque message est délivré/traité au maximum une fois (pertes possibles)

    Idéalement nous souhaitons un système de type “exactly-once delivery/processing”.

    Sans rentrer trop dans les détails, sachez que pour ce genre de systèmes :

    • "exactly-once delivery" est impossible en conditions dégradées.

    Mais le plus important est le traitement unique d’un message soit le respect de la règle “exactly-once processing”.

    En général les systèmes distribués vont garantir :

    • “exactly-once” en conditions normales,
    • “at-least-once” en conditions dégradées.

    Pour garantir un niveau plus élevé les systèmes utilisent un système externe de persistance des messages comme Apache Kafka.

  • ​Traitements Big Data

    Il y a trois grandes familles de traitement dans le Big Data :

    • Batch,
    • Micro-batch,
    • temps réel (streaming).

    Batchs

    Les traitements vont analyser l’ensemble des données disponibles à un instant t.

    • données en entrée : fichiers, résultat d’une requête (HDFS, Sqoop, ...),
    • résultats : les résultats ne seront disponibles qu’à la fin des traitements,
    • latence : souvent de l’ordre de la minute.

    Exemple d’implémentation : MapReduce

    Micro-batchs

    Les traitements vont analyser l’ensemble des données disponibles toutes les n secondes.

    • données en entrée : petits fichiers, API Web, ...
    • résultats : les résultats ne seront disponibles qu’à la fin des traitements d’un micro-batch,
    • latence : souvent de l’ordre de la seconde.

    Exemple d’implémentation : Spark streaming

    Temps réel

    Les traitements vont analyser les données au fur et à mesure de leur disponibilité.

    • données en entrée : petits fichiers, API Web, ...
    • résultats : les résultats sont disponibles au fur et à mesure,
    • latence : parfois inférieur à la seconde.

    Exemple d’implémentation : Flink, Tez, Storm

  • ​Pré requis matériel

    Dimensionnement des serveurs

    Big Data ne veut pas dire Big Hardware, en général on parle de “Commodity hardware”, c’est à dire de serveurs moyenne gamme car l’atout de cette technologie est la scalabilité horizontale.

    Évidemment ce point est à modérer car si l’on suit les recommandations des éditeurs, les machines doivent comporter un nombre élevé de coeurs et une capacité en RAM importante.

    Disques :

    Les disques locaux sont à privilégier (plutôt que SAN) afin de faciliter la co-localisation des traitements et des données.

    De même il vaut mieux multiplier les disques durs que d’augmenter leur capacité et les technologies de mirroring (RAID) sont rarement nécessaires pour la redondance (elle est gérée par le système de stockage).

    La technologie SSD est bien sûr recommandée pour les fichiers accédés fréquemment (journal des modifications pour les systèmes NoSQL).

    Utilisation des puces graphiques (GPU)

    Une tendance qui commence à se dessiner est l’utilisation des GPU en complément des CPU pour les traitements. De part leur architecture les GPU sont particulièrement adaptés au Big Data, ils sont composés d’un maximum de puces dédiées aux traitements parallèles, de milliers de cœurs, ... Ils sont donc idéaux pour les calculs répétitifs et mathématiques.

    A l’opposé les CPU ne gèrent pas uniquement les traitements dans un serveur et leur nombre de cœurs est limité.

    Les GPU ne remplacent pas les CPU mais permettent une architecture hybride pour le Big Data.

    Il existe des expérimentations Hadoop sur GPU menées par Yahoo pour du Deep Learning. Ils ont constaté un gain important (x10) pour ce type de traitements par rapport à des architectures sur CPU.

    Il existe déjà des initiatives sur le cloud :

    1. Amazon propose des clusters GPU pour son offre cloud EC2 (l’utilisateur choisit entre CPU et GPU)
    2. Deep-learning sur Spark à l’aide de GPU : http://fr.slideshare.net/SparkSummit/a-scaleable-implementation-of-deep-learning-on-spark-alexander-ulanov

    Virtualisation

    La virtualisation n’est pas mise en avant par la majorité des solutions Big Data qui recommandent souvent une approche de type « bare metal ».

    La virtualisation est toutefois supportée par la plupart des solutions. Il est à noter qu’en termes de coût de licence elle n’est pas toujours avantageuse (système de facturation qui ne tient pas compte des ressources allouées aux machines virtuelles mais des ressources physiques).

ECRIVEZ NOUS SI VOUS AVEZ UNE QUESTION SUR CE CHAPITRE
Pdf 11.39Mo
loading
POSEZ-NOUS VOTRE QUESTION
loading