Criar tabelas externas do BigLake para o Apache Iceberg

As tabelas externas do BigLake permitem acessar tabelas do Apache Iceberg com um controle de acesso mais refinado em um formato somente leitura. Esse recurso é diferente das tabelas do BigQuery para Apache Iceberg, que permitem criar tabelas do Apache Iceberg no BigQuery em um formato gravável.

O Iceberg é um formato de tabela de código aberto compatível com tabelas de dados em escala de petabytes. A especificação aberta do Iceberg permite executar vários mecanismos de consulta em uma única cópia dos dados armazenados em um armazenamento de objetos. As tabelas externas do BigLake para o Apache Iceberg (doravante chamadas de tabelas do BigLake Iceberg) oferecem suporte à versão 2 da especificação do Iceberg, incluindo a mesclagem na leitura.

Como administrador do BigQuery, é possível aplicar o controle de acesso no nível da linha e da coluna, incluindo o mascaramento de dados em tabelas. Para informações sobre como configurar o controle de acesso no nível da tabela, consulte Configurar políticas de controle de acesso. As políticas de acesso à tabela também são aplicadas quando você usa a API BigQuery Storage como fonte de dados da tabela no Dataproc e no Spark sem servidor. As tabelas do BigLake oferecem mais integrações com outros serviços do BigQuery. Para acessar uma lista completa das integrações disponíveis, consulte Introdução às tabelas do BigLake.

É possível criar tabelas do Iceberg BigLake das seguintes maneiras:

• Com o metastore do BigQuery (recomendado para Google Cloud). O Metastore do BigQuery é baseado no catálogo do BigQuery e se integra diretamente ao BigQuery. As tabelas na metastore do BigQuery são mutáveis em vários mecanismos de código aberto, e as mesmas tabelas podem ser consultadas no BigQuery. O BigQuery Metastore também oferece suporte à integração direta com o Apache Spark.

• Com o AWS Glue Data Catalog (recomendado para a AWS). O AWS Glue é o método recomendado para o AWS porque é um repositório de metadados centralizado em que você define a estrutura e o local dos dados armazenados em vários serviços da AWS e fornece recursos como descoberta automática de esquemas e integração com ferramentas de análise da AWS.

• Com arquivos de metadados JSON do Iceberg (recomendado para o Azure). Se você usa um arquivo de metadados JSON do Iceberg, atualize manualmente o arquivo de metadados mais recente sempre que houver uma atualização na tabela. É possível usar um procedimento armazenado do BigQuery para o Apache Spark para criar tabelas do Iceberg BigLake que fazem referência a um arquivo de metadados do Iceberg.

  Para acessar uma lista completa de limitações, consulte Limitações.

Confira a seguir uma comparação das tabelas do BigLake Iceberg com outras variedades de tabelas semelhantes no BigQuery:

Antes de começar

• Enable the BigQuery Connection and BigQuery Reservation APIs.

  Enable the APIs

• Se você usa um procedimento armazenado para o Spark no BigQuery para criar tabelas do Iceberg BigLake, siga estas etapas:

  1. Crie uma conexão do Spark.
  2. Configure o controle de acesso para essa conexão.

• Para armazenar os metadados e arquivos de dados da tabela do Iceberg BigLake no Cloud Storage, crie um bucket do Cloud Storage. Você precisa se conectar ao bucket do Cloud Storage para acessar arquivos de metadados. Para fazer isso, siga estas etapas:

  1. Crie uma conexão de recursos do Cloud.
  2. Configure o acesso para essa conexão.

Funções exigidas

Para receber as permissões necessárias para criar uma tabela do BigLake, peça ao administrador para conceder a você os seguintes papéis do IAM no projeto:

• Administrador do BigQuery (roles/bigquery.admin)
• Storage Object Admin (roles/storage.objectAdmin)

Para mais informações sobre a concessão de papéis, consulte Gerenciar o acesso a projetos, pastas e organizações.

Esses papéis predefinidos contêm as permissões necessárias para criar uma tabela do BigLake. Para conferir as permissões exatas necessárias, expanda a seção Permissões necessárias:

Essas permissões também podem ser concedidas com funções personalizadas ou outros papéis predefinidos.

Criar tabelas com o Metastore do BigQuery

Recomendamos a criação de tabelas do Iceberg BigLake com o metastore do BigQuery. É possível usar o Apache Spark para criar essas tabelas. Uma maneira conveniente de fazer isso é usar os procedimentos armazenados do BigQuery. Para conferir um exemplo, consulte Criar e executar um procedimento armazenado.

Criar tabelas com um arquivo de metadados

É possível criar tabelas do BigLake Iceberg com um arquivo de metadados JSON. No entanto, esse não é o método recomendado porque você precisa atualizar manualmente o URI do arquivo de metadados JSON para manter a tabela do BigLake atualizada. Se o URI não for atualizado, as consultas no BigQuery poderão falhar ou fornecer resultados diferentes de outros mecanismos de consulta que usam diretamente um catálogo do Iceberg.

Os arquivos de metadados da tabela do Iceberg são criados no bucket do Cloud Storage que você especificou ao criar uma tabela do Iceberg usando o Spark.

Selecione uma das seguintes opções:

  CREATE EXTERNAL TABLE myexternal-table
  WITH CONNECTION `myproject.us.myconnection`
  OPTIONS (
         format = 'ICEBERG',
         uris = ["gs://mybucket/mydata/mytable/metadata/iceberg.metadata.json"]
   )

bq mk 

    --table 

    --external_table_definition=TABLE_FORMAT=URI@projects/CONNECTION_PROJECT_ID/locations/CONNECTION_REGION/connections/CONNECTION_ID 

    PROJECT_ID:DATASET.EXTERNAL_TABLE

Atualizar metadados de tabela

Se você usar um arquivo de metadados JSON para criar uma tabela do BigLake Iceberg, atualize a definição da tabela para os metadados mais recentes dela. Para atualizar o esquema ou o arquivo de metadados, selecione uma das seguintes opções:

PATCH https://bigquery.googleapis.com/bigquery/v2/projects/PROJECT_ID/datasets/DATASET/tables/TABLE?autodetect_schema=true

{
     "externalDataConfiguration": {
      "sourceFormat": "ICEBERG",
      "sourceUris": [
        "URI"
      ]
    },
    "schema": null
  }'

Configurar políticas de controle de acesso

É possível usar vários métodos para controlar o acesso às tabelas do BigLake:

• Para instruções sobre como configurar a segurança no nível da coluna, consulte o guia de segurança no nível da coluna.

• Para ver instruções sobre como configurar o mascaramento de dados, consulte o guia de mascaramento de dados.

• Para instruções sobre como configurar a segurança no nível da linha, consulte o guia de segurança no nível da linha.

Por exemplo, digamos que você queira limitar o acesso à linha da tabela mytable no conjunto de dados mydataset:

+---------+---------+-------+
| country | product | price |
+---------+---------+-------+
| US      | phone   |   100 |
| JP      | tablet  |   300 |
| UK      | laptop  |   200 |
+---------+---------+-------+

É possível criar um filtro no nível da linha para Kim (kim@example.com) que restringe o acesso às linhas em que country é igual a US.

CREATE ROW ACCESS POLICY only_us_filter
ON mydataset.mytable
GRANT TO ('user:kim@example.com')
FILTER USING (country = 'US');

Em seguida, Kim executa a seguinte consulta:

SELECT * FROM projectid.mydataset.mytable;

A saída mostra apenas as linhas em que country é igual a US:

+---------+---------+-------+
| country | product | price |
+---------+---------+-------+
| US      | phone   |   100 |
+---------+---------+-------+

Consultar tabelas do BigLake

Para mais informações, consulte Consultar dados do Iceberg.

Mapeamento de dados

O BigQuery converte tipos de dados do Iceberg em tipos de dados do BigQuery, conforme mostrado na tabela a seguir:

Limitações

As tabelas do Iceberg BigLake têm limitações de tabela do BigLake, além das seguintes limitações:

• As tabelas que usam a mesclagem na leitura têm as seguintes limitações:

  • Cada arquivo de dados pode ser associado a até 10.000 arquivos de exclusão.
  • Não é possível aplicar mais de 100.000 IDs de igualdade a um arquivo de exclusão.
  • É possível contornar essas limitações compactando arquivos de exclusão com frequência ou criando uma visualização na tabela Iceberg que evite partições frequentemente modificadas.

• O BigQuery é compatível com a remoção de manifesto usando todas as funções de transformação de partição do Iceberg, exceto Bucket. Para saber mais sobre como remover partições, consulte Consultar tabelas particionadas. As consultas que fazem referência a tabelas do BigLake Iceberg precisam conter literais em predicados em comparação com colunas particionadas.

• Somente arquivos de dados do Apache Parquet são compatíveis.

Custos de mesclagem na leitura

O faturamento sob demanda para dados de mesclagem na leitura é a soma das verificações dos seguintes dados:

• Todos os bytes lógicos lidos no arquivo de dados (incluindo linhas marcadas como excluídas por posição e exclusões de igualdade).
• Os bytes lógicos lidos carregam a exclusão de igualdade e a posição exclui arquivos para encontrar as linhas excluídas em um arquivo de dados.

Exigir filtro de particionamento

É possível exigir o uso de filtros de predicado ativando a opção Exigir filtro de partição para sua tabela do Iceberg. Se você ativar essa opção, as tentativas de consultar a tabela sem especificar uma cláusula WHERE que se alinha a cada arquivo de manifesto produzirão o seguinte erro:

Cannot query over table project_id.dataset.table without a
filter that can be used for partition elimination.

Cada arquivo de manifesto requer pelo menos um predicado adequado para a eliminação de partições.

É possível ativar o require_partition_filter das seguintes maneiras ao criar uma tabela Iceberg :

  CREATE EXTERNAL TABLE TABLE
  WITH CONNECTION `PROJECT_ID.REGION.CONNECTION_ID`
  OPTIONS (
         format = 'ICEBERG',
         uris = [URI],
         require_partition_filter = true
   )

bq mk \
    --table \
    --external_table_definition=ICEBERG=URI@projects/CONNECTION_PROJECT_ID/locations/CONNECTION_REGION/connections/CONNECTION_ID \
    PROJECT_ID:DATASET.EXTERNAL_TABLE \
    --require_partition_filter

Você também pode atualizar sua tabela do Iceberg para ativar o filtro de partição necessário.

Se você não ativar a opção Exigir filtro de partição ao criar a tabela particionada, será possível atualizá-la para adicionar a opção.

bq update --require_partition_filter PROJECT_ID:DATASET.TABLE

A seguir

• Saiba mais sobre o procedimento armazenado para o Spark.
• Saiba mais sobre as tabelas BigLake.
• Saiba mais sobre as políticas de controle de acesso.
• Saiba mais sobre como executar consultas no BigQuery.
• Saiba mais sobre as instruções compatíveis e os dialetos SQL no BigQuery.