Ce tutoriel vous explique comment utiliser Apache Hive sur 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 sur Cloud SQL. Cette séparation entre les 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.
Hive est un système de stockage de données Open Source populaire basé sur Apache Hadoop. Hive propose un langage de requête semblable à SQL appelé HiveQL, utilisé pour analyser de grands ensembles de données structurés. Le métastore Hive contient des métadonnées sur les tables Hive, telles que leur schéma et leur emplacement. Alors que MySQL est couramment utilisé comme backend pour le métastore Hive, Cloud SQL facilite la configuration, la maintenance, la gestion et l'administration de vos bases de données relationnelles sur Google Cloud.
Objectifs
- Créer une instance MySQL sur Cloud SQL pour le métastore Hive
- Déployer des serveurs Hive sur Dataproc
- Installer le proxy Cloud SQL sur les instances de cluster Dataproc.
- Importer des données Hive vers Cloud Storage
- Exécuter des requêtes Hive sur plusieurs clusters Dataproc
Coûts
Ce tutoriel utilise 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.
Avant de commencer
Créer un projet
-
In the Google Cloud console, go to the project selector page.
-
Select or create a Google Cloud project.
Activer la facturation
Initialiser l'environnement
Démarrez une instance Cloud Shell :
Dans Cloud Shell, définissez la zone Compute Engine par défaut sur la zone dans laquelle vous allez créer vos clusters Dataproc.
export PROJECT=$(gcloud info --format='value(config.project)') export REGION=REGION export ZONE=ZONE gcloud config set compute/zone ${ZONE}Remplacez les éléments suivants :
REGION: région dans laquelle vous souhaitez créer le cluster, telle queus-central1.ZONE: zone dans laquelle vous souhaitez créer le cluster, telle queus-central1-a.
Activez les API Dataproc et Cloud SQL Admin en exécutant la commande suivante dans Cloud Shell :
gcloud services enable dataproc.googleapis.com sqladmin.googleapis.com
Architecture de référence
Pour des raisons de simplicité, dans ce tutoriel, vous déployez tous les services de calcul et de stockage dans la même région Google Cloud afin de minimiser la latence et les coûts de transport du réseau. La figure 1 présente l'architecture de ce tutoriel.
Avec cette architecture, le cycle de vie d'une requête Hive suit les étapes ci-dessous :
- Le client Hive envoie une requête à un serveur Hive exécuté dans un cluster Dataproc éphémère.
- Le serveur traite la requête et demande des métadonnées au service de métastore.
- Le service de métastore récupère les métadonnées Hive depuis Cloud SQL via le proxy Cloud SQL.
- Le serveur charge les données depuis l'entrepôt Hive situé dans un bucket régional dans Cloud Storage.
- Le serveur renvoie le résultat au client.
Considérations relatives aux architectures multirégionales
Ce tutoriel est axé sur une architecture à région unique. Toutefois, vous pouvez envisager 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.
La figure 2 présente un exemple d'architecture multirégionale.
Comme vous pouvez le constater, le scénario multirégional est légèrement plus complexe. Par souci de concision, ce tutoriel utilise une architecture à région unique.
(Facultatif) Créer le bucket d'entrepôt
Si vous n'avez pas de bucket Cloud Storage pour stocker des données Hive, créez un bucket d'entrepôt (vous pouvez exécuter les commandes suivantes dans Cloud Shell) en remplaçant BUCKET_NAME par un nom de bucket unique :
export WAREHOUSE_BUCKET=BUCKET_NAME
gsutil mb -l ${REGION} gs://${WAREHOUSE_BUCKET}
Créer l'instance Cloud SQL
Dans cette section, vous allez créer une nouvelle instance Cloud SQL qui sera ultérieurement utilisée pour héberger le métastore Hive.
Dans Cloud Shell, créez une instance Cloud SQL :
gcloud sql instances create hive-metastore \
--database-version="MYSQL_5_7" \
--activation-policy=ALWAYS \
--zone ${ZONE}L'exécution de cette commande peut prendre quelques minutes.
Création d'un cluster Dataproc
Créez le premier cluster Dataproc, en remplaçant CLUSTER_NAME par un nom tel que hive-cluster :
gcloud dataproc clusters create CLUSTER_NAME \
--scopes sql-admin \
--region ${REGION} \
--initialization-actions gs://goog-dataproc-initialization-actions-${REGION}/cloud-sql-proxy/cloud-sql-proxy.sh \
--properties "hive:hive.metastore.warehouse.dir=gs://${WAREHOUSE_BUCKET}/datasets" \
--metadata "hive-metastore-instance=${PROJECT}:${REGION}:hive-metastore" \
--metadata "enable-cloud-sql-proxy-on-workers=false"Remarques :
- Vous devez fournir le champ d'application d'accès
sql-adminafin d'autoriser les instances du cluster à accéder à l'API Cloud SQL Admin. - Vous placez l'action d'initialisation dans un script que vous stockez dans un bucket Cloud Storage, puis vous référencez ce bucket avec l'option
--initialization-actions. Pour en savoir plus, consultez la section Consignes et remarques importantes de la page Actions d'initialisation. - Vous devez fournir l'URI au bucket d'entrepôt Hive dans la propriété
hive:hive.metastore.warehouse.dir. Cela configure les serveurs Hive de sorte qu'ils puissent lire depuis l'emplacement correct et écrire à cet emplacement. Cette propriété doit contenir au moins un répertoire (par exemple,gs://my-bucket/my-directory). Hive ne fonctionnera pas correctement si cette propriété est définie sur un nom de bucket sans répertoire (par exemple,gs://my-bucket). - Vous devez spécifier
enable-cloud-sql-proxy-on-workers=falsepour vous assurer que le proxy Cloud SQL ne s'exécute que sur les nœuds maîtres, ce qui est suffisant pour que le service de métastore Hive fonctionne et évite une charge inutile sur Cloud SQL. Vous devez fournir l'action d'initialisation du proxy Cloud SQL que Dataproc exécute automatiquement sur toutes les instances de cluster. L'action a les effets suivants :
- Elle installe le proxy Cloud SQL.
- Elle établit une connexion sécurisée à l'instance Cloud SQL spécifiée dans le paramètre de métadonnées
hive-metastore-instance. - Elle crée l'utilisateur
hiveet la base de données du métastore Hive.
Vous pouvez consulter le code complet de l'action d'initialisation du proxy Cloud SQL sur GitHub.
Pour des raisons de simplicité, ce tutoriel utilise 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.
Ce tutoriel utilise une instance Cloud SQL avec une adresse IP publique. Si vous utilisez une instance dotée seulement d'une adresse IP privée, vous pouvez forcer le proxy à utiliser l'adresse IP privée en transmettant le paramètre
--metadata "use-cloud-sql-private-ip=true".
Créer une table Hive
Dans cette section, vous allez importer un exemple d'ensemble de données dans votre bucket d'entrepôt, créer une table Hive et exécuter des requêtes HiveQL sur cet ensemble de données.
Copiez l'exemple d'ensemble de données dans le bucket d'entrepôt :
gsutil cp gs://hive-solution/part-00000.parquet \ gs://${WAREHOUSE_BUCKET}/datasets/transactions/part-00000.parquetL'exemple d'ensemble de données est compressé au format Parquet et contient des milliers d'enregistrements de transactions bancaires fictifs avec trois colonnes : date, montant et type de transaction.
Créez une table Hive externe pour l'ensemble de données :
gcloud dataproc jobs submit hive \ --cluster CLUSTER_NAME \ --region ${REGION} \ --execute " CREATE EXTERNAL TABLE transactions (SubmissionDate DATE, TransactionAmount DOUBLE, TransactionType STRING) STORED AS PARQUET LOCATION 'gs://${WAREHOUSE_BUCKET}/datasets/transactions';"
Exécuter des requêtes Hive
Vous pouvez utiliser différents outils dans Dataproc pour exécuter des requêtes Hive. Dans cette section, vous allez apprendre à en envoyer à l'aide des outils suivants :
- API Hive Jobs de Dataproc
- Beeline, un client de ligne de commande populaire basé sur SQLLine
- SparkSQL, l'API d'Apache Spark pour l'interrogation de données structurées
Dans chaque section, vous allez exécuter un exemple de requête.
Interroger Hive avec l'API Jobs de Dataproc
Exécutez la requête HiveQL simple suivante pour vérifier que le fichier Parquet est correctement associé à la table Hive :
gcloud dataproc jobs submit hive \
--cluster CLUSTER_NAME \
--region ${REGION} \
--execute "
SELECT *
FROM transactions
LIMIT 10;"Le résultat comprend les éléments suivants :
+-----------------+--------------------+------------------+ | submissiondate | transactionamount | transactiontype | +-----------------+--------------------+------------------+ | 2017-12-03 | 1167.39 | debit | | 2017-09-23 | 2567.87 | debit | | 2017-12-22 | 1074.73 | credit | | 2018-01-21 | 5718.58 | debit | | 2017-10-21 | 333.26 | debit | | 2017-09-12 | 2439.62 | debit | | 2017-08-06 | 5885.08 | debit | | 2017-12-05 | 7353.92 | authorization | | 2017-09-12 | 4710.29 | authorization | | 2018-01-05 | 9115.27 | debit | +-----------------+--------------------+------------------+
Interroger Hive avec Beeline
Ouvrez une session SSH avec l'instance maître de Dataproc (
CLUSTER_NAME-m) :gcloud compute ssh CLUSTER_NAME-m
Dans l'invite de commande de l'instance maître, ouvrez une session Beeline :
beeline -u "jdbc:hive2://localhost:10000"
Remarques :
Vous pouvez également référencer le nom de l'instance maître en tant qu'hôte à la place de
localhost:beeline -u "jdbc:hive2://CLUSTER_NAME-m:10000"
Si vous utilisiez le mode haute disponibilité avec trois maîtres, vous devriez plutôt utiliser la commande suivante :
beeline -u "jdbc:hive2://CLUSTER_NAME-m-0:2181,CLUSTER_NAME-m-1:2181,CLUSTER_NAME-m-2:2181/;serviceDiscoveryMode=zooKeeper;zooKeeperNamespace=hiveserver2"
Lorsque l'invite Beeline apparaît, exécutez la requête HiveQL suivante :
SELECT TransactionType, AVG(TransactionAmount) AS AverageAmount FROM transactions WHERE SubmissionDate = '2017-12-22' GROUP BY TransactionType;
Le résultat comprend les éléments suivants :
+------------------+--------------------+ | transactiontype | averageamount | +------------------+--------------------+ | authorization | 4890.092525252529 | | credit | 4863.769269565219 | | debit | 4982.781458176331 | +------------------+--------------------+
Fermez la session Beeline :
!quit
Fermez la connexion SSH :
exit
Interroger Hive avec SparkSQL
Ouvrez une session SSH avec l'instance maître de Dataproc :
gcloud compute ssh CLUSTER_NAME-m
Dans l'invite de commande de l'instance maître, ouvrez une nouvelle session d'interface système PySpark :
pyspark
Lorsque l'invite d'interface système PySpark apparaît, saisissez le code Python suivant :
from pyspark.sql import HiveContext hc = HiveContext(sc) hc.sql(""" SELECT SubmissionDate, AVG(TransactionAmount) as AvgDebit FROM transactions WHERE TransactionType = 'debit' GROUP BY SubmissionDate HAVING SubmissionDate >= '2017-10-01' AND SubmissionDate < '2017-10-06' ORDER BY SubmissionDate """).show()Le résultat comprend les éléments suivants :
+-----------------+--------------------+ | submissiondate | avgdebit | +-----------------+--------------------+ | 2017-10-01 | 4963.114920399849 | | 2017-10-02 | 5021.493300510582 | | 2017-10-03 | 4982.382279569891 | | 2017-10-04 | 4873.302702503676 | | 2017-10-05 | 4967.696333583777 | +-----------------+--------------------+
Fermez la session PySpark :
exit()
Fermez la connexion SSH :
exit
Inspecter le métastore Hive
Vous allez maintenant vérifier que le métastore Hive dans Cloud SQL contient des informations sur la table transactions.
Dans Cloud Shell, démarrez une nouvelle session MySQL sur l'instance Cloud SQL :
gcloud sql connect hive-metastore --user=root
Lorsque vous êtes invité à saisir le mot de passe de l'utilisateur
root, ne tapez rien et appuyez simplement sur la toucheRETURN. Par souci de simplicité, vous n'avez défini aucun mot de passe pour l'utilisateurrootdans ce tutoriel. Pour plus d'informations sur la définition d'un mot de passe afin de mieux protéger la base de données métastore, reportez-vous à la documentation Cloud SQL. L'action d'initialisation du proxy Cloud SQL permet également de protéger les mots de passe grâce au chiffrement. Pour plus d'informations, consultez le dépôt de code de l'action.Dans l'invite de commande MySQL, faites de
hive_metastorela base de données par défaut pour le reste de la session :USE hive_metastore;
Vérifiez que l'emplacement du bucket d'entrepôt est enregistré dans le métastore :
SELECT DB_LOCATION_URI FROM DBS;
Le résultat est semblable à ce qui suit :
+-------------------------------------+ | DB_LOCATION_URI | +-------------------------------------+ | gs://[WAREHOUSE_BUCKET]/datasets | +-------------------------------------+
Vérifiez que la table est correctement référencée dans le métastore :
SELECT TBL_NAME, TBL_TYPE FROM TBLS;
Le résultat est semblable à ce qui suit :
+--------------+----------------+ | TBL_NAME | TBL_TYPE | +--------------+----------------+ | transactions | EXTERNAL_TABLE | +--------------+----------------+
Vérifiez que les colonnes de la table sont elles aussi correctement référencées :
SELECT COLUMN_NAME, TYPE_NAME FROM COLUMNS_V2 c, TBLS t WHERE c.CD_ID = t.SD_ID AND t.TBL_NAME = 'transactions';
Le résultat est semblable à ce qui suit :
+-------------------+-----------+ | COLUMN_NAME | TYPE_NAME | +-------------------+-----------+ | submissiondate | date | | transactionamount | double | | transactiontype | string | +-------------------+-----------+
Vérifiez que le format d'entrée et l'emplacement sont eux aussi correctement référencés :
SELECT INPUT_FORMAT, LOCATION FROM SDS s, TBLS t WHERE s.SD_ID = t.SD_ID AND t.TBL_NAME = 'transactions';
Le résultat est semblable à ce qui suit :
+---------------------------------------------------------------+------------------------------------------------+ | INPUT_FORMAT | LOCATION | +---------------------------------------------------------------+------------------------------------------------+ | org.apache.hadoop.hive.ql.io.parquet.MapredParquetInputFormat | gs://[WAREHOUSE_BUCKET]/datasets/transactions | +---------------------------------------------------------------+------------------------------------------------+
Fermez la session MySQL :
exit
Créer un autre cluster Dataproc
Dans cette section, vous allez créer un autre cluster Dataproc afin de vérifier que les données Hive et le métastore Hive peuvent être partagés entre plusieurs clusters.
Créez un cluster Dataproc :
gcloud dataproc clusters create other-CLUSTER_NAME \ --scopes cloud-platform \ --image-version 2.0 \ --region ${REGION} \ --initialization-actions gs://goog-dataproc-initialization-actions-${REGION}/cloud-sql-proxy/cloud-sql-proxy.sh \ --properties "hive:hive.metastore.warehouse.dir=gs://${WAREHOUSE_BUCKET}/datasets" \ --metadata "hive-metastore-instance=${PROJECT}:${REGION}:hive-metastore"\ --metadata "enable-cloud-sql-proxy-on-workers=false"Vérifiez que le nouveau cluster peut accéder aux données :
gcloud dataproc jobs submit hive \ --cluster other-CLUSTER_NAME \ --region ${REGION} \ --execute " SELECT TransactionType, COUNT(TransactionType) as Count FROM transactions WHERE SubmissionDate = '2017-08-22' GROUP BY TransactionType;"Le résultat comprend les éléments suivants :
+------------------+--------+ | transactiontype | count | +------------------+--------+ | authorization | 696 | | credit | 1722 | | debit | 2599 | +------------------+--------+
Félicitations, vous êtes arrivé à la fin de ce tutoriel !
Nettoyer
Pour éviter que les ressources utilisées lors de ce tutoriel soient facturées sur votre compte Google Cloud, supprimez le projet contenant les ressources, ou conservez le projet et supprimez les ressources individuelles.
Pour éviter que les ressources utilisées dans ce tutoriel soient facturées sur votre compte Google Cloud, procédez comme suit :
- Effectuez un nettoyage de toutes les ressources que vous avez créées pour qu'elles ne vous soient plus facturées à l'avenir. Le moyen le plus simple d'empêcher la facturation est de supprimer le projet que vous avez créé pour ce tutoriel.
- Vous pouvez également supprimer des ressources individuelles.
Supprimer le projet
- In the Google Cloud console, go to the Manage resources page.
- In the project list, select the project that you want to delete, and then click Delete.
- In the dialog, type the project ID, and then click Shut down to delete the project.
Supprimer des ressources individuelles
Exécutez les commandes suivantes dans Cloud Shell pour supprimer des ressources individuelles plutôt que le projet entier :
gcloud dataproc clusters delete CLUSTER_NAME --region ${REGION} --quiet
gcloud dataproc clusters delete other-CLUSTER_NAME --region ${REGION} --quiet
gcloud sql instances delete hive-metastore --quiet
gsutil rm -r gs://${WAREHOUSE_BUCKET}/datasetsÉ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.
- Découvrez des architectures de référence, des schémas et des bonnes pratiques concernant Google Cloud. Consultez notre Centre d'architecture cloud.