Chp5 – ”Putting it All Together"Big Data, BI, NOSQL

Big DataGL4 (Opt ion Management des Systèmes d'Information) - 2016

Dr. L i l ia SFAXIw w w.l i l iasfaxi .w ix.co m/ l i l iasfaxi

Sl id e 1

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• I l faut tout d’abord comprendre le métier:

§ Sources, types et cro issance des données§ Consommation des données

o Util isateur final , API , o uti ls de repo rting, interne…§ SLA (Service Level Agreement), temps de réponse, § Coût§ Penser à faire évoluer l’architecture avec la cro issance de votre entreprise, ne

pas penser trop gros depuis le jour 1

2

Que choisir?

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…

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 util isé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!

BIG DATA & NOSQLChp5: Putting it all together

5

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

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 faci le des données, plus faci le qu’une manipulation d’un fichier textue l§ Moins de r isques de données erronées ou non conformes

• Les résultats obtenus pourront être stockés: § Dans un fichier texte , exce l…§ Dans une base NOSQL, pour profiter de la capacité de stockage § Dans une base SQL pour faci l iter le reporting

7

Utiliser le MapReduce pour interroger les bases NOSQL

BIG DATA & BUSINESS INTELLIGENCEChp5: Putting it all together

8

9

Sources Statistiques

ExtractionTransformationChargement

AffichageReporting

BasesdeDonnées

Fichiers

ERP/CRM

DW

EntrepôtdeDonnées ServeurOLAP

RequêteAnalyse

Exploration

Structure d’un Système Décisionnel

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’explo iter 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

fo is 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 f igés pour les besoins actuels

• Données publiques

10

BI Traditionnelle, morte?

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éve loppeur pour construire des appl ications

de reporting sur les systèmes NOSQL§ Profite des avantages de NOSQL, mais coûteuse car

besoin d’un déve loppeur spécial isé§ Pas besoin d’outi ls BI , a seulement une seule source de

données

• Approche 2: Rapports NOSQL configurables§ Plus flexible que l ’approche 1 , car offre à l ’uti l isateur la

poss ibi l ité 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)

ApplicationReporting NOSQL

Application ReportingAvancée

Config

+

Approches d’Intégration

• Approche 3: NOSQL + MySQL§ Développement d ’une app l ication ETL pour

transporter les données d ’une base NOSQL vers la base MySQL, uti l isée par les outi ls de BI r i ches comme Pentaho et Jasper.

§ Moins coûteuse que 1 et 2, car pas besoin de développeur pour un outi l de reportingspéc i f ique

§ Mais, manque de fraîcheur de données, perte de la r ichesse offerte par NOSQL

• Approche 4: NOSQL comme source de données ETL§ Données extraites à part i r des bases NOSQL

et systèmes Big Data, et intégrées avec les autres données de l ’entrepr ise dans l ’entrepôt

§ Première arch itecture permettant d ’intégrer les données

§ Perte de l ’expressivi té de NOSQL pendant la phase ETL

12

NOSQL/BIG Data avec SQL/BI (2/3)

OutilBIETL

ETL

ERP

OutilBI

Entrepôt

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éf inir 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)

OutilBI

OutilBIEII

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, a lors 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 fa ites pour durer

§ NOSQL surtout pratique pour les analyses ponctuelles

14

Entrepôts de données NOSQL?

BI & NOSQL

• On pourra util iser NOSQL comme entrepôt de données, pour profiter de :§ Sa capacité de stockage§ Son évolutivité§ Sa to lérance aux fautes § Sa rapidité d’ insertion§ Peut-être même de la f lexibilité de sa structure dans le cas d’un besoin

d’évolution de l’entrepôt.• Mais:

§ On ne pourra pas (trop) bénéf ic ier 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 f lexibilité 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éf inissent un schéma c lair§ 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?

• 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