Introdução às tabelas externas do BigLake

Este documento oferece uma vista geral do BigLake e pressupõe familiaridade com as tabelas de bases de dados e a gestão de identidade e de acesso (IAM). Para consultar dados armazenados nos armazenamentos de dados suportados, primeiro tem de criar tabelas do BigLake e, em seguida, consultá-las através da sintaxe do GoogleSQL:

Também pode atualizar uma tabela externa para o BigLake. Para mais informações, consulte o artigo Atualize uma tabela externa para o BigLake.

As tabelas do BigLake permitem-lhe consultar dados estruturados em armazenamentos de dados externos com delegação de acesso. A delegação de acesso desvincula o acesso à tabela do BigLake do acesso ao repositório de dados subjacente. Uma ligação externa associada a uma conta de serviço é usada para estabelecer ligação ao repositório de dados. Uma vez que a conta de serviço processa a obtenção de dados do repositório de dados, só tem de conceder aos utilizadores acesso à tabela do BigLake. Isto permite-lhe aplicar uma segurança detalhada ao nível da tabela, incluindo a segurança ao nível da linha e ao nível da coluna. Para tabelas do BigLake baseadas no Cloud Storage, também pode usar a ocultação de dados dinâmica. Para saber mais sobre as soluções de análise em várias nuvens que usam tabelas do BigLake com dados do Amazon S3 ou Blob Storage, consulte o BigQuery Omni.

Armazenamentos de dados suportados

Pode usar tabelas do BigLake com os seguintes repositórios de dados:

Suporte de tabelas temporárias

As tabelas do BigLake baseadas no Cloud Storage podem ser temporárias ou permanentes. As tabelas do BigLake baseadas no Amazon S3 ou no Blob Storage têm de ser permanentes.

Vários ficheiros de origem

Pode criar uma tabela do BigLake com base em várias origens de dados externas, desde que essas origens de dados tenham o mesmo esquema.

Junções entre nuvens

As junções entre nuvens permitem-lhe executar consultas que abrangem regiões do BigQuery Trusted Cloud e do BigQuery Omni. Pode usar as operações do GoogleSQLJOIN para analisar dados em várias soluções de armazenamento diferentes, como a AWS, o Azure, conjuntos de dados públicos e outros serviços Trusted Cloud . As junções entre nuvens eliminam a necessidade de copiar dados entre origens antes de executar consultas.

Pode fazer referência a tabelas do BigLake em qualquer lugar numa declaração SELECT como se fossem tabelas padrão do BigQuery, incluindo em declarações de linguagem de manipulação de dados (DML) e linguagem de definição de dados (DDL) que usam subconsultas para obter dados. Pode usar várias tabelas do BigLake de diferentes nuvens e tabelas do BigQuery na mesma consulta. Todas as tabelas do BigQuery têm de ser da mesma região.

Autorizações necessárias para a união entre nuvens

Para receber as autorizações de que precisa para executar uma junção entre nuvens, peça ao seu administrador para lhe conceder as seguintes funções da IAM no projeto onde a junção é executada:

Para mais informações sobre a atribuição de funções, consulte o artigo Faça a gestão do acesso a projetos, pastas e organizações.

Estas funções predefinidas contêm as autorizações necessárias para executar uma junção entre nuvens. Para ver as autorizações exatas que são necessárias, expanda a secção Autorizações necessárias:

Autorizações necessárias

São necessárias as seguintes autorizações para executar uma junção entre nuvens:

  • bigquery.jobs.create
  • bigquery.tables.getData

Também pode conseguir estas autorizações com funções personalizadas ou outras funções predefinidas.

Custos de união entre nuvens

Quando executa uma operação de junção entre nuvens, o BigQuery analisa a consulta em partes locais e remotas. A parte local é tratada como uma consulta padrão na região do BigQuery. A parte remota é convertida numa operação CREATE TABLE AS SELECT (CTAS) na tabela BigLake referenciada na região do BigQuery Omni, que cria uma tabela temporária na sua região do BigQuery. Em seguida, o BigQuery usa esta tabela temporária para executar a junção entre nuvens e elimina a tabela automaticamente após oito horas.

Incorre em custos de transferência de dados para dados nas tabelas do BigLake referenciadas. No entanto, o BigQuery ajuda a reduzir estes custos transferindo apenas as colunas e as linhas na tabela do BigLake que são referenciadas na consulta, em vez da tabela completa. Recomendamos que especifique um filtro de colunas o mais restrito possível para reduzir ainda mais os custos de transferência. A tarefa CTAS aparece no seu histórico de tarefas e apresenta informações como o número de bytes transferidos. As transferências bem-sucedidas incorrem em custos, mesmo que a tarefa de consulta principal falhe. Para mais informações, consulte os preços do BigQuery Omni.

Considere a seguinte consulta como exemplo:

SELECT *
FROM bigquery_dataset.bigquery_table AS clients
WHERE clients.sales_rep IN (
  SELECT id
  FROM aws_dataset.aws_table1 AS employees
  INNER JOIN aws_dataset.aws_table2 AS active_employees
    ON employees.id = active_employees.id
  WHERE employees.level > 3
);

Este exemplo tem duas transferências: uma de uma tabela de funcionários (com um filtro de nível) e outra de uma tabela de funcionários ativos. A junção é realizada na região do BigQuery após a transferência. Se uma transferência falhar e a outra for bem-sucedida, continuam a ser aplicadas cobranças de transferência de dados à transferência bem-sucedida.

Limitações de junção entre nuvens

  • As junções entre nuvens não são suportadas no nível gratuito do BigQuery e no sandbox do BigQuery.
  • As agregações podem não ser enviadas para as regiões do BigQuery Omni se a consulta contiver declarações JOIN.
  • Cada tabela temporária é usada apenas para uma única consulta entre nuvens e não é reutilizada, mesmo que a mesma consulta seja repetida várias vezes.
  • O limite de tamanho de transferência para cada transferência é de 60 GB. Especificamente, se aplicar um filtro a uma tabela do BigLake e carregar o resultado, este tem de ter menos de 60 GB. Se necessário, pode pedir um ajuste da quota. Não existe um limite de bytes analisados.
  • As consultas de união entre nuvens usam uma quota interna na taxa de consultas. Se a taxa de consultas exceder a quota, pode receber um erro All our servers are busy processing data transferred between regions. Tentar novamente a consulta deve funcionar na maioria dos casos. Contacte o apoio técnico para aumentar a quota interna de forma a suportar uma taxa de consultas mais elevada.
  • As junções entre nuvens só são suportadas em regiões do BigQuery localizadas com as respetivas regiões do BigQuery Omni e nas multirregiões US e EU. As junções entre nuvens executadas nas multirregiões US ou EU só podem aceder a dados nas regiões do BigQuery Omni dos EUA ou da UE, respetivamente.
  • Se uma consulta de união entre nuvens referenciar 10 ou mais conjuntos de dados de regiões do BigQuery Omni, pode falhar com um erro Not found: Dataset <BigQuery dataset> was not found in location <BigQuery Omni region>. Para evitar este problema, especifique explicitamente uma localização quando executar uma junção entre nuvens que referencie mais de 10 conjuntos de dados. Tenha em atenção que, se especificar explicitamente uma região do BigQuery e a sua consulta contiver apenas tabelas do BigLake, a consulta é executada como uma consulta entre nuvens e incorre em custos de transferência de dados.
  • Não pode consultar a pseudocoluna _FILE_NAME com junções entre nuvens.
  • Quando faz referência às colunas de uma tabela BigLake numa cláusula WHERE, não pode usar os literais INTERVAL nem RANGE.
  • As tarefas de junção entre nuvens não comunicam o número de bytes processados e transferidos de outras nuvens. Estas informações estão disponíveis nos trabalhos CTAS filhos criados como parte da execução de consultas entre nuvens.
  • As vistas autorizadas e as rotinas autorizadas que fazem referência a tabelas ou vistas do BigQuery Omni só são suportadas nas regiões do BigQuery Omni.
  • Se a sua consulta entre nuvens fizer referência a colunas STRUCT ou JSON, não são aplicados pushdowns a nenhuma subconsulta remota. Para otimizar o desempenho, considere criar uma vista na região do BigQuery Omni que filtre as colunas STRUCT e JSON e devolva apenas os campos necessários como colunas individuais.
  • A colação não é suportada por uniões entre nuvens.

Exemplos de união entre nuvens

A consulta seguinte junta uma tabela orders numa região do BigQuery com uma tabela lineitem numa região do BigQuery Omni:

SELECT
  l_shipmode,
  o_orderpriority,
  count(l_linenumber) AS num_lineitems
FROM bigquery_dataset.orders
JOIN aws_dataset.lineitem
  ON orders.o_orderkey = lineitem.l_orderkey
WHERE
  l_shipmode IN ('AIR', 'REG AIR')
  AND l_commitdate < l_receiptdate
  AND l_shipdate < l_commitdate
  AND l_receiptdate >= DATE '1997-01-01'
  AND l_receiptdate < DATE '1997-02-01'
GROUP BY l_shipmode, o_orderpriority
ORDER BY l_shipmode, o_orderpriority;

Esta consulta é dividida em partes locais e remotas. A seguinte consulta é enviada para a região do BigQuery Omni para execução em primeiro lugar. O resultado é uma tabela temporária na região do BigQuery. Pode ver esta tarefa CTAS e os respetivos metadados no histórico de tarefas.

CREATE OR REPLACE TABLE temp_table
AS (
  SELECT
    l_shipmode,
    l_linenumber,
    l_orderkey
  FROM aws_dataset.lineitem
  WHERE
    l_shipmode IN ('AIR', 'REG AIR')
    AND l_commitdate < l_receiptdate
    AND l_shipdate < l_commitdate
    AND l_receiptdate >= DATE '1997-01-01'
    AND l_receiptdate < DATE '1997-02-01'
);

Depois de a tabela temporária ser criada, a operação JOIN é concluída e a consulta seguinte é executada:

SELECT
  l_shipmode,
  o_orderpriority,
  count(l_linenumber) AS num_lineitems
FROM bigquery_dataset.orders
JOIN temp_table
  ON orders.o_orderkey = lineitem.l_orderkey
GROUP BY l_shipmode, o_orderpriority
ORDER BY l_shipmode, o_orderpriority;

Como outro exemplo, considere a seguinte junção entre nuvens:

SELECT c_mktsegment, c_name
FROM bigquery_dataset.customer
WHERE c_mktsegment = 'BUILDING'
UNION ALL
SELECT c_mktsegment, c_name
FROM aws_dataset.customer
WHERE c_mktsegment = 'FURNITURE'
LIMIT 10;

Nesta consulta, a cláusula LIMIT não é enviada para a região do BigQuery Omni. Todos os clientes no segmento de mercado FURNITURE são transferidos primeiro para a região do BigQuery e, em seguida, é aplicado o limite de 10.

Conetores

Pode aceder a dados em tabelas do BigLake baseadas no Cloud Storage a partir de outras ferramentas de processamento de dados através da utilização de conetores do BigQuery. Por exemplo, pode aceder a dados em tabelas BigLake a partir do Apache Spark, Apache Hive, TensorFlow, Trino ou Presto. A API BigQuery Storage aplica políticas de governação ao nível da linha e da coluna em todos os acessos aos dados das tabelas BigLake, inclusive através de conetores.

Por exemplo, o diagrama seguinte demonstra como a API BigQuery Storage permite que os utilizadores acedam a dados autorizados através de motores de consulta de código aberto, como o Apache Spark:

Arquitetura do BigLake.

Para mais informações acerca dos conetores suportados pelo BigQuery, consulte o artigo Conetores do BigQuery.

Tabelas do BigLake em arquivos de objetos

Para os administradores de lagos de dados, o BigLake permite-lhe definir controlos de acesso em tabelas em vez de ficheiros, o que lhe dá opções mais detalhadas quando define o acesso dos utilizadores aos dados no lago de dados.

Uma vez que as tabelas do BigLake simplificam o controlo de acesso desta forma, recomendamos que use tabelas do BigLake para criar e manter ligações a armazenamentos de objetos externos.

Pode usar tabelas externas nos casos em que a governação não é um requisito ou para a deteção e a manipulação de dados ad hoc.

Limitações

  • Todas as limitações para tabelas externas aplicam-se às tabelas BigLake.
  • As tabelas do BigLake em armazenamentos de objetos estão sujeitas às mesmas limitações que as tabelas do BigQuery. Para mais informações, consulte a secção Quotas.

  • O BigLake não suporta credenciais com âmbito reduzido da autenticação de cluster pessoal do Dataproc. Como solução alternativa, para usar clusters com a autenticação de cluster pessoal, tem de injetar as suas credenciais através de um limite de acesso de credenciais vazio com a flag --access-boundary=<(echo -n "{}"). Por exemplo, o seguinte comando ativa uma sessão de propagação de credenciais num projeto denominado myproject para o cluster denominado mycluster: 

    gcloud dataproc clusters enable-personal-auth-session \
    --region=us \
    --project=myproject \
    --access-boundary=<(echo -n "{}") \
    mycluster

  • As tabelas do BigLake são só de leitura. Não pode modificar tabelas do BigLake com declarações DML nem outros métodos.

  • As tabelas do BigLake suportam os seguintes formatos:

  • Não pode usar metadados em cache com tabelas externas do Apache Iceberg; o BigQuery já usa os metadados que o Iceberg captura em ficheiros de manifesto.

  • A API BigQuery Storage não está disponível noutros ambientes de nuvem, como a AWS e o Azure.

  • Se usar metadados em cache, aplicam-se as seguintes limitações:

    • Só pode usar metadados em cache com tabelas BigLake que usam os formatos Avro, ORC, Parquet, JSON e CSV.
    • Se criar, atualizar ou eliminar ficheiros no Amazon S3, a consulta dos ficheiros não devolve os dados atualizados até à atualização seguinte da cache de metadados. Isto pode levar a resultados inesperados. Por exemplo, se eliminar um ficheiro e escrever um novo ficheiro, os resultados da consulta podem excluir o ficheiro antigo e o novo, consoante a última atualização dos metadados em cache.
    • A utilização de chaves de encriptação geridas pelo cliente (CMEK) com metadados em cache não é suportada para tabelas do BigLake que referenciam dados do Amazon S3 ou do Blob Storage.

Modelo de segurança

Normalmente, as seguintes funções organizacionais estão envolvidas na gestão e na utilização de tabelas do BigLake:

  • Administradores do lago de dados. Normalmente, estes administradores gerem as políticas de gestão de identidade e de acesso (IAM) em contentores e objetos do Cloud Storage.
  • Administradores do armazém de dados. Normalmente, estes administradores criam, eliminam e atualizam tabelas.
  • Analistas de dados. Normalmente, os analistas leem dados e executam consultas.

Os administradores do data lake são responsáveis por criar associações e partilhá-las com os administradores do data warehouse. Por sua vez, os administradores do data warehouse criam tabelas, definem controlos de acesso adequados e partilham as tabelas com os analistas de dados.

Colocação em cache de metadados para desempenho

Pode usar metadados em cache para melhorar o desempenho das consultas em alguns tipos de tabelas do BigLake. O armazenamento em cache de metadados é especialmente útil nos casos em que está a trabalhar com um grande número de ficheiros ou se os dados estiverem particionados no Hive. Os seguintes tipos de tabelas do BigLake suportam o armazenamento em cache de metadados:

  • Tabelas do Amazon S3 BigLake
  • Tabelas do Cloud Storage BigLake
O BigQuery usa o CMETA como um sistema de metadados distribuído para processar tabelas grandes de forma eficiente. O CMETA fornece metadados detalhados ao nível da coluna e do bloco, acessíveis através de tabelas do sistema. Este sistema ajuda a melhorar o desempenho das consultas otimizando o acesso e o processamento de dados. Para acelerar ainda mais o desempenho das consultas em tabelas grandes, o BigQuery mantém uma cache de metadados. As tarefas de atualização de CMETA mantêm esta cache atualizada.

Os metadados incluem nomes de ficheiros, informações de partição e metadados físicos de ficheiros, como a contagem de linhas. Pode optar por ativar ou não a colocação em cache de metadados numa tabela. As consultas com um grande número de ficheiros e com filtros de partição do Apache Hive beneficiam mais da colocação em cache de metadados.

Se não ativar a colocação em cache de metadados, as consultas na tabela têm de ler a origem de dados externa para obter os metadados de objetos. A leitura destes dados aumenta a latência da consulta. A listagem de milhões de ficheiros da origem de dados externa pode demorar vários minutos. Se ativar a colocação em cache de metadados, as consultas podem evitar a apresentação de ficheiros da origem de dados externa e podem particionar e reduzir ficheiros mais rapidamente.

A colocação em cache de metadados também se integra com o controlo de versões de objetos do Cloud Storage. Quando a cache é preenchida ou atualizada, captura metadados com base na versão em direto dos objetos do Cloud Storage nesse momento. Como resultado, as consultas com a cache de metadados ativada leem os dados correspondentes à versão específica do objeto em cache, mesmo que versões mais recentes fiquem ativas no Cloud Storage. O acesso a dados de quaisquer versões de objetos atualizadas posteriormente no Cloud Storage requer uma atualização da cache de metadados.

Existem duas propriedades que controlam esta funcionalidade:

  • O tempo máximo de desatualização especifica quando as consultas usam metadados em cache.
  • O modo de cache de metadados especifica como os metadados são recolhidos.

Quando tem a colocação em cache de metadados ativada, especifica o intervalo máximo de obsolescência dos metadados que é aceitável para operações na tabela. Por exemplo, se especificar um intervalo de 1 hora, as operações na tabela usam metadados em cache se tiverem sido atualizados na última hora. Se os metadados em cache forem mais antigos, a operação recorre à obtenção de metadados do armazenamento de dados (Amazon S3 ou Google Cloud Storage). Pode especificar um intervalo de desatualização entre 30 minutos e 7 dias.

Quando ativa o armazenamento em cache de metadados para tabelas de objetos ou do BigLake, o BigQuery aciona tarefas de atualização da geração de metadados. Pode optar por atualizar a cache de forma automática ou manual:

  • Para as atualizações automáticas, a cache é atualizada a um intervalo definido pelo sistema, normalmente entre 30 e 60 minutos. A atualização automática da cache é uma boa abordagem se os ficheiros no armazenamento de dados forem adicionados, eliminados ou modificados em intervalos aleatórios. Se precisar de controlar a sincronização da atualização, por exemplo, para acionar a atualização no final de uma tarefa de extração, transformação e carregamento, use a atualização manual.

  • Para atualizações manuais, executa o procedimento do sistema BQ.REFRESH_EXTERNAL_METADATA_CACHE para atualizar a cache de metadados de acordo com uma programação que cumpra os seus requisitos. Para tabelas BigLake, pode atualizar os metadados seletivamente indicando subdiretórios do diretório de dados da tabela. Isto permite-lhe evitar o processamento de metadados desnecessários. A atualização manual da cache é uma boa abordagem se os ficheiros no armazeno de dados forem adicionados, eliminados ou modificados a intervalos conhecidos, por exemplo, como resultado de um pipeline.

    Se emitir várias atualizações manuais em simultâneo, apenas uma é bem-sucedida.

A cache de metadados expira após 7 dias se não for atualizada.

As atualizações manuais e automáticas da cache são executadas com a prioridade de consulta INTERACTIVE.

Use reservas do BACKGROUND

Se optar por usar atualizações automáticas, recomendamos que crie uma reserva e, em seguida, crie uma atribuição com um BACKGROUNDtipo de tarefa para o projeto que executa as tarefas de atualização da cache de metadados. Com as reservas BACKGROUND, as tarefas de atualização usam um conjunto de recursos dedicado que impede que as tarefas de atualização concorram com as consultas dos utilizadores e impede que as tarefas falhem potencialmente se não houver recursos suficientes disponíveis para as mesmas.

Embora a utilização de um conjunto de intervalos partilhado não incorra em custos adicionais, a utilização de reservas BACKGROUND oferece um desempenho mais consistente através da atribuição de um conjunto de recursos dedicado e melhora a fiabilidade das tarefas de atualização e a eficiência geral das consultas no BigQuery.

Deve considerar a forma como os valores do intervalo de desatualização e do modo de colocação em cache de metadados interagem antes de os definir. Considere os seguintes exemplos:

  • Se estiver a atualizar manualmente a cache de metadados de uma tabela e definir o intervalo de desatualização para 2 dias, tem de executar o procedimento do sistema BQ.REFRESH_EXTERNAL_METADATA_CACHE a cada 2 dias ou menos se quiser que as operações na tabela usem metadados em cache.
  • Se estiver a atualizar automaticamente a cache de metadados de uma tabela e definir o intervalo de desatualização para 30 minutos, é possível que algumas das suas operações na tabela possam ler a partir do arquivo de dados se a atualização da cache de metadados demorar mais do que o habitual intervalo de 30 a 60 minutos.

Para encontrar informações sobre tarefas de atualização de metadados, consulte a vista INFORMATION_SCHEMA.JOBS, conforme mostrado no exemplo seguinte:

SELECT *
FROM `region-us.INFORMATION_SCHEMA.JOBS_BY_PROJECT`
WHERE job_id LIKE '%metadata_cache_refresh%'
AND creation_time > TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 6 HOUR)
ORDER BY start_time DESC
LIMIT 10;

Para tabelas BigLake do Cloud Storage baseadas em ficheiros Parquet, as estatísticas das tabelas são recolhidas durante a atualização da cache de metadados e usadas para melhorar os planos de consultas.

Para saber mais, consulte o artigo Colocação em cache de metadados.

Para mais informações sobre a definição de opções de colocação em cache de metadados, consulte os artigos Crie tabelas do BigLake no Amazon S3 ou Crie tabelas do BigLake no Cloud Storage.

Tabelas com cache ativada e vistas materializadas

Pode usar vistas materializadas em tabelas com a cache de metadados do BigLake ativada para melhorar o desempenho e a eficiência ao consultar dados estruturados armazenados no Cloud Storage ou no Amazon Simple Storage Service (Amazon S3). Estas vistas materializadas funcionam como vistas materializadas sobre tabelas de armazenamento geridas pelo BigQuery, incluindo as vantagens da atualização automática e do ajuste inteligente.

Integrações

As tabelas do BigLake são acessíveis a partir de várias outras funcionalidades do BigQuery e serviços da CLI gcloud, incluindo os seguintes serviços realçados.

Partilha do BigQuery (anteriormente Analytics Hub)

As tabelas do BigLake são compatíveis com a partilha. Os conjuntos de dados que contêm tabelas do BigLake podem ser publicados como partilhas de fichas. Os subscritores da partilha podem subscrever estas fichas, que aprovisionam um conjunto de dados só de leitura, denominado conjunto de dados associado, no respetivo projeto. Os subscritores podem consultar todas as tabelas no conjunto de dados associado, incluindo todas as tabelas do BigLake. Para mais informações, consulte o artigo Veja e subscreva fichas.

BigQuery ML

Pode usar o BigQuery ML para formar e executar modelos no BigLake no Cloud Storage.

Proteção de dados confidenciais

A proteção de dados confidenciais analisa as suas tabelas do BigLake para identificar e classificar dados confidenciais. Se forem detetados dados confidenciais, as transformações de desidentificação da Proteção de dados confidenciais podem ocultar, eliminar ou obscurecer de outra forma esses dados.

Custos

Os custos estão associados aos seguintes aspetos das tabelas do BigLake:

Se tiver reservas de slots, não lhe é cobrado qualquer valor pela consulta de tabelas externas. Em vez disso, são consumidos slots para estas consultas.

A tabela seguinte mostra como o seu modelo de preços afeta a forma como estes custos são aplicados:


Preços a pedido
Edições Standard, Enterprise e Enterprise Plus

Consultas
A faturação é feita com base nos bytes processados pelas consultas dos utilizadores.
Os slots nas atribuições de reservas com um QUERYtipo de tarefa são consumidos durante o tempo de consulta.

Atualizar manualmente a cache de metadados.
A faturação é feita pelos bytes processados para atualizar a cache.
Vagas em atribuições de reservas com um QUERYtipo de tarefa são consumidas durante a atualização da cache.

Atualizar automaticamente a cache de metadados.
A faturação é feita pelos bytes processados para atualizar a cache.
Vagas em atribuições de reservas com um BACKGROUNDtipo de tarefa são consumidas durante a atualização da cache.

Se não existirem reservas BACKGROUND disponíveis para atualizar a cache de metadados, o BigQuery usa automaticamente as posições nas reservas QUERY, se estiver a usar a edição Enterprise ou Enterprise Plus.

Também lhe é cobrado o armazenamento e o acesso aos dados pelo Cloud Storage, Amazon S3 e Azure Blob Storage, sujeito às diretrizes de preços de cada produto.

O que se segue?