BigData_Chp5: Putting it all together
7 j'aime31,641 vues
Le document examine les différentes approches de gestion des données à grande échelle, notamment l'utilisation de SQL et NoSQL pour répondre aux besoins opérationnels et analytiques des entreprises. Il met en lumière l'importance de choisir la technologie en fonction des spécificités métier et de la nature des données, tout en considérant l'évolution des besoins. En outre, il discute des méthodes d'intégration entre NoSQL et les outils de business intelligence pour tirer parti des avantages de chaque système.
![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
+](https://image.slidesharecdn.com/chp5-puttingitalltogether-160826092933/85/BigData_Chp5-Putting-it-all-together-11-320.jpg)
BigData_Chp5: Putting it all together
- 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