Le Big data en 5 grands modules d’architecture fonctionnelle

D’un point de vue fonctionnel, nous pouvons découper les architectures Big data en cinq grands modules :

1. Collecte : ce module vise à  récupérer les données à transmettre aux unités de transformation et d’analyse. La collecte peut se faire par lot ou en temps réel sur des données internes ou externes à l’entreprise.

2. Transformation : il s’agit ici d’extraire les informations utiles des données peu ou non structurées. En les interprétant pour les rendre exploitables et cohérentes, notamment via la constitution d’un catalogue de métadonnées. Cette étape n’est pas obligatoire pour les données déjà structurées.

3. Analyse : alors que la « transformation » se focalise sur l’enrichissement des données de manière unitaire, l’unité d’analyse va de son côté créer de nouvelles informations par identification, corrélation, agrégation ou projection de l’ensemble des données précédemment transformées. Tout comme pour la « collecte », ces analyses peuvent être effectuées par lot ou en temps réel.

4. Restitution : l’objectif de ce module est de permettre la visualisation des analyses et l’exploration des données.

5. Stockage : capable de stocker de très gros volumes de données structurées et non structurées, ce module est généralement sous-découpé de la façon suivante :

• Lac de données permettant d’héberger les données brutes ;
• Entrepôt de données stockant les données issues de la transformation ;
• Cache d’analyse permettant d’accélérer les traitements en vue de la restitution.

Quels critères adopter pour construire le socle technologique ?

Les modules fonctionnels de l’architecture étant posés, quelle stratégie adopter pour bâtir le socle sous-jacent ? Le Big data invite justement à l’adoption d’un triptyque gagnant pour bien choisir les outils :

Cet article Et si on vous offrait enfin une vision d’ensemble du Big data ? est apparu en premier sur RiskInsight.

De l’explosion des données au Big data

L’expression de « petite histoire du Big data », nous l’empruntons (presque) à Gil Press. Il livre en effet dans un long article documenté sur Forbes.com, daté du 5 mai 2013, « une très courte histoire du big data ». En une trentaine de dates de 1944 à 2012, il retrace la prise de conscience précoce de l’explosion des données (dans les rayons des bibliothèques universitaires dans un premier temps, puis via les NTIC), avec comme préoccupation centrale d’en quantifier la croissance tout en apportant  quelques considérations critiques autour du déluge informationnel.

L’explosion des données est en effet  d’abord perçue comme une menace sur la vie privée (« Assault on privacy – 1971-  Arthur Miller).  Côté technique aussi : l’espace de stockage grandit, mais les données s’étendent systématiquement jusqu’à le combler (Loi de parkinson, 1980). Dans les années 70, la qualité des données est enfin mise en cause : tout est stocké, il n’est plus utile de faire le tri.

L’expression « Big data » fait finalement son apparition en octobre 1997 dans la bibliothèque numérique de l’ACM¹, au sein d’articles scientifiques qui pointent du doigt les défis technologiques à visualiser les « grands ensembles de données ». Le Big data est né, et avec lui ses nombreux défis.

Et si ces données avaient de la valeur ?

Dans les années 2000, alors que l’exabytes² entrent en jeu dans la quantification des données produites annuellement, la valeur du Big data est mise en avant, d’abord pour les bénéfices que peuvent en tirer la recherche dans les secteurs de la physique, de la biologie ou des sciences sociales.

Ce que n’illustre pas l’article du Forbes.com, c’est la montée en puissance des Google, Facebook, Linkedin, Amazon et Twitter dans les années 2000 et plus particulièrement à partir de 2005. Celle-ci révèle tout le potentiel des données publiques disponibles sur internet. Les succès économiques des grands du web commencent alors à nourrir deux idées principales :

1- Les données brutes accumulées ont une valeur intrinsèque de par les fameuses 3 composantes en V ( pour volume essentiellement mais aussi variété et vitesse de leur production donc leur fraîcheur). Cette valeur est monétisable et Facebook en est l’illustration par excellence !

2- Ces données brutes ont une autre valeur liée aux analyses et corrélations auxquelles elles s’offrent et l’information qui en découle participe à la chaîne de valeur de l’entreprise (ex. : l’algorithme de recommandation d’Amazon).

Quelques principes technologiques qui expliquent la montée en puissance du Big data

Derrière ces succès, il y a évidemment des technologies qui font la différence et que les précurseurs du Big data ont contribué à développer et à faire connaître.  Les architectures Big data se fondent d’ailleurs sur 3 principes technologiques clés :

• L’accélération matérielle. Depuis toujours, les composants des systèmes (mémoire, processeur, bus) sont optimisés pour assurer toujours plus efficacement leur fonction.
• Le parallélisme.  C’est dans les années 2000 que ce paradigme devient dominant. Qu’il s’agisse de l’architecture interne d’un ordinateur (multi-cores, multi-processeurs, MPP*, SMP**) ou de l’architecture d’un réseau de machines (grid computing, cluster de machines, cluster hadoop), l’idée est de décomposer les problèmes complexes en plusieurs calculs traités de manière simultanée. Ces architectures sont d’autant plus efficaces qu’aucun composant n’est partagé entre les unités de traitement parallèles (« shared nothing ») et qu’il n’y a donc pas de point de contention.
• Le NoSQL, le mouvement décolle fin des années 2000 et promeut des alternatives aux bases de données relationnelles en en abandonnant certaines contraintes (notamment la consistance du théorème CAP³.)

Vous l’aurez compris, le Big data a émergé en 2010, mais il est né il y a quinze ans et il porte en lui un demi-siècle de réflexions, de concepts et de défis. Participerez-vous à son histoire ?

…………………………………………………………………………………………………..
*MPP : Massively Parallel Processing, à la différence du SMP, le MPP appliqué à l’architecture d’un ordinateur consiste en la mise en œuvre parallèle d’un grand nombre de processeurs disposant chacun de leur mémoire.

**SMP : Symetric MultiProcessing,  architecture parallèle constituée de plusieurs processeurs identiques partageant une même mémoire au sein d’un même ordinateur.

Cet article Aux origines du Big data… est apparu en premier sur RiskInsight.

Big data : un intérêt qui ne faiblit pas

Depuis 2012, l’intérêt pour le Big data ne cesse de croître (cf. courbe google trends). Pourtant, faute de disposer d’une définition tangible, la pertinence des usages de cette expression reste, aujourd’hui encore, sujette à interprétation.

Prenons un échantillon de définitions produites par les voix les plus influentes du domaine IT (Gartner, Forrester, IBM etc.). Derrière le Big data, une multitude de sujets : il peut s’agir, selon les analystes,  1) des données  (d’un genre caractéristique), 2) d’un phénomène ou encore 3) d’un ensemble de techniques ou technologies. Il en ressort cependant un champ lexical qui fait assez largement consensus et s’est imposé sur la plupart des slidewares (avec aussi des contradicteurs).

« Petite » analyse lexicale du « Big » data

3 V. Volume, Variété, Vélocité. Vision du Gartner de 2001 : chacune de ces caractéristiques constituent un défi pour les entreprises qui souhaitent les exploiter ; leur combinaison accentue d’autant la difficulté que représente le traitement des données. Le Big data n’est pas que l’explosion des volumes. C’est aussi la richesse des formats et le temps réel. Ce qui pose question et qui est rarement explicité, c’est la mesure de chacune de ces trois dimensions. Le volume se mesure-t-il en téra- ou en pétabytes ? Où se situent les niveaux d’acceptabilité qui permettent de déterminer qu’une situation ou un cas d’usage relève du Big data ? Le Big data d’aujourd’hui sera-t-il celui de demain ? Car avec la croissance des données et les avancées technologiques, le curseur ne cessera sans doute pas de se déplacer…

4V = 3V+Valeur. Certains ont noté un glissement de l’acception Big data de 3 à 4 V : des caractéristiques de nature technique à celle de « valeur ». Que peut-on tirer des données ? C’est en fait la question essentielle : celle de « l’opportunité à saisir » ou du « besoin à combler ». Une autre question apparaît avec les fournisseurs de données : quel est le prix des données ?

Technologie accessible. Il n’y a pas de définition technologique du Big data au sens où aucune technologie n’est liée de manière exclusive et catégorique au concept. Tout comme les web services n’étaient pas la SOA, le Big data n’est pas Hadoop*, même si Hadoop est la valeur sure d’un marché en plein essor et encore peu lisible. Certes, l’envolée du Big data doit beaucoup à l’« accessibilité »  d’Hadoop et du noSQL. Mais le coût et le ROI de ces solutions sont-ils à la hauteur des promesses ?

Acquisition, visualisation etc. Le Big data n’est pas que stockage et analyse de données. Il faut  développer son gisement pour trouver la bonne information. L’information produite doit être comprise, retenue, travaillée et des techniques d’analyse visuelle sont aujourd’hui mises en avant.  Enfin, pour les questions de fiabilité et de sécurité, des évidences en gestion des données, des solutions se positionnent.

Décision. Le Big data bouscule le décisionnel. Les cas d’usage Big data sont quasiment exclusivement analytiques. Les technologies dont nous parlions ne sont d’ailleurs pas construites pour supporter des processus transactionnels qui restent en périphérie de la « révolution » à la source des données.

Un Big data à ma sauce

Le Big data est une véritable problématique, soit littéralement un faisceau de questions. Si l’exercice de définition va se poursuivre, il serait salvateur de l’évacuer rapidement. Mieux vaut se concentrer sur les défis techniques et organisationnels du traitement des données et la recherche de nouveaux leviers de performance.

Forrester propose pour ce faire une approche pragmatique « Calculer son « Big Data score », qui vise à s’auto-évaluer sur sa capacité à stocker, traiter, requêter ses données selon chacune des 3 dimensions. Big data ne veut pas dire la même chose pour Google et pour moi. Il faut revenir à des enjeux réalistes : ai-je exploré les opportunités d’utilisation des données « à ma disposition » ? Suis-je capable de « passer à l’échelle » efficacement (délai, coût) si une opportunité se présente ?
Et, à quelle échelle : *10, *100, *1000 ? Que font mes concurrents ?

Alors : in or out ?

*Hadoop comme nombre de bases de données noSQL est distribué en open source. Le déploiement d’Hadoop n’exige pas d’infrastructure réseau et/ou serveurs haut de gamme.

Cet article Big data : tour d’horizon 2013 ! est apparu en premier sur RiskInsight.

Quelles sont caractéristiques du Big data ?

Comme son nom l’indique, le Big data définit une catégorie de données. Elle est souvent résumée par les 3 « V » :

• Volume : une quantité de données importante liée à la multiplication des données du client. Les données à manipuler sont de l’ordre de la dizaine de tera octets ;
• Variété : différents types de données  provenant de diverses sources (internes SI, externes comme les réseaux sociaux… Ces données vont du plus structuré (relationnel) au non structuré (fichiers, vidéo…) ;
• Vélocité : une fréquence rapide à laquelle les données doivent être traitées et partagées, liée à la volonté de tendre vers un SI « temps réel ».

 Comment savoir si l’on manipule des données Big data ?

C’est simple, c’est souvent lorsque l’une des couches du SI devient un facteur limitant lors du traitement de gros volume de données, que l’on comprend qu’il s’agit de Big data.

La couche stockage est l’un des premiers facteurs limitant et les problématiques associées sont les suivantes :

• Performance : l’augmentation du volume à traiter entraîne une diminution des performances ;
• Linéarité : l’outillage n’étant pas adapté aux gros volumes de données, le modèle de scalabilité n’est pas linéaire, l’ajout de stockage ne permettant pas d’améliorer les performances ;
• Dynamisme : l’allocation d’espace est fixe avec une faible réactivité pour en ajouter ou en retirer.

Les solutions du marché reposent sur des implémentations propriétaires.

Les solutions Big data reposent sur un stockage basé sur le modèle de fichier distribué : des nœuds de stockage sont répartis physiquement sur le réseau mais vus par les applications comme un seul volume de stockage logique.

Ce modèle répond justement aux enjeux suivants, auparavant problématiques :

• Performance : les données sont réparties sur plusieurs nœuds de stockage (stripping HADOOP HDFS) et ceux-ci se distribuent intelligemment la donnée afin de diminuer le trafic réseau (les données semblables sur un même nœud) et faciliter des traitements distribués (HADOOP map reduce)
• Linéarité : le modèle distribué permet d’ajouter des nœuds de stockage sans limite et permet de retrouver une scalabilité linéaire ;
• Dynamisme : l’ajout et la suppression de nœud de calcul peuvent se faire simplement et apportent une résilience (via la réplication automatique des données). Si un nœud de stockage tombe, le service est assuré sans arrêt et sans perte de données. On s’approche d’une perte de données « RPO » et d’un temps de reprise « RTO » nulle.

Les solutions du marché (IBM, EMC, etc.) répondent aux 3 « v » du Big data mais chacune suit son propre modèle d’implémentation du stockage distribué : Cluster File System, Parallel File System…. Chaque solution n’a donc pas les mêmes performances ou, capacité d’évolutivité suivant le besoin.

 La qualification des données est la clé du stockage

C’est pour cela que lors de la mise en œuvre de ces types de solutions, une étude sur le stockage est nécessaire.  Quelles sont mes données ? Quelle est la volumétrie (max, écart-type, moyenne) ? Quelle est leur croissance ? Quels types de traitements sont effectués ? Doivent-elles être centralisées ? Quel est le ratio de lecture / écriture ? …

Toutes ces réponses permettront de catégoriser les données, un entrant primordial à la qualification de la solution cible et à son optimisation. Ainsi l’optimisation des  services de stockage Big data permettent à l’entreprise de maîtriser la variabilité et les performances. L’indexation devient plus facile, la taille des caches est optimisée et le stripping (fait de couper le fichier en plusieurs morceaux) est facilité afin de garantir un accès plus rapide à la donnée.

La mise en place d’une technologie stockage distribué est idéale dans les configurations de type grille de calcul : les nœuds de calcul échangent un grand nombre de données entre eux. À  la place d’une configuration en étoile où tous les nœuds s’échangent directement des fichiers, chaque nœud utilise un même volume logique hébergé sur une infrastructure Big data. Les gains sont doubles : directement sur les temps de lecture / écriture des données partagées et la charge réseau (bien que plus concentrée sur un segment) et indirectement sur les temps de calculs de la grille. Les nœuds de la grille de calcul étant déchargés de leur fonction de distribution de fichiers vers les autres nœuds, les ressources sont exploitées au maximum par le calcul applicatif. L’applicatif est donc plus performant pour le business.

Les solutions de stockage Big data commencent à être adoptées par les entreprises, qui les utilisent sur leurs périmètres stratégiques pour en tirer des gains de performance là où les solutions standards étaient limitantes. L’intégration de ces solutions reste l’étape clé : l’étude des données est nécessaire pour choisir la bonne implémentation Big data, faciliter sa configuration et ainsi profiter pleinement des  bénéfices annoncés.

Cet article Big data : comment intégrer les technologies de stockage ? est apparu en premier sur RiskInsight.

MMI (Mathieu Millet) : Le premier élément structurant dans le contexte Big Data est le socle de “stockage” des données.

L’approche historique est celle des offres de DatawareHouse, qui ont évolué, sous forme d’appliance notamment, pour supporter de plus grandes quantités de données et faire porter par le « stockage » une capacité de traitement étendue (principe de PushDown). On retrouve les offres de fournisseurs tels que TeraData (leader historique sur le marché), Oracle avec ExaData, IBM/Netezza/Informix ou encore, EMC/Greenplum ou HP/Vertica.

Ces solutions ont toutes en commun un modèle de données fortement structuré (type, table, schéma, …) et le langage de requête SQL.

L’approche en rupture est celle proposée par Google, avec la publication de son Livre Blanc Big Table. Cette approche consiste en 2 grands principes. Tout d’abord, il s’agit de reprendre les principes de scalabilité (horizontale) des clusters de calcul scientifique (HPC).Puis, on peut se permettre de s’affranchir de certaines contraintes inhérentes à un usage transactionnel des bases de données relationnelles traditionnelles, et qui ne sont plus strictement nécessaires pour les usages analytiques, telles que les principes d’ACIDité (Atomicité, Cohérence, Isolation et Durabilité), le langage SQL (Not-Only SQL, NoSQL) et la contrainte de Cohérence (immédiate) du théorème CAP[1] de Brewer .

Cependant, pour simplifier la mise en œuvre d’une telle solution  et rendre l’infrastructure simple, scalable (à plusieurs centaines de nœuds), avec du matériel à bas coût (donc sans inclure de réseau faible latence, type InfiniBand ou même sans réseau de stockage spécifique), le framework de “gestion” d’un tel cluster est obligé de contraindre fortement l’organisation et la manière de développer. Les principes de Map Reduce[2] (toujours décrits dans le Libre Blanc de Google) répondent à ces contraintes.

La solution la plus emblématique de cette approche est Hadoop et son écosystème. Développé initialement par Yahoo, maintenant supporté par la fondation Apache, Hadoop implémente un système de Fichiers massivement Distribués (HDFS) et un moteur Map Reduce. Hadoop est épaulé par tout un écosystème afin d’étendre son champ fonctionnel, avec par exemple HBase (base de données de type NoSQL) ou encore Hive (entrepôt de données disposant d’un langage de requêtage à la SQL).

Hadoop a tellement le vent en poupe que presque tous les acteurs du DatawareHouse (Oracle, Microsoft, IBM, Teradata,…) ou de l’analytique (SAS, R, Micro Strategy, …) ont maintenant annoncé des solutions autour de ce nouvel écosystème.

LGA (Lise Gasnier) : La finalité du stockage est d’extraire l’information utile des données. L’analyse est naturellement l’autre volet majeur du paysage technologique du Big data.

Dans ce domaine, l’innovation porte sur l’intégration des solutions d’analyse à celles de stockage pour éviter les mouvements des données. Mathieu a cité Hive pour sa compatibilité avec Hadoop. Citons également Greenplum un dérivé de Postgres qui repose sur une architecture distribuée sur un cluster de machines. Cette tendance à l’interaction se traduit aussi par le rapprochement d’acteurs issus des deux mondes: Revolution Analytics (BI) et IBM Netezza,par exemple,  sont partenaires depuis début 2011.

Une approche banalisée de ce rapprochement entre traitements et données est celle des grilles de données tels que Oracle Coherence, Terracotta ou Gigaspaces XAP. Elles offrent la capacité de distribuer les données sur des nœuds de calcul. Elles se trouvent donc à la jonction entre clusters de traitements distribués et bases de données mémoire.

Ces dernières, en économisant les accès aux disques, permettent d’utiliser des approches analytiques classiques tout en garantissant les performances à mesure que la complexité des requêtes et leur volume évolue. Même si les produits (comme les appliances analytiques SAP HANA et Kognitio WX2) ne sont pas en mesure, aujourd’hui, de gérer les pétaoctets du Big Data, il faudra être attentif à l’innovation sur ce marché en croissance car on observe une convergence de différentes technologies au sein des solutions proposées par les éditeurs.

Toujours sur le plan de l’analyse, on assiste à la diffusion et à l’outillage des techniques analytiques, notamment par le recours à des méthodes issues de l’intelligence artificielle de type Machine Learning et Natural Language Processing.

Le Big data met aussi l’accent sur l’importance de restituer efficacement les résultats d’analyse et d’accroître l’interactivité entre utilisateurs et données. Ainsi, des produits comme Tableau (de Tableau Software) proposent des visualisations graphiques innovantes.

MMI : Enfin, pour pouvoir analyser ces données que l’on aura stockées, il ne faut pas oublier le processus d’acquisition et de chargement de ces mêmes données.

Cet article Quel est le paysage technologique du Big Data ? est apparu en premier sur RiskInsight.