Alcune o tutte le informazioni in questa pagina potrebbero non essere applicabili a Cloud de Confiance di S3NS. Per maggiori dettagli, consulta Differenze rispetto a Google Cloud.

Eseguire la migrazione di schema e dati da Apache Hive

Questo documento descrive come eseguire la migrazione di dati, impostazioni di sicurezza e pipeline da Apache Hive a BigQuery.

Puoi anche utilizzare la traduzione SQL batch per eseguire la migrazione degli script SQL in blocco o la traduzione SQL interattiva per tradurre le query ad hoc. Apache HiveQL è completamente supportato da entrambi i servizi di traduzione SQL.

Prepararsi per la migrazione

Le sezioni seguenti descrivono come raccogliere informazioni su statistiche delle tabelle, metadati e impostazioni di sicurezza per aiutarti a eseguire la migrazione del data warehouse da Hive a BigQuery.

Raccogliere informazioni sulla tabella di origine

Raccogli informazioni sulle tabelle Hive di origine, ad esempio il numero di righe, il numero di colonne, i tipi di dati delle colonne, le dimensioni, il formato di input dei dati e la località. Queste informazioni sono utili nel processo di migrazione e anche per convalidare la migrazione dei dati. Se hai una tabella Hive denominata employees in un database denominato corp, utilizza i seguenti comandi per raccogliere le informazioni sulla tabella:

# 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

Conversione del formato della tabella di origine

Alcuni dei formati supportati da Hive non possono essere importati direttamente in BigQuery.

Hive supporta l'archiviazione dei dati nei seguenti formati:

File di testo
File RC
File di sequenza
File Avro
File ORC
File Parquet

BigQuery supporta il caricamento dei dati da Cloud Storage in uno dei seguenti formati di file:

CSV
JSON (delimitato da nuova riga)
Avro
ORC
Parquet

BigQuery può caricare direttamente i file di dati in formato Avro, ORC e Parquet senza la necessità di file di schema. Per i file di testo non formattati come CSV o JSON (delimitato da nuova riga), puoi copiare i dati in una tabella Hive in formato Avro oppure convertire lo schema della tabella in uno schema JSON BigQuery da fornire durante l'importazione.

Raccogliere le impostazioni di controllo dell'accesso di Hive

Hive e BigQuery hanno meccanismi di controllo dell'accesso diversi. Raccogli tutte le impostazioni di controllo dell'accesso di Hive, come ruoli, gruppi, membri e privilegi concessi. Definisci un modello di sicurezza in BigQuery a livello di set di dati e implementa un elenco di controllo dell'accesso granulare. Ad esempio, un utente Hive può essere mappato a un Account Google e un gruppo HDFS può essere mappato a un gruppo Google. L'accesso può essere impostato a livello di set di dati. Utilizza i seguenti comandi per raccogliere le impostazioni di controllo dell'accesso in 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;

In Hive, puoi accedere direttamente ai file HDFS dietro le tabelle se disponi delle autorizzazioni richieste. Nelle tabelle BigQuery standard, dopo il caricamento dei dati nella tabella, i dati vengono archiviati nello spazio di archiviazione BigQuery. Puoi leggere i dati utilizzando l'API BigQuery Storage Read, ma tutte le autorizzazioni IAM e la sicurezza a livello di riga e di colonna vengono comunque applicate. Se utilizzi tabelle esterne BigQuery per eseguire query sui dati in Cloud Storage, l'accesso a Cloud Storage è controllato anche da IAM.

Puoi creare una tabella BigLake che ti consente di utilizzare i connettori per eseguire query sui dati con Apache Spark, Trino o Apache Hive. L'API BigQuery Storage applica le policy di governance a livello di riga e di colonna per tutte le tabelle BigLake in Cloud Storage o BigQuery.

Migrazione dei dati

La migrazione dei dati Hive dal cluster di origine on-premise o basato su cloud a BigQuery prevede due passaggi:

Copia dei dati da un cluster di origine a Cloud Storage
Caricamento dei dati da Cloud Storage in BigQuery

Le sezioni seguenti riguardano la migrazione dei dati Hive, la convalida dei dati migrati e la gestione della migrazione dei dati importati continuamente. Gli esempi sono scritti per tabelle non ACID.

Dati della colonna di partizione

In Hive, i dati nelle tabelle partizionate vengono archiviati in una struttura di directory. Ogni partizione della tabella è associata a un valore specifico della colonna di partizione. I file di dati stessi non contengono dati delle colonne di partizione. Utilizza il comando SHOW PARTITIONS per elencare le diverse partizioni in una tabella partizionata.

L'esempio seguente mostra che la tabella Hive di origine è partizionata in base alle colonne joining_date e department. I file di dati in questa tabella non contengono dati relativi a queste due colonne.

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"

Un modo per copiare queste colonne è convertire la tabella partizionata in una tabella non partizionata prima di caricarla in BigQuery:

Crea una tabella non partizionata con uno schema simile alla tabella partizionata.
Carica i dati nella tabella non partizionata dalla tabella partizionata di origine.
Copia questi file di dati nella tabella non partizionata di gestione temporanea in Cloud Storage.
Carica i dati in BigQuery con il comando bq load e fornisci il nome della colonna di partizione di tipo TIMESTAMP o DATE, se presente, come argomento time_partitioning_field.

Copiare i dati in Cloud Storage

Il primo passaggio della migrazione dei dati consiste nel copiare i dati in Cloud Storage. Utilizza Hadoop DistCp per copiare i dati dal cluster on-premise o da un altro cluster cloud a Cloud Storage. Archivia i dati in un bucket nella stessa regione o multiregione del set di dati in cui vuoi archiviare i dati in BigQuery. Ad esempio, se vuoi utilizzare un set di dati BigQuery esistente come destinazione nella regione di Tokyo, devi scegliere un bucket regionale Cloud Storage a Tokyo per contenere i dati.

Dopo aver selezionato la località del bucket Cloud Storage, puoi utilizzare il seguente comando per elencare tutti i file di dati presenti nella località della tabella 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

Copia tutti i file sopra in Cloud Storage:

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

Tieni presente che ti viene addebitato il costo di archiviazione dei dati in Cloud Storage in base ai prezzi di archiviazione dei dati.

Potrebbero essere presenti directory di gestione temporanea che contengono file intermedi creati per i job di query. Devi assicurarti di eliminare queste directory prima di eseguire il comando bq load.

Caricamento di dati

BigQuery supporta il caricamento batch dei dati in molti formati da Cloud Storage. Assicurati che il set di dati BigQuery in cui vuoi caricare i dati esista prima di creare un job di caricamento.

Il seguente comando mostra i dati copiati da Hive per una tabella non ACID:

> gcloud storage 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

Per caricare i dati Hive in BigQuery, utilizza il bq load comando. Puoi utilizzare un carattere jolly * nell'URL per caricare i dati da più file che condividono un prefisso oggetto comune. Ad esempio, utilizza il seguente comando per caricare tutti i file che condividono il prefisso gs://hive_data/corp/employees/:

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

Poiché il completamento dei job può richiedere molto tempo, puoi eseguirli in modo asincrono impostando il flag --sync su False. L'esecuzione del comando bq load restituisce l'ID job del job di caricamento creato, quindi puoi utilizzare questo comando per eseguire il polling dello stato del job. Questi dati includono dettagli come il tipo di prestazione, lo stato del job e l'utente che ha eseguito il job.

Esegui il polling dello stato di ogni job di caricamento utilizzando il rispettivo ID job e verifica la presenza di eventuali job non riusciti con errori. In caso di errore, BigQuery utilizza un approccio "Tutto o niente" durante il caricamento dei dati in una tabella. Puoi provare a risolvere gli errori e ricreare in sicurezza un altro job di caricamento. Per ulteriori informazioni, consulta la sezione Risoluzione dei problemi relativi agli errori.

Assicurati di avere una quota di job di caricamento sufficiente per tabella e progetto. Se superi la quota, il job di caricamento non riesce e viene visualizzato un errore quotaExceeded.

Tieni presente che non ti viene addebitato alcun costo per un'operazione di caricamento dei dati in BigQuery da Cloud Storage. Dopo il caricamento dei dati in BigQuery, questi sono soggetti ai prezzi di archiviazione di BigQuery. Al termine dei job di caricamento, puoi eliminare i file rimanenti in Cloud Storage per evitare di incorrere in addebiti per l'archiviazione di dati ridondanti.

Convalida

Dopo aver caricato correttamente i dati, puoi convalidarli confrontando il numero di righe nelle tabelle Hive e BigQuery. Visualizza le informazioni sulla tabella per ottenere dettagli sulle tabelle BigQuery, ad esempio il numero di righe, il numero di colonne, i campi di partizionamento o i campi di clustering. Per una convalida aggiuntiva, valuta la possibilità di provare lo strumento di convalida dei dati.

Importazione continua

Se importi continuamente dati in una tabella Hive, esegui una migrazione iniziale e poi esegui la migrazione solo delle modifiche incrementali dei dati in BigQuery. È normale creare script che vengono eseguiti ripetutamente per trovare e caricare nuovi dati. Esistono molti modi per farlo e le sezioni seguenti descrivono un approccio possibile.

Puoi tenere traccia dello stato di avanzamento della migrazione in una Cloud SQL tabella di database, denominata tabella di monitoraggio nelle sezioni seguenti. Durante la prima esecuzione della migrazione, memorizza lo stato di avanzamento nella tabella di monitoraggio. Per le esecuzioni successive della migrazione, utilizza le informazioni della tabella di monitoraggio per rilevare se sono stati importati dati aggiuntivi e se è possibile eseguirne la migrazione a BigQuery.

Seleziona una colonna identificatore di tipo INT64, TIMESTAMP o DATE per distinguere i dati incrementali. Questa colonna è denominata colonna incrementale.

La tabella seguente è un esempio di tabella senza partizionamento che utilizza un tipo TIMESTAMP per la colonna incrementale:

+-----------------------------+-----------+-----------+-----------+-----------+
| 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 tabella seguente è un esempio di tabella partizionata in base a una colonna di tipo DATE partition_column. Ha una colonna incrementale di tipo integer int_identifier in ogni partizione.

+---------------------+---------------------+----------+----------+-----------+
| 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                |          |          |           |
+---------------------+---------------------+----------+----------+-----------+

Le sezioni seguenti descrivono la migrazione dei dati Hive in base al fatto che siano partizionati o meno e se abbiano colonne incrementali o meno.

Tabella non partizionata senza colonne incrementali

Supponendo che non siano presenti compattazioni di file in Hive, Hive crea nuovi file di dati durante l'importazione di nuovi dati. Durante la prima esecuzione, memorizza l'elenco dei file nella tabella di monitoraggio e completa la migrazione iniziale della tabella Hive copiando questi file in Cloud Storage e caricandoli in 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

Dopo la migrazione iniziale, alcuni dati vengono importati in Hive. Devi solo eseguire la migrazione di questi dati incrementali in BigQuery. Nelle esecuzioni di migrazione successive, elenca di nuovo i file di dati e confrontali con le informazioni della tabella di monitoraggio per rilevare i nuovi file di dati di cui non è stata eseguita la migrazione.

> 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

In questo esempio, nella località della tabella sono presenti due nuovi file. Esegui la migrazione dei dati copiando questi nuovi file di dati in Cloud Storage e caricandoli nella tabella BigQuery esistente.

Tabella non partizionata con colonne incrementali

In questo caso, puoi utilizzare il valore massimo delle colonne incrementali per determinare se sono stati aggiunti nuovi dati. Durante la migrazione iniziale, esegui una query sulla tabella Hive per recuperare il valore massimo della colonna incrementale e memorizzalo nella tabella di monitoraggio:

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

Nelle esecuzioni di migrazione successive, ripeti la stessa query per recuperare il valore massimo attuale della colonna incrementale e confrontalo con il valore massimo precedente della tabella di monitoraggio per verificare se esistono dati incrementali:

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

Se il valore massimo attuale è maggiore del valore massimo precedente, indica che i dati incrementali sono stati importati nella tabella Hive come nell'esempio. Per eseguire la migrazione dei dati incrementali, crea una tabella di gestione temporanea e carica solo i dati incrementali.

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"

Esegui la migrazione della tabella di gestione temporanea elencando i file di dati HDFS, copiandoli in Cloud Storage e caricandoli nella tabella BigQuery esistente.

Tabella partizionata senza colonne incrementali

L'importazione di dati in una tabella partizionata potrebbe creare nuove partizioni, aggiungere dati incrementali alle partizioni esistenti o entrambe le cose. In questo scenario, puoi identificare le partizioni aggiornate, ma non puoi identificare facilmente i dati aggiunti a queste partizioni esistenti perché non esiste una colonna incrementale da distinguere. Un'altra opzione è acquisire e gestire gli snapshot HDFS, ma la creazione di snapshot crea problemi di prestazioni per Hive, quindi in genere è disabilitata.

Durante la prima migrazione della tabella, esegui il comando SHOW PARTITIONS e memorizza le informazioni sulle diverse partizioni nella tabella di monitoraggio.

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

L'output precedente mostra che la tabella employees ha due partizioni. Di seguito è riportata una versione semplificata della tabella di monitoraggio per mostrare come è possibile memorizzare queste informazioni.

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

Nelle esecuzioni di migrazione successive, esegui di nuovo il comando SHOW PARTITIONS per elencare tutte le partizioni e confrontarle con le informazioni sulle partizioni della tabella di monitoraggio per verificare se sono presenti nuove partizioni di cui non è stata eseguita la migrazione.

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

Se vengono identificate nuove partizioni come nell'esempio, crea una tabella di gestione temporanea e carica solo le nuove partizioni dalla tabella di origine. Esegui la migrazione della tabella di gestione temporanea copiando i file in Cloud Storage e caricandoli nella tabella BigQuery esistente.

Tabella partizionata con colonne incrementali

In questo scenario, la tabella Hive è partizionata e in ogni partizione è presente una colonna incrementale. I dati importati continuamente aumentano in base al valore di questa colonna. Qui hai la possibilità di eseguire la migrazione delle nuove partizioni come descritto nella sezione precedente e puoi anche eseguire la migrazione dei dati incrementali importati nelle partizioni esistenti.

Quando esegui la migrazione della tabella per la prima volta, memorizza i valori minimo e massimo della colonna incrementale in ogni partizione insieme alle informazioni sulle partizioni della tabella nella tabella di monitoraggio.

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

L'output precedente mostra che la tabella employees ha due partizioni e i valori minimo e massimo della colonna incrementale in ogni partizione. Di seguito è riportata una versione semplificata della tabella di monitoraggio per mostrare come è possibile memorizzare queste informazioni.

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

Nelle esecuzioni successive, esegui le stesse query per recuperare il valore massimo attuale in ogni partizione e confrontalo con il valore massimo precedente della tabella di monitoraggio.

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";

Nell'esempio, sono state identificate due nuove partizioni e alcuni dati incrementali sono stati importati nella partizione esistente partition_column=2018-10-01. Se sono presenti dati incrementali, crea una tabella di gestione temporanea, carica solo i dati incrementali nella tabella di gestione temporanea, copia i dati in Cloud Storage e carica i dati nella tabella BigQuery esistente.

Impostazioni di sicurezza

BigQuery utilizza IAM per gestire l'accesso alle risorse. I ruoli predefiniti di BigQuery forniscono un accesso granulare per un servizio specifico e sono progettati per supportare casi d'uso comuni e pattern di controllo dell'accesso. Puoi utilizzare ruoli personalizzati per fornire un accesso ancora più granulare personalizzando un insieme di autorizzazioni.

I controlli dell'accesso a tabelle e set di dati specificano le operazioni che utenti, gruppi e account di servizio possono eseguire su tabelle, viste e set di dati. Le viste autorizzate ti consentono di condividere i risultati delle query con utenti e gruppi specifici senza concedere loro l'accesso ai dati di origine sottostanti. Con la sicurezza a livello di riga e la sicurezza a livello di colonna, puoi limitare chi può accedere a quali righe o colonne all'interno di una tabella. Il mascheramento dei dati ti consente di oscurare selettivamente i dati delle colonne per gruppi di utenti, consentendo comunque l'accesso alla colonna.

Quando applichi i controlli dell'accesso, puoi concedere l'accesso ai seguenti utenti e gruppi:

Utente per email: concede a un singolo Account Google l'accesso al set di dati
Gruppo per email: concede a tutti i membri di un gruppo Google l'accesso al set di dati
Dominio: concede a tutti gli utenti e i gruppi di un dominio Google l'accesso al set di dati
Tutti gli utenti autenticati: concede a tutti i titolari di Account Google l'accesso al set di dati (rende pubblico il set di dati)
Project Owner: concede a tutti i Project Owner l'accesso al set di dati
Project Viewer: concede a tutti i Project Viewer l'accesso al set di dati
Project Editor: concede a tutti i Project Editor l'accesso al set di dati
Vista autorizzata: concede l'accesso in visualizzazione al set di dati

Modifiche della pipeline di dati

Le sezioni seguenti descrivono come modificare le pipeline di dati quando esegui la migrazione da Hive a BigQuery.

Sqoop

Se la pipeline esistente utilizza Sqoop per importare i dati in HDFS o Hive per l'elaborazione, modifica il job per importare i dati in Cloud Storage.

Se importi i dati in HDFS, scegli una delle seguenti opzioni:

Copia i file di output di Sqoop in Cloud Storage utilizzando Hadoop DistCp.
Esegui l'output dei file direttamente in Cloud Storage utilizzando il connettore Cloud Storage. Il connettore Cloud Storage è una libreria Java open source che ti consente di eseguire job Apache Hadoop o Apache Spark direttamente sui dati in Cloud Storage. Per ulteriori informazioni, consulta la sezione Installare il connettore Cloud Storage.

Se vuoi che Sqoop importi i dati in Hive in esecuzione su Cloud de Confiance, indirizzalo direttamente alla tabella Hive e utilizza Cloud Storage come warehouse Hive anziché HDFS. Per farlo, imposta la proprietà hive.metastore.warehouse.dir su un bucket Cloud Storage.

Puoi eseguire il job Sqoop senza gestire un cluster Hadoop utilizzando Managed Service per Apache Spark per inviare job Sqoop per importare i dati in BigQuery.

Spark SQL e HiveQL

Il traduttore SQL batch o traduttore SQL interattivo può tradurre automaticamente Spark SQL o HiveQL in GoogleSQL.

Se non vuoi eseguire la migrazione di Spark SQL o HiveQL a BigQuery, puoi utilizzare Managed Service per Apache Spark o il connettore BigQuery con Apache Spark.

Hive ETL

Se esistono job ETL in Hive, puoi modificarli nei seguenti modi per eseguirne la migrazione da Hive:

Converti il job ETL di Hive in un job BigQuery utilizzando il traduttore SQL batch.
Utilizza Apache Spark per leggere e scrivere in BigQuery utilizzando il connettore BigQuery. Puoi utilizzare Managed Service per Apache Spark per eseguire i job Spark in modo economicamente vantaggioso con l'aiuto di cluster temporanei.
Riscrivi le pipeline utilizzando l' SDK Apache Beam ed eseguile su Dataflow.
Utilizza Apache Beam SQL per riscrivere le pipeline.

Per gestire la pipeline ETL, puoi utilizzare Cloud Composer (Apache Airflow) e i modelli di workflow di Managed Service per Apache Spark. Cloud Composer fornisce uno strumento per convertire i workflow Oozie in workflow Cloud Composer.

Dataflow

Se vuoi spostare la pipeline ETL di Hive in servizi cloud completamente gestiti, valuta la possibilità di scrivere le pipeline di dati utilizzando l'SDK Apache Beam ed eseguirle su Dataflow.

Dataflow è un servizio gestito per l'esecuzione di pipeline di trattamento dati. Esegue programmi scritti utilizzando il framework open source Apache Beam. Apache Beam è un modello di programmazione unificato che ti consente di sviluppare pipeline batch e di streaming.

Se le pipeline di dati sono spostamenti di dati standard, puoi utilizzare i modelli Dataflow per creare rapidamente pipeline Dataflow senza scrivere codice. Puoi fare riferimento a questo modello fornito da Google che ti consente di leggere i file di testo da Cloud Storage, applicare trasformazioni e scrivere i risultati in una tabella BigQuery.

Per semplificare ulteriormente il trattamento dati, puoi anche provare Beam SQL che ti consente di trattare i dati utilizzando istruzioni simili a SQL.