Solutions    
  • ​Solutions Big Data

    Traitement

    Hadoop a posé les bases du Big Data (surtout en termes de traitements). La plateforme est capable de traiter des volumes conséquent de données, mais avec une latence importante. C’est pourquoi sont apparu des systèmes temps réels tels que Spark, Storm, Flink, Druid, ou encore Tez.

    L’enjeu étant de conserver les points forts de la plateforme Hadoop :

    • capacité à traiter des quantités énormes de données,
    • sécurité,
    • distribution,
    • tolérance à la panne.

    Tout en augmentant les possibilités d’interactions grâce à des traitements temps réels.

    Les solutions temps réel améliorent les performances grâce à une meilleure utilisation de la mémoire mais aussi (surtout) en offrant la possibilité de définir des fenêtres de traitements (micro batch, windowing) ainsi que des traitements itératifs.

    Stockage

    Coté stockage, il y a émergence des solutions NoSQL. Même si certaines solutions se détachent en termes de part de marché (MongoDB, Cassandra, CouchDB, ...) il n’y a pas de solutions universelles capables de répondre à tous les besoins.

    Une erreur classique héritée de pratiques répandues dans le monde des SGBD-R ou des serveurs d’applications consiste à ne retenir pour l’ensemble d’un SI qu’une seule solution. Cette approche était déjà ambiguë et souvent contre productive avant, elle l’est encore plus dans le monde du Big Data.

    Il n’y a rien de pire que l’utilisation d’une solution en dehors de son cadre d’utilisation, c’est typiquement le genre de pratique qui peut faire perdre beaucoup de temps et aboutir à une solution instable. Évidemment cela n’est pas vrai pour l’ensemble des entreprises qui n’ont pas des besoins nécessitant plusieurs implémentations mais c’est un écueil fréquent.

    Interrogations

    Le (pseudo)SQL tente de s’imposer comme standard pour l’interrogation des données stockées dans le Big Data. C’est le cas des solutions comme Hive, Drill, ou Spark SQL, ... Même s’il manque une normalisation entre les différentes implémentations du pseudo-SQL, l’apprentissage est rapide pour quiconque possède une base dans la syntaxe SQL.

    Au final le but est de permettre une exploration interactive des données, et d’ouvrir la plateforme à une population plus large que celle des programmeurs.

  • ​Catégories

    Catégories des solutions Big Data :

    • ingestion/extraction de données,
    • traitement de données,
    • analyse/apprentissage,
    • data visualisation,
    • requête,
    • workflow,
    • stockage,
    • ordonnancement,
    • sécurité,
    • gouvernance,
    • messages,
    • frameworks.

    TRAITEMENTS

    Traitements

  • ​Ingestion/Collecte

    Talend

    Site web http://www.talend.com
    Licence GPL et commerciale
    Technologie Java
    Année création 2005

    Talend est un ETL open source, développé par la société française Talend. Il permet de créer graphiquement des processus de manipulation et de transformation de données puis de générer l’exécutable correspondant sous forme de programme Java.

    Talend permet :

    • la synchronisation entre deux systèmes de données,
    • la transformation des données.
    • Connecteurs :
    • SGBD,
    • fichiers,
    • Base NoSQL,
    • Hadoop,
    • Spark
    • ...

    Sqoop

    Site web http://sqoop.apache.org
    Licence Apache
    Technologie Java
    Année création 2009

    Sqoop est un projet de la fondation Apache qui a pour objectif de permettre une meilleure cohabitation des systèmes traditionnels de type SGBDs avec la plateforme Hadoop. Il est ainsi possible d’exporter des données depuis la base de données et de procéder aux traitements coûteux en exploitant le cluster Hadoop. Les bases de données traditionnelles sont très répandues et Sqoop permet à des applications traditionnelles de profiter d’un cluster Hadoop.

    Inversement, il est possible d’exporter le résultat d’un traitement vers une base de données tierce afin qu’il soit exploité par une application (à des fins de restitution par exemple).

    Sqoop a été conçu avec comme objectif principal d’assurer des performances élevées pour ces opérations d’import ou d’export massifs grâce à la parallélisation des traitements. Un job Sqoop c’est :

    • une requête de sélection des données dans la cible,
    • un mapping entre source et cible.

    Datastax fournit une version de Sqoop capable de s’interfacer avec Cassandra.

  • ​Messages

    Kafka

    Site web http://kafka.apache.org
    Licence Apache
    Technologie Java
    Année création 2005

    Kafka est un broker de messages crée par Linkedin à la fois très performant et scalable. Kafka est un système de messagerie distribué, initialement développé par l’équipe de Jay Kreps chez LinkedIn, et publié en 2011, en tant que projet open source Apache.

    Les créateurs du projet ont ensuite fondé la société Confluent en 2014 qui propose du support mais aussi sa propre plateforme de streaming.

    Kafka s’appuie sur le système de fichiers pour gérer les événements reçus. La file de messages est donc persistée (et les données distribuées) et reconsultable à tout moment.

    Contrairement à ce qu’on retrouve dans les systèmes de messagerie traditionnels, un message stocké dans un cluster Kafka ne possède pas d’identifiant. En fait, chaque message d’une partition se voit assigné un offset (ou position) unique permettant de le localiser au sein d’un log. C’est notamment de cette manière qu’un cluster Kafka peut ainsi supporter un nombre très large de consommateurs tout en retenant un très gros volume de messages.

    Concepts

    • Broker : un service Kafka,
    • Topic : une file de messages,
    • Log : stockage des messages,
    • Zookeeper : gestion du clustering.

    Consommation des messages

    Kafka propose la gestion de groupe de consommateur, qui sont des clients abonnés a un même topic. Ceci qui permet de ne traiter qu’une seule fois un message d’un topic lu par plusieurs consommateurs.

    Kafka propose trois API pour les consommateurs :

    • Low Level,
    • High Level,
    • New Consummer (en béta depuis la 0.9).

    Ces API permettent aux clients de mieux contrôler la façon de consommer les messages et notamment la gestion du message courant (offset).

    Si la perte de message n’est pas primordiale alors on peut opter pour une gestion automatisée de l’offset : quand un message est lu par un consommateur alors la position courante évolue automatiquement (au bout d’un certain délai le plus souvent). Si jamais le consommateur crash avant d’avoir pu traiter le message alors ce message ne pourra plus être traité (en tout cas sans code particulier).

    Au contraire on peut opter pour une gestion coté client de l’avancement dans la file de message, le client ne faisant évoluer l’offset qu’après avoir traité le message. C’est notamment le cas avec le connecteur Spark/Kafka (direct stream) qui va même plus loin puisqu’il ne modifie pas du tout l’offset. En cas de crash tous les messages sont relus et donc traités.

    Toutefois Kafka ne conserve pas indéfiniment les messages, ceux ci ont une durée de vie au sein des topics (168 heures soit 7 jours par défaut).

    Partitions

    Kafka étant un système distribué, les topics sont partitionnés à travers plusieurs nœuds du cluster. Kafka diffère des systèmes de messagerie traditionnels par sa capacité à traiter chaque topic comme un log, c’est-à-dire un ensemble ordonné de messages. En raison de sa scalabilité et de ses performances, Kafka est le système privilégié par de nombreux systèmes de traitements (Apache Spark, Flink, ...) pour assurer la reprise sur erreurs.

    Redis

    Site web http://redis.io
    Licence BSD
    Technologie C/C++
    Année création 2009

    Redis est un dépôt de données clé/valeur issue de la mouvance NoSQL et créé en 2009 par Salvatore Sanfilippo et Pieter Noordhuis. Le projet est sponsorisé par VMware et Pivotal.

    Une des principales caractéristiques de Redis est de conserver l’intégralité des données en mémoire. Cela permet d’obtenir d’excellentes performances en évitant les accès disques, particulièrement coûteux. Lorsque la taille des données est trop importante pour tenir en mémoire, Redis peut également utiliser de la mémoire virtuelle (swap).

    Tolérance à la panne

    Redis s’appuie sur deux mécanismes afin d’assurer la continuité de service ainsi que la non perte de données malgré son stockage uniquement en mémoire.

    • sauvegarde : Il est possible de créer régulièrement une image de l’état des données dans un fichier (principe du snapshot).
    • journal des modifications : Il est également possible de conserver une trace de toutes ces manipulations. En cas d’incident, la base peut être restaurée en rejouant dans l’ordre les événements.

    Réplication des données

    Redis supporte la réplication via un modèle maître/esclave à des fins de résistance aux pannes et de répartition de la charge. Toutes les écritures  doivent se faire via l’instance maîtresse, mais il est possible de faire des lectures sur les instances esclaves.

    Partitionnement (sharding)

    Il est possible, afin d’améliorer les performances en écriture, de partitionner les données au sein des différentes instances Redis du cluster. Deux modes sont proposés pour la répartition des données en fonction de la valeur de la clé : intervalle ou hash.

    Les deux modes partitionnement et réplication ne sont pas compatibles.

    Clients natifs :

    • C#,
    • C++,
    • Clojure,
    • Java,
    • Javascript,
    • Objective-C,
    • Python,
    • R,
    • Scala, ...

    En termes de commandes et de manipulation des données Redis va bien au delà d’un système simple de type CRUD :

    • richesse de manipulation des chaînes de caractères,
    • richesse de manipulation des listes :
    • récupérer le premier/dernier élément d’une liste,
    • extraire et insérer un élément d’une liste à l’autre,
    • requêtes plus complexes (géo-spatiales, agrégations, mathématiques, ...),
    • hyperLogLog, compteurs, ...

    Redis propose aussi une interface de type REST pour la manipulation des données.

    Fonctionnalités avancées

    • transactions,
    • enchaîner des commandes (pipeline).

    Sécurité

    Il est possible de sécuriser Redis avec un mot de passe obligatoire. Ce mot de passe est commun à l’ensemble des clients et il n’est pas (encore) possible de définir de rôles.

  • ​Stockage

    Cassandra

    Site web http://cassandra.apache.org
    Licence Apache
    Technologie Java
    Année création 2008

    Cassandra est une autre base de données de la mouvance NoSQL.

    Initialement développée par Facebook en 2008, elle a été par la suite libérée et son développement est aujourd’hui assuré par la fondation Apache. La société Datastax fournit du support ainsi qu’une version Entreprise avec quelques fonctionnalités supplémentaires.

    Cassandra est une base de données orientée colonne. Étudiée pour des déploiements massivement distribués (éventuellement sur plusieurs datacenters). Cassandra permet de stocker un élément qui est un ensemble de valeurs reliées entre elles par un identifiant unique.

    Une valeur dans Cassandra est caractérisée par :

    • rowKey (identifiant unique),
    • nom colonne,
    • valeur colonne,
    • + Timestamp automatiquement géré par Cassandra,
    • + Date d’expiration de la donnée (option).

    Son architecture complètement décentralisée lui assure une résistance à la panne très importante. Elle est particulièrement adaptée aux problématiques “timeseries” (suite de données chronologiques).

    Les différentes distributions

    • Apache Cassandra
      • licence : Apache License, Version 2.0
      • comprend la base de données et les utilitaires
    • DataStax
      • DSC : Version communautaire (Apache Cassandra + exemples + Ops Center light)
      • DSE : Version entreprise

    Cycle de stockage d’une écriture

    • Écriture dans le commit log,
    • Écriture en mémoire : Memtable,
    • Écriture sur disque : SSTable.

    Tolérance à la panne

    Cassandra s’appuie sur deux mécanismes afin d’assurer la continuité de service ainsi que la non perte de données :

    • Sauvegarde : Il est possible de créer une image de l’état des données dans un fichier.
    • Journal des modifications : Cassandra utilise un fichier trace de toutes les manipulations de données. La durée de vie des traces est paramétrable.

    Réplication des données

    Cassandra supporte la réplication via un modèle “masterless” à des fins de résistance aux pannes et de répartition de la charge. Les nœuds se partagent les données qui sont répliquées un certain nombre de fois (Replicas).

    Tous les replicas ont le même rôle, on peut lire/écrire sur n’importe quel nœud, le nœud contacté sert de coordinateur et est en charge de solliciter les nœuds qui hébergent (lecture), hébergeront (écriture) la donnée.

    Pour des raisons évidentes de performances, le driver contacte directement les nœuds concernés (grâce au token).

    Partitionnement des données

    Les données sont réparties uniformément sur les réplicas (facteur de réplication). Chaque partition se voit affecter un lot de données à héberger en fonction du hash de la clé de partition.

    Sécurité

    L’accès au cluster peut être protégé par un mot de passe. Pour des fonctionnalités plus avancées (LDAP, chiffrement des données) il faut recourir aux versions commerciales.

    HBase

    Site web http://hbase.apache.org
    Licence Apache
    Technologie Java
    Année création 2006

    HBase est un sous projet d’Hadoop, c’est un système de gestion de base de données non relationnelles distribué, écrit en Java, disposant d’un stockage structuré pour les grandes tables.

    HBase est né afin de proposer un accès temps réel à un cluster Hadoop. Contrairement à HDFS l’accès au données est aléatoire et donc plus performant malgré les très fortes volumétries.

    Facebook pourtant à l’origine de Cassandra a décidé de l’abandonner en 2010 au profit de HBase.

    HBase est inspiré des publications de Google sur BigTable, c’est donc une base de données orientée colonnes et sans schéma (en théorie). HBase est très lié à Hadoop et en mode cluster HDFS est obligatoire.

    Chaque valeur d’une cellule (champ dans le monde relationnel) est horodatée (tout comme Cassandra) ce qui permet de récupérer une ancienne version du contenu.

    Concernant la purge de ces anciennes valeurs, HBase propose deux options :

    • définir le nombre de versions à conserver,
    • définir une durée de vie pour les données (en secondes).

    Il est possible de combiner ces deux paramètres.

    Une table est segmentée en plusieurs partitions que l’on nomme région, ces partitions sont réparties entre les différents serveurs. Ces partitions sont horizontales, c’est à dire découpées par intervalle de clés contigües.

    La gestion des régions est dynamique :

    • la région est divisée quand elle dépasse une certaine taille,
    • deux régions peuvent être fusionnées pour des raisons d’optimisation.

    Lors d’une modification les opérations sont consolidées en mémoire (tampon) avant d’être persistées sur disque.

    Contrairement à Cassandra l’architecture est de type maître/esclave, un maître (HMaster) est chargé de la coordination des opérations et du cluster. Parmi les opérations gérées directement par le HMaster, on trouve les manipulations sur les tables (création, modification et suppression).

    Par contre les lectures, écritures se font directement sur les nœuds abritant les données.

    Zookeeper est utilisé pour la gestion des ressources du cluster.

    Cas d’utilisation :

    • HBase est souvent utilisé conjointement au système de fichiers HDFS, ce dernier facilitant la distribution des données de HBase sur plusieurs noeuds.

    HBase est alors un moyen supplémentaire d’interroger les données construites avec Hadoop. Contrairement à HDFS, HBase permet de gérer les accès aléatoires read/write pour des applications de type temps réel.

    HDFS

    Site web http://hadoop.apache.org/
    Licence Apache
    Technologie Java
    Année création 2005

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

    HDFS est un système de fichiers distribués, extensible et portable développé par Hadoop à partir 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 standards.

    HDFS s’appuie sur le système de fichier natif du système d’exploitation 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.

    Un cluster HDFS comporte deux types de composants majeurs :

    • NameNode :

    Ce composant gère les fichiers et les répertoires du cluster de manière centralisée.

    Il est unique (pour un namespace) mais dispose d’une instance secondaire afin d’assurer la continuité du fonctionnement du cluster Hadoop en cas de panne.

    • DataNode (nœud de données) :

    Ce composant stocke et restitue les blocs de données (données primaires) et abrite des copies des autres instances.

    Par défaut, les données sont stockées sur trois nœuds différents : dans deux nœuds proches (même machine ou rack) et l’autre sur un nœud plus distant. Le RAID est par conséquent inutile sur un cluster HDFS.

    La consistance des données est basée sur la redondance. Une donnée est stockée sur au moins n volumes différents (souvent 3).

    Un principe important d’HDFS est que les fichiers sont de type «write-once/immutable» car dans des opérations analytiques, on lit la donnée beaucoup plus qu’on ne l’écrit. C’est donc sur la lecture que les efforts ont été portés.

    Ce qui signifie que l’on ne modifie pas les données déjà présentes, on les remplace entièrement.

    Un principe lié est qu’à partir du moment où un fichier HDFS est ouvert en écriture, il est verrouillé pendant toute la durée du traitement.

    Il est donc impossible d’accéder à des données ou à un résultat tant que le job n’est pas terminé et n’a pas fermé le fichier (et un fichier peut être très volumineux avec Hadoop).

    Résumé de Hadoop Distributed File System :

    • Open Source,
    • développé en Java,
    • supporte de très gros volumes,
    • tolérant à la faute,
    • un ensemble de disques de taille modeste,
    • possibilité d’OS hétérogènes (c’est une surcouche),
    • blocs de 64 Mo à 1 Go (un fichier est donc découpé en n blocs, le prendre en compte dans les traitements),
    • de type write-once (impossible de modifier a posteriori un enregistrement),
    • le verrou est posé sur tout le bloc pendant la phase d’écriture (impossible de lire),
    • plus lent que l’OS : ± 25 % en lecture, ± 50 % en écriture.
    • haut débit (volume),
    • scalable,
    • localisation des disques dans une machine/un rack.

    Politique de réplication :

    3 replicas dont 1 replica sur la machine locale et 2 replicas sur un rack distant.

    MongoDB

    Site web http://www.mongodb.org
    Licence Affero GPL
    Technologie C/C++
    Année création 2009

    MongoDB est une base de données orientée documents de la mouvance NoSQL permettant le stockage de documents au format BSON (une forme binaire de JSON). Son langage d’interrogation est aussi au format JSON.

    Elle dispose de mécanismes de réplication et de sharding afin d’assurer la résilience et la scalabilité même si son architecture est de type maître/secondaire. Un mécanisme d’élection permet d’assurer la continuité de service en cas de défaillance du maître.

    MongoDB est schemaless, ce qui signifie que les documents d’une même collection n’ont pas tous les mêmes champs. On peut ajouter / retirer des champs à un document sans migration.

    MongoDB se positionne comme une base NoSQL généraliste avec des cas d’utilisation proches des SGBD relationnels (à l’exception du transactionnel) : 80% des applications actuelles qui utilisent un SGBD sont visées.

    Chaque opération (lecture, écriture, mise à jour) demande un lock avant de commencer à accéder aux données. Il y a deux types de locks dans MongoDB :

    • lock de lecture : peut être partagé entre plusieurs opérations de lecture,
    • lock d’écriture : exclusif, ce qui veut dire qu’aucune autre opération ne peut avoir lieu (écriture ou même lecture).

    Depuis la version 3.0 le lock d’écriture peut être positionné au niveau documents (uniquement en utilisant le moteur de stockage WiredTiger). Plus globalement, la version 3 apporte une ouverture des API internes pour permettre à un éditeur de plugger son propre moteur de stockage.

    Actuellement sont disponibles : MMAPv1, WiredTiger, TokuMX,RocksDB.

    Les frameworks d’agrégation permettent d’aller au-delà des opérations simples sur les données afin de proposer des capacités d’analyse poussées.

    L’un des points forts de MongoDB est la multitude de clients disponibles:

    • JavaScript,
    • Python,
    • Ruby,
    • PHP,
    • Perl,
    • Java,
    • Scala,
    • C#,
    • C,
    • C++,
    • Haskell,
    • Erlang.

    La solution est supportée par la société MongoDB qui propose une version commerciale et du support.

    La version commerciale apporte :

    1. Sécurité étendue
    2. Utilisation de la solution de monitoring en local et non sur le cloud
    3. Sauvegardes incrémentales
    4. MongoDB Compass (analyse des modèles)
    5. Base mémoire
    6.  ...

    Neo4j

    Site web http://neo4j.org
    Licence GPLV3
    Technologie Java
    Année création 2003

    Neo4j est une des plus anciennes base NoSQL (première version en 2000). C’est une base orientée graphes écrite en Java.

    Les données sont stockées sur disque sous la forme d’une structure de données optimisée pour les réseaux de graphes.

    Les bases de données orientées graphes, sont particulièrement adaptées dans des contextes où les données sont fortement connectées et organisées selon des modèles complexes. La structure de l’entité (nœud ou relation) y est définie au moment du stockage de la donnée (structure schemaless), ce qui lui confère une très grande flexibilité.

    Étant spécialisée dans ce domaine le parcours de graphes est particulièrement performant.

    En plus de la structuration des données, Neo4j diffère aussi techniquement des autres bases NoSQL par les points suivants :

    • support des transactions ACID (commit à 2 phases, compatibilité XA),
    • utilisable en mode embarqué ou serveur,
    • langage d’interrogation CYPHER.

    Du fait du support de pseudo transactions l’architecture de Neo4j (et celle des autres bases orientées graphe) est obligatoirement de type maître/esclave (les mises à jour doivent être centralisées).

    Cas d’utilisations :

    • web Sémantique et RDF,
    • web des données (LinkedData),
    • données cartographiques (GIS),
    • réseaux sociaux,
    • configurations/catégories de produits, ...

    Liste des connecteurs disponibles :

    • Java,
    • .NET,
    • Ruby,
    • Python,
    • Go,
    • etc

    Fonctionnalités de la version entreprise :

    • cache répliqué,
    • haute disponibilité, réplication
    • sauvegarde à chaud,
    • etc

    CouchBase

    Site web http://www.couchbase.com/
    Licence Apache + commerciale
    Technologie C/C++
    Année création 2011

    CouchBase est une base orientée document née en 2011, elle est issue du rapprochement de deux projets Open Source : Membase (basé sur memcached) et Apache CouchDB avec lesquels il reste compatible.

    CouchBase stocke les documents au format JSon et propose les moyens suivant pour accéder aux données :

    • en utilisant la clé unique,
    • à travers les vues (de deux types MapReduce/spatial construites à partir de fonctions JavaScript),
    • au moyen d’un langage pseudo SQL (N1QL),
    • grâce à la recherche plein texte (Full Text Search).

    Tout comme MongoDB, le format JSon permet à CouchBase d’être shemaless, il est aussi possible de définir une durée de vie automatique aux données (TTL).

    CouchBase supporte la gestion multi-datacenter en mode bidirectionnel.

    Ceci permet d’assurer la continuité de service en cas d’indisponibilité d’un datacenter mais aussi à l’utilisateur d’interroger le datacenter le plus proche en fonctionnement normal.

    CouchBase propose les filtres de réplication qui permettent de sélectionner les données à répliquer entre deux datacenters (version entreprise uniquement).

    La version 4.0 apporte un nouveau langage SQL pour requêter les données et capitaliser sur les compétences SQL des entreprises et aussi simplifier la montée en compétence.

    N1QL étend la syntaxe de base de SQL afin de faciliter l’interprétation des des documents JSon et de les traiter comme des données tabulaires en provenance d’une base SQL classique (fonctions Nest et UnNest).

    Contrairement à d’autres bases NoSQL, N1QL supporte les jointures entre les tables.

    Un autre avantage est la présence de pilotes ODBC/JDBC qui vont permettre de créer des jointures entre des bases relationnelles (mais aussi Excel et Tableau) et des bases CouchBase.

    CouchBase propose de nombreux connecteurs qui vont permettre l’intégration avec des solutions de traitement, de gestion d’événements ou d’indexation :

    • Talend,
    • ElasticSearch,
    • Hadoop,
    • Kafka,
    • Spark.

    Depuis la version 4, il est possible d’attribuer des rôles aux nœuds CouchBase parmi les possibilités suivantes :

    • requêtage (Query Service),
    • indexation (Indexing Service),
    • stockage des données (Data Service).

    Cette répartition des fonctionnalités (Multi Dimensional Scaling) n’est disponible que dans la version entreprise. Il existe aussi un autre rôle, Cluster Manager : tous les nœuds ont ce rôle mais un seul est choisi pour une opération donnée, c’est l’orchestrator.

    Une donnée est répliquée sur les nœuds du cluster afin d’assurer la continuité de service en cas de crash d’un nœud.

    CouchBase peut partitionner les données grâce au concept de Bucket.

    Un Bucket permet de distribuer les données d’une table sur différents nœuds (c’est le principe du sharding). Le choix d’un Bucket est important car il va permettre de distribuer la charge sur différents nœuds.

    Pour implémenter le principe de Bucket CouchBase utilise les vBuckets Chaque Bucket est divisé en 1024 vBuckets actifs et 1024 vBuckets répliqués qu’il va distribuer équitablement sur tous les nœuds qui exécutent le service de stockage de données (Data Service).

    Un service permet de faire le lien entre un vBucket et sa localisation (cluster map).

    CouchBase bénéficie d’une déclinaison mobile native qui peut être déployée sur un terminal. Ceci permet de synchroniser automatiquement la base mobile à partir du serveur CouchBase, et à l’inverse de conserver les données du terminal déconnecté pour une synchronisation ultérieure.

    Architecture :

    • Couchbase Lite : déclinaison mobile de la base de données (iOS, Android et Java),
    • Sync Gateway : gestion de la synchronisation (authentification des utilisateurs, contrôle des accès, filtrage et validation des données) entre les terminaux mobiles et le serveur,
    • Couchbase Server : base de données NoSQL.

    Les plus de la version entreprise :

    • sécurité avancée,
    • filtres de réplication,
    • sauvegardes incrémentales,
    • localisation des nœuds (racks, ...),
    • Multi-dimensional scaling.

    En temps normal, CouchBase va combiner les deux solutions :

    • Memcached pour le cache et couchDB pour les fonctionnalités NoSQL et la persistance.

    Mais il est possible de choisir uniquement Memcached :

    API Memcached CouchDB
    Limite d’un document 1 Mo 20 Mo
    Réplication Non Oui
    Réplication DataCenter Non Oui
    Chiffrement des données Non Oui
    Sauvegarde Non Oui
    Stockage Mémoire Persistant

    Une API REST permet d’accéder à l’administration du cluster.

    Une interface web (Couchbase Web Console) permet d’accéder aux statistiques ainsi qu’à l’administration du cluster.

    Enfin un outil en ligne de commande permet d’accéder aux métriques du cluster (cbstats).

  • ​Transformation/Enrichissement

    Spark

    Site web

    http://spark.apache.org/

    Licence

    Affero GPL

    Technologie

    Scala

    Année création

    2009

    Spark est né en 2009 dans le laboratoire AMPLab de l’université de Berkeley en partant du principe que :

    • d’une part, la mémoire coûte de moins en moins cher et les serveurs en ont donc de plus en plus à disposition.
    • d’autre part, beaucoup de jeux de données dits “Big Data” ont une taille de l’ordre de 10 Go et ils tiennent donc en mémoire.

    Il fallait donc un système de traitement qui privilégie le traitement en mémoire des données.

    Le projet a intégré l’incubateur Apache en juin 2013 et est devenu un “Top-Level Project” en février 2014.

    Le projet s’est enrichi progressivement afin de proposer aujourd’hui un écosytème complet.

    L’écosystème Spark comporte ainsi aujourd’hui plusieurs outils :

    • Spark pour les traitements “en batch”
    • Spark Streaming pour le traitement en continu de flux de données
    • MLlib pour le “machine learning”, complété par SparkML depuis 2012
    • GraphX pour les calculs de graphes
    • Spark SQL, une implémentation SQL-like d’interrogation de données.

    Enfin, le framework est écrit en Scala et propose un binding Java qui permet de l’utiliser sans problème en Java. Java 8 est toutefois recommandé pour exploiter les expressions lambdas qui permettront d’écrire un code plus fonctionnel.

    Il existe des versions de Spark spécifiques pour Python et R afin de capitaliser sur les langages habituellement maîtrisés par les Data Scientists.

     

    Vue de l’écosystème Spark :

     

    Gestion des clusters

    Options disponibles avec Spark :

    • Standalone,
    • Mesos,
    • Yarn,
    • Cloud (Amazon EMR, Google DataFlow, …),
    • Cassandra (en version entreprise et basé sur Mesos).

    ​Batch

    Un RDD (Resilient Distributed Dataset) est une abstraction de collection sur laquelle les opérations sont effectuées de manière distribuée tout en étant tolérante aux pannes matérielles.

    En utilisant les types proposés par Spark et en respectant certaines contraintes, le traitement sera automatiquement découpé pour s’exécuter sur plusieurs noeuds. En cas de perte d’un nœud, le sous traitement sera automatiquement relancé sur un autre nœud par le framework, sans que cela impacte le résultat.

    L’API exposée par le RDD permet d’effectuer des transformations sur les données (map, filter, reduce, etc).

    Ces transformations sont “lazy” : elles ne s’exécuteront que si une opération finale est réalisée en bout de chaîne.

    ​Streaming (micro batch)

    Une API (Spark Streaming) permet à Spark de traiter les événements en temps réel et non plus en batch.

    En réalité Spark utilise le principe des micro-batch, c’est-à-dire que l’on peut obliger Spark à fournir un résultat au bout d’un certain temps et ce même si les événements en entrée continuent d’arriver.

    Structured Streaming

    La version 2.0 de Spark apporte le "Structured Streaming" qui n'est pas une nouvelle API mais un enrichissement des APIs existantes.

    Avec cette évolution il est en effet plus facile de gérer les cas nécessitant du temps réel et une réactivité plus forte.

    Le "Structured Streaming" permet de gommer l'aspect micro-batch de l'API Streaming.

    Structures spécifiques Spark

    En plus des RDD, Spark propose deux API plus riches : Les DataFrames et les DataSet.

    L'API DataFrame a fait son apparition en version 1.3, le but étant d'offrir une API plus fonctionnelle (en utilisant Spark SQL) et faire la jonction entre Spark et les DataAnalyst. Pour cela l’API DataFrame exige de définir un schéma qui va permettre de décrire et de manipuler les données contenues.

    Ce schéma peut être automatiquement crée lorsque la source de données le permet (SGBD, Hive, fichiers CSV, …) ou devra être définie si le DataFrame est construit à partir d’un RDD par exemple.

    L'API DataSet a fait son apparition en version 1.6, le but étant d'offrir une API profitant de la puissance des RDD et du moteur d’exécution Spark SQL. L’API DataSet permet de manipuler avec Spark SQL des objets métiers écrit en Java/Scala.

    L’API DataSet est une extension de l’API DataFrame, c’est pourquoi Spark 2.0 unifie ces deux API.

    ​Gestion des Graphes

    Pour la gestion des graphes, Spark s'appuie sur la solution GraphX.

    GraphX est un framework distribué de graphes construit au dessus de Spark (depuis 2013). Il fournit à la fois une API de modélisation et d'exécution et est basé sur le projet Google Pregel. GraphX privilégie la simplicité d'utilisation et non la vitesse de traitement. C'est sans doute dû à une population ciblée différente (Big Data Analyst).

    ​Machine Learning

    Spark utilise la librairie MLlib dont la notoriété est grandissante. Une évolution nommée (Spark ML) est à la fois une refonte de certains traitements ainsi qu’un ajout de fonctionnalités.

    Concrètement MLlib va utiliser l’API RDD, alors que Spark ML utilise les DataFrames.

    ​Tolérance à la panne

    “exactly once” en conditions normales et “at least once” en conditions dégradées. La haute tolérance doit être activée par l’utilisateur (Write Ahead Log).

    Performances

    Afin d’améliorer les performances, Spark a lancé le projet Tungsten en 2015 qui a pour objectif une meilleure gestion de la mémoire, les opérations sur les données binaires, etc.

    ​MapReduce

    Site web

    https://hadoop.apache.org/

    Licence

    Apache

    Technologie

    Java

    Année création

    2005

     

    MapReduce est un framework de traitements parallélisés, créé par Google pour indexer les contenus de son moteur de recherche web. Disponible sous forme de document de recherche, sa première implémentation est apparue au moment du développement d’Hadoop en 2005.

    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.

    Dans un traitement MapReduce, différents acteurs vont intervenir :

    • Workers : liste de nœuds Hadoop capables de traiter des tâches MapReduce
    • Master : un worker dédié à la gestion des tâches
    • Client : lance le traitement MapReduce (souvent nommé driver)

    Les différentes phases (Hadoop)

    1. Initialisation : le client/driver charge un/des fichiers dans HDFS et soumet un traitement MapReduce à la grille
    2. Split : les données en entrée sont éventuellement divisées en blocs (16-64 Mo)
    3. Affectation : le master affecte les tâches (Map et Reduce) aux workers ; la configuration définit le nombre de tâches de type Map et Reduce supportées par chacun des noeuds
    4. Map : lecture des splits qui sont transmis à la fonction Map ; les ensembles clé/valeur produits par la fonction sont d’abord stockés en mémoire avant d’être périodiquement écrits localement et non sur HDFS
    5. Shuffle : les résultats des fonctions Map sont agrégés par la valeur de la clé pour produire une liste de valeurs traitées par le Reducer
    6. Reduce : le master distribue au Reducer la liste des données à traiter ; les résultats sont envoyés au flux de sortie (HDFS, web services, …)
    7. Combiner : optimisation, utilise les résultats intermédiaires du Map en entrée pour un traitement qui est généralement équivalent au Reducer (pas de garantie de passage)
    8. Fin : le master redonne la main au programme client

    Implémentation

    En plus d’Hadoop, MapReduce est disponible dans une multitude de frameworks

    1. NoSQL : Cassandra, MongoDB
    2. Traitements distribués : Spark, Flink
    3. Cloud

    ​Flink

    Site web

    https://flink.apache.org/

    Licence

    Apache

    Technologie

    Java

    Année création

    2009

     

    Apache Flink est un Top Level Project Apache depuis décembre 2014.

    Anciennement nommé Stratosphere et projet de recherche par Data Artisans il a été créé en 2009 (tout comme Spark).

    Son but est de fournir un framework de traitements distribués en mémoire adapté au traitement temps réel.

    Différences avec Spark :

    • Flink a été conçu dès le départ pour le temps réel.
    • Flink a été écrit initialement en Java et supporte Scala grâce à des wrappers.
    • Flink peut exécuter des traitements Hadoop directement (idéal pour une transition en douceur).

    Apache Flink comprend :

    • Des APIs en Java/Scala pour le traitement par batch et en temps réel,
    • Un moteur de transformation des programmes en flots de données parallèles,
    • Un moteur d'exécution pour la distribution des traitements sur un cluster.

    Flink propose une véritable API de streaming mais aussi de micro batch.

    Gestion des clusters

    Options disponibles avec Flink pour la gestion des clusters :

    • Standalone,
    • Yarn,
    • Cloud (EC2, Google DataFlow, …),
    • Apache TEZ

    Liste des connecteurs streaming :

    1. File System (HDFS, S3, Azure,...)
    2. JDBC
    3. Cache (Memcached)
    4. NoSQL (Hbase, Redis, ...)
    5. Kafka
    6. Rabbit MQ
    7. Flume
    8. Twitter
    9. ...

    API Fonctionnelle

    L'API Table est aussi très récente et permet de formaliser les traitements dans une forme proche de la syntaxe SQL. Cette API est disponible pour le batch et le temps réel et offre une API de haut niveau qui apporte concision et clarté.

    ​Gestion des graphes

    ​Jusqu'à récemment la gestion des graphes avec Flink était déléguée à Apache Spargel (projet générique).

    Un projet nommé Gelly a été lancé afin de tirer profit des spécificités de Flink.

    Gelly offre :

    1. Utilitaires d'analyse de graphes
    2. Traitements itératifs sur les graphes
    3. Algorithmes dédiés aux graphes

    Gelly n'est compatible qu'avec des objets héritant des DataSet (Vertex et Edges) et n'est donc compatible qu'avec les batchs et non les flux temps réel.

    Parmi les algorithmes :

    • PageRank,
    • Weakly Connected Components,
    • Single Source Shortest Paths,
    • Label propagation.

    Gelly est actuellement en bêta et le but à terme est de remplacer Spargel.

    Machine learning

    Flink Machine Learning Library (Flink-ML), orienté pipeline inspiré de scikit-learn (framework de ML écrit en python).

    Implémentation des principaux algorithmes de Machine Learning optimisés spécifiquement pour Flink.

    Flink-ML dispose des algorithmes suivants :

    • Classification
    • Regression (Logistic regression)
    • Clustering (k-Means)
    • Recommendation (Alternating least squares)

    NB : il existe d'autres algorithmes mais uniquement en Scala pour le moment (est-ce une tentative de séduction des “data analyst” ?).

    Une intégration avec Mahout DSL comme moteur d'exécution est en cours.

    Tolérance à la panne

    “exactly once” en conditions normales et conditions dégradées (grâce au mécanisme de checkpoints) qui est de plus automatique.

    Performances

    L'optimisation des traitements est un point important de Flink, par analogie on peut voir l'optimiseur comme celui d'une base de données.

    Le meilleur « chemin » est choisi au moment de l'exécution en fonction de paramètres et en privilégiant le traitement le plus rapide.

    Pour faire ce choix l'optimiseur analyse principalement :

    • Les types de données,
    • Les fonctions utilisées.

    Il intervient à la fois pour les traitements batch et les traitements en temps réel.

    Ainsi pour une méthode de type join utilisée dans le programme, Flink peut décider d'utiliser :

    • Un partitionnement ou non des DataSet impliqués,
    • Un hash join ou un merge join avec tri,

    Une grosse partie a aussi lieu au moment des itérations :

    1. Mise en cache des données constantes
    2. Les opérations les plus coûteuses sont déplacées en dehors de la boucle,
    3. ...
    4.  

    La plupart du temps l'optimiseur va faire les bons choix sans que vous ayez à vous en préoccuper, toutefois il est possible de forcer la stratégie d'exécution.

    Itérations

    ​Flink propose deux types d'itérations :

    1. Itérations simples
    2. Delta-itérations

    La première facilite la gestion de flux successifs et l’agrégation des résultats.

    La deuxième vise avant tout les performances.

    Les itérations sont de moins en moins coûteuses au fur et à mesure des traitements.

    L'inconvénient étant qu'il faut un certain nombre d'itérations avant d'obtenir le résultat final, mais ensuite si les entrées évoluent seules les nouvelles seront traitées (delta-itérations).

    Déploiement

    Flink est déployable sur HadoopDataPlatform d’HortonWorks et des évolutions sont en cours pour :

    1. Cloudera (fichier de configuration Hadoop non compatible).
    2. Cloud Google : Disponibilité de Flink comme runtime pour Google Cloud Dataflow

    Clients expérimentant Flink : Amadeus, Spotify , …​

  • ​Analyse/Requêtage/Visualisation

    Hive

    Site web http://hive.apache.org
    Licence Apache
    Technologie Java
    Année création 2008

    Hive est un projet initié par Facebook en 2008.

    A l’image de Pig, Hive permet l’écriture de tâches de traitement/requêtage de données aux développeurs ne maîtrisant pas Java.

    Là où Pig définit un langage procédural permettant d’exploiter le cluster, Hive permet de définir des tables structurées de type SQL et de les alimenter avec des données provenant soit du cluster, soit de sources externes.

    Hive repose sur les notions suivantes :

    • Tables : une table est une succession de colonnes et de lignes tout comme pour le monde des SGBD. La différence provient du système de stockage qui est distribué (HDFS ou autre). Une autre différence importante est l’absence de notion de clé primaire.
    • Partitions : une table Hive peut être découpée en partitions afin de répartir les données sur le cluster (en fonction de la valeur de plusieurs champs)
    • Buckets : une fois partitionnées, les données peuvent être ensuite découpées selon une seule colonne de la table afin de diviser le stockage des données. Le bucketing améliore les performances des jointures et permet de ne travailler que sur des échantillons.
    • Metastore : c’est l’endroit où Hive stocke les métadonnées des tables (schéma, droits d’accès, statistiques, …)

    Une table Hive peut être soit :

    • interne, les données sont dupliquées dans un répertoire HDFS dédié à Hive (warehouse).
    • externe, les données sont entreposées dans un répertoire HDFS externe et seules les métadonnées sont conservées dans Hive. 

    Requêtes

    Une fois le schéma des tables défini et les données insérées, il est possible d’utiliser le langage HiveQL pour requêter ces tables. HiveQL a une syntaxe proche de SQL et permet de réaliser l’essentiel des opérations de lecture permettant de produire des analyses classiques (sélection de champs, somme, agrégat, tri, jointure, …).

    Traitements

    Les scripts Hive sont transformés afin d’être exécutés dans un cluster Hadoop :

    • en traitement MapReduce,
    • en traitement Spark,
    • en traitement TEZ. 

    Le plus gros avantage de Hive est sa capacité à utiliser une compétence très répandue qu’est la connaissance de SQL rendant les développeurs 

    Pig

    Site web http://pig.apache.org
    Licence Apache
    Technologie Java
    Année création 2008

    Pig est un outil de traitement de données qui fait partie de la suite Hadoop et qui permet l’écriture de scripts qui sont exécutés sur l’infrastructure Hadoop sans être obligé de passer par l’écriture de tâche en Java via le framework MapReduce. Il dispose en outre de fonctionnalités permettant le chargement de données depuis une source externe vers le cluster HDFS ou de fonctionnalités permettant l’export de données pour utilisation par des applications tierces.

    Pig s’appuie sur son propre langage nommé Pig Latin. Il permet en outre d’accéder à la couche applicative Java. Ce langage est assez simple ce qui permet au développeur venant d’un autre monde que Java de produire des scripts de traitement s’exécutant sur Hadoop beaucoup plus rapidement.

    Pig propose deux modes d’exécution :

    • Local : sur une seule machine sans HDFS ni MapReduce,
    • Hadoop : les traitements Pig sont convertis en code MapReduce et exécutés sur un serveur Hadoop.

    Opérations possibles sur les données :

    • chargement et stockage,
    • streaming,
    • filtre,
    • agrégation,
    • tri, ...

    Dans la pratique, Pig est surtout utilisé pour charger des données externes vers HDFS et transformer des fichiers afin de faciliter leur analyse surtout dans des cas où plusieurs étapes sont nécessaires (du fait de la nature procédurale du langage et de sa capacité à stocker des résultats temporaires).

    Un projet nommé DataFu permet d’enrichir les fonctions disponibles 

    Drill

    Site web http://drill.apache.org/
    Licence Apache
    Technologie Java
    Année création 2012

    Le projet Drill a été placé dans l’incubateur de la fondation Apache en août 2012, c’est un moteur de requêtes SQL pour Hadoop, développé initialement chez MapR. 

    Inspiré du projet Dremel de Google, Drill, quant à lui, permet d’effectuer des requêtes interactives SQL au dessus d’Hadoop, avec pour objectif premier de donner accès aux utilisateurs non développeurs de réaliser des analyses à partir de données stockées dans HDFS et Hadoop. 

    Même si la comparaison n’est pas totalement juste (Drill se présente plutôt comme un Spark facile d’accès) on retrouve donc les mêmes cas d’utilisation que Hive. 

    Requêtage

    Drill permet le requêtage de données : 

    • dans des fichiers, 
    • Hive,
    • HBase,
    • HDFS,
    • Solr,
    • JDBC, ...

    Le langage utilisé est le SQL et permet de manipuler les données de sources différentes, les requêtes sont exécutées in-situ et permettent à Drill d’être shemaless, ou plutôt de découvrir le schéma à la volée. Le parseur SQL est Apache Calcite (utilisé par les projets Apache : Hive, Phoenix et Kylin).

    Drill offre aussi des extensions au langage SQL afin d’offrir des types spécifiques (tableau, map, …) et fournit des drivers ODBC et JDBC afin de s’interconnecter avec le SI et des outils comme Tableau.

    Déploiement

    Apache Drill peut être déployé en cluster afin d’augmenter sa puissance de traitement et garantir le failover.

    Performances

    Apache Drill privilégie la mémoire afin de favoriser les performances.

    Stockage des résultats

    Une fois requêtées, les données peuvent : 

    • être stockées dans un système compatible : 
      • File System : HDFS, MapR-FS, ... 
      • Hive, 
      • NoSQL : MongoDB, Cassandra, Hbase, MapR-DB, ...
    • être disponibles sous forme de vues qui sont des fichiers distribués dans le file système sous-jacent : 
      • l’emplacement du stockage des vues est un paramètre de la requête.

    Sécurité

    En terme de Sécurité, Drill offre deux possibilités :

    • le système de permissions système de fichiers ou sont stockées les vues,
    • un système interne d’authentification qui permet de contrôler l’accès aux vues. 

    Drill est un projet jeune avec des livraisons très fréquentes afin d’améliorer le support du format SQL, d’améliorer les performances.

    Monitoring

    Le monitoring des requêtes Drill ainsi que leur annulation peut se faire au moyen d’une application Web.

  • ​Indexation

    Elastic (Elasticsearch)

    Site web https://elastic.co
    Licence Licence Apache 2.0
    Technologie Java
    Année création 2010

    Elasticsearch est un moteur de recherche open-source, distribué et basé sur Lucene. Elasticsearch a été créé par Shay Banon, initiateur du projet Compass, en remplacement de ce dernier.

    Contrairement à Lucene, c’est un cluster d’indexation, qui s’appuie sur une base documentaire NoSQL interne utilisant le format JSON pour le stockage des documents. De plus tout comme Solr et contrairement à Lucene son mode d’interrogation est de type client/serveur (il n’a pas besoin d’être déployé dans la même JVM que le client) 

    Les documents sont répliqués sur différents nœuds de stockage, afin d’améliorer la performance des recherches mais également de gérer la haute disponibilité. 

    La décomposition des rôles est la suivante :

    • Lucene gère les opérations « bas niveau » comme l’indexation et le stockage des données,
    • Elasticsearch apporte plusieurs couches d’abstraction pour accepter du JSON, offrir une API REST sur HTTP et faciliter la constitution de clusters. 

    Contrairement à certaines bases NoSQL, Elasticsearch n’est pas schema-less. Il est possible d’indexer un document sans aucune information sur son format (uniquement la donnée), mais ElasticSearch va en créer un automatiquement à partir du format des données.

    Elasticsearch évolue constamment et dans ses évolutions récentes il faut noter :

    • abandon du fameux système de river au profit d’une approche de type push par les clients,
    • abandon des facettes au profit des agrégations. 

    Le langage d’interrogation est propriétaire (Query DSL) et utilise une approche de type DSL et se base sur le format JSon.

    Clients

    Clients Elasticsearch disponibles :

    • Java,
    • JavaScript,
    • Groovy,
    • .NET,
    • PHP,
    • Perl,
    • Python,
    • Ruby. 

    Écosystème

    Elastic, l’éditeur d'Elasticsearch, propose un écosystème de plus en plus riche autour de son moteur de recherche. 

    Logstash

    Logstash, permet de collecter les logs, d’appliquer quelques traitements simples sur les messages reçus pour ensuite les transmettre vers une solution tierce, en particulier Elasticsearch pour pouvoir effectuer des recherches parmi ces messages. 

    Kibana

    Kibana, autre solution très connue, propose une interface graphique pour explorer et visualiser les données poussées vers Elasticsearch ou celles stockées dans d’autres solutions que celles de l’éditeur.

    Ces trois solutions forment le trio le plus répandu pour l’analyse des logs : ELK. Malheureusement ces produits avaient jusqu’à peu un cycle de vie indépendant qui pouvait parfois entraîner des problèmes de compatibilité. Conscient de ces problèmes et afin d’accroître encore l’attrait de ces trois produits, la société Elastic a récemment réorganisé son offre afin de :

    • fournir un packaging cohérent de ces trois solutions,
    • permettre l’intégration de nouvelles solutions et fonctionnalités.

    Le nouveau packaging a été renommé Elastic Stack . Elastic Stack intègre une nouvelle solution dédiée au monitoring, Beats, qui est en réalité composé des produits suivants :

    • PacketBeat : supervision réseau,
    • TopBeat : supervision Mémoire et CPU,
    • FileBeat : supervision des fichiers,
    • WinlogBeat : supervision des événements OS (Windows uniquement),
    • LibBeat : utilitaires.

    Sécurité

    En terme de sécurisation, un plugin Elastic, Shield, permet de sécuriser les accès aux documents indexés mais uniquement réservé à la version commerciale.

    Version commerciale

    Marvel qui est une application web de monitoring du moteur de recherche en temps réel ainsi que Watcher (plugin de notifications) sont aussi réservés à la version commerciale.

    Orientation

    Parmi les orientations récentes :

    • l’API Graph (d’abord présentée comme extension à l’outil de visualisation Kibana) permet à Elasticsearch d’explorer et d’afficher les relations qui existent entre des données (comme une base orientée graphe),
    • rapprochement de plus en plus visible avec le domaine du machine learning.

    ELASTICSEARCH 

    Elasticsearch

  • ​Prédiction/Apprentissage

    Spark ML et MLlib

    Site web http://spark.apache.org/mllib/
    Licence Licence Apache 2.0
    Technologie Scala
    Année création 2003

    MLlib

    MLlib est un sous projet Spark depuis la version 0.8. Tout comme Spark elle trouve son origine dans le laboratoire de Berkeley (AMPLab). 

    MLlib est la librairie de Machine Learning de Spark. Les algorithmes sont conçus de manière à tirer profit du calcul en parallèle sur un cluster Spark.

    Elle est donc particulièrement adaptée aux fortes volumétries

    MLlib, tout comme le reste du framework Spark est développé en Scala. Les opérations d’algèbre linéaire se basent sur les librairies Breeze et JBlas.

    Algorithmes disponibles :

    • classification: logistic regression, linear support vector machine (SVM), naive Bayes,
    • régression: generalized linear regression (GLM),
    • filtrage collaboratif : alternating least squares (ALS), 
    • clustering: k-means,
    • décomposition: singular value decomposition (SVD), principal component analysis (PCA),
    • données clairsemées. (Sparse data),
    • arbres de Décision (CART), Régressions Logistiques,
    • méthode de Broyden-Fletcher-Goldfarb-Shanno (L-BFGS),
    • évaluation modèle,
    • discrétisation.

    En plus de tirer profit du noyau de Spark MLlib s’intègre avec :

    • Spark SQL (DataFrames en entrée),
    • Streaming (flux temps réel pour la prédiction),
    • GraphX

    Spark ML

    Ce sous projet (disponible sous forme de package dans Mllib depuis la version 1.5) est une évolution visant à introduire de nouvelle fonctionnalités (DataFrame, Pipeline) et d’uniformiser les API.

    Mahout

    Site web http://mahout.apache.org
    Licence Licence Apache 2.0
    Technologie Scala
    Année création 2010

    Apache Mahout est un projet de la fondation Apache depuis 2011 visant à créer des implémentations d’algorithmes d’apprentissage automatique et de Data Mining.

    Même si les principaux algorithmes d’apprentissage se basent sur MapReduce, il n’y a pas d’obligation à utiliser Hadoop. 

    Apache Mahout ayant été conçu pour pouvoir fonctionner sans cette dépendance. 

    Précurseur historique, Mahout fait face à de nouvelles librairies soit plus adaptées aux algorithmes itératifs, telles que MLlib de Spark (complétée par Spark ML), soit provenant du monde des Data Scientist telles que Scikit-learn ou bien le langage R.

    C’est pourquoi depuis la version 0.10.0 (Avril 2015) Mahout a utilisé Apache Spark ainsi que H2O (en fonction des algorithmes).

    Une intégration avec Flink est en cours.

    Ce nouvel environnement mathématique est appelé Samsara.

    En fonction des algorithmes Mahout va choisir le moteur d’exécution le plus adapté (et parfois laisser le choix) entre 

    • Spark,
    • Hadoop MapReduce,
    • H2O. 

    Mahout-Samsara est une refonte de Mahout afin de favoriser la scalabilité et les performances mais aussi fournir un canevas afin de créer ses propres algorithmes (développement en Scala).

    Samsara propose aussi un shell interactif afin de lancer les traitements sur un cluster Spark

    Mahout est très riche en algorithmes d’apprentissage, clustering, classification, filtrage collaboratif, analyse d’items fréquents, etc. 

    Clustering :

    • K-means (parallélisable), 
    • Fuzzy K-means (parallélisable), 
    • Spectral K-means (parallélisable). 

    Classification: 

    • Logistic regression (non parallélisable), 
    • Naive Bayes (parallélisable), 
    • Random Forest (parallélisable), 
    • Multilayer perceptron (non parallélisable).

    Réduction de la dimensionnalité : 

    • Singular Value Decomposition (parallélisable), 
    • PCA (parallélisable), 
    • Lanczos decomposition (parallélisable),
    • QR decomposition (parallélisable).

    Texte : 

    • TF-IDF (parallélisable)
  • ​Acteurs

    Akka

    Site web http://akka.io/
    Licence Licence Apache 2.0
    Technologie Scala
    Année création 2009

    Akka est un framework pour construire des applications concurrentes, distribués, résilientes avec la JVM. Akka est une implémentation basée sur les acteurs qui a démarré en 2009 par Jonas Bonér et qui a été tout d’abord intégré à Scala.

    La source d’inspiration est le langage Erlang qui propose une architecture hautement concurrente et basée sur les événements. Akka est maintenant un framework OpenSource soutenu par TypeSafe (tout comme Play et Scala), disponible à la fois en Scala et en Java.

    La programmation par acteurs propose les postulats suivants :

    Un acteur est une entité qui sur réception d’un événement (message) peut :

    • envoyer des messages à d’autres acteurs,
    • créer de nouveaux acteurs,
    • spécifier le comportement à avoir lors de la prochaine réception de messages.

    L’exécution de ces tâches ci-dessus n’est pas ordonnée, elles peuvent donc être parallélisées.

    Le paradigme Acteur découple l’émetteur du message du message lui-même, permettant donc l’asynchronisme des communications et l’introduction de structures dédiées à la gestion des messages. Un acteur doit connaître l’adresse de l’acteur à qui il veut envoyer un message. Les adresses peuvent être échangées par message.

    En résumé un acteur est :

    • systèmes avec état, 
    • réagit sur réception de messages,
    • envoie des messages aux acteurs : 

                  > par leur nom ou adresse, 

                 > en retour de réception d’un message, 

                 > à un acteur parent, …

    Akka n’est pas qu’une implémentation du modèle d’acteurs :

    • pseudo transactions (Transactors) qui permet en cas d’erreur d’annuler les modifications et de relancer automatiquement le traitement,
    • messages ordonnés pour un couple émetteur/récepteur.

    Liste des frameworks construit avec Akka :

    • Apache Spark,
    • Gatling,
    • Apache Flink.

    Akka possède toutefois les défauts suivants : 

    • traite les messages séquentiellement (mais on peut multiplier le nombre d’acteurs),
    • pas de garantie de livraison/traitement des messages (at-most-once delivery).

     

  • ​Interaction/Visualisation

    Les notebooks permettent d’analyser simplement de gros volumes de données. Le tout avec une interface web ergonomique et un langage d’interrogation le plus accessible. Ils sont principalement destinés à des Data Scientist.

    SlamData

    SlamData se positionne comme l’un des notebooks les plus simple à mettre en œuvre et à utiliser.

    Il élimine la phase de recopie des données (dans un bac à sable ou un Data Lake) en déployant ses capacités d’analyse directement au cœur de la donnée, sur les mêmes serveurs que le stockage. C’est le principe “Zero Relocation”.

    Avantages :

    • coût de stockage réduit,
    • scalabilité identique à celle du stockage,
    • données réelles.

    Inconvénients :

    • impacts sur stockage,
    • pas de séparation claire entre environnement de production et d’expérimentation/analyse.

    L’interface peut être déployée dans le cloud ou dans votre SI.

    Langage d’interrogation :

    • pseudo SQL avec une mise en forme JSon.

    Liste des connecteurs :

    • MongoDB,
    • HBase, 
    • Cassandra, 
    • Spark.

     cell query and results

    Source image : http://docs.slamdata.com/en/v2.5/users-guide.html

    Zeppelin

    Apache Zeppelin est un notebook inspiré par Jupyter et crée par Lee Moon Soo.

    Au départ solution payante, Zeppelin a été offert à la fondation Apache en 2014. Après presque deux ans d’incubation, Zeppelin est maintenant un projet majeur chez Apache (depuis juin 2016). 

    Techniquement Apache Zeppelin est une application web écrite en Java pour la partie serveur et en angularJS pour la couche de présentation qui va permettre à des analystes de visualiser et requêter la donnée. Comme les autres notebooks, Zeppelin vise à étendre la population des utilisateurs du Big Data en offrant de manière ergonomique et performante les fonctionnalités suivantes :

    • ingestion de données,
    • découverte et analyse des données,
    • visualisation des données.

    Zeppelin s’appuie fortement sur Spark pour l’analyse et l’exploration des données même si des alternatives sont possibles (Hive, Flink). Zeppelin repose sur un système d’interpréteurs (Interpreters) qui permettent l’utilisation d’une technologie dans Zeppelin. 

    La liste bien que non exhaustive ci-dessous permet de mesurer leur richesse :

    • Hive,
    • Markdown,
    • Apache Spark (Scala, Python et R),
    • Spark SQL,
    • Apache Flink,
    • Postgres,
    • Pivotal HAWQ,
    • Shell,
    • Apache Cassandra,
    • Apache Ignite.

    Ajouté a cela il y a des interpréteurs très intéressants :

    • AngularJS permet de créer des interfaces utilisateurs personnalisées,
    • Apache Kylin (à l’origine un projet eBay) est un projet open source qui vise à fournir des fonctionnalités de type OLAP et SQL à Hadoop,
    • Apache Lens permet de fournir une vue unique à différentes sources de données (Hadoop, Data warehouse, …) et de les requêter avec Spark. 

    L’interface est plus riche que Jupyter bien que le projet soit plus jeune.

    Le projet Hub a pour but de faciliter le travail collaboratif dans Zeppelin : différentes personnes d’une même société peuvent travailler sur les mêmes données sans toutefois interférer entre elles.

    Par contre il est possible de partager les résultats. 

    Le projet Helium est un changement de paradigme important puisque plutôt que de tout gérer dans un notebook Zeppelin (écriture du code et affichage des résultats), il permet d’exécuter un traitement puis d’intégrer les résultats à un notebook Zeppelin. Les possibilités de traitements sont donc plus importantes et seul l’envoi des résultats est intimement lié à Zeppelin. 

    Devant le succès de Zeppelin on commence à le trouver dans différentes distributions Hadoop (Hortonworks). Zeppelin est un projet jeune, toujours en incubation, ce qui se ressent sur certains points :

    • pour l’installation il faudra le plus souvent construire le projet à partir des sources,
    • instabilité.

    zeppelin medical

    Source image : http://hortonworks.com/wp-content/uploads/2015/10/zeppelin_medical.jpg

    Jupyter

    Jupyter (connu autrefois sous le nom de IPython Notebook) est un des précurseurs en termes d’accès unifié à la donnée. Le projet a démarré en 2001 sous l’impulsion de Fernando Perez mais la première version suffisamment mature et complète date de 2011. 

    En 2015, IPython Notebook devient le projet Jupyter. La disparition de Python dans le nom du projet n’est pas innocente puisque Jupyter s’ouvre vers d’autres langages. On peut citer :

    • Ruby,
    • Javascript,
    • Scala,
    • Go,
    • R,
    • Java (à partir de la v9), ...

    Dans Jupyter un notebook est une liste de cellules qui peuvent contenir du code, du texte, des formules mathématique ou encore des graphiques. Plus concrètement encore un notebook Jupyter est un document JSon.

    Rackspace, au travers de sa plateforme JupyterHub propose l’hébergement de notebooks et en héberge actuellement plus de 20 000. Le projet est assez actif est soutenu par une forte communauté (Rackspace, Microsoft, Continuum Analytics, Google, Github,  ...).

    L’intégration avec Spark se fait au travers de PySpark.

    ipython-f21

    Source image : http://blog.cloudera.com/wpcontent/uploads/2014/08/ipythonf21.png

  • ​Offres Cloud

    La multiplication des offres cloud a permis de démocratiser le Big Data, sur certains points elles sont même à l’origine du mouvement (beaucoup de solutions BigData proviennent des acteurs du cloud).

    Selon une étude IDC, les solutions Big Data & Analytics du cloud connaîtront une croissance 4,5 fois plus rapide que celle des plateformes physiques jusqu’en 2020.

    Le cloud sera donc la plateforme privilégiée pour les prochaines années. 

    Cf. http://minely.com/blog/top-10-big-data-and-analytics-predictions-2016/

    Les offres cloud facilitent l’adoption du Big Data en permettant de se focalisant uniquement sur la valeur métier.

    Elles permettent une adoption plus rapide et permettent de réduire les coûts grâce à une facturation sur mesure et extensible.

    A l’opposé parmi les freins possibles il y a :

    • la question de la sécurité des données,
    • la maîtrise de l’évolution des versions des logiciels.

    Voici une comparaison de quatre offres relativement complètes et matures.

    Google

    Nom offre

    Google Cloud Engine

    Google Dataflow

    Google DataProc

    NoSQL BigTable
    Traitements

    Flink

    Spark (Google Cloud Dataflow)

    Query BigQuery
    Hadoop

    Google Cloud Dataproc (Spark et Hadoop)

    • Cloudera
    • Hortonworks
    • MapR
    Stockage Google Cloud Storage

    Type cloud (public/ privé/Hybride)

    Public
    Machine Learning

    Prediction API

    Mahout/MLlib

    Rackspace

    Nom offre

    Managed Big Data

    ManagedNoSQL (ObjectRocket)

    NoSQL

    MongoDB

    Redis

    Cassandra

    HBase

    Traitements

    Spark

    Hadoop MapReduce

    TEZ

    Query

    Pig

    Hive

    Spark SQL

    Hadoop 

    Hortonworks Data Platform

    Stockage HDFS

    Type cloud (public/privé/Hybride)

    Public/Privé
    Machine Learning Mahout/MLlib

    Amazon

    Nom offre Amazon Elastic Compute Cloud (Amazon EC2)
    NoSQL

    Solutions natives :

    • DynamoDB
    • SimpleDB

    Amazon EC2 :

    • Cassandra
    • Couchbase
    • MarkLogic
    • MongoDB

    Amazon AWS :

    • Titan
    • Neo4j
    • OrientDB
    • GraphDB

    Amazon ElastiCache :

    • Redis
    Traitements

    Spark (EC2) +

    Elastic Apache Mesos (EC2)

    Spark on EMR

    Query

    Spark SQL (EC2)

    Spark SQL (EMR)

    Hadoop Amazon Elastic MapReduce (EMR)
    Stockage

    HDFS

    Amazon Glacier

    Amazon Simple Storage Service (S3)

    Elastic Block Storage (EBS)

    Elastic File System (EFS)

    Type cloud (public/

    privé/Hybride)

    Public
    Machine Learning Mahout/MLlib

    Microsoft

    Nom offre Azure
    NoSQL

    MongoDB

    Neo4J

    DocumentDB

    Redis

    Table

    Traitements

    Azure Compute

    Stream Analytics

    Storm/Spark

    Query

    Stream Analytics

    Hadoop

    HDInsight (Hortonworks Data Platform)

    Stockage

    Azure Storage

    StorSimple (hybride)

    Type cloud (public/ privé/Hybride)

    Public/Hybride

    Machine Learning

    Azure Compute

    Stream Analytics

    Storm/Spark

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