Début 2017, le Big Data semble encore réservé aux seules grandes entreprises, les autres n’arrivant pas à franchir une série d’obstacles dont les suivants :
-
complexité technique et manque de compétences.
Les technologies Big Data restant relativement "jeunes", il y a une vraie problématique de recrutement et de formation sur ce dernier point.-
la collecte des données reste problématique.
Une collecte de données efficace nécessite généralement de revoir les canaux de collecte en place.
Il y a également une problématique de traitement de ces données, généralement non structurées. -
coût matériel et logiciel.
De nouvelles briques techniques vont devoir être ajoutées au SI. -
manque de visualisation des opportunités.
La conséquence d’un manque d’expertise, ce qui revient au point précédent.
Au delà du "Buzz" du Big Data, il n’est pas forcément évident de savoir quand le préférer à des solutions plus classiques (datawarehouse, SGBD, etc.) -
le ROI des investissements Big Data n’a pas été estimé.
Pas encore assez de feedback sur les gains obtenus suite à ces investissements.
-
On en conclut que l'exploitation de la data a un coût de mise en place engendrant une dette initiale.
Il est donc important de commencer par de petits projets, afin de limiter les investissements et de valider la solution, avant de penser à la généraliser à tout le SI.
Dans le même esprit, il est important de choisir une architecture évolutive, que l’on adaptera aux nouveaux besoins, plutôt qu’une architecture complexe dès le départ.
Par Big Data, on entend la production massive et hétérogène de données numériques par les entreprises et les particuliers, dont les caractéristiques (très grand volume, diversité de forme, vitesse attendue de traitement) requièrent de nouveaux moyens de stockage et d’analyse.
Par les "nouvelles" sources de données, on peut citer :
-
smartpohnes, tablettes et ordinateurs
-
objets connectés et IoT.
Grosse explosion au niveau des données remontées par toutes les familles de capteurs (plusieurs dizaines de milliers pour un appareil de type Airbus) -
les données rendues accessibles par l’Etat, les établissements publics et les collectivités dans le cadre de l'Open Data.
Parmi les domaines d’applications, on peut citer :
-
la santé : le Big Data favorise une médecine prédictive et personnalisée.
On peut envisager un futur (proche) où les appareils connectés devraient permettre l’analyse en continu des données biométriques des patients. -
les transports : modélisation des déplacements de populations afin d’adapter les services et infrastructures.
-
la finance de marché : où le Machine Learning est de plus en plus utilisé dans le cadre de la prévision de l’évolution des marchés.
-
Batch
-
Micro-batch
-
Temps réel (streaming)
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, etc.).
Apache Sqoop :
-
System for bulk data transfer between HDFS and structured datastores as RDBMS. Like Flume but from HDFS to RDBMS.
-
Résultats : les résultats ne seront disponibles qu’à la fin des traitements.
-
Latence : souvent de l’ordre de la minute, voire dans certains cas de l’heure.
Les traitements vont analyser l’ensemble des données disponibles toutes les n secondes.
-
Données en entrée :
-
petits fichiers
-
données Web
-
etc.
-
-
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.
Les traitements vont analyser les données au fur et à mesure de leur disponibilité.
-
Données en entrée :
-
stream Web
-
messages provenant d’un bus
-
flux de logs
-
etc.
-
-
Résultats : les résultats sont disponibles au fur et à mesure.
-
Latence : parfois inférieur à la seconde.
-
Flink
Apache Flink (formerly called Stratosphere) features powerful programming abstractions in Java and Scala, a high-performance runtime, and automatic program optimization. It has native support for iterations, incremental iterations, and programs consisting of large DAGs of operations.
Flink is a data processing system and an alternative to Hadoop’s MapReduce component. It comes with its own runtime, rather than building on top of MapReduce. As such, it can work completely independently of the Hadoop ecosystem.
However, Flink can also access Hadoop’s distributed file system (HDFS) to read and write data, and Hadoop’s next-generation resource manager (YARN) to provision cluster resources. Since most Flink users are using Hadoop HDFS to store their data, it ships already the required libraries to access HDFS.Voir :
-
mon résumé de Stream Processing avec Apache Flink (Devoxx France 2017, Tugdual Grall)
-
-
-
Tez
Tez is a proposal to develop a generic application which can be used to process complex data-processing task DAGs and runs natively on Apache Hadoop YARN.
Tez generalizes the MapReduce paradigm to a more powerful framework based on expressing computations as a dataflow graph.
Tez is not meant directly for end-users – in fact it enables developers to build end-user applications with much better performance and flexibility.
Hadoop has traditionally been a batch-processing platform for large amounts of data. However, there are a lot of use cases for near-real-time performance of query processing. There are also several workloads, such as Machine Learning, which do not fit will into the MapReduce paradigm. Tez helps Hadoop address these use cases.
Tez framework constitutes part of Stinger initiative (a low latency based SQL type query interface for Hadoop based on Hive).Voir :
-
Storm
Storm is a complex event processor (CEP) and distributed computation framework written predominantly in the Clojure programming language.
It is a distributed real-time computation system for processing fast, large streams of data.
Storm is an architecture based on master-workers paradigma. So a Storm cluster mainly consists of a master and worker nodes, with coordination done by Zookeeper.
Storm makes use of zeromq (0mq, zeromq), an advanced, embeddable networking library. It provides a message queue, but unlike message-oriented middleware (MOM), a 0MQ system can run without a dedicated message broker. The library is designed to have a familiar socket-style API.
Originally created by Nathan Marz and team at BackType, the project was open sourced after being acquired by Twitter. Storm was initially developed and deployed at BackType in 2011. After 7 months of development BackType was acquired by Twitter in July 2011. Storm was open sourced in September 2011.Hortonworks is developing a Storm-on-YARN version and plans finish the base-level integration in 2013 Q4. This is the plan from Hortonworks. Yahoo/Hortonworks also plans to move Storm-on-YARN code from github.com/yahoo/storm-yarn to be a subproject of Apache Storm project in the near future.
Twitter has recently released a Hadoop-Storm Hybrid called "Summingbird". Summingbird fuses the two frameworks into one, allowing for developers to use Storm for short-term processing and Hadoop for deep data dives, a system that aims to mitigate the tradeoffs between batch processing and stream processing by combining them into a hybrid system.
📎Personnellement, j’ai souvent eu de très mauvais échos sur l’utilisation de Storm (références à retrouver) Voir :
Il n’y a pas de façon de faire unique répondant à tous les problèmes.
Il est capital de bien définir ses besoins (surtout en termes de latence) afin de choisir les bonnes briques techniques.
Afin d’améliorer les performances (et se rapprocher le plus possible du temps réel), les nouveaux frameworks permettent de plus en plus de définir des fenêtres de traitement (windowing), et proposent des traitements itératifs.
-
Ingestion / Extraction de données
-
Traitement de données
-
Analyse / Apprentissage
-
Data visualisation
-
Requête / Interrogation
-
Workflow
-
Stockage
-
Ordonnancement
-
Sécurité
-
Gouvernance
-
Messages
Ce point acquiert une importance d’autant plus capitale qu’il représente l'interface avec les utilisateurs.
Les besoins en termes de manipulation des données affichées (filtre, sélection / manipulation de colonnes, charts, etc.) sont tels que de plus en plus de solutions de BI (Tableau, MicroStrategy) s’intégrent maintenant aux briques Big Data.
Voir :
Pour l’interrogation d’une plateforme Big Data, le pseudo-SQL tente de s’imposer avec des solutions comme :
-
Drill
-
Hive
-
Pig
-
Spark SQL
Druid is a column-oriented, open-source, distributed data store written in Java.
Druid is designed to quickly ingest massive quantities of event data, and provide low-latency queries on top of the data.
The name Druid comes from the shapeshifting Druid class in many role-playing games, to reflect the fact that the architecture of the system can shift to solve different types of data problems.
Druid is commonly used in business intelligence/OLAP applications to analyze high volumes of real-time and historical data.
Druid is used in production by technology companies such as Alibaba, Airbnb, Cisco, eBay, Netflix, Paypal, and Yahoo.
Voir :
L’architecture est de type Share nothing : aucune donnée n’est traitée par deux nœuds différents, même si les données sont réparties sur plusieurs noeuds (principe d’un noeud primaire et de noeuds secondaires).
La stack Hadoop (version 2.0, incorporant YARN) est composée de 4 éléments :
-
Hadoop Common : ensemble d’utilitaires utilisés par les autres briques Hadoop.
-
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.
Ce pattern, inventé par Google en 2004, consiste :
-
à partir d’un même vaste ensemble de données,
-
à le diviser en ensembles plus petits
-
puis à traiter chacun de ces nouveaux ensembles en parallèle
Développé par Hadoop à partir de GoogleFS, ce système de fichiers distribué a été conçu pour stocker de très gros volumes de données sur un grand nombre de machines "classiques" (équipées de disques durs banals).
Il repose sur 2 composants principaux :
-
le NameNode : composant unique (même si backupé par un NameNode secondaire), il centralise la localisation des blocs de données répartis dans le cluster.
-
le DataNode : stocke et restitue les blocs de données.
Le NameNode reverra toujours l’adresse du DataNode disposant de la plus grande bande passante.
Il réprésente également un Single Point of Failure pour HDFS.
Le HDFS stocke les fichiers de grande taille sur plusieurs machines, et la fiabilité de la solution est assurée par la réplication des données sur plusieurs hôtes (par défaut, réplication sur 3 noeuds : 2 sur le même support, et 1 sur un support différent).
Le cas d’usage courant (début 2017) de la stack Hadoop.
Pour une définition courte, j’aime bien celle-ci provenant de LeMagIT :
Un lac de données (Data Lake) est un référentiel de stockage qui conserve une grande quantité de données brutes dans leur format natif jusqu’à ce qu’elles soient nécessaires.
Pour une version plus complète, voici celle de Wikipedia :
A data lake is a method of storing data within a system or repository, in its natural format, that facilitates the collocation of data in various schemata and structural forms, usually object blobs or files.
The idea of data lake is to have a single store of all data in the enterprise ranging from raw data (which implies exact copy of source system data) to transformed data which is used for various tasks including reporting, visualization, analytics and machine learning.
The data lake includes structured data from relational databases (rows and columns), semi-structured data (CSV, logs, XML, JSON), unstructured data (emails, documents, PDFs) and even binary data (images, audio, video) thus creating a centralized data store accommodating all forms of data.
Les notions capitales étant :
-
référentiel de stockage (et, dans l’idéal, l’unique référentiel)
-
stockage des données brutes (non transformées, conforme à la source)
Voici un schéma illustrant bien l’architecture globale d’un data lake, avec les flux associés :
MDM = Master Data Management (gestion des données de référence)
Bien retenir la différence entre le schema-on-write du Data warehouse, et le schema-on-read du Data lake. En voici une bonne explication :
Compared to a data warehouse, which uses a “schema on write” approach to hold structured, processed data, a data lake uses a “schema on read” approach in which structure and schema are only applied when the data is being read from the data lake to answer a business intelligence question or for other analytics purposes. In other words, whereas a data warehouse functions via an ETL process (extract, transform, load), a data lake uses ELT (extract, load, and then transform) instead.
Une architecture Lambda est composée de trois couches :
-
Couche batch (Batch Layer)
-
Stocke des données en format brut.
-
Lance périodiquement des traitements massifs afin de produire des vues consultables par les utilisateurs.
Ces dernières sont typiquement stockées dans des bases en lecture seule, les nouvelles vues logiques précalculées remplaçant les anciennes. -
La fréquence des traitements ne doit pas être trop importante afin de minimiser les tâches de fusion des résultats et de constituer les vues.
-
-
Couche temps réel (Speed Layer)
-
Ne traite que les données récentes (flux de données en entrée, Kafka est votre ami).
-
Calcule des vues incrémentales qui vont compléter les vues batch afin de fournir des résultats plus récents.
-
Supprime les vues temps réel obsolètes (postérieures à un traitement batch)
-
-
Couche de service (Serving Layer)
-
Rend exploitables aux clients les vues créées par les couches batch et temps réel.
-
Permet également de (re)calculer dynamiquement ces vues.
-
Briques techniques pouvant être utilisées :
-
Stockage : NoSQL surtout mais aussi JMS, Kafka, HDFS.
-
Couche Batch : Hadoop MapReduce, Spark, Flink, etc.
-
Couche Temps réel : Storm, Spark Streaming, Flink, Samza, Tez, etc.
-
Couche de service : bases NoSQL, Druid, Cassandra, Hive, HBase, ElasticSearch, etc.
L’architecture Lambda est générique mais complexe à mettre à oeuvre du fait du grand nombre de briques techniques utilisées.
Créée par Jay Kreps suite à son expérience chez LinkedIn, il s’agit principalement d’une simplification de l’architecture Lambda.
De nombreuses solutions de traitement de données étant maintenant capables de gérer des traitements temps réel (streaming) ET des traitements batchs, il est donc possible de fusionner les couches batch et temps réél.
Une grande différence avec l’architecture Lambda est que le système de stockage des données doit être un système de fichiers de type log immuable, tel que Kafka.
Kafka permet de conserver les messages pendant un certain temps afin de pouvoir les retraiter.
l’architecture Kappa ne permet donc pas le stockage permanent des données, mais est destinée à leur traitement.
-
http://blog.ippon.fr/2016/03/31/big-data-panorama-des-solutions-2016/ : TRES bonne ressource, un résumé complet de l’état de l’art.
-
https://hadoopecosystemtable.github.io/ : la table de l’éco-système Hadoop. Liste un grand nombre de technologies, avec un bon abstract pour chacune d’elles.
Document de référence à garder sous le coude. -
https://www.sisense.com/blog/demystifying-data-warehouses-data-lakes-data-marts/ : une bonne comparaison en data warehouse et data lake
-
https://big-data.developpez.com/tutoriels/apprendre-faire-choix-architecture-big-data/ : cours très complet sous forme d’article dans Developpez.com
-
https://www.slideshare.net/gschmutz/big-data-and-fast-data-lambda-architecture-in-action : de bons schémas des architectures Lambda et Kappa, avec les technologies associées, même si le document commence à dater (début 2015)
- OLAP
-
Online analytical processing
- MDM
-
Master Data Management (voir cet article de Micropole)
- YARN
-
YARN stands for "Yet-Another-Resource-Negotiator".
It is a new framework that facilitates writing arbitrary distributed processing frameworks and applications.YARN’s execution model is more generic than the earlier MapReduce implementation. YARN can run applications that do not follow the MapReduce model, unlike the original Apache Hadoop MapReduce (also called MR1).
Hadoop YARN is an attempt to take Apache Hadoop beyond MapReduce for data-processing.