Big Data Chp4 – « Putting It All Together »

Dr. Lilia SFAXI GL4-OPTION MANAGEMENT DES SYSTÈMES D’INFORMATION - 2013-2014

Institut National des Sciences Appliquées et de Technologie

Ø  Pas de solution miracle qui fonctionne dans toutes les situations

Ø  Le métier et le type des données définissent la solution adéquate

o  Si la compagnie X réussit à gérer ses 500M utilisateurs avec MySQL, cela ne veut pas dire que vous arriverez à bien gérer vos 100M d’utilisateurs avec MySQL

o  Si la compagnie Y utilise MongoDB pour gérer ses 100M utilisateurs, cela ne veut pas dire que vous y arriverez aussi!

Ø  A good engineer can make bad product to work

Ø  A bad engineer can make good product to suck

Ø  Il faut tout d’abord comprendre le métier:

o  Sources, types et croissance des données

o  Consommation des données

ü  Utilisateur final, API, outils de reporting, interne…

o  SLA (Service Level Agreement), temps de réponse,

o  Coût

o  Penser à faire évoluer l’architecture avec la croissance de votre entreprise, ne pas penser trop gros depuis le jour 1

2 Big Data, BI, NOSQL: Que choisir?

Ø  SQL:

o  Relationnel et transactionnel

Ø  NOSQL

o  Non-relationnel, distribué, haute performance, et hautement évolutif

Ø  Analytiques et Business Intelligence

o  Entrepôt de données centralisé et unique, analyses métier, reporting

Ø  Big Data, Hadoop et MapReduce

o  Distribué, hautement évolutif, tolérance aux fautes et traitement des données parallèle

Ø  Combinaison des quatre:

o  Commencer avec SQL et/ou NOSQL, et envisager ensuite BigData/Analytiques

3 D’abord, comprendre les objectifs des différentes technologies…

Ø  Choix entre deux classes de technologie :

o  Systèmes fournissant des capacités opérationnelles pour des charges de travail quotidiennes, interactives et en temps réel, où les données sont principalement capturées et sauvegardées

o  Systèmes fournissant des capacités analytiques pour une analyse rétrospective et complexe qui peut toucher toutes ou la plupart des données.

Ø  Deux classes complémentaires et en général utilisées ensemble

Ø  Systèmes opérationnels : Bases de données SQL et NOSQL

o  Satisfaire des requêtes concurrentes

o  Exhiber une latence faible (temps de réponse très rapide)

Ø  Systèmes analytiques : Entrepôts de données et MapReduce

o  Se concentrent sur un grand débit

o  Requêtes peuvent être très complexes et toucher plusieurs sinon toutes les données du système à tout moment

4 Ensuite, savoir ce qu’on veut!

Big Data & NOSQL BIG DATA CHP3 – BASES DE DONNÉES NOSQL

5

Ø  HDFS représente l’un des atouts majeurs de Hadoop car:

o  Distribué, en cluster

o  Facilement extensible

o  Offre une haute disponibilité

Ø  Mais, il offre certains désavantages:

o  Utilise un système de stockage direct (DAS: Direct Attached Storage), pas de SAN (Storage Area Network)

o  Problème de disponibilité pour les utilisateurs des anciennes versions de Hadoop, où le NameNode n’est pas dupliqué

o  Les utilisateurs utilisent déjà une base de données distribuée, et ne veulent pas perdre du temps à copier les données d’un système à un autre

Ø  Plusieurs options sont proposées pour remplacer HDFS, dont l’utilisation de bases NOSQL

6 Remplacer HDFS par NOSQL

Ø  C’est l’approche la plus utilisée

Ø  NOSQL offrent des données diversifiées, en grand nombre et de divers types, regroupées dans un endroit unique.

Ø  Map Reduce pourra parcourir ces données, les filtrer, les traiter et afficher les résultats

o  Profiter des capacités de stockage des bases NOSQL

o  Profiter de la tolérance aux pannes pour éviter la perte de données

o  Extraction facile des données, plus facile qu’une manipulation d’un fichier textuel

o  Moins de risques de données erronées ou non conformes

Ø  Les résultats obtenus pourront être stockés:

o  Dans un fichier texte, excel…

o  Dans une base NOSQL, pour profiter de la capacité de stockage

o  Dans une base SQL pour faciliter le reporting

7 Utiliser le MapReduce pour interroger les bases NOSQL

Big Data & Business

Intelligence

BIG DATA CHP3 – BASES DE DONNÉES NOSQL

8

9 Sources Statistiques

Extraction Transformation Chargement

Affichage Reporting

Bases de Données

Fichiers

ERP/CRM

DW

Entrepôt de Données Serveur OLAP

Requête Analyse

Exploration

Structure d’un Système Décisionnel

Ø  Big Data s’impose pour les technologies touchant à l’analytique

Ø  « La BI traditionnelle est morte, vive la Big BI! »

Ø  Données peu structurées, de plus en plus nombreuses et diversifiées (Variété)

o  Impossible d’exploiter cette volumétrie de données avec les techniques de BI traditionnelle

o  Risque d’obtenir des infrastructures très complexes

Ø  Données doit être traitées à chaud (Vélocité)

o  Opération d’ETL en BI se fait périodiquement, dans des moments où le système opérationnel est au repos

o  Impossible de rafraîchir les tableaux de bord d’aide à la décision plus qu’une fois par jour, ce qui est maintenant requis pour certains métiers (e-commerçants, par ex.)

o  Outils décisionnels sont, certes, robustes, mais paraissent trop figés pour les besoins actuels

Ø  Données publiques

10 BI Traditionnelle, morte?

Ø  D’après [Roe-2012], il existe 6 approches pour combiner NOSQL avec BI

o  Approche 1: Rapports NOSQL

ü  Payer un développeur pour construire des applications de reporting sur les systèmes NOSQL

ü  Profite des avantages de NOSQL, mais coûteuse car besoin d’un développeur spécialisé

ü  Pas besoin d’outils BI, a seulement une seule source de données

o  Approche 2: Rapports NOSQL configurables

ü  Plus flexible que l’approche 1, car offre à l’utilisateur la possibilité de configurer son propre rapport

ü  Systèmes plus ad-hoc, mais plus coûteux que l’approche 1

ü  Problème d’intégration avec les autres données SQL-centric

11 Approches d’Intégration: NOSQL/BIG Data avec SQL/BI (1/2)

Application Reporting NOSQL

Application Reporting Avancée

Config

+

o  Approche 3: NOSQL + MySQL

ü  Développement d’une application ETL pour transporter les données d’une base NOSQL vers la base MySQL, utilisée par les outils de BI riches comme Pentaho et Jasper.

ü  Moins coûteuse que 1 et 2, car pas besoin de développeur pour un outil de reporting spécifique

ü  Mais, manque de fraîcheur de données, perte de la richesse offerte par NOSQL

o  Approche 4: NOSQL comme source de données ETL

ü  Données extraites à partir des bases NOSQL et systèmes Big Data, et intégrées avec les autres données de l’entreprise dans l’entrepôt

ü  Première architecture permettant d’intégrer les données

ü  Perte de l’expressivité de NOSQL pendant la phase ETL

12 Approches d’Intégration: NOSQL/BIG Data avec SQL/BI (1/2)

Outil BI ETL

ETL

ERP

Outil BI

Entrepôt

o  Approche 5 : Programmes NOSQL dans les outils BI

ü  Développement d’un programme pour l’outil BI qui le connecte à la base NOSQL

ü  Pas besoin de définir les rapports un à un comme dans Approche 1, mais étaler les données NOSQL pour les rendre compréhensibles par l’outil de reporting

o  Approche 6 : Système d’intégration

ü  Ajout d’un système tiers EII (Enterprise Information Integration) entre l’outil BI et le système NOSQL/BigData, qui agit comme intermédiaire

ü  Peut discuter avec les deux parties, traduit les données en modèles utilisables par l’outil BI

13 Approches d’Intégration: NOSQL/BIG Data avec SQL/BI (2/2)

Outil BI

Outil BI EII

Ø  Avantages du NOSQL

o  Stockage efficace et évolutif

o  La possibilité de toujours stocker plus de données

o  Coûts réduits des outils

o  Outils analytiques plus riches: utilisation de l’analyse de graphes, des frameworks Map-Reduce… au lieu du filtrage classique et « group by » de SQL

o  Structures de données flexibles tolérance aux fautes

Ø  Mais

o  NOSQL n’est pas « propre », car la structure est évolutive, donc facilement modifiable, alors la BI cherche avant tout à rendre les différentes sources de données (en général des bases de production plutôt anarchiques) structurées, solides et faites pour durer

o  NOSQL surtout pratique pour les analyses ponctuelles

14 Entrepôts de données NOSQL?

Ø  On pourra utiliser NOSQL comme entrepôt de données, pour profiter de : o  Sa capacité de stockage

o  Son évolutivité

o  Sa tolérance aux fautes

o  Sa rapidité d’insertion

o  Peut-être même de la flexibilité de sa structure dans le cas d’un besoin d’évolution de l’entrepôt.

Ø  Mais: o  On ne pourra pas (trop) bénéficier de la diversité des formats de données supportées

o  L’utilisateur sera pénalisé par les restrictions de requêtage des bases NOSQL, et leur manque de flexibilité et de consistance.

Ø  Les Bases orientées colonnes pourraient s’avérer être les plus appropriées pour un entrepôt de données, car: o  Elles définissent un schéma clair

o  Elles supportent de très grands volumes de données,

o  Elles sont très rapides en terme d’écriture par rapport aux autres

15 Entrepôts de données NOSQL?

Ø  Présentations

o  Venu Anuganti, « SQL, NOSQL and Big Data in Architecture », 2012

Ø  Sites

o  MongoDB, BigData Explained,  http://www.mongodb.com/big-data-explained

Ø  Articles

o  Romain Chaumais, “Le Big Data ou la mort annoncée de la BI traditionnelles”, http://technologies.lesechos.fr/business-intelligence/le-big-data-ou-la-mort-annoncee-de-la-bi-traditionnelle-_a-41-681.html , juin 2013

o  Charles Roe, « BI/Analytics on NoSQL: Review of architectures », http://www.dataversity.net/bianalytics-on-nosql-review-of-architectures-part-1/ Février 2012

16 Sources