Eseguire la migrazione di schema e dati da Apache Hive

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

Puoi anche utilizzare la traduzione SQL batch per eseguire la migrazione collettiva degli script SQL o la traduzione SQL interattiva per tradurre 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, metadati e impostazioni di sicurezza delle tabelle per aiutarti a eseguire la migrazione del tuo data warehouse da Hive a BigQuery.

Raccogliere le informazioni della 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 posizione. Queste informazioni sono utili nella procedura 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 file:

• CSV
• JSON (delimitato da nuova riga)
• Avro
• ORC
• Parquet

BigQuery può caricare file di dati in formati Avro, ORC e Parquet direttamente senza bisogno di file di schema. Per i file di testo non formattati come CSV o JSON (delimitati da una nuova riga), puoi copiare i dati in una tabella Hive in formato Avro oppure puoi convertire lo schema della tabella in uno schema JSON di 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. Raccogliere tutte le impostazioni di controllo dell'accesso di Hive, come ruoli, gruppi, membri e privilegi concessi. Mappa un modello di sicurezza in BigQuery a livello di set di dati e implementa un'ACL 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 alla base delle tabelle se disponi delle autorizzazioni richieste. Nelle tabelle BigQuery standard, dopo che i dati sono stati caricati nella tabella, vengono archiviati nello spazio di archiviazione BigQuery. Puoi leggere i dati utilizzando l'API BigQuery Storage Read, ma la sicurezza a livello di IAM, riga e colonna viene comunque applicata. Se utilizzi le tabelle esterne di 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 i criteri di governance a livello di riga e colonna per tutte le tabelle BigLake in Cloud Storage o BigQuery.

Migrazione dei dati

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

1. Copiare i dati da un cluster di origine a Cloud Storage
2. Caricamento dei dati da Cloud Storage in BigQuery

Le sezioni seguenti illustrano la migrazione dei dati di Hive, la convalida dei dati di cui è stata eseguita la migrazione e la gestione della migrazione dei dati importati continuamente. Gli esempi sono scritti per le tabelle non ACID.

Dati della colonna della partizione

In Hive, i dati nelle tabelle partizionate vengono archiviati in una struttura di directory. Ogni partizione della tabella è associata a un determinato valore 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 di 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 del caricamento in BigQuery:

1. Crea una tabella non partizionata con uno schema simile alla tabella partizionata.
2. Carica i dati nella tabella non partizionata dalla tabella partizionata di origine.
3. Copia questi file di dati nella tabella non partizionata pianificata in Cloud Storage.
4. 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 copiarli in Cloud Storage. Utilizza Hadoop DistCp per copiare i dati dal tuo cluster on-premise o di un altro cloud a Cloud Storage. Archivia i dati in un bucket nella stessa regione o nella stessa regione o più regioni del set di dati in cui vuoi archiviarli 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 posizione del bucket Cloud Storage, puoi utilizzare il seguente comando per elencare tutti i file di dati presenti nella posizione 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 precedenti in Cloud Storage:

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

Tieni presente che ti vengono addebitati i costi per l'archiviazione dei dati in Cloud Storage in base ai prezzi di archiviazione dei dati.

Potrebbero essere presenti directory di staging 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 in batch dei dati in molti formati da Cloud Storage. Prima di creare un job di caricamento, assicurati che il set di dati BigQuery in cui vuoi caricare i dati esista.

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 di Hive in BigQuery, utilizza il comando bq load. Puoi utilizzare un carattere jolly * nell'URL per caricare i dati da più file che condividono un prefisso dell'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 genera l'ID 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 job, lo stato del job e l'utente che ha eseguito il job.

Monitora lo stato di ogni job di caricamento utilizzando il rispettivo ID job e controlla se sono presenti job che non sono 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 sulla risoluzione degli errori.

Assicurati di disporre di una quota sufficiente per i job di caricamento per tabella e progetto. Se superi la quota, il job di caricamento non riesce con un quotaExceeded errore.

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

Convalida

Dopo aver caricato i dati correttamente, puoi convalidarli confrontando il numero di righe in Hive e nelle tabelle BigQuery. Visualizza le informazioni sulle tabelle per ottenere dettagli sulle tabelle BigQuery, ad esempio il numero di righe, il numero di colonne, i campi di partizione o i campi di clustering. Per un'ulteriore convalida, ti consigliamo 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. È comune creare script che vengono eseguiti ripetutamente per trovare e caricare nuovi dati. Esistono molti modi per farlo e le sezioni seguenti descrivono un possibile approccio.

Puoi monitorare l'avanzamento della migrazione in una tabella del database Cloud SQL, indicata come tabella di monitoraggio nelle sezioni seguenti. Durante la prima esecuzione della migrazione, memorizza l'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 in BigQuery.

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

La tabella seguente è un esempio di tabella senza partizioni 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 intero 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 o meno suddivisi e se hanno o meno colonne incrementali.

Tabella non partizionata senza colonne incrementali

Se non sono presenti compattazioni dei file in Hive, Hive crea nuovi file di dati quando importa 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 posizione 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 l'esecuzione della migrazione iniziale, esegui una query sulla tabella Hive per recuperare il valore massimo della colonna incrementale e memorizzarlo nella tabella di monitoraggio:

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

Nelle esecuzioni successive della migrazione, ripeti la stessa query per recuperare il valore massimo attuale della colonna incrementale e confrontarlo 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 intermedia 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 intermedia elencando i file di dati HDFS, copiandoli in Cloud Storage e caricandoli nella tabella BigQuery esistente.

Tabella partizionata senza colonne incrementali

L'importazione dei dati in una tabella partizionata potrebbe creare nuove partizioni, aggiungere dati incrementali alle partizioni esistenti o eseguire entrambe le operazioni. In questo scenario, puoi identificare le partizioni aggiornate, ma non puoi identificare facilmente quali dati sono stati aggiunti a queste partizioni esistenti perché non esiste una colonna incrementale per distinguerle. Un'altra opzione è acquisire e gestire gli snapshot HDFS, ma poiché lo snapshot crea problemi di prestazioni per Hive, in genere viene disattivato.

Durante la migrazione della tabella per la prima volta, 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 riportato sopra mostra che la tabella employees ha due partizioni. Di seguito è riportata una versione semplificata della tabella di monitoraggio per mostrare come queste informazioni possono essere archiviate.

partition_information	file_path	gcs_copy_status	gcs_file_path	bq_job_id	...
colonna_partizione =01/10/2018
colonna_partizione =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 intermedia 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 ed è presente una colonna incrementale in ogni partizione. I dati importati continuamente vengono incrementati in base a questo valore di colonna. Qui puoi eseguire la migrazione delle nuove partizioni come descritto nella sezione precedente e puoi anche eseguire la migrazione dei dati incrementali che sono stati 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 riportato sopra mostra che la tabella dipendenti 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 queste informazioni possono essere archiviate.

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

Nelle esecuzioni successive, esegui le stesse query per recuperare il valore massimo attuale in ogni partizione e confrontarlo 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 intermedia, carica solo i dati incrementali nella tabella intermedia, copia i dati in Cloud Storage e caricali nella tabella BigQuery esistente.

Impostazioni di sicurezza

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

I controlli dell'accesso su tabelle e set di dati specificano le operazioni che utenti, gruppi e service account possono eseguire su tabelle, viste e set di dati. Le viste autorizzate ti consentono di condividere i risultati di una 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 nascondere in modo selettivo i dati delle colonne per gruppi di utenti, continuando però a consentire l'accesso alla colonna.

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

• Utente via email: consente a un singolo Account Google di accedere al set di dati
• Raggruppa per email: consente a tutti i membri di un gruppo Google di accedere al set di dati
• Dominio: consente a tutti gli utenti e ai gruppi di un dominio Google di accedere al set di dati
• Tutti gli utenti autenticati: consente a tutti i titolari di Account Google di accedere al set di dati (lo rende pubblico).
• Project Owners: consente a tutti i proprietari del progetto di accedere al set di dati
• Visualizzatori progetto: consente a tutti i visualizzatori del progetto di accedere al set di dati
• Editor del progetto: consente a tutti gli editor del progetto di accedere al set di dati
• Visualizzazione autorizzata: concede a una visualizzazione l'accesso al set di dati

Modifiche alla pipeline di dati

Le sezioni seguenti spiegano come modificare le pipeline di dati durante 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 in modo da importare i dati in Cloud Storage.

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

• Copia i file di output di Sqoop in Cloud Storage utilizzando Hadoop DistCp.
• Esporta i file direttamente in Cloud Storage utilizzando il connettore Cloud Storage. Il connettore Cloud Storage è una libreria Java open source che ti consente di eseguire Apache Hadoop o Apache Spark job 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 Google Cloud, indirizzalo direttamente alla tabella Hive e utilizza Cloud Storage come data warehouse di 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 Dataproc per inviare job Sqoop per importare i dati in BigQuery.

Spark SQL e HiveQL

Il traduttore SQL batch o il 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 Dataproc o il connettore BigQuery con Apache Spark.

ETL Hive

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

• Converti il job ETL Hive in un job BigQuery utilizzando il traduttore SQL batch.
• Utilizza Apache Spark per leggere da e scrivere in BigQuery utilizzando il connettore BigQuery. Puoi utilizzare Dataproc per eseguire i tuoi job Spark in modo economico con l'aiuto di cluster effimeri.
• Riscrivere le pipeline utilizzando l'SDK Apache Beam ed eseguirle su Dataflow.
• Utilizza Apache Beam SQL per riscrivere le pipeline.

Per gestire la pipeline ETL, puoi utilizzare Cloud Composer (Apache Airflow) e Modelli di flusso di lavoro di Dataproc. Cloud Composer fornisce un strumento per convertire i flussi di lavoro Oozie in flussi di lavoro 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 eseguire le su Dataflow.

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

Se le tue pipeline di dati sono trasferimenti 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 l'elaborazione dei dati, puoi anche provare Beam SQL che ti consente di elaborare i dati utilizzando istruzioni simili a SQL.