Cette architecture de référence décrit les avantages liés à l'utilisation d'Apache Hive dans Dataproc de manière efficace et flexible en stockant des données Hive dans Cloud Storage et en hébergeant le métastore Hive dans une base de données MySQL dans Cloud SQL.
Ce document est destiné aux architectes de cloud et aux ingénieurs de données qui souhaitent déployer Apache Hive sur Dataproc et le métastore Hive dans Cloud SQL.
Architecture
Le schéma suivant illustre le cycle de vie d'une requête Hive.
Dans le schéma, le cycle de vie d'une requête Hive suit les étapes suivantes:
- Le client Hive envoie une requête à un serveur Hive exécuté dans un cluster Dataproc éphémère.
- Le serveur Hive traite la requête et demande des métadonnées au service de métastore.
- Le service Metastore récupère les métadonnées Hive depuis Cloud SQL via le proxy Cloud SQL.
- Le serveur Hive charge les données depuis l'entrepôt Hive situé dans un bucket régional dans Cloud Storage.
- Le serveur Hive renvoie le résultat au client.
Alternatives de conception
La section suivante présente une alternative potentielle à la conception de cette architecture.
Architecture multirégionale
Pensez à utiliser une architecture multirégionale si vous devez exécuter des serveurs Hive dans différentes régions géographiques. Dans ce cas, vous devez créer des clusters Dataproc distincts dédiés à l'hébergement du service de métastore et résidant dans la même région que l'instance Cloud SQL.
Le service de métastore peut parfois envoyer de gros volumes de requêtes à la base de données MySQL. Il est donc essentiel de maintenir le service de métastore à proximité géographique de la base de données MySQL afin de minimiser tout impact sur les performances. Par comparaison, le serveur Hive envoie généralement beaucoup moins de requêtes au service de métastore. Par conséquent, le serveur Hive et le service de métastore peuvent avoir intérêt à résider dans différentes régions malgré la latence accrue.
Le service de métastore ne peut être exécuté que sur les nœuds maîtres Dataproc et non sur les nœuds de calcul. Dataproc applique un minimum de deux nœuds de calcul dans les clusters standards et à haute disponibilité.
Pour éviter de gaspiller des ressources sur des nœuds de calcul inutilisés, vous pouvez créer un cluster à un seul nœud pour le service de métastore. Pour atteindre une haute disponibilité, vous pouvez créer plusieurs clusters à un seul nœud.
Le proxy Cloud SQL doit être installé uniquement sur les clusters du service de métastore, qui sont les seuls à avoir besoin d'une connexion directe à l'instance Cloud SQL. Les serveurs Hive pointent ensuite vers les clusters de service de métastore en définissant la propriété hive.metastore.uris sur la liste des URI séparés par une virgule. Exemple :
thrift://metastore1:9083,thrift://metastore2:9083
Vous pouvez également envisager d'utiliser un bucket birégional ou multirégional si les données Hive doivent être accessibles à partir de serveurs Hive situés à divers emplacements. Le choix entre différents types d'emplacements de bucket dépend de votre cas d'utilisation. Vous devez équilibrer la latence, la disponibilité et les coûts.
Le schéma suivant montre un exemple d'architecture multirégionale.
Comme vous pouvez le constater, le scénario multirégional est légèrement plus complexe et beaucoup plus robuste. Le guide de déploiement pour cette architecture de référence utilise un scénario dans une seule région.
Avantages d'une architecture multirégionale
La séparation des ressources de calcul et de stockage présente certains avantages :
- Flexibilité et agilité : vous pouvez personnaliser les configurations de cluster pour des charges de travail Hive spécifiques et procéder au scaling de chaque cluster indépendamment, vers le haut ou le bas.
- Économies de coûts : vous pouvez créer un cluster éphémère lorsque vous devez exécuter une tâche Hive, puis le supprimer une fois la tâche terminée. Les ressources nécessaires à vos tâches ne sont actives que lorsqu'elles sont utilisées. Vous ne payez donc que ce que vous utilisez. Vous pouvez également utiliser des VM préemptives pour le traitement de données non critiques ou pour créer de très grands clusters pour un coût total plus faible.
- Résilience : pour des raisons de simplicité, cette architecture de référence n'utilise qu'une seule instance maître. Pour augmenter la résilience des charges de travail de production, envisagez de créer un cluster doté de trois instances maîtres en employant le mode haute disponibilité de Dataproc.
Optimisation des coûts
Cette architecture de référence et son déploiement utilisent les composants facturables suivants de Google Cloud :
- Dataproc
- Cloud Storage
- Cloud SQL
Vous pouvez utiliser le Simulateur de coût pour générer une estimation du coût en fonction de votre utilisation prévue.
Les nouveaux utilisateurs de Google Cloud peuvent bénéficier d'un essai gratuit.
Déploiement
Pour déployer cette architecture, consultez la page Déployer Apache Hive sur Dataproc.
Étapes suivantes
- Essayez BigQuery, l'entrepôt de données d'entreprise à faible coût, extrêmement évolutif et sans serveur de Google.
- Consultez ce guide sur la migration des charges de travail Hadoop vers Google Cloud.
- Découvrez cette action d'initialisation pour plus de détails sur l'utilisation de Hive HCatalog sur Dataproc.
- Découvrez comment configurer la haute disponibilité de Cloud SQL afin d'accroître la fiabilité du service.
- Pour découvrir d'autres architectures de référence, schémas et bonnes pratiques, consultez le Centre d'architecture cloud.