BigData_Chp5: Putting it all together

BigData_Chp5: Putting it all together

• 1.
  Chp5 – ”Puttingit 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’unSystè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 • Approche3: 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 • Approche5 : 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 § VenuAnuganti, « 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