Introdução às tabelas externas do BigLake

Este documento apresenta uma visão geral do BigLake e supõe que você tenha familiaridade com tabelas de banco de dados e Identity and Access Management (IAM). Para consultar os dados armazenados nos armazenamentos de dados compatíveis, crie as tabelas do BigLake e, em seguida, consulte-as usando a sintaxe do GoogleSQL:

Também é possível fazer upgrade de uma tabela externa para o BigLake. Para mais informações, consulte Fazer upgrade de uma tabela externa para o BigLake.

Com as tabelas do BigLake, é possível consultar dados estruturados em repositórios de dados externos com delegação de acesso. A delegação de acesso desacopla o acesso à tabela do BigLake ao acesso ao armazenamento de dados subjacente. Uma conexão externa associada a uma conta de serviço é usada para se conectar ao armazenamento de dados. Como a conta de serviço processa a recuperação de dados do armazenamento de dados, você só precisa conceder aos usuários acesso à tabela do BigLake. Isso permite aplicar segurança detalhada no nível da tabela, incluindo segurança no nível da linha e no nível da coluna. Nas tabelas do BigLake baseadas no Cloud Storage, também é possível usar o mascaramento de dados dinâmicos. Para saber mais sobre soluções de análise de várias nuvens usando tabelas do BigLake com dados do Amazon S3 ou do Blob Storage, consulte BigQuery Omni.

Armazenamentos de dados com suporte

É possível usar tabelas do BigLake com os seguintes armazenamentos de dados:

Suporte a 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 precisam ser permanentes.

Vários arquivos de origem

É possível criar uma tabela do BigLake com base em várias fontes de dados externas, desde que essas fontes tenham o mesmo esquema.

Mesclagens entre nuvens

As mesclagens entre nuvens permitem executar consultas que abrangem as regiões do Google Cloud e do BigQuery Omni. É possível usar as operações JOIN do GoogleSQL para analisar dados em várias soluções de armazenamento diferentes, como AWS, Azure, conjuntos de dados públicos e outros serviços do Google Cloud. As mesclagens entre nuvens eliminam a necessidade de copiar dados entre fontes antes de executar consultas.

É possível referenciar tabelas do BigLake em qualquer lugar em uma instrução SELECT como se fossem tabelas padrão do BigQuery, inclusive em instruções de linguagem de manipulação de dados (DML, na sigla em inglês) e instruções de linguagem de definição de dados (DDL, na sigla em inglês) que usam subconsultas para recuperar dados. É possível usar várias tabelas do BigLake de diferentes nuvens e tabelas do BigQuery na mesma consulta. Todas as tabelas do BigQuery precisam ser da mesma região.

Permissões necessárias para mesclagem entre nuvens

Para ter as permissões necessárias para executar uma mesclagem entre nuvens, peça ao administrador para conceder a você o papel do IAM Editor de dados do BigQuery (roles/bigquery.dataEditor) no projeto em que a mesclagem será executada. Para mais informações sobre a concessão de papéis, consulte Gerenciar o acesso a projetos, pastas e organizações.

Esse papel predefinido contém as permissões necessárias para executar uma mesclagem entre nuvens. Para conferir as permissões exatas necessárias, expanda a seção Permissões necessárias:

Permissões necessárias

As seguintes permissões são necessárias para executar uma mesclagem entre nuvens:

  • bigquery.datasets.create
  • bigquery.tables.create

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

As junções entre nuvens criam conjuntos de dados com o prefixo __bigquery_xregion_sink_ e tabelas temporárias dentro desses conjuntos de dados. Portanto, para conceder acesso apenas a recursos criados por mesclagens entre nuvens, use a função resource.name.startsWith para os tipos de recurso Table e Dataset.

Para mais informações sobre os papéis e as permissões do IAM no BigQuery, consulte Introdução ao IAM.

Custos da mesclagem entre nuvens

Quando você executa uma operação de mesclagem 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 em uma operação CREATE TABLE AS SELECT (CTAS) na tabela do BigLake referenciada na região do BigQuery Omni, que cria uma tabela temporária na região do BigQuery. Em seguida, o BigQuery usa essa tabela temporária para executar a mesclagem entre nuvens e a exclui automaticamente após oito horas.

Há cobrança pela transferência de dados nas tabelas referenciadas do BigLake. No entanto, o BigQuery ajuda a reduzir esses custos transferindo apenas as colunas e linhas na tabela do BigLake que são referenciadas na consulta, e não a tabela inteira. Recomendamos especificar um filtro de coluna da forma mais restrita possível para reduzir ainda mais os custos de transferência. O job de CTAS é exibido no histórico de jobs e exibe informações como o número de bytes transferidos. Transferências bem-sucedidas geram custos mesmo que o job 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
);

Esse 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 mesclagem é realizada na região do BigQuery após a transferência. Se uma transferência falhar e a outra for bem-sucedida, as cobranças pela transferência de dados ainda serão aplicadas à transferência bem-sucedida.

Limitações da mesclagem entre nuvens

  • As mesclagens entre nuvens não são compatíveis com o nível gratuito do BigQuery e o sandbox do BigQuery.
  • As agregações talvez não sejam transferidas para as regiões do BigQuery Omni se a consulta contiver instruçõ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 para cada transferência é de 60 GB. Especificamente, se você aplicar um filtro em uma tabela do BigLake e carregar o resultado, ele precisará ser menor que 60 GB. Se necessário, solicite um limite de cota maior. Não há limite de bytes verificados.
  • As consultas de mesclagem entre nuvens empregam uma cota interna na taxa de consultas. Se a taxa de consultas exceder a cota, talvez você receba um erro All our servers are busy processing data transferred between regions. Tentar a consulta novamente deve funcionar na maioria dos casos. Entre em contato com o suporte para aumentar a cota interna e dar suporte a uma taxa mais alta de consultas.
  • As mesclagens entre nuvens só são possíveis em regiões colocalizadas do BigQuery com as regiões correspondentes do BigQuery Omni e nas multirregiões US e EU. As mesclagens entre nuvens executadas nas multirregiões US ou EU só podem acessar dados nas regiões do BigQuery Omni nos EUA ou na UE, respectivamente.
  • Se uma consulta de mesclagem entre nuvens fizer referência a 10 ou mais conjuntos de dados de regiões do BigQuery Omni, ela poderá falhar com um erro Not found: Dataset <BigQuery dataset> was not found in location <BigQuery Omni region>. Para evitar esse problema, recomendamos especificar explicitamente um local ao executar uma mesclagem entre nuvens com referência a mais de 10 conjuntos de dados. Lembre-se que se você especificar explicitamente uma região do BigQuery e a consulta contiver apenas tabelas do BigLake, ela será executada como uma consulta entre nuvens, gerando custos de transferência de dados.
  • Não é possível consultar a pseudocoluna _FILE_NAME com mesclagens entre nuvens.
  • Ao referenciar as colunas de uma tabela do BigLake em uma cláusula WHERE, não é possível usar literais INTERVAL ou RANGE.
  • Os jobs de mesclagem entre nuvens não informam o número de bytes processados e transferidos de outras nuvens. Essas informações estão disponíveis nos jobs-filhos de CTAS criados como parte da execução de consultas entre nuvens.
  • As visualizações autorizadas e rotinas autorizadas que fazem referência a tabelas ou visualizações do BigQuery Omni são compatíveis apenas com regiões do BigQuery Omni.
  • Se a consulta entre nuvens fizer referência a colunas STRUCT ou JSON, nenhum pushdown será aplicado a subconsultas remotas. Para otimizar o desempenho, crie uma visualização na região do BigQuery Omni que filtre as colunas STRUCT e JSON e retorne apenas os campos necessários como colunas individuais.
  • As consultas de viagem no tempo não são compatíveis com mesclagens entre nuvens.

Exemplos de mesclagem entre nuvens

A consulta a seguir mescla uma tabela orders em uma região do BigQuery com uma tabela lineitem em uma 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;

Essa consulta é dividida em partes locais e remotas. A consulta a seguir é enviada à região do BigQuery Omni para ser executada primeiro. O resultado é uma tabela temporária na região do BigQuery. É possível ver esse job de CTAS filho e respectivos metadados no histórico de jobs.

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'
);

Após a criação da tabela temporária, a operação JOIN é concluída e a seguinte consulta é 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 mesclagem 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;

Nessa 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, o limite de 10 é aplicado.

Conectores

É possível acessar dados em tabelas do BigLake baseadas no Cloud Storage de outras ferramentas de processamento de dados usando conectores do BigQuery. Por exemplo, é possível acessar dados nas tabelas do BigLake doApache Spark, Apache Hive, TensorFlow, Trino ou Presto. A API BigQuery Storage aplica políticas de governança no nível da linha e da coluna em todo o acesso aos dados nas tabelas do BigLake, inclusive por conectores.

Por exemplo, o diagrama a seguir demonstra como a API BigQuery Storage permite que os usuários acessem dados autorizados usando mecanismos de consulta de código aberto, como o Apache Spark:

Arquitetura do BigLake.

Para mais informações sobre os conectores compatíveis com o BigQuery, consulte Conectores do BigQuery.

Tabelas BigLake em armazenamentos de objetos

Para administradores do data lake, o BigLake permite que você defina os controles de acesso em tabelas em vez de arquivos, o que oferece opções mais refinadas ao definir o acesso do usuário aos dados no data lake.

Como as tabelas do BigLake simplificam o controle de acesso dessa maneira, recomendamos o uso de tabelas do BigLake para criar e manter conexões com armazenamentos de objetos externos.

É possível usar tabelas externas nos casos em que a governança não é um requisito ou para descoberta e manipulação de dados ad hoc.

Limitações

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

  • O BigLake não oferece suporte a credenciais com escopo reduzido do Dataproc Personal Cluster Authentication. Como solução alternativa, para usar clusters com a autenticação de cluster pessoal, é necessário injetar suas credenciais usando um limite de acesso a credenciais vazio com a flag --access-boundary=<(echo -n "{}"). Por exemplo, o comando a seguir ativa uma sessão de propagação de credencial em um projeto chamado myproject para o cluster chamado mycluster: 

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

  • As tabelas do BigLake são somente leitura. Não é possível modificar as tabelas do BigLake usando instruções DML ou outros métodos.

  • As tabelas do BigLake oferecem suporte para os seguintes formatos:

  • Não é possível usar metadados armazenados em cache com tabelas externas do BigLake para o Apache Iceberg. O BigQuery já usa os metadados capturados pelo Iceberg nos arquivos de manifesto.

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

  • Se você usa metadados armazenados em cache, as seguintes limitações se aplicam:

    • Só é possível usar metadados armazenados em cache com tabelas do BigLake que usam os formatos Avro, ORC, Parquet, JSON e CSV.
    • Se você criar, atualizar ou excluir arquivos no Amazon S3, a consulta deles não retornará os dados atualizados até a próxima atualização do cache de metadados. Isso pode levar a resultados inesperados. Por exemplo, se você excluir um arquivo e gravar um novo, os resultados da consulta poderão excluir os arquivos antigos e novos, dependendo de quando os metadados armazenados em cache foram atualizados pela última vez.
    • O uso de chaves de criptografia gerenciadas pelo cliente (CMEK, na sigla em inglês) com metadados em cache não é compatível com tabelas do BigLake que fazem referência a dados do Amazon S3 ou do Blob Storage.

Modelo de segurança

Os papéis organizacionais a seguir geralmente são envolvidos no gerenciamento e no uso de tabelas do BigLake:

  • Administradores do data lake. Esses administradores normalmente gerenciam políticas de gerenciamento de identidade e acesso (IAM) em buckets e objetos do Cloud Storage.
  • Administradores de armazenamento de dados. Esses administradores geralmente criam, excluem e atualizam tabelas do BigLake.
  • Analistas de dados. Normalmente, os analistas leem dados e executam consultas.

Os administradores do data lake são responsáveis por criar conexões e compartilhá-las com administradores de data warehouses. Por sua vez, os administradores de data warehouse definem tabelas, definem controles de acesso apropriados e compartilham as tabelas com analistas de dados.

Armazenamento em cache de metadados para desempenho

É possível usar metadados em cache para melhorar o desempenho da consulta em alguns tipos de tabelas do BigLake. Armazenar metadados em cache é muito útil nos casos em que você está trabalhando com um grande número de arquivos ou quando os dados são particionados no Hive. Os seguintes tipos de tabelas do BigLake são compatíveis com o armazenamento em cache de metadados:

  • Tabelas do Amazon S3 BigLake
  • Tabelas do BigLake do Cloud Storage
Os metadados incluem nomes de arquivos, informações de particionamento e metadados físicos de arquivos, como contagens de linhas. Você pode escolher se quer ativar o armazenamento em cache de metadados em uma tabela. As consultas com um grande número de arquivos e os filtros de partição do Hive são mais beneficiados com o armazenamento em cache de metadados.

Se você não ativar o armazenamento em cache de metadados, as consultas na tabela precisarão ler a fonte de dados externa para receber os metadados do objeto. A leitura desses dados aumenta a latência da consulta. Listar milhões de arquivos da fonte de dados externa pode levar vários minutos. Se você ativar o armazenamento em cache de metadados, as consultas podem evitar a listagem de arquivos da fonte de dados externa e podem particionar e remover arquivos mais rapidamente.

Há duas propriedades que controlam esse recurso:

  • A inatividade máxima especifica quando as consultas usam metadados armazenados em cache.
  • O modo de cache de metadados especifica como os metadados são coletados.

Quando o armazenamento em cache de metadados está ativado, você especifica o intervalo máximo de inatividade dos metadados que é aceitável para operações na tabela. Por exemplo, se você especificar um intervalo de uma hora, as operações na tabela usarão metadados em cache se eles tiverem sido atualizados na última hora. Se os metadados armazenados em cache forem mais antigos que isso, a operação voltará à recuperação de metadados do repositório de dados (Amazon S3 ou Cloud Storage). É possível especificar um intervalo de inatividade entre 30 minutos e 7 dias.

É possível atualizar o cache de maneira automática ou manual:

  • Para atualizações automáticas, o cache é atualizado em um intervalo definido pelo sistema, geralmente entre 30 e 60 minutos. A atualização automática do cache é uma boa abordagem quando os arquivos no repositório de dados são adicionados, excluídos ou modificados em intervalos aleatórios. Se você precisar controlar o tempo da atualização, por exemplo, para acioná-la no final de um job extract-transform-load, use a atualização manual.

  • No caso de atualizações manuais, execute o procedimento do sistema BQ.REFRESH_EXTERNAL_METADATA_CACHE para atualizar o cache de metadados de acordo com uma programação que atenda aos seus requisitos. Para tabelas do BigLake, é possível atualizar os metadados de maneira seletiva fornecendo subdiretórios do diretório de dados da tabela. Isso permite evitar o processamento desnecessário de metadados. A atualização manual do cache é uma boa abordagem quando os arquivos no repositório de dados são adicionados, excluídos ou modificados em intervalos conhecidos, como a saída de um pipeline.

    Se você emitir várias atualizações manuais simultâneas, apenas uma vai ser bem-sucedida.

O cache de metadados expira após sete dias se não for atualizado.

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

Se você optar por usar atualizações automáticas, recomendamos que crie uma reserva e, em seguida, crie umuma tarefaBACKGROUND tipo de job para o projeto que executa os jobs de atualização do cache de metadados. Isso impede que os jobs de atualização compitam com as consultas do usuário por recursos e podem falhar se não houver recursos suficientes disponíveis.

Pense em como os valores do intervalo de inatividade e do modo de armazenamento em cache de metadados vão interagir antes de serem definidos. Confira estes exemplos:

  • Se você estiver atualizando manualmente o cache de metadados de uma tabela e definir o intervalo de inatividade como dois dias, será necessário executar o procedimento do sistema BQ.REFRESH_EXTERNAL_METADATA_CACHE a cada dois dias ou menos se quiser operações na tabela para usar metadados em cache.
  • Se você estiver atualizando automaticamente o cache de metadados de uma tabela e definir o intervalo de inatividade como 30 minutos, é possível que algumas das operações na tabela sejam lidas pelo repositório de dados se a atualização dos metadados de cache levar mais tempo do que a janela normal de 30 a 60 minutos.

Para encontrar informações sobre jobs de atualização de metadados, consulte a visualização INFORMATION_SCHEMA.JOBS, como mostrado no exemplo a seguir:

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 do BigLake do Cloud Storage baseadas em arquivos Parquet, as estatísticas da tabela são coletadas durante a atualização do cache de metadados e usadas para melhorar os planos de consulta.

Para saber mais, consulte Armazenamento de metadados em cache.

Para mais informações sobre como definir opções de armazenamento em cache de metadados, consulte Criar tabelas do Amazon S3 BigLake ou Criar tabelas do BigLake do Cloud Storage.

Tabelas ativadas em cache com visualizações materializadas

É possível usar visualizações materializadas em tabelas ativadas com cache de metadados do BigLake para melhorar o desempenho e a eficiência ao consultar dados estruturados armazenados no Cloud Storage ou no Amazon Simple Storage Service (Amazon S3). Essas visualizações materializadas funcionam como visualizações materializadas em tabelas de armazenamento gerenciadas pelo BigQuery, incluindo os benefícios da atualização automática e do ajuste inteligente.

Integrações

As tabelas do BigLake são acessíveis a partir de vários outros recursos do BigQuery e dos serviços da CLI gcloud, incluindo os seguintes serviços destacados.

Analytics Hub

As tabelas do BigLake são compatíveis com o Analytics Hub. Os conjuntos de dados que contêm tabelas do BigLake podem ser publicados como listagens do Analytics Hub. Os assinantes do Analytics Hub podem se inscrever nessas listagens, que provisionam um conjunto de dados somente leitura, chamado de conjunto de dados vinculado no projeto. Os assinantes podem consultar todas as tabelas no conjunto de dados vinculado, incluindo todas as tabelas do BigLake. Para mais informações, consulte Visualizar e assinar listagens.

BigQuery ML

Use o BigQuery ML para treinar e executar modelos no BigLake no Cloud Storage.

Proteção de dados sensíveis

A Proteção de dados confidenciais verifica suas tabelas do BigLake para identificar e classificar dados confidenciais. Se dados confidenciais forem detectados, as transformações de desidentificação da Proteção de dados confidenciais poderão mascarar, excluir ou ocultar esses dados.

Custos

Os custos são associados aos seguintes aspectos das tabelas do BigLake:

Se você tiver reservas de slot, não receberá cobranças por consultar tabelas externas. Em vez disso, os slots são consumidos por essas consultas.

A tabela a seguir mostra como o modelo de preços afeta a aplicação desses custos:


Preços sob demanda
Edições Standard, Enterprise e Enterprise Plus

Consultas
Você é cobrado pelos bytes processados pelas consultas do usuário.
Slots em atribuições de reserva com um tipo de job QUERY são consumidos durante o tempo de consulta.

Atualização manual do cache de metadados.
Você paga pelos bytes processados para atualizar o cache.
Slots em atribuições de reserva com um tipo de job QUERY são consumidos durante a atualização do cache.

Atualização automática do cache de metadados.
Você paga pelos bytes processados para atualizar o cache.
Slots em atribuições de reserva com um tipo de job BACKGROUND são consumidos durante a atualização do cache.

Se não houver reservas BACKGROUND disponíveis para atualizar o cache de metadados, o BigQuery usará automaticamente slots em reservas QUERY se você estiver usando a edição Enterprise ou Enterprise Plus.

O Cloud Storage, Amazon S3, e o Armazenamento de Blobs do Azure também cobra pelo armazenamento e acesso, sujeitos sàs diretrizes de preços de cada produto.

A seguir