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
Top Related