Migre o esquema e os dados do Apache Hive

Este documento descreve como migrar os seus dados, definições de segurança e pipelines do Apache Hive para o BigQuery.

Também pode usar a tradução de SQL em lote para migrar os seus scripts SQL em massa ou a tradução de SQL interativa para traduzir consultas ad hoc. O Apache HiveQL é totalmente suportado pelos serviços de tradução de SQL.

Prepare-se para a migração

As secções seguintes descrevem como recolher informações sobre as estatísticas, os metadados e as definições de segurança das tabelas para ajudar a migrar o seu armazém de dados do Hive para o BigQuery.

Recolha informações da tabela de origem

Recolha informações sobre tabelas Hive de origem, como o número de linhas, o número de colunas, os tipos de dados das colunas, o tamanho, o formato de entrada dos dados e a localização. Estas informações são úteis no processo de migração e também para validar a migração de dados. Se tiver uma tabela Hive denominada employees numa base de dados denominada corp, use os seguintes comandos para recolher informações da tabela:

# 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

Conversão do formato da tabela de origem

Alguns dos formatos suportados pelo Hive não podem ser carregados diretamente para o BigQuery.

O Hive suporta o armazenamento de dados nos seguintes formatos:

• Ficheiro de texto
• Ficheiro RC
• Ficheiro de sequência
• Ficheiro Avro
• Ficheiro ORC
• Ficheiro Parquet

O BigQuery suporta o carregamento de dados do Cloud Storage em qualquer um dos seguintes formatos de ficheiro:

• CSV
• JSON (delimitado por Newline)
• Avro
• ORC
• Parquet

O BigQuery pode carregar ficheiros de dados nos formatos Avro, ORC e Parquet diretamente, sem precisar de ficheiros de esquema. Para ficheiros de texto que não estão formatados como CSV ou JSON (delimitados por nova linha), pode copiar os dados para uma tabela do Hive no formato Avro ou converter o esquema da tabela num esquema JSON do BigQuery a fornecer durante a ingestão.

Recolha as definições de controlo de acesso do Hive

O Hive e o BigQuery têm mecanismos de controlo de acesso diferentes. Recolher todas as definições de controlo de acesso do Hive, como funções, grupos, membros e privilégios concedidos aos mesmos. Mapear um modelo de segurança no BigQuery ao nível do conjunto de dados e implementar uma ACL detalhada. Por exemplo, um utilizador do Hive pode ser mapeado para uma Conta Google e um grupo HDFS pode ser mapeado para um Grupo Google. O acesso pode ser definido ao nível do conjunto de dados. Use os seguintes comandos para recolher as definições de controlo de acesso no 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;

No Hive, pode aceder diretamente aos ficheiros HDFS por detrás das tabelas se tiver as autorizações necessárias. Nas tabelas padrão do BigQuery, depois de os dados serem carregados na tabela, são armazenados no armazenamento do BigQuery. Pode ler dados através da API BigQuery Storage Read, mas a segurança ao nível do IAM, da linha e da coluna continua a ser aplicada. Se estiver a usar tabelas externas do BigQuery para consultar os dados no Cloud Storage, o acesso ao Cloud Storage também é controlado pela IAM.

Pode criar uma tabela BigLake que lhe permita usar conetores para consultar os dados com o Apache Spark, o Trino ou o Apache Hive. A API BigQuery Storage aplica políticas de governação ao nível da linha e da coluna a todas as tabelas BigLake no Cloud Storage ou no BigQuery.

Migração de dados

A migração de dados do Hive do cluster de origem no local ou noutro cluster baseado na nuvem para o BigQuery tem dois passos:

1. Copiar dados de um cluster de origem para o Cloud Storage
2. Carregar dados do Cloud Storage para o BigQuery

As secções seguintes abordam a migração de dados do Hive, a validação dos dados migrados e o processamento da migração de dados carregados continuamente. Os exemplos são escritos para tabelas não ACID.

Dados da coluna de partição

No Hive, os dados em tabelas particionadas são armazenados numa estrutura de diretórios. Cada partição da tabela está associada a um valor específico da coluna de partição. Os próprios ficheiros de dados não contêm dados das colunas de partição. Use o comando SHOW PARTITIONS para listar as diferentes partições numa tabela particionada.

O exemplo abaixo mostra que a tabela Hive de origem está particionada nas colunas joining_date e department. Os ficheiros de dados desta tabela não contêm dados relacionados com estas duas colunas.

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"

Uma forma de copiar estas colunas é converter a tabela particionada numa tabela não particionada antes de a carregar para o BigQuery:

1. Crie uma tabela não particionada com um esquema semelhante ao da tabela particionada.
2. Carregue dados na tabela não particionada a partir da tabela particionada de origem.
3. Copie estes ficheiros de dados para o armazenamento na nuvem na tabela não particionada preparada.
4. Carregue os dados para o BigQuery com o comando bq load e indique o nome da coluna de partição do tipo TIMESTAMP ou DATE, se existir, como argumento time_partitioning_field.

Copie dados para o Cloud Storage

O primeiro passo na migração de dados é copiar os dados para o Cloud Storage. Use o Hadoop DistCp para copiar dados do seu cluster nas instalações ou noutra nuvem para o Cloud Storage. Armazene os dados num contentor na mesma região ou multirregião que o conjunto de dados onde quer armazenar os dados no BigQuery. Por exemplo, se quiser usar um conjunto de dados do BigQuery existente como destino, que está na região de Tóquio, tem de escolher um contentor regional do Cloud Storage em Tóquio para armazenar os dados.

Depois de selecionar a localização do contentor do Cloud Storage, pode usar o seguinte comando para listar todos os ficheiros de dados presentes na localização da tabela do employeesHive:

> 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

Copie todos os ficheiros acima para o Cloud Storage:

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

Tenha em atenção que o armazenamento dos dados no Cloud Storage é cobrado de acordo com os preços de armazenamento de dados.

Podem existir diretórios de preparação que contêm ficheiros intermédios criados para tarefas de consulta. Tem de garantir que elimina esses diretórios antes de executar o comando bq load.

Carregar dados

O BigQuery suporta o carregamento de dados em lote em vários formatos a partir do Cloud Storage. Certifique-se de que o conjunto de dados do BigQuery no qual quer carregar os dados existe antes de criar uma tarefa de carregamento.

O comando seguinte mostra os dados copiados do Hive para uma tabela não 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

Para carregar os seus dados do Hive para o BigQuery, use o comando bq load. Pode usar um caráter universal * no URL para carregar dados de vários ficheiros que partilham um prefixo de objeto comum. Por exemplo, use o seguinte comando para carregar todos os ficheiros que partilham o prefixo gs://hive_data/corp/employees/:

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

Uma vez que as tarefas podem demorar muito tempo a concluir, pode executá-las de forma assíncrona definindo a flag --sync como False. A execução do comando bq load gera o ID da tarefa de carregamento criada, para que possa usar este comando para sondar o estado da tarefa. Estes dados incluem detalhes como o tipo de tarefa, o estado da tarefa e o utilizador que executou a tarefa.

Sonde o estado de cada tarefa de carregamento através do respetivo ID da tarefa e verifique se existem tarefas que falharam com erros. Em caso de falha, o BigQuery usa uma abordagem "Tudo ou nada" ao carregar dados para uma tabela. Pode tentar resolver os erros e recriar com segurança outra tarefa de carregamento. Para mais informações, consulte a secção de resolução de problemas de erros.

Certifique-se de que tem cota de tarefas de carregamento suficiente por tabela e projeto. Se exceder a quota, a tarefa de carregamento falha com um erro quotaExceeded.

Tenha em atenção que não lhe é cobrada uma operação de carregamento para carregar dados para o BigQuery a partir do Cloud Storage. Depois de carregar os dados para o BigQuery, estes ficam sujeitos aos preços de armazenamento do BigQuery. Quando as tarefas de carregamento terminam com êxito, pode eliminar todos os ficheiros restantes no Cloud Storage para evitar incorrer em custos de armazenamento de dados redundantes.

Validação

Depois de carregar os dados com êxito, pode validar os dados migrados comparando o número de linhas nas tabelas do Hive e do BigQuery. Veja as informações da tabela para obter detalhes sobre as tabelas do BigQuery, como o número de linhas, o número de colunas, os campos de partição ou os campos de agrupamento. Para uma validação adicional, considere experimentar a ferramenta de validação de dados.

Carregamento contínuo

Se ingerir continuamente dados numa tabela Hive, faça uma migração inicial e, em seguida, migre apenas as alterações incrementais de dados para o BigQuery. É comum criar scripts que são executados repetidamente para encontrar e carregar novos dados. Existem muitas formas de o fazer e as secções seguintes descrevem uma abordagem possível.

Pode acompanhar o progresso da migração numa tabela da base de dados do Cloud SQL, que é denominada tabela de acompanhamento nas secções seguintes. Durante a primeira execução da migração, armazene o progresso na tabela de acompanhamento. Para as execuções subsequentes da migração, use as informações da tabela de acompanhamento para detetar se foram carregados dados adicionais e se podem ser migrados para o BigQuery.

Selecione uma coluna de identificador do tipo INT64, TIMESTAMP ou DATE para distinguir os dados incrementais. Isto é designado por coluna incremental.

A tabela seguinte é um exemplo de uma tabela sem particionamento que usa um tipo TIMESTAMP para a respetiva coluna incremental:

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

A tabela seguinte é um exemplo de uma tabela particionada numa DATEcoluna de tipo.partition_column Tem uma coluna incremental do tipo inteiro int_identifier em cada partição.

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

As secções seguintes descrevem a migração de dados do Hive com base no facto de estarem ou não particionados e de terem ou não colunas incrementais.

Tabela não particionada sem colunas incrementais

Partindo do princípio de que não existem compactações de ficheiros no Hive, o Hive cria novos ficheiros de dados quando carrega novos dados. Durante a primeira execução, armazene a lista de ficheiros na tabela de acompanhamento e conclua a migração inicial da tabela do Hive copiando estes ficheiros para o Cloud Storage e carregando-os no 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

Após a migração inicial, alguns dados são carregados no Hive. Só precisa de migrar estes dados incrementais para o BigQuery. Nas execuções de migração subsequentes, liste novamente os ficheiros de dados e compare-os com as informações da tabela de acompanhamento para detetar novos ficheiros de dados que não foram migrados.

> 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

Neste exemplo, existem dois novos ficheiros na localização da tabela. Migre os dados copiando estes novos ficheiros de dados para o Cloud Storage e carregando-os na tabela do BigQuery existente.

Tabela não particionada com colunas incrementais

Neste caso, pode usar o valor máximo das colunas incrementais para determinar se foram adicionados novos dados. Durante a migração inicial, consulte a tabela do Hive para obter o valor máximo da coluna incremental e armazene-o na tabela de acompanhamento:

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

Nas execuções subsequentes da migração, repita a mesma consulta para obter o valor máximo atual da coluna incremental e compare-o com o valor máximo anterior da tabela de acompanhamento para verificar se existem dados incrementais:

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

Se o valor máximo atual for superior ao valor máximo anterior, significa que foram carregados dados incrementais para a tabela do Hive, como no exemplo. Para migrar os dados incrementais, crie uma tabela de preparação e carregue apenas os dados incrementais na mesma.

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"

Migre a tabela de preparação listando os ficheiros de dados do HDFS, copiando-os para o Cloud Storage e carregando-os na tabela do BigQuery existente.

Tabela particionada sem colunas incrementais

A carregamento de dados numa tabela particionada pode criar novas partições, anexar dados incrementais a partições existentes ou fazer ambas as ações. Neste cenário, pode identificar essas partições atualizadas, mas não pode identificar facilmente os dados que foram adicionados a estas partições existentes, uma vez que não existe uma coluna incremental para distinguir. Outra opção é tirar e manter instantâneos do HDFS, mas a criação de instantâneos gera preocupações de desempenho para o Hive, pelo que está geralmente desativada.

Ao migrar a tabela pela primeira vez, execute o comando SHOW PARTITIONS e armazene as informações sobre as diferentes partições na tabela de acompanhamento.

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

A saída acima mostra que a tabela employees tem duas partições. A baixo, é apresentada uma versão simplificada da tabela de acompanhamento para mostrar como estas informações podem ser armazenadas.

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

Nas execuções de migração subsequentes, execute novamente o comando SHOW PARTITIONS para listar todas as partições e compare-as com as informações de partição da tabela de acompanhamento para verificar se existem novas partições que não foram migradas.

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 forem identificadas novas partições, como no exemplo, crie uma tabela de preparação e carregue apenas as novas partições na mesma a partir da tabela de origem. Migre a tabela de preparação copiando os ficheiros para o Cloud Storage e carregando-os na tabela do BigQuery existente.

Tabela particionada com colunas incrementais

Neste cenário, a tabela do Hive está particionada e existe uma coluna incremental em todas as partições. Os dados carregados continuamente são incrementados com base no valor desta coluna. Aqui, tem a capacidade de migrar as novas partições, conforme descrito na secção anterior, e também pode migrar dados incrementais que foram carregados para as partições existentes.

Quando migrar a tabela pela primeira vez, armazene os valores mínimo e máximo da coluna incremental em cada partição, juntamente com as informações sobre as partições da tabela na tabela de acompanhamento.

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

A saída acima mostra que a tabela employees tem duas partições e os valores mínimo e máximo da coluna incremental em cada partição. A baixo, é apresentada uma versão simplificada da tabela de acompanhamento para mostrar como estas informações podem ser armazenadas.

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

Nas execuções subsequentes, execute as mesmas consultas para obter o valor máximo atual em cada partição e compare-o com o valor máximo anterior da tabela de acompanhamento.

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

No exemplo, foram identificadas duas novas partições e alguns dados incrementais foram carregados na partição existente partition_column=2018-10-01. Se existirem dados incrementais, crie uma tabela de preparação, carregue apenas os dados incrementais na tabela de preparação, copie os dados para o Cloud Storage e carregue os dados na tabela do BigQuery existente.

Definições de segurança

O BigQuery usa o IAM para gerir o acesso aos recursos. As funções predefinidas do BigQuery oferecem acesso detalhado para um serviço específico e destinam-se a suportar padrões de controlo de acesso e exemplos de utilização comuns. Pode usar funções personalizadas para fornecer um acesso ainda mais detalhado, personalizando um conjunto de autorizações.

Os controlos de acesso em tabelas e conjuntos de dados especificam as operações que os utilizadores, os grupos e as contas de serviço podem realizar em tabelas, vistas e conjuntos de dados. As vistas autorizadas permitem-lhe partilhar resultados de consultas com utilizadores e grupos específicos sem lhes dar acesso aos dados de origem subjacentes. Com a segurança ao nível da linha e a segurança ao nível da coluna, pode restringir quem pode aceder a que linhas ou colunas numa tabela. A ocultação de dados permite-lhe ocultar seletivamente os dados das colunas para grupos de utilizadores, ao mesmo tempo que permite o acesso à coluna.

Quando aplica controlos de acesso, pode conceder acesso aos seguintes utilizadores e grupos:

• Utilizador por email: concede a uma Conta Google individual acesso ao conjunto de dados
• Agrupar por email: concede a todos os membros de um grupo Google acesso ao conjunto de dados
• Domínio: concede a todos os utilizadores e grupos num domínio Google acesso ao conjunto de dados
• Todos os utilizadores autenticados: concede a todos os titulares de contas Google acesso ao conjunto de dados (torna o conjunto de dados público)
• Proprietários do projeto: concede a todos os proprietários do projeto acesso ao conjunto de dados
• Visualizadores do projeto: concede a todos os visualizadores do projeto acesso ao conjunto de dados
• Editores do projeto: concede a todos os editores do projeto acesso ao conjunto de dados
• Vista autorizada: concede acesso de visualização ao conjunto de dados

Alterações ao pipeline de dados

As secções seguintes abordam como alterar os pipelines de dados quando migrar do Hive para o BigQuery.

Sqoop

Se o seu pipeline existente usar o Sqoop para importar dados para o HDFS ou o Hive para processamento, modifique a tarefa para importar dados para o Cloud Storage.

Se estiver a importar dados para o HDFS, escolha uma das seguintes opções:

• Copie os ficheiros de saída do Sqoop para o Cloud Storage através do Hadoop DistCp.
• Produzir os ficheiros diretamente no Cloud Storage através do conetor do Cloud Storage. O conetor do Cloud Storage é uma biblioteca Java de código aberto que lhe permite executar tarefas do Apache Hadoop ou do Apache Spark diretamente em dados no Cloud Storage. Para mais informações, consulte o artigo Instalar o conector do Cloud Storage.

Se quiser que o Sqoop importe dados para o Hive em execução no Google Cloud, direcione-o diretamente para a tabela Hive e use o Cloud Storage como o armazém do Hive em vez do HDFS. Para o fazer, defina a propriedade hive.metastore.warehouse.dir para um contentor do Cloud Storage.

Pode executar a sua tarefa do Sqoop sem gerir um cluster do Hadoop usando o Dataproc para enviar tarefas do Sqoop para importar dados para o BigQuery.

Spark SQL e HiveQL

O tradutor de SQL em lote ou o tradutor de SQL interativo podem traduzir automaticamente o seu Spark SQL ou HiveQL para GoogleSQL.

Se não quiser migrar o seu Spark SQL ou HiveQL para o BigQuery, pode usar o Dataproc ou o conetor do BigQuery com o Apache Spark.

ETL do Hive

Se existirem tarefas de ETL no Hive, pode modificá-las das seguintes formas para as migrar do Hive:

• Converta a tarefa de ETL do Hive numa tarefa do BigQuery através do tradutor de SQL em lote.
• Use o Apache Spark para ler e escrever no BigQuery através do conetor do BigQuery. Pode usar o Dataproc para executar os seus trabalhos do Spark de forma rentável com a ajuda de clusters efémeros.
• Reescreva os seus pipelines usando o SDK Apache Beam e execute-os no Dataflow.
• Use o SQL do Apache Beam para reescrever os seus pipelines.

Para gerir o seu pipeline ETL, pode usar o Cloud Composer (Apache Airflow) e os modelos de fluxo de trabalho do Dataproc. O Cloud Composer oferece uma ferramenta para converter fluxos de trabalho do Oozie em fluxos de trabalho do Cloud Composer.

Dataflow

Se quiser mover o seu pipeline de ETL do Hive para serviços na nuvem totalmente geridos, considere escrever os seus pipelines de dados com o SDK do Apache Beam e executá-los no Dataflow.

O Dataflow é um serviço gerido para executar pipelines de tratamento de dados. Executa programas escritos com a framework de código aberto Apache Beam. O Apache Beam é um modelo de programação unificado que lhe permite desenvolver pipelines de processamento em lote e em fluxo contínuo.

Se os seus pipelines de dados forem de movimentação de dados padrão, pode usar modelos do Dataflow para criar rapidamente pipelines do Dataflow sem escrever código. Pode consultar este modelo fornecido pela Google que lhe permite ler ficheiros de texto do Cloud Storage, aplicar transformações e escrever os resultados numa tabela do BigQuery.

Para simplificar ainda mais o processamento de dados, também pode experimentar o Beam SQL que lhe permite processar dados através de declarações semelhantes a SQL.