VISION GLOBALE SUR LES NOTIONS DE BIG DATA, BI ET NOSQL

1. Chp5 – ”Putting it All Together"
Big Data, BI, NOSQL
Big Data
GL4 (Option Management des Systèmes d'Information) - 2016
Dr. Lilia SFAXI
www.liliasfaxi.wix.com/liliasfaxi
Slide 1

2. Big Data, BI, NOSQL
• 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
§ 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
§ 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:
§ Sources, types et croissance des données
§ Consommation des données
o Utilisateur final, API, outils de reporting, interne…
§ SLA (Service Level Agreement), temps de réponse,
§ Coût
§ Penser à faire évoluer l’architecture avec la croissance de votre entreprise, ne
pas penser trop gros depuis le jour 1
2
Que choisir?

3. Big Data, BI, NOSQL
• SQL:
§ Relationnel et transactionnel
• NOSQL
§ Non-relationnel, distribué, haute performance, et hautement évolutif
• Analytiques et Business Intelligence
§ Entrepôt de données centralisé et unique, analyses métier, reporting
• Big Data, Hadoop et MapReduce
§ Distribué, hautement évolutif, tolérance aux fautes et traitement des
données parallèle
• Combinaison des quatre:
§ Commencer avec SQL et/ou NOSQL, et envisager ensuite BigData/Analytiques
3
D’abord, comprendre les objectifs des différentes technologies…

4. Big Data, BI, NOSQL
• Choix entre deux classes de technologie :
§ 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
§ 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
§ Satisfaire des requêtes concurrentes
§ Exhiber une latence faible (temps de réponse très rapide)
• Systèmes analytiques : Entrepôts de données et MapReduce
§ Se concentrent sur un grand débit
§ 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!

5. BIG DATA & NOSQL
Chp5: Putting it all together
5

6. Big Data & NOSQL
• HDFS représente l’un des atouts majeurs de Hadoop car:
§ Distribué, en cluster
§ Facilement extensible
§ Offre une haute disponibilité
• Mais, il offre certains désavantages:
§ Utilise un système de stockage direct (DAS: Direct Attached Storage), pas
de SAN (Storage Area Network)
§ Problème de disponibilité pour les utilisateurs des anciennes versions de
Hadoop, où le NameNode n’est pas dupliqué
§ 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

7. Big Data & 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
§ Profiter des capacités de stockage des bases NOSQL
§ Profiter de la tolérance aux pannes pour éviter la perte de données
§ Extraction facile des données, plus facile qu’une manipulation d’un fichier textuel
§ Moins de risques de données erronées ou non conformes
• Les résultats obtenus pourront être stockés:
§ Dans un fichier texte, excel…
§ Dans une base NOSQL, pour profiter de la capacité de stockage
§ Dans une base SQL pour faciliter le reporting
7
Utiliser le MapReduce pour interroger les bases NOSQL

8. BIG DATA & BUSINESS INTELLIGENCE
Chp5: Putting it all together
8

9. 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
Structured’un SystèmeDécisionnel

10. Big Data & BI
• 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é)
§ Impossible d’exploiter cette volumétrie de données avec les techniques de BI
traditionnelle
§ Risque d’obtenir des infrastructures très complexes
• Données doit être traitées à chaud (Vélocité)
§ Opération d’ETL en BI se fait périodiquement, dans des moments où le système
opérationnel est au repos
§ 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.)
§ Outils décisionnels sont, certes, robustes, mais paraissent trop figés pour les
besoins actuels
• Données publiques
10
BI Traditionnelle, morte?

11. Approches d’Intégration
• D’après [Roe-2012], il existe 6 approches pour
combiner NOSQL avec BI
• 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
• 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
NOSQL/BIG Data avec SQL/BI (1/3)
Application
Reporting NOSQL
Application Reporting
Avancée
Config
+

12. Approches d’Intégration
• 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
• 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
NOSQL/BIG Data avec SQL/BI (2/3)
Outil BI
ETL
ETL
ERP
Outil BI
Entrepôt

13. Approches d’Intégration
• 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
• 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
NOSQL/BIG Data avec SQL/BI (3/3)
Outil BI
Outil BI
EII

14. BI & NOSQL
• Avantages du NOSQL
§ Stockage efficace et évolutif
§ La possibilité de toujours stocker plus de données
§ Coûts réduits des outils
§ Outils analytiques plus riches: utilisation de l’analyse de graphes, des
frameworks Map-Reduce… au lieu du filtrage classique et « group by » de
SQL
§ Structures de données flexibles tolérance aux fautes
• Mais
§ 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
§ NOSQL surtout pratique pour les analyses ponctuelles
14
Entrepôts de données NOSQL?

15. BI & NOSQL
• On pourra utiliser NOSQL comme entrepôt de données, pour profiter de :
§ Sa capacité de stockage
§ Son évolutivité
§ Sa tolérance aux fautes
§ Sa rapidité d’insertion
§ Peut-être même de la flexibilité de sa structure dans le cas d’un besoin
d’évolution de l’entrepôt.
• Mais:
§ On ne pourra pas (trop) bénéficier de la diversité des formats de données
supportées
§ 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:
§ Elles définissent un schéma clair
§ Elles supportent de très grands volumes de données,
§ Elles sont très rapides en terme d’écriture par rapport aux autres
15
Entrepôts de données NOSQL?

16. • Présentations
§ Venu Anuganti, « SQL, NOSQL and Big Data in Architecture », 2012
• Sites
§ MongoDB, BigData Explained, http://www.mongodb.com/big-data-explained
• Articles
§ 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
§ 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