Vidéo: How to Build and Install Hadoop on Windows 2024
Le coût peu élevé du stockage pour Hadoop et la possibilité d'interroger les données Hadoop avec SQL font d'Hadoop la destination principale des données d'archivage. Ce cas d'utilisation a un faible impact sur votre organisation car vous pouvez commencer à développer votre ensemble de compétences Hadoop sur des données qui ne sont pas stockées sur des systèmes critiques en termes de performances.
De plus, vous n'avez pas à travailler dur pour obtenir les données. (Étant donné que les données archivées sont normalement stockées sur des systèmes peu utilisés, il est plus facile d'obtenir des informations que sur des systèmes critiques, tels que les entrepôts de données.) Si vous utilisez déjà Hadoop comme landing zone, vous avez la base de vos archives! Vous gardez simplement ce que vous voulez archiver et effacez ce que vous ne voulez pas.
Si vous pensez à la zone d'atterrissage de Hadoop, l'archive interrogeable, illustrée dans la figure, étend la valeur de Hadoop et commence à intégrer des pièces qui existent probablement déjà dans votre entreprise. C'est un excellent exemple de la recherche d'économies d'échelle et d'opportunités de prise de coûts grâce à Hadoop.
Ici, le composant d'archive connecte la zone d'atterrissage et l'entrepôt de données. Les données archivées proviennent de l'entrepôt et sont ensuite stockées dans le cluster Hadoop, qui provisionne également la zone d'atterrissage. En bref, vous pouvez utiliser le même cluster Hadoop pour archiver des données et agir en tant que zone d'atterrissage.
La technologie Hadoop clé que vous utiliseriez pour effectuer l'archivage est Sqoop, qui peut déplacer les données à archiver depuis l'entrepôt de données vers Hadoop. Vous devrez examiner la forme que vous souhaitez prendre pour les données dans votre cluster Hadoop. En général, les fichiers Hive compressés sont un bon choix.
Vous pouvez, bien sûr, transformer les données des structures d'entrepôt en une autre forme (par exemple, une forme normalisée pour réduire la redondance), mais ce n'est généralement pas une bonne idée. Si vous gardez les données dans la même structure que celle de l'entrepôt, il sera beaucoup plus facile d'exécuter une requête de jeu de données complète sur les données archivées dans Hadoop et les données actives dans l'entrepôt.
Le concept d'interrogation des ensembles de données actifs et archivés soulève une autre question: combien de données devriez-vous archiver? Il y a vraiment deux choix communs: archiver tout lorsque les données sont ajoutées et modifiées dans l'entrepôt de données, ou seulement archiver les données que vous jugez froides.
L'archivage a pour avantage de vous permettre d'émettre facilement des requêtes à partir d'une interface unique sur l'ensemble du fichier. Sans une archive complète, vous devez trouver une solution de requête fédérée dans laquelle vous devez fusionner les résultats. l'archive et l'entrepôt de données actif.
Mais l'inconvénient ici est que les mises à jour régulières des données chaudes de votre entrepôt de données causeraient des maux de tête pour l'archive basée sur Hadoop. En effet, toute modification des données dans des lignes et des colonnes individuelles nécessiterait une suppression et un reclassement en masse des ensembles de données existants.
Maintenant que les données d'archives sont stockées dans votre zone d'atterrissage basée sur Hadoop (en supposant que vous utilisez une option comme les fichiers Hive compressés mentionnés précédemment), vous pouvez l'interroger. C'est là que les solutions SQL sur Hadoop peuvent devenir intéressantes.
Un excellent exemple de ce qui est possible est que les outils d'analyse (à droite sur la figure) permettent d'exécuter directement des rapports ou des analyses sur les données archivées stockées dans Hadoop. Cela ne veut pas remplacer l'entrepôt de données - après tout, Hadoop ne serait pas capable de faire correspondre les caractéristiques de performance de l'entrepôt pour supporter des centaines d'utilisateurs simultanés ou plus qui posent des questions complexes.
Le point ici est que vous pouvez utiliser des outils de reporting contre Hadoop pour expérimenter et trouver de nouvelles questions à répondre dans un entrepôt ou un magasin dédié.
Lorsque vous démarrez votre premier projet basé sur Hadoop pour l'archivage des données d'entrepôt, ne cassez pas les processus en cours avant de les avoir entièrement testés sur votre nouvelle solution Hadoop. En d'autres termes, si votre stratégie d'entreposage actuelle consiste à archiver sur bande, maintenez ce processus en place et archivez les données dans Hadoop et sur bande jusqu'à ce que vous ayez entièrement testé le scénario (ce qui inclut généralement la restauration des données de l'entrepôt). d'un échec d'entrepôt).
Bien que vous conserviez (à court terme) deux référentiels d'archives, vous disposerez d'une infrastructure robuste et testée avant de mettre hors service un processus éprouvé. Ce processus peut vous assurer que vous restez employé - avec votre employeur actuel.
Ce cas d'utilisation est simple car il n'y a aucun changement dans l'entrepôt existant. L'objectif métier reste le même: des coûts de stockage et de licence moins élevés en migrant des données rarement utilisées vers une archive. La différence dans ce cas est que la technologie derrière l'archive est Hadoop plutôt que le stockage hors ligne, comme la bande.
De plus, divers fournisseurs d'archives ont commencé à incorporer Hadoop dans leurs solutions (par exemple, en permettant à leurs fichiers d'archives propriétaires de résider sur HDFS), alors attendez-vous à ce que les fonctionnalités dans ce domaine se développent rapidement.
Au fur et à mesure que vous développez des compétences Hadoop (comme l'échange de données entre Hadoop et des bases de données relationnelles et l'interrogation de données dans HDFS), vous pouvez les utiliser pour résoudre des problèmes plus importants tels que les projets d'analyse.
