Esegui la migrazione dello schema e dei 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 in batch per eseguire la migrazione collettiva degli script SQL oppure la traduzione SQL interattiva per tradurre le query ad hoc. Apache HiveQL è completamente supportato da entrambi i servizi di traduzione SQL.

Preparati per la migrazione

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

Raccogli informazioni sulla tabella di origine

Raccoglie informazioni sulle tabelle Hive di origine come numero di righe, numero di colonne, tipi di dati delle colonne, dimensioni, formato di input dei dati e posizione. Queste informazioni sono utili durante il 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 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 direttamente nei formati Avro, ORC e Parquet, senza bisogno di file di schema. Per i file di testo non formattati in formato 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 di BigQuery da fornire durante l'importazione.

Raccolta delle 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 i ruoli, i gruppi, i membri e i privilegi concessi. Traccia 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 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 che i dati sono stati caricati nella tabella, i dati vengono archiviati nello spazio di archiviazione di BigQuery. Puoi leggere i dati utilizzando l'API BigQuery Storage Read, ma viene comunque applicata tutta la sicurezza IAM, di riga e di colonna. Se utilizzi tabelle esterne di BigQuery per eseguire query sui dati in Cloud Storage, anche l'accesso a Cloud Storage è controllato da IAM.

Puoi creare una tabella BigLake che ti consente di utilizzare i connectors per eseguire query sui dati con Apache Spark, Trino o Apache Hive. L'API BigQuery Storage applica 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 Hive da un cluster di origine on-premise o da un altro cluster di origine basato su cloud a BigQuery prevede due passaggi:

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

Le sezioni seguenti illustrano la migrazione dei dati Hive, la convalida dei dati migrati e la gestione della migrazione dei dati importati in modo continuo. Gli esempi sono scritti per le tabelle non ACID.

Dati della colonna di partizione

In Hive, i dati delle tabelle partizionate sono archiviati in una struttura di directory. Ogni partizione della tabella è associata a un determinato valore della colonna di partizione. I file di dati 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:

  1. Crea una tabella non partizionata con uno schema simile a quello della tabella partizionata.
  2. Carica i dati nella tabella non partizionata dalla tabella partizionata di origine.
  3. Copia questi file di dati sotto la tabella temporanea non partizionata in Cloud Storage.
  4. Carica i dati in BigQuery con il comando bq load e fornisci il nome dell'eventuale colonna di partizione di tipo TIMESTAMP o DATE come argomento time_partitioning_field.

Copia i dati in Cloud Storage

Il primo passaggio della migrazione dei dati è la copia dei dati in Cloud Storage. Utilizza Hadoop DistCp per copiare dati dal cluster on-premise o da un cluster di un altro cloud a Cloud Storage. Archivia i tuoi dati in un bucket che si trova nella stessa regione o in più regioni 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 che si trova nella regione di Tokyo, devi scegliere un bucket regionale Cloud Storage di Tokyo per contenere i dati.

Dopo aver selezionato la località del bucket Cloud Storage, puoi utilizzare il comando seguente 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 qui sopra 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 esserci directory temporanee che contengono i file intermedi creati per i job di query. Devi assicurarti di eliminare tali directory prima di eseguire il comando bq load.

Caricamento dei dati

BigQuery supporta il caricamento in batch dei dati da Cloud Storage in molti formati. 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:

> 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

Per caricare i dati Hive in BigQuery, utilizza il comando bq load. Puoi utilizzare un carattere jolly * nell'URL per caricare dati da più file che condividono un prefisso di 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é i job possono richiedere molto tempo per essere completati, puoi eseguirli in modo asincrono impostando il flag --sync su False. L'esecuzione del comando bq load restituisce l'ID del job di caricamento creato, pertanto puoi utilizzarlo 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.

Esegui il sondaggio su ogni stato del job di caricamento utilizzando il rispettivo ID job e verifica se sono presenti job non riusciti e con errori. In caso di errore, BigQuery utilizza l'approccio "Tutti o Nessuno" durante il caricamento dei dati in una tabella. Puoi provare a risolvere gli errori e a ricreare in sicurezza un altro job di caricamento. Per ulteriori informazioni, consulta la sezione sulla risoluzione degli errori.

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

Tieni presente che non viene addebitato alcun costo per un'operazione di caricamento di dati in BigQuery da Cloud Storage. Una volta caricati in BigQuery, i dati sono soggetti ai prezzi di archiviazione di BigQuery. Una volta completati correttamente i job di caricamento, puoi eliminare tutti i file rimanenti in Cloud Storage per evitare che ti vengano addebitati costi per l'archiviazione di dati ridondanti.

Convalida

Dopo aver caricato correttamente i dati, puoi convalidare i dati di cui è stata eseguita la migrazione confrontando il numero di righe nelle tabelle Hive e BigQuery. Visualizza le informazioni della tabella per ottenere dettagli sulle tabelle BigQuery, come numero di righe, numero di colonne, campi di partizionamento o campi di clustering. Per un'ulteriore convalida, puoi provare lo strumento di convalida dei dati.

Importazione continua

Se importi continuamente i dati in una tabella Hive, esegui una migrazione iniziale e poi esegui la migrazione solo delle modifiche incrementali dei dati a BigQuery. È prassi comune creare script eseguiti più volte per trovare e caricare nuovi dati. Ci sono molti modi per farlo e le seguenti sezioni descrivono un approccio possibile.

Puoi tenere traccia dell'avanzamento della migrazione in una tabella di database Cloud SQL, indicata nelle seguenti sezioni come tabella di monitoraggio. Durante la prima esecuzione della migrazione, archivia 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 a BigQuery.

Seleziona una colonna di identificatori di tipo INT64, TIMESTAMP o DATE per distinguere i dati incrementali. Detta 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 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 seguenti sezioni descrivono la migrazione dei dati Hive a seconda che siano partizionati o meno e che contengano o meno colonne incrementali.

Tabella non partizionata senza colonne incrementali

Supponendo che non ci siano compattazioni dei file in Hive, Hive crea nuovi file di dati quando importa nuovi dati. Durante la prima esecuzione, archivia 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 a BigQuery. Nelle esecuzioni successive della migrazione, elenca nuovamente i file di dati e confrontali con le informazioni della tabella di monitoraggio per rilevare 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, sono presenti due nuovi file nella posizione della tabella. 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 nella tabella Hive per recuperare il valore massimo della colonna incrementale e archiviarlo 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 confrontalo con il valore massimo precedente dalla 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 temporanea e carica al suo interno 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 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 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 poiché non esiste una colonna incrementale da distinguere. Un'altra opzione consiste nell'acquisire e gestire gli snapshot HDFS, ma lo snapshot crea problemi di prestazioni per Hive, pertanto è generalmente disabilitato.

Quando esegui la migrazione della tabella per la prima volta, esegui il comando SHOW PARTITIONS e archivia 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. Una versione semplificata della tabella di monitoraggio è fornita di seguito per mostrare come è possibile archiviare queste informazioni.

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

Nelle esecuzioni successive della migrazione, 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 temporanea e carica al suo interno solo le nuove partizioni dalla tabella di origine. Esegui la migrazione della tabella 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 costantemente vengono incrementati 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 che sono stati importati nelle partizioni esistenti.

Quando esegui la migrazione della tabella per la prima volta, archivia 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 i dipendenti della tabella hanno due partizioni e i valori minimo e massimo della colonna incrementale in ogni partizione. Una versione semplificata della tabella di monitoraggio è fornita di seguito per mostrare come è possibile archiviare queste informazioni.

partition_information inc_col_min inc_col_max file_path gcs_copy_status ...
colonna_partizione =01-10-2018 1 1000
colonna_partizione =01-11-2018 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 temporanea, carica solo i dati incrementali nella tabella 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 pensati 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 di accesso su tabelle e set di dati specificano le operazioni che utenti, gruppi e account di servizio sono autorizzati a eseguire su tabelle, viste e set di dati. Le visualizzazioni autorizzate consentono di condividere i risultati delle query con determinati utenti e gruppi 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 l'accesso a determinate righe o colonne all'interno di una tabella. Il mascheramento dei dati ti consente di oscurare in modo selettivo i dati delle colonne per i gruppi di utenti, permettendo comunque l'accesso alla colonna.

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

  • Utente via email: concede a un singolo Account Google l'accesso 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 i gruppi di un dominio Google di accedere al set di dati
  • Tutti gli utenti autenticati: concede a tutti i proprietari di Account Google l'accesso al set di dati (rende pubblico il set di dati)
  • Proprietari del progetto: fornisce a tutti i proprietari del progetto l'accesso al set di dati
  • Visualizzatori del progetto: fornisce a tutti i visualizzatori del progetto l'accesso al set di dati.
  • Editor di progetto: fornisce a tutti gli editor di progetto l'accesso al set di dati
  • Visualizzazione autorizzata: fornisce l'accesso in visualizzazione al set di dati

Modifiche alla pipeline di dati

Le seguenti sezioni 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 stai importando dati in HDFS, scegli una delle seguenti opzioni:

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

Puoi eseguire un job Sqoop senza gestire un cluster Hadoop utilizzando Dataproc per inviare job Sqoop e importare 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 esistono job ETL esistenti in Hive, puoi modificarli nei seguenti modi per eseguirne la migrazione da Hive:

  • Converti il job Hive ETL in un job BigQuery utilizzando il traduttore SQL batch.
  • Utilizza Apache Spark per leggere e scrivere in BigQuery mediante il connettore BigQuery. Puoi utilizzare Dataproc per eseguire job Spark in modo economico con l'aiuto dei cluster temporanei.
  • Riscrivi le tue pipeline utilizzando l'SDK Apache Beam ed eseguile su Dataflow.
  • Utilizza SQL di Apache Beam per riscrivere le tue pipeline.

Per gestire la pipeline ETL, puoi utilizzare Cloud Composer (Apache Airflow) e i modelli di flusso di lavoro Dataproc. Cloud Composer fornisce uno strumento per convertire i flussi di lavoro di Oozie in quelli di Cloud Composer.

Dataflow

Se vuoi spostare la tua pipeline Hive ETL 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 elaborazione dati. Esegue programmi scritti utilizzando il framework open source Apache Beam. Apache Beam è un modello di programmazione unificato che consente di sviluppare pipeline in modalità batch e flusso.

Se le tue pipeline di dati utilizzano lo spostamento 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 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 consente di elaborare i dati utilizzando istruzioni di tipo SQL.