Vidéo: Introduction to Amazon Web Services by Leo Zhadanovsky 2025
Une multitude d'études montrent que la plupart des données d'un entrepôt de données d'entreprise sont rarement interrogées. Les fournisseurs de bases de données ont réagi à ces observations en mettant en œuvre leurs propres méthodes de tri des données.
Une méthode ordonne l'univers des données en désignations de données chaudes, chaudes ou froides, avec des données chaudes (parfois appelé données ) est souvent utilisé, données sont utilisées de temps en temps et les données données sont rarement utilisées. pour stocker les données froides sur les disques plus lents dans les boîtiers d'entrepôt de données ou pour créer des stratégies de mise en cache intelligentes pour conserver les données chaudes en mémoire, entre autres.
Le problème avec cette approche Même si le stockage est plus lent, il est toujours coûteux de stocker des données froides et rarement utilisées dans un entrepôt. licence de matériel et de logiciel. Dans le même temps, les données froides et dormantes sont souvent archivées sur bande.
Ce modèle traditionnel de données d'archivage se décompose lorsque vous souhaitez interroger toutes les données froides d'une manière rentable et relativement efficace - sans avoir à demander d'anciennes bandes, en d'autres termes.
Si vous regardez le coût et les caractéristiques opérationnelles de Hadoop, il semble en effet qu'il s'agisse de la nouvelle bande de sauvegarde. Hadoop est peu coûteux, en grande partie parce que les systèmes Hadoop sont conçus pour utiliser un matériel de qualité inférieure à ce qui est normalement déployé dans les systèmes d'entrepôt de données. Une autre économie significative est la licence de logiciel.
Les licences commerciales Hadoop nécessitent une fraction du coût des licences logicielles d'entrepôt de données relationnelles, qui sont réputées coûteuses. D'un point de vue opérationnel, Hadoop est conçu pour évoluer facilement en ajoutant des nœuds esclaves supplémentaires à un cluster existant. Et comme les noeuds esclaves sont ajoutés et que les ensembles de données augmentent en volume, les frameworks de traitement des données de Hadoop permettent à vos applications de gérer de manière transparente l'augmentation de la charge de travail.
Hadoop représente une manière simple, flexible et peu coûteuse de pousser le traitement sur des milliers de serveurs.
Avec son architecture évolutive et peu coûteuse, Hadoop semble être un choix parfait pour l'archivage des données d'entrepôt … sauf pour un petit détail: la plupart du monde informatique fonctionne sur SQL, et SQL seul ne fonctionne pas bien avec Hadoop.
Bien sûr, plus le mouvement NoSQL de Hadoop est actif, mais la plupart des utilisateurs avancés utilisent maintenant SQL au moyen d'outils communs, qui génèrent des requêtes SQL sous le capot - des produits tels que Tableau, Microsoft Excel et IBM Cognos BI.
Il est vrai que l'écosystème Hadoop inclut Hive, mais Hive ne prend en charge qu'un sous-ensemble de SQL, et bien que les performances s'améliorent (avec la prise en charge SQL), il n'est pas aussi rapide que les systèmes relationnels. Récemment, des progrès importants ont été réalisés en matière d'accès SQL à Hadoop, ce qui a permis à Hadoop de devenir la nouvelle destination des archives d'entrepôt de données en ligne.
En fonction du fournisseur Hadoop, des API SQL (ou SQL) deviennent disponibles pour que les outils de reporting et d'analyse les plus courants puissent émettre de manière transparente du code SQL s'exécutant sur des données stockées dans Hadoop. Par exemple, IBM a son API Big SQL, Cloudera a Impala et Hive elle-même, via l'initiative Hortonworks Stinger, devient de plus en plus conforme à SQL.
Bien que différents points de vue existent (certains visent à améliorer Hive, d'autres à étendre Hive et d'autres à fournir une alternative), toutes ces solutions tentent de résoudre deux problèmes: MapReduce est une mauvaise solution pour exécuter des requêtes plus petites, et l'accès SQL est - pour l'instant - la clé permettant aux informaticiens d'utiliser leurs compétences SQL existantes pour tirer parti des données stockées dans Hadoop.
