Hadoop comme une archive interrogeable des données de l'entrepôt froid

Une multitude d'études montrent que la plupart des données dans un entrepôt de données d'entreprise est rarement interrogés. Les fournisseurs de base de données ont répondu à ces observations en mettant en œuvre leurs propres méthodes pour trier les données obtient placé où.

Une méthode ordonne l'univers de données en désignations de chaud, ou froid, où chaud données (parfois appelés actif données) est souvent utilisé, chaleureux données sont utilisées de temps en temps et froid des données est rarement utilisé. La solution proposée pour de nombreux fournisseurs est de stocker les données sur des disques plus lents froides dans les compartiments des entrepôts de données ou de créer des stratégies de mise en cache astucieux pour conserver les données chaudes en mémoire, entre autres.

Le problème avec cette approche est que, même si le stockage plus lent est utilisé, il est encore cher pour stocker des données rarement utilisées froides, dans un entrepôt. Les coûts ici vient à la fois du matériel et des licences de logiciels. Dans le même temps, les données froid et de dormance est souvent archivée sur bande.

Ce modèle traditionnel de données d'archivage décompose quand vous voulez interroger toutes les données froides d'une manière rentable et relativement efficace - sans avoir à demander de vieilles bandes, en d'autres termes.

Si vous regardez les caractéristiques financières et opérationnelles de Hadoop, il semble en effet qu'il est en passe de devenir 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 grade inférieur du matériel que ce qui est normalement déployé dans les systèmes d'entrepôt de données. Un autre d'importantes économies de coût est de licences de logiciels.

Licences de distribution Hadoop commerciales exigent une fraction du coût des licences de logiciels d'entreposage de données relationnelles, qui sont connus pour être cher. D'un point de vue opérationnel, Hadoop est conçu pour évoluer facilement simplement en ajoutant des nœuds esclaves supplémentaires à un cluster existant. Et comme nœuds esclaves sont ajoutés et des ensembles de données augmentent en volume, les cadres de traitement des données de Hadoop permettent à vos applications à gérer de façon transparente la charge de travail accrue.

Hadoop représente un moyen simple, flexible et peu coûteuse pour 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 de l'entrepôt. . . sauf pour une petite affaire: la plupart du monde, il fonctionne sur SQL et SQL sur son propre ne joue pas bien avec Hadoop.

Bien sûr, le mouvement NoSQL plus Hadoop-friendly est bel et bien vivant, mais la plupart des utilisateurs de puissance utilisent maintenant SQL par le biais de, boîtes à outils communs off-the-shelf qui génèrent des requêtes SQL sous le capot - produits tels que Tableau, Microsoft Excel, et IBM Cognos BI.

Il est vrai que l'écosystème Hadoop Hive comprend, mais Hive ne supporte qu'un sous-ensemble de SQL, et bien que la performance est améliorée (avec le soutien de SQL), il est loin d'être aussi rapide à répondre à des requêtes plus petites que les systèmes relationnels sont. Récemment, il ya eu des progrès majeurs autour de l'accès SQL à Hadoop, qui a ouvert la voie à Hadoop pour devenir la nouvelle destination pour les archives en ligne de l'entrepôt de données.

Selon le fournisseur Hadoop, SQL (ou SQL-like) API deviennent disponibles afin que les rapports et d'analyse des outils les plus courants hors-the-shelf peut parfaitement émettre SQL qui exécute sur les données stockées dans Hadoop. Par exemple, IBM a son Big API SQL, Cloudera Impala a, et la ruche elle-même, par l'intermédiaire de l'initiative Hortonworks Stinger, devient de plus en plus conforme SQL.

Bien que différents points de vue existent (certains visent à améliorer Hive- certains, d'étendre Hive- et d'autres, de fournir une alternative), toutes ces solutions tentent de s'attaquer à deux questions: MapReduce est une mauvaise solution pour exécuter des requêtes plus petites, et l'accès SQL est - pour l'instant - la clé pour permettre aux travailleurs de TI d'utiliser leurs compétences SQL existantes pour obtenir la valeur sur des données stockées dans Hadoop.