Tutoriel pour apprendre à faire le choix d'une architecture big data

L'approche SGBDR ne respecte pas les exigences des entreprises du Web 2.0 telles que Google, Amazon, Yahoo, Facebook et LinkedIn. Ces sociétés gèrent une grande quantité de données en raison de l'explosion des sites, des réseaux sociaux et IdO (Internet des objets). Ils travaillent avec différents types de données qui doivent être stockées et traitées. Alors, quand il s'agit de volumétrie importante de données, les propriétés ACID des SGBDR ne sont plus valides, et lors de l'utilisation des solutions de réplication basées sur des architectures maître/esclave, les données sont répliquées de manière asynchrone qui signifie que l'opération d'écriture des données prend du temps pour se propager du maître à l'esclave, causant ainsi la perte de la cohérence des données. Face aux problèmes de performance, dénormaliser le modèle de données semble la solution, mais nous risquons d'obtenir des données dupliquées.

La plupart des données sont générées par des utilisateurs ou des machines. Ces données générées sont non seulement volumineuses, ont une vélocité importante, mais aussi diversifiées, ce qui traduit le terme «big data». big data impose de nouveaux défis à la manière traditionnelle de traiter les données en utilisant les SGBDR, car ils ne sont pas conçus pour l'échelle de Web comme nous l'avons mentionné auparavant. Un nouveau mouvement de gestion des données est né collectivement appelé « NoSQL » qui est l'abréviation de Not Only SQL. C'est une approche différente des SGBDR qui offre une mise à l'échelle linéaire en suivant le théorème CDP (Cohérence, Disponibilité,tolérance au Partitionnement), et peut stocker du big data.

Les bases de données NoSQL peuvent traiter différents types de données, qui ne nécessitent pas un schéma strict. Le NoSQL a différente catégorisation (Value Key Store, entrepôt orienté colonne, entrepôt orienté document, base de données orientée graphe ) pour répondre aux différents besoins de stockage du big data.

NoSQL a introduit de nouveaux défis lorsqu'ils traitent avec la modélisation des données. Chaque catégorie a ses techniques de modélisation, par exemple Apache Cassandra utilise une technique appelée « Modélisation par Query ».

I-B-1. Pourquoi de nouveaux outils statistiques ?▲

Très souvent les données de l'entreprise proviennent des PGI (Progiciels de données de gestion), GRC (gestion de relation client), commerce électronique (E-Commerce), GCL (gestion de la chaîne logistique), des entrepôts de données (Data Warehouse en anglais) et des bases de données issues d'un développement applicatif interne. La majorité de ces données sont souvent stockées dans un système de gestion de bases de données relationnelles (SGBDR).

Les SGBDR sont toujours au cœur du système d'information des entreprises et les investissements lourds de ces dernières dans ces solutions de stockage rendent leurs remplacements problématiques, et toutes les tentatives ont échoué (à titre d'exemple les bases orientées objet), devant leurs puissances, parce qu'ils ont d'abord de très nombreux avantages que nous allons expliquer dans la partie « limitations des bases de données relationnelles », de plus ils sont devenus un référentiel et un mécanisme d'intégration pour la majorité des DSI.

Aujourd'hui, avec le Web 2.0, nous sommes confrontés à une croissance incomparable de la quantité de données que nous traitons, et qui augmente très rapidement comme on peut le voir sur des sites comme : http://www.internetlivestats.com/. Le volume des données atteindra certainement l'exabytes ou yottabytes, comme le montre la figure ci-dessous.

Source : http://air.imag.fr/index.php/EA2014-NoSQL

Les sources des données sont des systèmes d'information traditionnels comme on l'a vu, qui sont jusqu'à présent bien gérés par les entreprises. Les nouveaux arrivants sont les réseaux sociaux (Facebook, Twitter, Google +, blogs) où les utilisateurs génèrent d'énormes flux de données et d'évènements semi-structurés, qu'on ne peut pas stocker dans un SGBDR classique lorsqu'on a des besoins opérationnels avec une très faible latence, et enfin les données des objets connectés qui envoient de plus en plus d'informations en flux continu et qu'on doit pouvoir stocker et traiter.

Nous allons voir pourquoi les SGBDR ne sont pas adaptés à ces nouveaux besoins.

On va rappeler brièvement les caractéristiques des SGBDR classiques, afin de voir les challenges qu'ils posent lorsqu'on a des données massives dans le contexte d'applications web à grande échelle.

Les SGBDR reposent sur des fondements mathématiques élaborés par Edgar Frank Codd (1923-2003), qui a publié un papier intitulé « A relational Model of Data for Large Shared Data Banks », ces théorèmes sont appelés l'algèbre relationnelle, qui sont principalement des opérations comme la sélection, la projection, l'agrégation, l'union, la jointure, etc., et définissent des règles de normalisation qui ont pour but d'obtenir un modèle performant et sûr.

Les SGBDR traditionnels assurent, les points suivants :

• la cohérence des données à travers le schéma des bases de données, qui est établie à la phase de la conception, avec le choix des meilleurs types de données possibles, ce qui évite le risque de changer le schéma relationnel ;
• les contraintes d'intégrité référentielle, un gage de cohérence du contenu de la base de données, car une fois les contraintes déclarées, aucune violation de ces règles ne sera permise pas le SGBDR ;
• un mode de fonctionnement transactionnel avec la gestion des transactions caractérisé par l'acronyme ACID (Atomicité, Cohérence, Isolation, Durabilité), qui garantit que soit toutes les opérations d'une transaction sont effectuées avec succès, soit aucune opération n'est effectuée.
• bien que le SGBDR soit basé sur l'algèbre relationnelle, l'utilisateur utilise un langage déclaratif SQL, qui exécute rapidement des requêtes SQL complexes avec une optimisation automatique des plans d'exécutions, sur des volumes de données raisonnables.

Lorsqu'on a de grands volumes de données, des solutions peuvent être envisagées :

• la montée en charge verticale (Scale-up) reste possible, pour augmenter l'espace de stockage et de traitement de ces volumes au sein de la même machine ;
• la montée en charge horizontale (Scale-out), qui consiste à distribuer les SGBDR ;
• les administrateurs de bases de données optimisent les performances à travers la dénormalisation, afin d'éviter les jointures, ou génèrent des tables agrégeant un certain nombre de données, afin d'augmenter les performances.

Malgré ces solutions les SGBDR rencontrent certains challenges techniques et/ou financiers qui sont :

• les coûts de la montée en charge verticale ;
• la montée en charge horizontale limitée à 10 nœuds, pour des contraintes techniques ;
• les coûts en ressources humaines pour mettre en place un tel matériel et assurer son bon fonctionnement, ce qui implique plus de coûts pour héberger plus de données ;
• les bases de données relationnelles ne sont pas adaptées pour les traitements temps réel ;
• les prix des licences de logiciels comme Oracle s'ajoutant au prix des machines spécifiques.

Pour résumer les contraintes des moteurs relationnels sont trop lourds, dans le contexte big data.

Le big data fait référence à l'explosion du volume de données informatiques qui transitent dans le monde. Ces données deviennent tellement volumineuses qu'elles ne peuvent plus être stockées dans des bases de données de tailles normales, ce qui mène à l'utilisation d'outils informatiques de plus en plus performants pour les gérer. Le big data peut être défini par ses trois (voire quatre) caractéristiques majeures, toutes commençant par la lettre V : le Volume, la Vélocité, la Variété, auxquelles peut s'ajouter la Véracité des données.

III-C-1. Volume▲

III-C-2. Vélocité▲

III-C-3. Variété▲

III-C-4. Véracité▲

On a vu que la quantité des données dépasse ce qu'on peut stocker sur une seule machine. D'où le besoin de répartir le stockage sur différentes machines, pour cela il existe deux types d'architectures distribuées, qui sont au cœur du big data et du NoSQL, afin de distribuer et répartir les données et les traitements le plus efficacement possible. Ces solutions sont la distribution avec maître ou sans maître.

• Architecture maître/esclave 

Une architecture distribuée avec maître repose sur l'existence d'une machine « maître » qui conserve la configuration du système et reçoit les requêtes des clients puis les distribue vers la machine contenant la donnée. Ce modèle peut souffrir de la présence « Point unique de Défaillance » lorsqu'un des éléments n'est pas redondant.

• Architecture sans maître 

Dans une architecture distribuée sans maître, toutes les machines ont la même importance et ont les mêmes capacités dans un cluster. Elle repose sur une table de hachage distribuée DHT, qui permet de répartir le stockage sur tous les nœuds du réseau.

Avec l'apparition du web 2.0 et des réseaux sociaux, outre le problème de stockage de données et leur gestion par des SGBDR, les contraintes sont devenues de plus en plus importantes et les solutions évoquées de montée en charge en particulier le scale-out et le clustering ont permis la naissance d'une nouvelle famille de moteur de données dite : Not Only SQL ou « NoSQL » (terme apparu pour la première fois en 2009), pour contourner les limites des bases de données relationnelles.

À l'origine de cette nouvelle famille de moteur de données, ce sont les leaders web qui ont commencé à publier un certain nombre de papiers sur le sujet, pour expliquer comment ils ont résolu les problèmes de stockage de données volumineux, par exemple :

Google a expliqué comment elle stocke des données de Google Calender, YouTube, les e-mails, etc., en s'appuyant sur des technologies solides et puissantes qui permettent une rapide montée en charge, et de supporter des volumes importants de données, avec son système de fichiers distribués et ses algorithmes de traitements distribués, afin de réduire les temps de réponse de son moteur de recherche et le stockage des données structurées dans sa base de données distribuée BigTable ;

Amazon a publié des papiers sur Dynamo qui est un système de bases de données distribué, qui permet de gérer son panier d'achats.

Le mode de stockage NoSQL, permet de gérer de gros volumes de données qui peuvent être non structurées dans des serveurs de stockage distribués qui sont capables de monter en charge à moindre coût.

Ces nouvelles bases abandonnent la notion de durabilité, comme le cas des bases de données en mémoire vive, d'autres abandonnent la notion de transaction pour laisser place aux caractéristiques du théorème CDP (Cohérence, Disponibilité, tolérance au Partitionnement) établies par Éric Brewer en 2000, auxquelles répondent les moteurs NoSQL.

Voici les caractéristiques du théorème CDP :

• Cohérence : la même version des données sur tous les nœuds ;
• Disponibilité : les données sont accessibles à tout instant, et une requête reçoit une réponse ;
• Tolérance au Partitionnement (pannes) : le système doit pouvoir continuer à fonctionner et à répondre, même si un problème survient sur un nœud du cluster.

Impact du théorème CDP :

Dans un système à état partagé en réseau, seules deux des trois propriétés peuvent être satisfaites comme le montre le schéma, ce qui a un impact sur les choix du moteur NoSQL, pour répondre à des problèmes de montée en charge en fonction de la complexité des données. Toutefois on peut combiner différents moteurs NoSQL c'est ce qu'on appelle « persistance polyglotte » qu'on va détailler plus loin à travers un exemple.

Sachant que dans un contexte big data la « scalabilité » est le facteur le plus important, on ne parle plus d'un système consistant, mais « éventuellement consistant » lors du choix d'une base NoSQL, et qui fait partie du concept « BASE », qui veut dire Basically Available, Soft state, Eventual Consistant.

Source : http://air.imag.fr/index.php/EA2014-NoSQLC.

Contrairement au SGBDR, les schémas des données ne sont pas obligatoires pour les moteurs NoSQL, ils utilisent une approche dite : « sans schéma » ou schéma « relaxé », et offrent plusieurs formats et modèles de stockage là où on travaille avec des tables contenant des enregistrements sous forme de lignes. Dans les moteurs NoSQL on peut stocker les données sous forme de base orientée agrégat : clé/valeur dans des entrepôts dites : entrepôts clé/valeur qui supportent la montée en charge, document (JSON, XML…) dans des bases dites : bases orientées documents, colonnes dans des bases dites : bases orientées colonnes qui supportent les données complexes, ou graphe dans des bases dites : bases orientées graphes qui fournissent un modèle de données très complexe.

Maintenant nous allons détailler les trois modes de stockage NoSQL orientés agrégats :

Les bases orientées graphes, ne seront pas détaillées ici, vu qu'elles ne sont pas adaptées pour une utilisation big data.

III-E-1. Entrepôt clé/Valeur - ECV▲

C'est le type de stockage le plus simple qui est un ensemble formé de deux données liées entre elles comme le montre le schéma, par une clé unique qui représente une information atomique et la valeur qui contient les données qui peuvent être complexes et représentées sous forme de liste, tableau ou d'autres clés qui pointent vers d'autres valeurs, et contiennent aussi plusieurs métadonnées.

Ce type de stockage peut être en mémoire ou sur disque dur, et le seul moyen d'accès est par la clé de la ligne qui est indexée.

Ils représentent l'avantage d'être très facilement distribués au sein d'un cluster, ainsi que de meilleures performances en écriture et lecture à travers un dictionnaire. De plus, ces structures de données sont très utilisées par les développeurs.

III-E-1-a. Panorama des solutions ECV▲

La plupart des solutions se basent sur le papier d'Amazon Dynamo :

• Voldemort : initié en 2008 au sein de la société Linkedin, peut être stocké en mémoire et sur disque, extensible à la fois par réplication horizontale et verticale, favorise la disponibilité et la tolérance au morcellement ;
• Riak : initié en 2008, par la société Basho, pas de point unique de défiance (SPOF), favorise la cohérence et la tolérance au morcellement ;
• Amazon DynamoDB : base de données en tant que service BDaaS fournie par Amazon AWS.

D'autres solutions se basent sur memcached conçue par Brad Fizpatrick :

• Redis initié en 2009 par Salavador Sanfilippo, peut être stocké en mémoire et sur disque ;
• OrientDB initié en 2010 par Luca Garulli, est une base multi-model qui peut être configurée pour supporter la cohérence et la tolérance au morcellement, ainsi que la disponibilité selon la configuration du cluster.

III-E-2. Base orientée document▲

Les bases de données orientées document sont semblables aux ECV, mais avec des valeurs qui sont semi-structurées (format JSON, XML), appelées documents comme le montre le schéma, et qui peuvent être hétérogènes.

Les bases orientées document offrent des fonctionnalités avancées, comme la sélection et la modification de la valeur d'un champ à l'intérieur d'un document, le requêtage et l'indexation de certains champs, ce qui réduit les développements niveau client.

Ce modèle est très utilisé dans le développement des applications web, de par leur facilité d'accès et de versionning qui est très utile dans le cas de modification des structures des documents.

III-E-2-a. Panorama des bases orientées documents▲

• MongoDB : initié en 2007 par la société 10gen pour créer une Plateforme (PaaS), favorise la cohérence et la tolérance au morcellement.
• CouchDB : initié en 2005 par Damien Katz pour la mise en place d'un système de stockage dédié au site web, favorise la disponibilité et la tolérance au morcellement.
• RavenDB :
• OrientDB : initié en 2010 par Luca Garulli, est une base multi-model.
• DocumentDB 

III-E-3. Base orientée colonnes▲

Un autre modèle d'ECV, à l'origine conçu par Google pour BigTable qui est hautement distribué et qui gère des données tabulaires et stocke les données par colonnes et non par lignes. Les tables de données ne sont pas reliées (pas de jointures) entre elles comme dans les SGBDR, favorisant ainsi la dénormalisation au profit de la performance, très utile lorsqu'on a une grosse volumétrie de données avec beaucoup d'opérations d'écriture/lecture.

Les bases orientées colonnes ont des tables qui peuvent contenir des structures de données complexes. Ces tables sont constituées d'une clé unique qui référencie un enregistrement, et d'un groupe de colonnes, ou super-colonnes qui peuvent être dynamiques contrairement à des colonnes de SGBDR comme le montre le schéma.

Le choix de la clé est crucial pour avoir de bonne performance, puisqu'on n'a pas des index secondaires.

Grâce à leurs modèles de stockage par colonnes, elles favorisent l'enrichissement du schéma initial sans avoir un impact.

III-E-3-a. Panorama des bases orientées colonnes▲

• Cassandra : initiée et développée par Facebook en 2008, pour son système de mail puis devenu un projet de la fondation Apache, Cassandra est très utile pour le traitement temps réel et favorise la disponibilité et la tolérance au morcellement.
• Cas d'utilisation d'Apache Cassandra
• HBase : initiée en 2007 par la société Powerset, qui est un clone open source de BigTable, qui utilise le système de fichier HDFS de Hadoop, ZooKeeper pour la coordination et a un accès direct (aléatoire) à la donnée favorisant la cohérence et la tolérance au morcellement, avec une latence inférieure à la seconde ce qui le rend utile pour les traitements temps réel.

Le tableau comparatif suivant montre d'une manière synthétique les différents moteurs NoSQL et leurs caractéristiques sans être exhaustif.

Tableau 1: tableau comparatif des moteurs NoSQL

	Format de stockage	Transactions	Relation	Haute disponibilité	Fonctions avancées
HBase	Colonnes	Non	Oui	Cluster
Cassandra	Colonnes	Non	Oui	Cluster	Réplication avancée
Redis	Clé/Valeur	Non	Non	Cluster	Communication asynchrone
Riak	Clé/Valeur, Série temporelle			Cluster	Tolérance aux pannes
MongoDB	Document JSON	Non	Non	Cluster	Agrégation
OrientDB	Multi-Format	Oui	Oui	Cluster	Transactions et sécurité
Neo4j	Graphe	Oui	Oui	Cluster	Intégration avec d'autres solutions NoSQL

D'après le schéma suivant, on voit que les bases orientées colonnes, comme Apache Cassandra, Apache HBase, Apache Accumulo et OrientDB sont les plus utilisées grâce à leur flexibilité et leur rapprochement du modèle SGBDR, ainsi que leur capacité à stocker d'énormes quantités des données.

Source : http://air.imag.fr/index.php/EA2014-NoSQL

À titre d'information aujourd'hui il n'existe pas moins de 255 moteurs NoSQL d'après le site : http://nosql-database.org/ qui ont tous été conçus pour stocker de gros volumes de données, donc le choix dépendra forcément des besoins métier.

Toujours par rapport au besoin métier, on peut mettre en place une persistance polyglotte, comme le montre bien le schéma suivant. Une base orientée clé/valeur en mémoire pour la gestion des sessions et la gestion du panier d'achats, un SGBDR pour les données financières, et le reporting, une base orientée document pour la gestion du catalogue des produits, une base orientée colonnes pour l'analytique et la gestion des logs des utilisateurs et enfin une base orientée graphe pour la gestion du système de recommandation :

Source : http://datadventures.ghost.io/2014/07/06/polyglot-processing/

Lorsqu'il s'agit des besoins statistiques, d'analyse d'historique, d'analyse d'activité ou de tableau de bord de suivi pour connaître les tendances de ventes par exemple selon différents paramètres, le modèle relationnel ne permet pas de répondre à ce besoin.

« Le modèle relationnel est performant pour une utilisation purement transactionnelle, ce qu'on appelle OLTP (On Line Transactional Processing) » (Bruchez, 2015)

OLTP est destinée à recevoir des opérations d'écriture et lecture très fréquentes, sur des volumes de données qui peuvent être importants, grâce à une bonne modélisation du schéma des données et l'utilisation des index, afin d'optimiser ces opérations.

Pour répondre à ces besoins les entreprises se basent sur des solutions très maîtrisées, en particulier les entrepôts de données (DW pour Data Warehouse) qui étaient une discipline très populaire, depuis les années 1970, qui a aidé les entreprises à transformer les données en informations, en utilisant OLAP (On Line Analytical Processing) qui est généralement en lecture seule, cette analyse est ce qu'on appelle « Business Intelligence ou BI », et qui est apparue début 1980. 

« DW est l'abréviation de Data Warehouse, ce qui signifie que la base de données est à fort volume, et a été spécialement préparée pour l'analyse, avec des tables de faits et des tables de dimensions. » (GOUIGOUX, 2014)

L'objectif principal des entrepôts des données est d'intégrer les données à partir de différents systèmes et différentes applications, puis les restituer sous différentes formes, à travers « la chaîne de traitement » comme le montre la figure suivante, et très souvent, pour un métier particulier, afin de faciliter l'analyse pour la prise de décision stratégique pour l'entreprise, nous ne nous arrêtons pas au niveau des entrepôts des données (DW), mais on utilise des magasins de données (Data marts en anglais) qui sont alimentés par un sous-ensemble de ces derniers.

Source : http://www.piloter.org/business-intelligence/business-intelligence.htm

Cette chaîne de traitement est un instrument d'aide à la décision pour des besoins transversaux, qui consiste à extraire des informations des bases de données de l'entreprise, puis construire des entrepôts de données afin de modéliser l'information à des fins d'analyse.

L'approche BI se base sur différentes approches OLAP :

• des bases de données relationnelles pour construire les entrepôts de données, c'est ce qu'on appelle ROLAP abréviation de « Relational OLAP » qui n'a pas de limite de quantité des données au détriment de la performance ;
• des cubes pour construire des entrepôts de données, c'est ce qu'on appelle MOLAP abréviation de « Multi OLAP », utilisé sur des tailles de données limitées et qui ne changent pas ;
• la dernière approche est une approche Hybride HOLAP, qui est un compromis entre les deux solutions précédentes ;
• DOLAP pour Desktop OLAP, consiste à récupérer en local une partie d'une base de données multidimensionnelle ;
• SOLAP pour Spatial OLAP.

Historiquement la B.I. est concentrée sur :

• la consolidation financière ;
• la planification budgétaire.

Au fil du temps elle s'est étendue à différents autres métiers :

• la gestion de la relation client-GRC ;
• la gestion de la chaîne logistique-GCL ;
• les ressources humaines-RH ;
• la fabrication.

Le besoin de l'entreprise aujourd'hui n'est pas uniquement de faire le diagnostic de ses propres données comme le montre la figure suivante, mais également de croiser des données provenant de différentes sources (réseaux sociaux, open data...), afin d'anticiper des évènements par l'analyse prédictive.

Un exemple de l'analyse prédictive serait : l'entreprise aimerait savoir quels facteurs influencent les ventes. Si nous réduisons le prix, combien allons-nous vendre de plus ? Si nous faisons de la publicité, quel serait notre profit ? Est-ce que la saison est importante pour ce que nous vendons ? Est-ce que nous vendons bien les jours fériés ? La réponse à ces questions peut aider l'entreprise à faire du profit.

Source : http://www.gartner.com/it-glossary/predictive-analytics/

Ce genre de besoin pose des problèmes de « scalabilité » et de performance précédemment évoqués et comme le témoigne ce retour d'expérience.

« Après deux ans passés à construire des applications BI pour leboncoin à l'aide d'ETL et de bases de données relationnelles, le constat est criant : les limites frustrent le développeur, l'analyste, et in fine, l'utilisateur. » (Baltus, 2016)

Ce témoignage montre les limites des bases de données relationnelles dans le contexte des applications BI.

Les architectures traditionnelles de BI, sont dans l'incapacité de se projeter sur des téraoctets voir des pétaoctets de données, malgré la baisse des prix de la RAM, CPU, et disque dur, comme le montre le schéma :

Source : http://radar.oreilly.com/2011/08/building-data-startups.html

La capacité du débit du disque dur est un problème qui n'a pas de solution technique aujourd'hui, « la capacité de stockage des disques a augmenté de 100 000, le débit lui n'a augmenté que de 100 ». Ce problème est le goulot d'étranglement « bottleneck » de l'architecture.

Pour contourner ce problème, il faut soit minimiser l'utilisation du disque dur (utilisation de la mémoire) soit paralléliser le débit (architecture distribuée), afin qu'il soit acceptable, en utilisant le big data.

Source : http://blog.octo.com/levolution-des-architectures-decisionnelles-avec-big-dataures-decisionnelles-avec-big-data

« La collaboration la plus naturelle entre le big data et la BI consiste à alimenter les datawarehouses (entrepôts de données) et les cubes OLAP avec des éléments de prédictions issus des traitements de data-sciences effectués sur des données gérées par une architecture big data. » (LAUDE, 2016)

Désormais dans la société de la connaissance (Knowledge society), les entreprises doivent être proactives et agiles dans un monde instable au lieu d'être réactives au détriment des enjeux économiques et concurrentiels ardus. Or les lourdeurs des outils classiques (SGBDR, BI) ne permettent pas de suivre les nouveaux besoins du marché.

On pense modestement que l'enjeu majeur pour les entreprises est un enjeu économique, car les entreprises stockent plusieurs données de leurs clients qui ne sont pas exploitées. Ces données engorgent de l'argent, et si les entreprises arrivent à proposer des services innovants et personnalisés pouvant répondre aux besoins de clients, ils peuvent représenter une source de valeur. On va illustrer cela à travers quelques cas d'usage du big data, pour créer de la valeur. Sachant que toutefois le big data est utilisé dans plusieurs contextes et couvre plusieurs cas d'usage.

• Exemple de la banque privée

Les activités marketing 

Le développement de la proximité avec le client : grâce à la dénormalisation des données des clients, et les données des transactions, les banques utilisent les techniques d'apprentissage machine (Machine Learning), afin d'exploiter les données pour déterminer de nouvelles possibilités. Cette connaissance permet la personnalisation du conseil.

Le profilage des clients permet d'améliorer les conseils en investissement : les profils peuvent être analysés sous les différents angles possibles en combinant plusieurs caractéristiques du client.

La réduction des coûts de calcul : l'utilisation des technologies big data est peu onéreuse pour le stockage et pour le traitement soit par lots ou temps réel sur des quantités considérables d'informations, ce qui représente des gains économiques.

• La grande distribution

Fait usage du big data pour faire « le suivi des émissions des tickets de caisse, le flux de marchandises entre ses fournisseurs, entrepôts et magasins, et le parcours utilisateur sur son site e-commerce ».

• Open data : le gouvernement met en avant des banques de données, qui permettent à des entreprises de proposer des services innovants, à titre d'exemple l'application « citymapper », qui utilise des données fournies par l'agglomération lyonnaise, pour proposer des services dans le domaine du « transport », et qui donne des résultats très satisfaisants.
  Le tableau suivant dresse d'autres utilisations du Big Databig data, ainsi que les gains.

On a vu dans la définition des caractéristiques du big data, l'importance de la volumétrie, cette dernière a conduit à l'émergence du mouvement NoSQL, afin de stocker les données et répondre à la problématique de la scalabilité. Le traitement d'une telle quantité de données a engendré un nouveau paradigme appelé « MapReduce ».

Qu'est-ce que le paradigme MapReduce ?

IV-A-1. MapReduce▲

À l'origine de ce paradigme Google, dans les années 2004 avait effectué des travaux de recherche dans l'automatisation des traitements parallèles pour son moteur de recherche, et s'est inspiré de la programmation fonctionnelle.

MapReduce est un paradigme de programmation qui permet de distribuer des traitements parallèles sur des volumétries de données dépassant typiquement 1To, dans un cluster composé de centaines, voire de milliers de nœuds - machines - peu coûteux, avec une architecture de type maître/esclave, grâce à la séparation des données et des traitements.

Le traitement parallèle des données avec MapReduce est simple et s'effectue avec deux opérations qu'on appelle map et reduce. Les données d'entrée doivent être structurées sous forme d'une liste de clé/valeur (une Map) qui peut être très volumineuse (téraoctets voire pétaoctets). Ce format unique facilite les entrées\sorties.

Cette simplicité est composée d'une couche logicielle ou d'un Framework. Le Framework open source le plus connu est Apache Hadoop, (que nous allons détailler dans la section suivante) qu'on peut découper en quatre phases, dont deux à la charge du développeur (map/reduce) et le reste à la charge du Framework :

Source : http://blog.matthewrathbone.com/2013/04/17/what-is-hadoop.html

• Phase de « split » : dans cette phase c'est le Framework qui divise la liste en entrée en plusieurs splits et chaque split sera attribué à une machine qu'on appelle mapper, afin de passer à grande échelle dans le traitement, en se basant sur une architecture de type « share nothing », ce qui rend les traitements indépendants et aucune donnée ne sera traitée par deux nœuds différents. Toutefois le choix de la clé à utiliser et la structure du code est à la charge du développeur.
• Phase de « map » : les mappers vont exécuter l'opération « map », sur les splits qui leur ont été attribués puis produire une liste intermédiaire de clés/valeurs.
• Phase de « Shuffle and Sort », où le Framework fait le tri des fichiers par rapport à la clé, puis échange les splits entre les nœuds, et chaque split contient les valeurs associées à une même clé, qui sera ensuite attribuée au reducer.
• Phase de « Reduce » : dans cette phase chaque reducer appelle la fonction reduce et applique des fonctions d'agrégations, afin de rassembler et produire le résultat souhaité.

Bien que le concept de MapReduce semble simple, sa conception est complexe et souvent confiée à des développeurs confirmés dans la programmation parallèle.

Pour résumer MapReduce propose une architecture logicielle qui simplifie la complexité de l'informatique distribuée, toutefois il faut avoir l'architecture technique qui permet de mettre en place les phases de split et Shuffle and Sort qu'on a vus, c'est ce que nous allons voir dans la section suivante avec l'implémentation open source Apache Hadoop.

IV-A-2. Qu'est-ce que le traitement par lots ? ▲

Le traitement par lots (Batch) est un traitement automatique et sans intervention humaine, avec un temps d'exécution élevé. ((Lemberger, Batty, Médéric, Raffaelli, & Delattre, 2015)

IV-A-3. Qu'est-ce que le temps réel ?▲

Le traitement temps réel (streaming) est capable de prendre en compte les contraintes temporelles, pour délivrer des résultats exacts avec le respect d'une latence très faible. Ce qu'il faut noter c'est que la signification de la latence change d'un contexte à l'autre. Dans le contexte du big data la latence peut être de l'ordre de la seconde (opération de bourse, système de réservation, détection de fraude), voire plusieurs secondes - presque temps réel - (système de traking, monétisation des tweets, analyse des données de géolocalisation dans un centre commercial pour envoyer des offres promotionnelles).

Exemple : Apache Spark Streaming, Apache Storm

Il existe aujourd'hui un nombre important d'architectures big data, l'architecture Lambda, l'architecture Kappa ou l'architecture Zeta, regroupées sous le nom de traitement polyglotte (Polyglot Processing). Dans ce qui suit, nous allons nous intéresser à l'architecture Lambda qui est la plus répandue en ce moment.

IV-B-1. L'architecture Lambda▲

Créée par Nathan Marz en se basant sur ses expériences chez Twitter et Backtype, le but de l'architecture Lambda est de fournir un modèle de traitement presque temps réel sur des volumes importants de données, en proposant un nouveau modèle de calcul. Ce modèle essaie de trouver l'équilibre entre la tolérance aux pannes, les contraintes de latence (latence très faible pour les lectures/écritures) et le débit des disques durs en se basant à la fois sur les traitements batch qui fournissent des vues batch et les traitements temps réel qui fournissent des vues, puis les joint avant leur présentation.

Hadoop n'est pas capable de traiter un grand volume de données qui doit satisfaire une faible latence, même en ajoutant d'autres serveurs de calcul, d'où la naissance de cette architecture qui ne remet pas en question le paradigme MapReduce, mais propose une amélioration, afin de contourner les contraintes de latence de Hadoop.

L'architecture Lambda est indépendante de la technologie, et se base sur le précalcul des résultats, puis à les récupérer dans une base et les envoyant au demandeur. Elle est composée de trois couches.

* Couche Batch : mode de fonctionnement classique des applications big data type Hadoop, cette couche est responsable de deux choses : récupérer les données et les stocker en format brut (AS-IS : pour pouvoir répondre à de nouveaux besoins métier sans impacter les données initiales) dans des puits de données (Data Lake en anglais), et lancer périodiquement des traitements sur les données, pour précalculer les résultats sous forme de vue logique. Le résultat est ensuite stocké typiquement dans des bases en lecture seule et les mises à jour remplacent les vues logiques précalculées.

Cette couche peut être implémentée à l'aide de Apache Hadoop, MapReduce, Spark que nous allons voir par la suite.

* Couche de vitesse ou temps réel (Speeding) : traiter les nouveaux flux de données en temps réel, sans aucun prétraitement (correction des jeux des données). Cette couche minimise la latence et fournit en temps réel des vues avec les données les plus récentes. C'est un fonctionnement en mode continu unitairement pour chaque nouvelle donnée. Les résultats (les vues temps réel) fournis par cette couche ne sont pas aussi fiables, que ceux de la couche batch.

Cette couche peut être implémentée à l'aide de Apache Storm ou Spark Streaming.

* Couche de service (Serving) : rend exploitables les résultats précalculés par la couche batch et la couche temps réel, pour effectuer des requêtes à la volée (ad hoc).

Cette couche peut être implémentée à l'aide des technologies NoSQL Apache HBase, Cassandra, et ElasticSearch qui permettent de merger les vues batch et les vues temps réel.

Source : https://fr.slideshare.net/MohanBavirisetty/polyglot-processing-an-introduction-10

Par rapport au stockage des données l'architecture Lambda recommande de ne plus toucher à la donnée après leurs insertions dans la couche batch.

Pour plus d'informations, vous pouvez voir le site http://lambda-architecture.net/

IV-B-2. L'architecture Kappa▲

Créée par Jay Kreps en se basant sur ses expériences chez LinkedIn et son retour d'expérience de l'architecture Lambda, dans un article : ‘‘Questioning the Lambda Architecture''.

Partant d'un constat que la plupart des solutions sont capables de faire à la fois des traitements temps réel (streaming) et traitements batch, l'architecture Kappa, permet de simplifier l'architecture Lambda, en fusionnant la couche batch et la couche Speeding.

Elle apporte aussi une modification sur les SGBD qui doivent être un système de fichiers de log immuable.

L'architecture Kappa n'est pas destinée au stockage des données, mais uniquement à leur traitement, comme le montre le schéma suivant :

Pour plus d'informations, voir : http://milinda.pathirage.org/kappa-architecture.com/

Dans cette partie nous allons présenter les différentes solutions techniques pour le big data.

La solution Hadoop a été développée par Doug Cutting bénévole à la fondation Apache qui avait des besoins similaires en termes de stockage et traitement de grosses volumétries de données en s'inspirant des publications de Google sur le sujet et les entreprises comme Facebook, Yahoo, Amazon, Twitter et Netflix ont contribué à son développement.

IV-C-1. Le noyau d'Hadoop▲

IV-C-2. Le système de stockage de fichier HDFS▲

Dans cette partie nous allons aborder le système de stockage HDFS, ses objectifs, ses fonctionnalités, son accès et son architecture.

HDFS (Hadoop Distributed File System) est le système de stockage de fichiers d'Hadoop, basé sur le système de fichiers développé par Google, GDF (Google File System) et dont la théorie a été publiée dans des papiers de recherche de Google.

HDFS a pour objectifs d'être :

• tolérant aux pannes d'une manière native (Fault tolerant) : c'est-à-dire qu'il peut résister à l'erreur, en partant du principe que la défaillance est la règle générale plutôt que l'exception, en premier lieu la panne matérielle et notamment le disque dur ;
• scalable : il peut supporter une montée en charge horizontale, avec très peu de contraintes et de pertes de performance ;
• modèle d'accès immuable : écriture unique (il n'est plus modifiable) et multiples lectures pour les fichiers, ce qui favorise la cohérence des données.
• Déplacer les calculs vers les données : parce que le déplacement des fichiers volumineux peut conduire à un goulot d'étranglement réseau et impacter les performances globales du système.
• simple à mettre en place en assurant la portabilité sur différentes plateformes.

Il propose de nombreuses fonctionnalités :

• gestion des fichiers par blocs : chaque fichier sera découpé en blocs de 64 Mo ;
• réplication et distribution : tous les blocs seront à la fois répliqués et distribués pour assurer un stockage fiable des fichiers de très grand volume. Répliqués sur différents endroits sur l'HDFS, par défaut trois endroits, le premier est le serveur pour positionner le fichier, le second est un serveur voisin sur le même rack et le troisième sur autre rack ou un autre Datacenter, pour permettre d'avoir la meilleure distribution possible ;
• gestion des droits : les permissions en lecture et écriture et l'accès au répertoire à la fois pour le propriétaire et pour le groupe. L'authentification peut être soit absente, soit gérée par login et mot de passe ou bien par Kerberos ;
• accès aux données en continu (Streaming) : il a un accès continu aux jeux de données, avec un haut débit d'accès au détriment de la faible latence, parce qu'il est adapté au traitement par lots ;
• stockage des grands jeux de données, les fichiers stockés dans HDFS sont typiquement de plusieurs gigaoctets ou téraoctets, avec une bande passante de haut débit pour les différents nœuds du cluster.

On peut utiliser HDFS grâce :

• aux commandes bash ;
• aux bibliothèques Java ou autres langages ;
• aux interfaces REST avec HttpFS ou WebHDFS.

L'architecture HDFS repose sur une architecture maître/esclave comme le montre le schéma. Elle est composée de :

• un serveur maître nommé « NameNode », qui gère l'espace de noms des fichiers et répertoires ainsi que les droits d'accès ;
• un certain nombre de serveurs esclaves nommés « DataNodes », qui gèrent le stockage des fichiers divisés en plusieurs blocs répliqués et distribués.

Source :https://hadoop.apache.org/docs/current/hadoop-project-dist/hadoop-hdfs/images/hdfsarchitecture.png

Nous allons voir les différents outils de l'écosystème d'Hadoop.

IV-D-1. HBase▲

HBase est la base NoSQL de Hadoop, inspirée de BigTable, qui a pour objectif de stocker une grosse volumétrie de données avec des accès rapides en lecture/écriture, et qui est utilisée en entrée et en sortie de MapReduce.

Source : http://www.dummies.com/how-to/content/the-hbase-masterserver.html

HBase a plusieurs propriétés qu'on a déjà vues dans la partie consacrée à NoSQL et que nous allons rappeler ici :

• base orientée colonnes, c'est-à-dire qu'on peut ajouter ou supprimer des colonnes et modifier la structure de la base sans impact sur les performances, les données sont stockées dans des fichiers distincts dans des colonnes ;
• schéma flexible ou « schema-less », qui ne veut pas dire qu'elle n'a pas de schéma, mais elle contient des métadonnées qui sont définies à l'avance, citons les informations sur la table, avec les familles de colonnes (permet de définir des groupements de colonnes en fonction par exemple de spécificités métier), sans définir forcement chaque colonne à l'avance, mais on peut les insérer dynamiquement aux familles de colonnes ;
• découpage en régions : toutes les données sont réparties sur des régions de façon alphabétique en fonction de leur clé de stockage. Ce découpage est fait avec des espaces de noms (namespace), sans chevauchement entre les régions ;
• scalable horizontalement : grâce au découpage en régions qui sont montées en serveur, toutefois si le découpage est bien fait ;
• non transactionnelle : toutes les opérations sont unitaires et ne peuvent pas être annulées ;
• clé unique : cette clé est obligatoire et il faut lui accorder une grande réflexion, car elle permet entre autres de faire le découpage en régions, en plus de l'indexation, et du tri.

IV-D-2. Hive ▲

IV-D-3. Pig▲

IV-D-4. Zookeeper▲

IV-D-5. Sqoop ▲

Sqoop est créé par Cloudera, Sqoop est un outil Hadoop en ligne de commande permettant d'échanger les données entre Hadoop et les SGBDR.

Sqoop gère les données stockées dans HDFS, Hive et HBase, et fonctionne dans les deux sens de Hadoop vers les SGBDR et vice versa. Il permet :

• d'importer des tables individuellement ou des schémas entiers vers le HDFS ;
• de générer des classes Java qui permettent d'interagir avec les données importées ;
• d'exporter les données de HDFS vers les SGBDR.

Source : http://www.dummies.com/how-to/content/the-principles-of-sqoop-design.html

IV-D-6. Oozie▲

Oozie a été créé par la fondation Apache.

La plupart des algorithmes ne font pas un seul Map/Reduce, mais un enchainement de Map/Reduce, par conséquent Oozie a été créé, afin de coordonner et de créer de workflow de Map/Reduce. Il permet de faire appel à Hive, aux scripts Pig, commandes Batch et des appels Java, comme le montre la figure suivante :

Source : http://www.dummies.com/how-to/content/developing-oozie-workflows-in-hadoop.html

IV-D-7. Flume ▲

« Flume est une solution de collecte, agrégation et transfert de gros volumes de logs. Il a été pensé pour gérer des débits importants avec une fonctionnalité native d'écriture dans HDFS au fil de l'eau ».

Source : https://flume.apache.org/

Flume permet d'apporter des données de serveurs et de les importer vers Hadoop HDFS. Conçu à la base pour traiter les journaux serveur, il se base sur trois notions :

• La source : c'est la donnée qu'on veut importer ;
• Channel : c'est la manière dont il stocke l'information lorsqu'elle est en traitement (RAM, sur disque, SGBDR, etc.) ;
• Sink : l'endroit vers lequel il exporte la donnée, qui peut être HDFS, une table HBase, Kafka, Avro et Thrift (voir l'annexe pour plus d'explications).

IV-D-8. Kafka ▲

Apache Kafka est un broker de message, qui gère des évènements en se basant sur un modèle publish-subscribe. Donc on a des producteurs qui vont envoyer des évènements vers le cluster Kafka, ensuite le cluster Kafka va réceptionner ces évènements et va les mettre en queue, puis va permettre au consommateur d'évènements de souscrire des abonnements sur ces queues d'évènements pour être prévenu s'il y a un évènement qui les intéresse.

Source : http://kafka.apache.org/documentation.html

Kafka se base sur ZooKeeper, pour assurer la scalabilité.

IV-D-9. Spark▲

Hadoop est un système complet, il comporte plusieurs briques logicielles, plusieurs contributeurs et plusieurs mainteneurs, ce qui entraine plusieurs cycles de version pour les outils. En conséquence une maitrise des versions compatibles entre elles est très complexe, cela nécessite également une configuration entre les composants, également très complexe et présente de grandes difficultés à l'installation.

De ce fait, on va avoir plusieurs distributions qui se positionnent, afin de faciliter le déploiement de Hadoop. Une distribution est un ensemble de briques d'Hadoop prépackagées, mises ensemble, et configurées pour fonctionner ensemble. L'intérêt d'un package complet c'est qu'il permet de démarrer plus facilement, plus rapidement et d'avoir un support.

Aujourd'hui il existe plusieurs distributions sur le marché, mais nous allons présenter une liste non exhaustive des solutions les plus utilisées.

IV-E-1. Hortonworks▲

• Hortonworks ou HDP : a été fondée en 2011 par une équipe de Yahoo, et se base sur une philosophie 100 % open source et libre sous la licence Apache. Par ailleurs, ils font très peu de développements spécifiques, très peu de corrections et ils essayent de rester le plus proches de la plateforme Apache d'origine. Elle est également utilisée dans l'offre Cloud de Microsoft Azure.

Source : http://fr.hortonworks.com/products/data-center/hdp/

IV-E-2. MapR▲

• MapR : a été créée en 2009 par une équipe de Google, MapR mentionne trois versions, une version open source et deux versions payantes. MapR à la spécificité d'avoir redéveloppé plusieurs composants du noyau d'Hadoop, notamment HDFS qui a été remplacé par MapR FS, et YARN qui a été remplacé par MapR MR et de la même façon, ils ont apporté beaucoup de modifications à HBase. MapR est utilisée dans les offres cloud de Amazon EMR (Elastic Map and Reduce) et de Google GCE (Google Compute Engine).

Source : http://doc.mapr.com/display/MapR/MapR+Overview

IV-E-3. Cloudera▲

Cloudera ou CDH : a été créée par divers experts de différents acteurs du web (Oracle, Facebook, Google, Yahoo), elle a une seule version qui est libre et ils ont développé quelques composants spécifiques qui ont été donnés à la fondation Apache notamment Cloudera Search, Hue et Impala. Cloudera est spécialisée dans les offres commerciales de support, formations et certifications.

Source : https://www.cloudera.com/documentation/enterprise/5-4-x/topics/cdh_intro.html

Malgré les solutions qu'on vient de citer, le big data est un domaine très vaste et les choix techniques ne cessent d'évoluer dans ce domaine, même s'il existe déjà d'innombrables choix disponibles. Souvent les entreprises supposent que la mise en place d'une solution Hadopp avec une analyse personnalisée va permettre de tirer parti des capacités du big data, mais ce n'est pas le cas.

Dans la partie suivante, nous allons voir qu'il faut réunir plusieurs critères afin de répondre aux besoins métier et tirer parti des technologies big data.

On a vu précédemment les différents types d'architectures Lambda, Kappa et l'impact de la latence sur choix du type de traitement.

Le type de traitement va déterminer les caractéristiques suivantes.

Est-ce que les données sont traitées en temps réel (streaming), presque temps réel ou par lots pour une analyse ultérieure ? Est-ce qu'on va mélanger différents types de traitements ? Le choix du type d'analyse doit être examiné attentivement.

Pour aider à répondre à cette question, nous proposons de voir la nature du besoin, et du résultat attendu.

Est-ce que c'est un traitement opérationnel avec de petits ensembles ou sous-ensembles de données avec une faible latence qui ne dépasse pas la seconde et avec de faibles exigences sur l'exactitude des résultats ?

Dans ce cas, il faut choisir une architecture presque temps réel, qui intègre les données provenant de différentes sources, et fournir rapidement les résultats qui ne sont pas forcément cohérents, sans attendre la fin des données en entrée pour retourner des résultats.

Est-ce que c'est un traitement analytique avec d'énormes quantités de données, avec de fortes exigences sur l'exactitude des résultats ?

Dans ce cas, il faut choisir une architecture batch pour le traitement d'un ensemble de données, on a un résultat qui est cohérent et disponible uniquement à la fin des traitements. Il faut garder à l'esprit que les données qui parviennent en cours de traitement ne seront pas traitées.

Il faut lister tous les utilisateurs possibles des données traitées :

• êtres humains lorsque l'utilisateur final est l'être humain, il faut accorder une grande importance à la visualisation des données, car l'être humain comprend mieux le graphique que le texte. Il faut donc garder ça à l'esprit constamment lorsqu'on modélise l'interface pour donner du sens à l'information, à son utilisation, ainsi qu'à son interprétation, pour permettre une prise de décision rapide et efficace ;
• processus métier : il faut penser au format des données et à leur intégration ;
• applications d'entreprise ;
• référentiel de données.

La source des données peut être problématique lorsqu'on a différentes sources de données. Contrairement à un modèle traditionnel où on a la plupart du temps une seule et unique source de données, le big data peut traiter différentes sources de données, et cela a un impact sur la qualité des résultats. Comme source de données, on trouve :

• Web et réseaux sociaux, dans ce cas il faut prendre en considération la qualité des données, le nettoyage et l'enrichissement des données en définissant des règles, et en cas de rejet des données, il faut voir pourquoi elles sont irrécupérables ;
• données saisies par des utilisateurs, générées par des machines ;
• données internes à l'entreprise.

La variété des données, rend la qualité des données difficile à atteindre, en fonction de la nature du besoin final, donc si l'application à des exigences fortes en termes de qualité de données, il faudra adapter des processus robustes. De même le nettoyage des données consiste à l'identification et l'élimination des données inexactes pour les futurs traitements. Et dans le cadre du big data l'inexactitude des données a un impact sur les qualités des analyses

La variété du big data, offre des possibilités d'explorations des données en se basant sur des processus de classification et clustering.

Le format du contenu impacte directement la qualité de la recherche et l'analyse des données, car il repose sur un schéma de données qui prend en compte le format des données afin de répondre à un besoin métier. Le modèle de données doit être dynamique lorsqu'on a un volume important de données. Les formats big data supportés sont :

• structuré (SGBDR) ;
• non structuré (audio, vidéo et images) ;
• semi-structuré : log.

Le format des données détermine la façon dont les données entrantes doivent être traitées, et le besoin de faire des transformations d'un contenu non structuré vers un contenu semi-structuré.

Métadonnées, transactionnelles, données historiques, connaître le type permet de séparer les données dans le stockage.

Quelle quantité des données est attendue et à quelle fréquence va-t-elle arriver ? Connaître la fréquence et la taille permet de déterminer le format de stockage, le mécanisme de stockage que nous allons utiliser et traiter la complexité autour de la réplication, la compression, la disponibilité, l'accessibilité, la mutabilité, la capacité, la latence, le débit, et enfin la sécurité des données.

Parmi les différents points évoqués, il faut en particulier s'intéresser à la compression des données pour avoir une solution optimale en termes de réduction d'espace de stockage, ainsi que la réplication des données, car plus on a de données redondantes plus on aura des traitements rapides.

La fréquence et la taille dépendent des sources des données qu'on a vues :

• série temporelle : en fonction du temps ;
• temps réel, flux continu : données transactionnelles, données météorologiques ;
• flux à la demande : réseaux sociaux.

Puisqu'on traite un volume important de données, il est important de choisir une méthodologie qui réponde aux besoins et au contexte métier, sans impacter les données brutes, car il se peut qu'un nouveau besoin métier se manifeste sur les mêmes données qu'on avait.

Il existe différents types d'analyses :

• analyse descriptive ;
• analyse prédictive ;
• génération de requête ;
• génération de rapport.

Les exigences opérationnelles déterminent la méthode de traitement appropriée.

Ce type d'architecture ne requiert pas un type de matériel particulier, et les machines bon marché sont bien adaptées. Cependant, comprendre les limites du matériel contribue aussi au choix dans le cadre d'une architecture big data, et permet de renforcer les points de défaillance possible d'un tel système.

Vous devez choisir le matériel et le système d'exploitation en fonction des préférences de l'entreprise et des coûts.

Le schéma suivant résume les différentes étapes à suivre lors du choix d'une architecture big data.

Les différents critères qu'on a vus vont permettre de faire le choix technologique le mieux adapté pour chaque couche big data, afin de choisir l'architecture big data qui répond le mieux aux besoins métier.

Toutefois, lors du passage à un projet piloté par les données, il faut garder à l'esprit que c'est une architecture distribuée qui doit prendre en considération les problèmes de scalabilité, de performance et de synchronisation entre les différents couches et modèles. Au final il n'y a pas une solution, mais des solutions à chaque problème, et il faudra trancher en fonction des besoins et du contexte métier.