Consultar o BigQuery usando a federação de catálogos

O Lakehouse para Apache Iceberg oferece interoperabilidade com o BigQuery por meio de um recurso conhecido como federação de catálogos do BigQuery. Esse recurso permite expor tabelas gerenciadas pelo BigQuery, por exemplo, tabelas gerenciadas pelo Iceberg, a mecanismos de código aberto (OSS) externos, como Apache Spark e Trino.

Em vez de criar um contêiner de catálogo do Lakehouse dedicado para armazenar metadados, o endpoint do catálogo REST do Apache Iceberg atua puramente como um gateway de proxy. Quando mecanismos externos se conectam usando o prefixo do data warehouse bq://, o gateway encaminha as solicitações de catálogo diretamente para o catálogo interno do BigQuery. Isso permite criar e gerenciar tabelas diretamente no BigQuery usando a DDL ou as APIs padrão do BigQuery, ao mesmo tempo em que oferece aos mecanismos OSS externos acesso somente leitura para consultar essas tabelas pelo endpoint do catálogo REST.

Como funciona a federação de catálogos do BigQuery

A federação de catálogos do BigQuery permite expor tabelas do BigQuery, como tabelas gerenciadas pelo Iceberg e tabelas de metastore do BigQuery, pelo endpoint do catálogo REST do Apache Iceberg do catálogo de ambientes de execução do Lakehouse.

O fluxo de federação de catálogos do BigQuery funciona da seguinte maneira:

  1. Criar uma tabela no catálogo do BigQuery: você cria uma tabela gerenciada pelo Iceberg no BigQuery usando instruções DDL. Essa tabela existe no catálogo do BigQuery, é regida por listas de controle de acesso (ACLs) do BigQuery e funciona como um recurso REST do BigQuery.
  2. Federar no data warehouse do BigQuery pelo catálogo de ambientes de execução do Lakehouse: usando a API REST do Apache Iceberg do catálogo de ambientes de execução do Lakehouse, você federa em um data warehouse especificado pelo formato de caminho do data warehouse bq://projects/PROJECT_ID (ou a versão regional, bq://projects/PROJECT_ID/locations/LOCATION). Isso permite acessar a tabela do BigQuery de mecanismos de computação como o Apache Spark, pela API Lakehouse para Apache Iceberg. Nessa configuração, você tem uma experiência somente leitura do Spark, mas uma experiência de leitura e gravação do BigQuery.

Considerações

  • Como a federação de catálogos do BigQuery não cria um recurso de catálogo do Lakehouse dedicado, outros conceitos e configurações de nível de catálogo, como a hierarquia de recursos, as regiões de bucket e catálogo e a estrutura de nomenclatura P.C.N.T de quatro partes, não se aplicam a esse método. Na API subjacente, isso corresponde à configuração CATALOG_TYPE_BIGQUERY. A delegação de acesso ao armazenamento (venda de credenciais) não é compatível com catálogos federados do BigQuery.

  • A federação de catálogos do BigQuery é diferente do Lakehouse entre nuvens. Enquanto a federação de catálogos do BigQuery expõe tabelas do Google Cloud a mecanismos OSS externos, o Lakehouse entre nuvens conecta o Google Cloud a catálogos externos remotos, como o Databricks Unity Catalog, para consultar dados armazenados em outros provedores de nuvem diretamente do BigQuery e de mecanismos OSS sem migrar dados. Para mais informações sobre esse fluxo de trabalho, consulte Sobre o Lakehouse entre nuvens.

Comparação com tabelas gerenciadas pelo endpoint do catálogo REST do Apache Iceberg

A federação de catálogos do BigQuery difere dos fluxos de trabalho em que o catálogo de ambientes de execução do Lakehouse usa o endpoint do catálogo REST do Apache Iceberg das seguintes maneiras:

  • Gerenciamento de recursos e armazenamento de catálogos: as tabelas federadas residem no catálogo do BigQuery como recursos REST do BigQuery, e o catálogo de ambientes de execução do Lakehouse atua como um gateway de proxy. Quando o catálogo de ambientes de execução do Lakehouse usa o endpoint do catálogo REST do Apache Iceberg, as tabelas são armazenadas diretamente no catálogo como recursos REST do Lakehouse para Apache Iceberg.
  • Controle de acesso: as tabelas federadas usam permissões do IAM do BigQuery e listas de controle de acesso (ACLs). Quando o catálogo de ambientes de execução do Lakehouse usa o endpoint do catálogo REST do Apache Iceberg, as tabelas usam ACLs do Lakehouse para Apache Iceberg.
  • Recursos de leitura e gravação do mecanismo: as tabelas federadas fornecem acesso de leitura e gravação pelo BigQuery, mas acesso somente leitura de mecanismos externos, como o Spark. Quando o catálogo de ambientes de execução do Lakehouse usa o endpoint do catálogo REST do Apache Iceberg, as tabelas oferecem suporte a operações de leitura e gravação das APIs do BigQuery e de mecanismos externos, como o Spark.

Antes de começar

  1. Verifique se o faturamento está ativado para o Google Cloud projeto.

  2. Ative a API BigLake.

    Funções necessárias para ativar APIs

    Para ativar as APIs, é necessário ter o papel do IAM de administrador de uso do serviço (roles/serviceusage.serviceUsageAdmin), que contém a permissão serviceusage.services.enable. Saiba como conceder papéis.

    Ativar a API

Funções exigidas

Para receber as permissões necessárias para usar a federação de catálogos no BigQuery, peça ao administrador para conceder a você os seguintes papéis do IAM:

  • Ler recursos de catálogo e consultar dados da tabela:
  • Realizar operações de linguagem de manipulação de dados (DML) com a federação de catálogos do BigQuery:
    • Editor de dados do BigQuery (roles/bigquery.dataEditor) no projeto
    • Administrador de armazenamento (roles/storage.admin) no bucket do Cloud Storage. Se você usar mecanismos de consulta, como o Serviço Gerenciado para Apache Spark, para realizar operações de DML, conceda esses papéis à conta de serviço usada para executar jobs nesse mecanismo.

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

Também é possível conseguir as permissões necessárias usando personalizados papéis ou outros predefinidos papéis.

Configurar a federação de catálogos do BigQuery

Para ativar a federação de catálogos do BigQuery, configure seu cliente (como Apache Spark ou Trino) com o bq://projects/PROJECT_ID formato de data warehouse em o campo WAREHOUSE_PATH nos exemplos de configuração do cliente em Configurar o aplicativo cliente.

Também é possível incluir um local do BigQuery para restringir solicitações futuras a um único local usando o bq://projects/PROJECT_ID/locations/LOCATION formato.

Como esses recursos são gerenciados pelo BigQuery, você precisa ter as permissões necessárias aplicáveis.

Criar namespaces para tabelas federadas

Depois de configurar o cliente para a federação de catálogos do BigQuery, você pode criar um namespace para as tabelas federadas.

Spark

Para usar a federação de catálogos do BigQuery, inclua as cláusulas LOCATION e DBPROPERTIES:

spark.sql("CREATE NAMESPACE IF NOT EXISTS NAMESPACE_NAME LOCATION 'gs://BUCKET_NAME/NAMESPACE_NAME' WITH DBPROPERTIES ('gcp-region' = 'LOCATION');")
spark.sql("USE NAMESPACE_NAME;")

Substitua:

  • NAMESPACE_NAME: um nome para o namespace.
  • BUCKET_NAME: o bucket do Cloud Storage que você está usando com o catálogo.
  • LOCATION: um local do BigQuery. O valor padrão é a multirregião US.

Trino

Para usar a federação de catálogos do BigQuery, inclua as propriedades LOCATION e gcp-region:

CREATE SCHEMA IF NOT EXISTS  CATALOG_NAME.SCHEMA_NAME WITH ( LOCATION = 'gs://BUCKET_NAME/SCHEMA_NAME', "gcp-region" = 'LOCATION');
USE CATALOG_NAME.SCHEMA_NAME;

Substitua:

  • CATALOG_NAME: o nome do catálogo do Trino usando o endpoint do catálogo REST do Apache Iceberg.
  • SCHEMA_NAME: um nome para o esquema.
  • BUCKET_NAME: o bucket do Cloud Storage que você está usando com o catálogo.
  • LOCATION: um local do BigQuery. O valor padrão é a multirregião US.

Consultar tabelas federadas no BigQuery

As tabelas criadas em um catálogo federado ficam visíveis no BigQuery e podem ser consultadas diretamente usando o SQL padrão do BigQuery (sem a necessidade de um nome P.C.N.T de quatro partes):

SELECT * FROM `NAMESPACE_NAME.TABLE_NAME`;

Substitua:

  • NAMESPACE_NAME: o nome do namespace.
  • TABLE_NAME: o nome da tabela.

A seguir