Migrer des schémas et des données depuis Apache Hive

Ce document explique comment migrer vos données, vos paramètres de sécurité et vos pipelines depuis Apache Hive vers BigQuery.

Vous pouvez également utiliser la traduction SQL par lot pour migrer vos scripts SQL de façon groupée, ou la traduction SQL interactive pour traduire des requêtes ad hoc. Apache HiveQL est entièrement compatible avec les deux services de traduction SQL.

Préparer la migration

Les sections suivantes expliquent comment collecter des informations sur les statistiques des tables, les métadonnées et les paramètres de sécurité pour vous aider à migrer votre entrepôt de données de Hive vers BigQuery.

Collecter les informations des tables sources

Collectez des informations sur les tables Hive sources, telles que le nombre de lignes, le nombre de colonnes, les types de données de colonne, la taille, le format d'entrée des données et l'emplacement. Ces informations sont utiles dans le processus de migration ainsi que pour valider la migration des données. Si vous disposez d'une table Hive nommée employees dans une base de données nommée corp, utilisez les commandes suivantes pour collecter des informations sur la table :

# Find the number of rows in the table
hive> SELECT COUNT(*) FROM corp.employees;

# Output all the columns and their data types
hive> DESCRIBE corp.employees;

# Output the input format and location of the table
hive> SHOW CREATE TABLE corp.employees;
Output:
…
STORED AS INPUTFORMAT
  'org.apache.hadoop.hive.ql.io.avro.AvroContainerInputFormat'
OUTPUTFORMAT
  'org.apache.hadoop.hive.ql.io.avro.AvroContainerOutputFormat'
LOCATION
  'hdfs://demo_cluster/user/hive/warehouse/corp/employees'
TBLPROPERTIES (
…

# Get the total size of the table data in bytes
shell> hdfs dfs -du -s TABLE_LOCATION

Conversion de format des tables sources

Certains des formats compatibles avec Hive ne peuvent pas être ingérés directement dans BigQuery.

Hive accepte le stockage des données aux formats suivants :

Fichier texte
Fichier RC
Fichier de séquences
Fichier Avro
Fichier ORC
Fichier Parquet

BigQuery permet de charger des données à partir de Cloud Storage dans les formats de fichiers suivants :

CSV
JSON (délimité par un retour à la ligne)
Avro
ORC
Parquet

BigQuery peut charger des fichiers de données aux formats Avro, ORC et Parquet directement sans qu'il soit nécessaire d'utiliser des fichiers de schéma. Pour les fichiers texte qui ne sont pas au format CSV ou JSON (délimité par un retour à la ligne), vous pouvez copier les données dans une table Hive au format Avro ou convertir le schéma de la table en un schéma JSON BigQuery à fournir lors de l'ingestion.

Collecter les paramètres de contrôle des accès Hive

Hive et BigQuery ont des mécanismes de contrôle des accès différents. Collectez tous les paramètres de contrôle des accès Hive, tels que les rôles, les groupes, les membres et les droits qui leur sont accordés. Mappez un modèle de sécurité dans BigQuery au niveau de chaque ensemble de données et mettez en œuvre une LCA précise. Par exemple, un utilisateur Hive peut être mappé à un compte Google et un groupe HDFS peut être mappé à un groupe Google. L'accès peut être défini au niveau de l'ensemble de données. Utilisez les commandes suivantes pour collecter les paramètres de contrôle des accès dans Hive :

# List all the users
> hdfs dfs -ls /user/ | cut -d/ -f3

# Show all the groups that a specific user belongs to
> hdfs groups user_name

# List all the roles
hive> SHOW ROLES;

# Show all the roles assigned to a specific group
hive> SHOW ROLE GRANT GROUP group_name

# Show all the grants for a specific role
hive> SHOW GRANT ROLE role_name;

# Show all the grants for a specific role on a specific object
hive> SHOW GRANT ROLE role_name on object_type object_name;

Dans Hive, vous pouvez accéder directement aux fichiers HDFS derrière les tables si vous disposez des autorisations requises. Dans les tables BigQuery standards, les données sont chargées dans l'espace de stockage BigQuery une fois les données chargées dans la table. Vous pouvez lire des données à l'aide de l'API BigQuery Storage Read, mais toute la sécurité IAM et au niveau des lignes et des colonnes reste appliquée. Si vous utilisez des tables externes BigQuery pour interroger les données dans Cloud Storage, l'accès à Cloud Storage est également contrôlé par IAM.

Vous pouvez créer une table BigLake permettant d'utiliser des connecteurs pour interroger les données avec Apache Spark, Trino ou Apache Hive. L'API BigQuery Storage applique des règles de gouvernance au niveau des lignes et des colonnes pour toutes les tables BigLake dans Cloud Storage ou BigQuery.

Migration de données

La migration des données Hive de votre cluster sur site ou d'un autre cluster source cloud vers BigQuery s'effectue en deux étapes :

Copier des données d'un cluster source vers Cloud Storage
Charger des données de Cloud Storage vers BigQuery

Les sections suivantes décrivent la migration des données Hive, la validation des données migrées et la gestion de la migration des données ingérées en continu. Les exemples sont écrits pour les tables autres que ACID.

Partitionner les données de colonne

Dans Hive, les données des tables partitionnées sont stockées dans une structure de répertoires. Chaque partition de la table est associée à une valeur particulière de colonne de partition. Les fichiers de données eux-mêmes ne contiennent aucune donnée des colonnes de partition. Utilisez la commande SHOW PARTITIONS pour répertorier les différentes partitions d'une table partitionnée.

L'exemple ci-dessous montre que la table Hive source est partitionnée en fonction des colonnes joining_date et department. Les fichiers de données de cette table ne contiennent aucune donnée liée à ces deux colonnes.

hive> SHOW PARTITIONS corp.employees_partitioned
joining_date="2018-10-01"/department="HR"
joining_date="2018-10-01"/department="Analyst"
joining_date="2018-11-01"/department="HR"

Pour copier ces colonnes, vous pouvez convertir la table partitionnée en table non partitionnée avant de la charger dans BigQuery :

Créez une table non partitionnée avec un schéma semblable à la table partitionnée.
Chargez des données dans la table non partitionnée à partir de la table partitionnée source.
Copiez ces fichiers de données sous la table non partitionnée en préproduction dans Cloud Storage.
Chargez les données dans BigQuery à l'aide de la commande bq load et indiquez le nom de la colonne de partition de type TIMESTAMP ou DATE, le cas échéant, en tant qu'argument time_partitioning_field.

Copier des données dans Cloud Storage

La première étape de la migration des données consiste à les copier dans Cloud Storage. Utilisez Hadoop DistCp pour copier des données de votre cluster sur site ou d'un autre cluster cloud vers Cloud Storage. Stockez vos données dans un bucket situé dans la même région ou dans la même zone multirégionale que l'ensemble de données dans lequel vous souhaitez stocker les données dans BigQuery. Par exemple, si vous souhaitez utiliser un ensemble de données BigQuery existant comme destination dans la région de Tokyo, vous devez choisir un bucket régional Cloud Storage à Tokyo pour conserver les données.

Après avoir sélectionné l'emplacement du bucket Cloud Storage, vous pouvez utiliser la commande suivante pour répertorier tous les fichiers de données présents à l'emplacement de la table Hive employees :

> hdfs dfs -ls hdfs://demo_cluster/user/hive/warehouse/corp/employees
hdfs://demo_cluster/user/hive/warehouse/corp/employees/000000_0
hdfs://demo_cluster/user/hive/warehouse/corp/employees/000001_0
hdfs://demo_cluster/user/hive/warehouse/corp/employees/000002_0

Copiez tous les fichiers ci-dessus dans Cloud Storage :

> hadoop distcp
hdfs://demo_cluster/user/hive/warehouse/corp/employees
gs://hive_data/corp/employees

Notez que le stockage des données dans Cloud Storage vous est facturé conformément aux tarifs de stockage des données.

Il peut y avoir des répertoires de préproduction contenant des fichiers intermédiaires créés pour les tâches de requête. Vous devez vous assurer de supprimer tous ces répertoires avant d'exécuter la commande bq load.

Chargement des données

BigQuery accepte le chargement de données par lot dans de nombreux formats depuis Cloud Storage. Avant de créer une tâche de chargement, assurez-vous que l'ensemble de données BigQuery dans lequel vous souhaitez charger vos données existe.

La commande suivante affiche les données copiées à partir de Hive pour une table autre que ACID :

> gsutil ls gs://hive_data/corp/employees/
gs://hive-migration/corp/employees/
gs://hive-migration/corp/employees/000000_0
gs://hive-migration/corp/employees/000001_0
gs://hive-migration/corp/employees/000002_0

Pour charger vos données Hive dans BigQuery, exécutez la commande bq load. Vous pouvez utiliser un caractère générique * dans l'URL pour charger des données à partir de plusieurs fichiers partageant un préfixe d'objet commun. Par exemple, utilisez la commande suivante pour charger tous les fichiers partageant le préfixe gs://hive_data/corp/employees/ :

bq load --source_format=AVRO corp.employees gs://hive_data/corp/employees/*

Comme les tâches peuvent prendre beaucoup de temps, vous pouvez les exécuter de manière asynchrone en définissant l'option --sync sur False. L'exécution de la commande bq load renvoie l'ID de la tâche de chargement créée. Vous pouvez donc utiliser cette commande pour interroger l'état de la tâche. Ces données incluent des détails tels que le type de la tâche, l'état de la tâche et l'utilisateur qui a exécuté la tâche.

Interrogez chaque état de tâche de chargement à l'aide de son ID de tâche respectif et recherchez les tâches qui ont échoué en renvoyant des erreurs. En cas d'échec, BigQuery utilise une approche "Tout ou Aucun" lors du chargement des données dans une table. Vous pouvez essayer de résoudre les erreurs et recréer en toute sécurité une autre tâche de chargement. Pour en savoir plus, consultez la page Résoudre les erreurs.

Assurez-vous de disposer d'un quota de tâches de chargement suffisant par table et par projet. Si vous dépassez votre quota, la tâche de chargement échoue avec une erreur quotaExceeded.

Notez que les opérations de chargement des données dans BigQuery à partir de Cloud Storage ne vous sont pas facturées. Une fois les données chargées dans BigQuery, elles sont soumises aux tarifs de stockage de BigQuery. Une fois les tâches de chargement terminées, vous pouvez supprimer les fichiers restants dans Cloud Storage afin d'éviter que le stockage des données redondantes ne vous soit facturé.

Validation

Une fois les données chargées, vous pouvez valider vos données migrées en comparant le nombre de lignes dans les tables Hive et BigQuery. Affichez les informations sur la table pour obtenir des détails sur les tables BigQuery telles que le nombre de lignes, le nombre de colonnes, les champs de partitionnement et les champs de clustering. Pour une validation supplémentaire, envisagez d'essayer l'outil de validation des données.

Ingestion continue

Si vous ingérez des données en continu dans une table Hive, effectuez une migration initiale, puis effectuez la migration des seules modifications des données incrémentielles vers BigQuery. Il est courant de créer des scripts qui s'exécutent de manière répétée pour rechercher et charger de nouvelles données. Il existe de nombreuses façons de procéder. Les sections suivantes décrivent une approche possible.

Vous pouvez suivre la progression de la migration dans une table de base de données Cloud SQL, appelée table de suivi dans les sections suivantes. Lors de la première exécution de la migration, stockez la progression dans la table de suivi. Pour les exécutions ultérieures de la migration, utilisez les informations de la table de suivi pour détecter si des données supplémentaires ont été ingérées et peuvent être migrées vers BigQuery.

Sélectionnez une colonne d'identifiant de type INT64, TIMESTAMP ou DATE pour distinguer les données incrémentielles. C'est ce que l'on appelle une colonne incrémentielle.

La table suivante est un exemple de table sans partitionnement qui utilise un type TIMESTAMP pour sa colonne incrémentielle :

+-----------------------------+-----------+-----------+-----------+-----------+
| timestamp_identifier        | column_2  | column_3  | column_4  | column_5  |
+-----------------------------+-----------+-----------+-----------+-----------+
| 2018-10-10 21\:56\:41       |           |           |           |           |
| 2018-10-11 03\:13\:25       |           |           |           |           |
| 2018-10-11 08\:25\:32       |           |           |           |           |
| 2018-10-12 05\:02\:16       |           |           |           |           |
| 2018-10-12 15\:21\:45       |           |           |           |           |
+-----------------------------+-----------+-----------+-----------+-----------+

La table suivante est un exemple de table partitionnée sur une colonne partition_column de type DATE. Elle comporte une colonne incrémentielle int_identifier de type entier dans chaque partition.

+---------------------+---------------------+----------+----------+-----------+
| partition_column    | int_identifier      | column_3 | column_4 | column_5  |
+---------------------+---------------------+----------+----------+-----------+
| 2018-10-01          | 1                   |          |          |           |
| 2018-10-01          | 2                   |          |          |           |
| ...                 | ...                 |          |          |           |
| 2018-10-01          | 1000                |          |          |           |
| 2018-11-01          | 1                   |          |          |           |
| 2018-11-01          | 2                   |          |          |           |
| ...                 | ...                 |          |          |           |
| 2018-11-01          | 2000                |          |          |           |
+---------------------+---------------------+----------+----------+-----------+

Les sections suivantes décrivent la migration de données Hive selon qu'elles sont partitionnées ou non et qu'elles contiennent ou non des colonnes incrémentielles.

Table non partitionnée sans colonnes incrémentielles

En supposant qu'il n'existe pas de compactage de fichiers dans Hive, Hive crée des fichiers de données lors de l'ingestion de nouvelles données. Lors de la première exécution, stockez la liste des fichiers dans la table de suivi, puis terminez la migration initiale de la table Hive en copiant ces fichiers dans Cloud Storage et en les chargeant dans BigQuery.

> hdfs dfs -ls hdfs://demo_cluster/user/hive/warehouse/corp/employees
Found 3 items
hdfs://demo_cluster/user/hive/warehouse/corp/employees/000000_0
hdfs://demo_cluster/user/hive/warehouse/corp/employees/000001_0
hdfs://demo_cluster/user/hive/warehouse/corp/employees/000002_0

Après la migration initiale, certaines données sont ingérées dans Hive. Il vous suffit de migrer ces données incrémentielles vers BigQuery. Au cours des migrations suivantes, répertoriez à nouveau les fichiers de données et comparez-les aux informations de la table de suivi pour détecter les nouveaux fichiers de données qui n'ont pas été migrés.

> hdfs dfs -ls hdfs://demo_cluster/user/hive/warehouse/corp/employees
Found 5 items
hdfs://demo_cluster/user/hive/warehouse/corp/employees/000000_0
hdfs://demo_cluster/user/hive/warehouse/corp/employees/000001_0
hdfs://demo_cluster/user/hive/warehouse/corp/employees/000002_0
hdfs://demo_cluster/user/hive/warehouse/corp/employees/000003_0
hdfs://demo_cluster/user/hive/warehouse/corp/employees/000004_0

Dans cet exemple, deux nouveaux fichiers sont présents à l'emplacement de la table. Migrez les données en copiant ces nouveaux fichiers de données dans Cloud Storage et en les chargeant dans la table BigQuery existante.

Table non partitionnée avec colonnes incrémentielles

Dans ce cas, vous pouvez utiliser la valeur maximale des colonnes incrémentielles pour déterminer si de nouvelles données ont été ajoutées. Lors de la migration initiale, interrogez la table Hive pour récupérer la valeur maximale de la colonne incrémentielle et la stocker dans la table de suivi :

hive> SELECT MAX(timestamp_identifier) FROM corp.employees;
2018-12-31 22:15:04

Lors des exécutions suivantes de la migration, répétez la même requête pour récupérer la valeur maximale actuelle de la colonne incrémentielle, puis comparez-la à la valeur maximale précédente de la table de suivi pour vérifier si des données incrémentielles existent :

hive> SELECT MAX(timestamp_identifier) FROM corp.employees;
2019-01-04 07:21:16

Si la valeur maximale actuelle est supérieure à la valeur maximale précédente, cela signifie que des données incrémentielles ont été ingérées dans la table Hive, comme dans l'exemple. Pour migrer les données incrémentielles, créez une table de préproduction et n'y chargez que les données incrémentielles.

hive> CREATE TABLE stage_employees LIKE corp.employees;
hive> INSERT INTO TABLE stage_employees SELECT * FROM corp.employees WHERE timestamp_identifier>"2018-12-31 22:15:04" and timestamp_identifier<="2019-01-04 07:21:16"

Migrez la table de préproduction en répertoriant les fichiers de données HDFS, en les copiant dans Cloud Storage, puis en les chargeant dans la table BigQuery existante.

Table partitionnée sans colonnes incrémentielles

L'ingestion de données dans une table partitionnée peut créer des partitions, ajouter des données incrémentielles aux partitions existantes, ou les deux. Dans ce scénario, vous pouvez identifier ces partitions mises à jour, mais vous ne pouvez pas facilement identifier les données qui ont été ajoutées à ces partitions existantes, car il n'y a pas de colonne incrémentielle à distinguer. Une autre option consiste à prendre et à gérer des instantanés HDFS, mais la création d'instantanés crée des problèmes de performances pour Hive. Elle est donc généralement désactivée.

Lors de la migration initiale de la table, exécutez la commande SHOW PARTITIONS et stockez les informations sur les différentes partitions de la table de suivi.

hive> SHOW PARTITIONS corp.employees
partition_column=2018-10-01
partition_column=2018-11-01

La sortie ci-dessus indique que la table employees comporte deux partitions. Une version simplifiée de la table de suivi est fournie ci-dessous pour montrer comment ces informations peuvent être stockées.

partition_information	file_path	gcs_copy_status	gcs_file_path	bq_job_id	...
partition_column =2018-10-01
partition_column =2018-11-01

Lors des migrations suivantes, exécutez à nouveau la commande SHOW PARTITIONS pour répertorier toutes les partitions et les comparer aux informations de partition de la table de suivi pour vérifier si de nouvelles partitions qui n'ont pas été migrées sont présentes.

hive> SHOW PARTITIONS corp.employees
partition_column=2018-10-01
partition_column=2018-11-01
partition_column=2018-12-01
partition_column=2019-01-01

Si de nouvelles partitions sont identifiées comme dans l'exemple, créez une table de préproduction et n'y chargez que les nouvelles partitions depuis la table source. Migrez la table de préproduction en copiant les fichiers vers Cloud Storage et en les chargeant dans la table BigQuery existante.

Table partitionnée avec colonnes incrémentielles

Dans ce scénario, la table Hive est partitionnée et une colonne incrémentielle est présente dans chaque partition. Les données ingérées en continu sont incrémentées sur cette valeur de colonne. Ici, vous avez la possibilité de migrer les nouvelles partitions comme décrit dans la section précédente, ainsi que les données incrémentielles qui ont été ingérées dans les partitions existantes.

Lorsque vous migrez la table pour la première fois, stockez les valeurs minimales et maximales de la colonne incrémentielle dans chaque partition, ainsi que les informations sur les partitions de la table de suivi.

hive> SHOW PARTITIONS corp.employees
partition_column=2018-10-01
partition_column=2018-11-01

hive> SELECT MIN(int_identifier),MAX(int_identifier) FROM corp.employees WHERE partition_column="2018-10-01";
1 1000

hive> SELECT MIN(int_identifier),MAX(int_identifier) FROM corp.employees WHERE partition_column="2018-11-01";
1 2000

La sortie ci-dessus indique que les employés de la table ont deux partitions et affiche les valeurs minimales et maximales de la colonne incrémentielle dans chaque partition. Une version simplifiée de la table de suivi est fournie ci-dessous pour montrer comment ces informations peuvent être stockées.

partition_information	inc_col_min	inc_col_max	file_path	gcs_copy_status	...
partition_column =2018-10-01	1	1000
partition_column =2018-11-01	1	2000

Lors des exécutions suivantes, exécutez les mêmes requêtes pour récupérer la valeur maximale actuelle dans chaque partition et la comparer à la valeur maximale précédente dans la table de suivi.

hive> SHOW PARTITIONS corp.employees
partition_column=2018-10-01
partition_column=2018-11-01
partition_column=2018-12-01
partition_column=2019-01-01

hive> SELECT MIN(int_identifier),MAX(int_identifier) FROM corp.employees WHERE partition_column="2018-10-01";

Dans l'exemple, deux nouvelles partitions ont été identifiées, et des données incrémentielles ont été ingérées dans la partition existante partition_column=2018-10-01. S'il existe des données incrémentielles, créez une table de préproduction, ne chargez que les données incrémentielles dans la table de préproduction, copiez les données dans Cloud Storage, puis chargez les données dans la table BigQuery existante.

Paramètres de sécurité

BigQuery utilise IAM pour gérer l'accès aux ressources. Les rôles prédéfinis BigQuery fournissent un accès précis à un service spécifique et sont conçus pour accepter des modèles de contrôle des accès et des cas d'utilisation courants. Vous pouvez utiliser des rôles personnalisés pour fournir un accès encore plus précis en personnalisant un ensemble d'autorisations.

Les contrôles des accès sur les tables et les ensembles de données spécifient les opérations que les utilisateurs, les groupes et les comptes de service sont autorisés à effectuer sur les tables, les vues et les ensembles de données. Les vues autorisées vous permettent de partager des résultats de requête avec des utilisateurs et des groupes particuliers sans leur donner accès aux données sources sous-jacentes. Grâce à la sécurité au niveau des lignes et à la sécurité au niveau des colonnes, vous pouvez restreindre l'accès aux lignes ou aux colonnes d'une table. Le masquage des données vous permet de masquer de manière sélective les données de colonne de groupes d'utilisateurs, tout en autorisant l'accès à la colonne.

Lorsque vous appliquez des contrôles d'accès, vous pouvez accorder l'accès aux utilisateurs et groupes suivants :

Utilisateur par e-mail : permet à un compte Google individuel d'accéder à l'ensemble de données.
Groupe par e-mail : permet à tous les membres d'un groupe Google d'accéder à l'ensemble de données.
Domaine : permet à tous les utilisateurs et groupes d'un domaine Google d'accéder à l'ensemble de données.
Tous les utilisateurs authentifiés : permet à tous les titulaires d'un compte Google d'accéder à l'ensemble de données (l'ensemble de données devient public).
Propriétaires du projet : permet à tous les propriétaires du projet d'accéder à l'ensemble de données.
Lecteurs du projet : permet à tous les lecteurs du projet d'accéder à l'ensemble de données.
Éditeurs du projet : permet à tous les éditeurs du projet d'accéder à l'ensemble de données.
Vue autorisée : permet à une vue d'accéder à l'ensemble de données.

Modifications des pipelines de données

Les sections suivantes expliquent comment modifier vos pipelines de données lorsque vous migrez de Hive vers BigQuery.

Sqoop

Si votre pipeline existant utilise Sqoop pour importer des données dans HDFS ou Hive en vue du traitement, modifiez la tâche pour importer des données dans Cloud Storage.

Si vous importez des données dans HDFS, choisissez l'une des options suivantes :

Copiez les fichiers de sortie Sqoop dans Cloud Storage à l'aide de Hadoop DistCp.
Transférez les fichiers directement dans Cloud Storage à l'aide du connecteur Cloud Storage. Le connecteur Cloud Storage est une bibliothèque Java Open Source qui vous permet d'exécuter des tâches Apache Hadoop ou Apache Spark directement sur des données dans Cloud Storage. Pour en savoir plus, consultez la page Installer le connecteur Cloud Storage.

Si vous souhaitez que Sqoop importe des données dans Hive exécuté sur Google Cloud, pointez-le directement vers la table Hive et utilisez Cloud Storage comme entrepôt Hive au lieu de HDFS. Pour ce faire, définissez la propriété hive.metastore.warehouse.dir sur un bucket Cloud Storage.

Vous pouvez exécuter votre tâche Sqoop sans gérer de cluster Hadoop. Pour cela, utilisez Dataproc afin d'envoyer des tâches Sqoop pour importer des données dans BigQuery.

Spark SQL et HiveQL

Le traducteur SQL par lot ou le traducteur SQL interactif peut traduire automatiquement votre Spark SQL ou HiveQL en GoogleSQL.

Si vous ne souhaitez pas migrer votre Spark SQL ou HiveQL vers BigQuery, vous pouvez utiliser Dataproc ou le connecteur BigQuery avec Apache Spark.

ETL Hive

S'il existe déjà des tâches ETL dans Hive, vous pouvez les modifier des manières suivantes pour les migrer depuis Hive :

Convertissez la tâche ETL Hive en une tâche BigQuery à l'aide du traducteur SQL par lot.
Utilisez Apache Spark pour lire et écrire dans BigQuery à l'aide du connecteur BigQuery. Vous pouvez utiliser Dataproc pour exécuter vos tâches Spark de manière rentable à l'aide de clusters éphémères.
Réécrivez vos pipelines à l'aide du SDK Apache Beam et exécutez-les sur Dataflow.
Utilisez Apache Beam SQL pour réécrire vos pipelines.

Pour gérer votre pipeline ETL, vous pouvez utiliser Cloud Composer (Apache Airflow) et les modèles de workflows Dataproc. Cloud Composer fournit un outil permettant de convertir des workflows Oozie en workflows Cloud Composer.

Dataflow

Si vous souhaitez déplacer votre pipeline ETL Hive vers des services cloud entièrement gérés, pensez à écrire vos pipelines de données à l'aide du SDK Apache Beam et à les exécuter sur Dataflow.

Dataflow est un service géré permettant d'exécuter des pipelines de traitement de données. Il exécute des programmes écrits à l'aide du framework Open Source Apache Beam. Apache Beam est un modèle de programmation unifié qui permet à la fois de développer des pipelines par lots et par flux.

Si vos pipelines de données sont en déplacement standard, vous pouvez utiliser des modèles Dataflow pour créer rapidement des pipelines Dataflow sans écrire de code. Vous pouvez consulter ce modèle fourni par Google qui vous permet de lire des fichiers texte à partir de Cloud Storage, d'appliquer des transformations et d'écrire les résultats dans une table BigQuery.

Pour simplifier davantage le traitement des données, vous pouvez également essayer Beam SQL, qui vous permet de traiter des données à l'aide d'instructions de type SQL.