Para executar consultas em tempo real de dados analíticos junto com seus dados operacionais sem criar pipelines complexos, use a federação de lakehouse no AlloyDB para PostgreSQL. Com a tecnologia da extensão bigquery_fdw, o AlloyDB encaminha suas consultas para o BigQuery para acessar dados ativos e formatos abertos, como o Apache Iceberg, usando tabelas externas do BigLake, eliminando a necessidade de migrações complexas de ETL (extração, transformação e carregamento).
Benefícios da federação de lakehouse
A abordagem de federação de lakehouse oferece os seguintes benefícios:
- ETL zero: consulte dados analíticos diretamente sem criar ou manter pipelines complexos.
- Sintaxe familiar: use a sintaxe padrão do PostgreSQL para consultar dados do BigQuery.
- Insights em tempo real: acesse dados atualizados junto com suas tabelas operacionais.
- Descarregue a computação: use o mecanismo distribuído do BigQuery para tarefas pesadas com a otimização de pushdown.
- Acesso autorizado: para garantir que apenas contas de serviço autorizadas possam consultar dados externos, use o Identity and Access Management (IAM) para controle de acesso centralizado.
Casos de uso
A federação de lakehouse oferece suporte aos seguintes casos de uso comerciais e técnicos:
- Cargas de trabalho de processamento transacional e analítico híbrido (HTAP): é possível consultar dados operacionais em tempo real no AlloyDB e dados históricos ou analíticos no BigQuery ou no Cloud Storage simultaneamente sem afetar o desempenho transacional.
- Insights em tempo real sem pipelines frágeis: é possível evitar a latência e os modos de falha dos processos tradicionais de ETL. Acesse dados analíticos atualizados instantaneamente para tomar decisões de negócios com base nas informações mais recentes.
- Materialização de dados para fluxos de trabalho de agentes: é possível materializar dados analíticos externos no AlloyDB para usar o mecanismo colunar e os recursos de IA do AlloyDB. Isso permite pesquisas vetoriais de alto desempenho, incorporações de machine learning e fluxos de trabalho de agentes avançados orientados por IA nos seus dados federados.
Arquitetura e fluxo de dados
O diagrama a seguir mostra o fluxo de dados e as interações de componentes ao usar a federação de lakehouse:
A seguir, descrevemos o processo de fluxo de dados para federação de lakehouse no AlloyDB:
- Envio de consulta: você envia uma consulta padrão do PostgreSQL para sua instância do AlloyDB.
- Planejamento e otimização de consultas: o planejador de consultas do AlloyDB identifica tabelas mapeadas para conjuntos de dados externos do BigQuery usando o wrapper de dados externos (FDW, na sigla em inglês) do BigQuery.
- Otimização de pushdown: o AlloyDB otimiza a consulta enviando filtros e agregações específicos diretamente para o BigQuery. Isso garante que a rede transfira apenas as linhas filtradas relevantes ou resumos pré-agregados.
- Execução e recuperação: o BigQuery executa a parte da consulta, verificando diretamente o armazenamento integrado do BigQuery ou lendo tabelas do Apache Iceberg armazenadas no Cloud Storage, e transmite o conjunto de dados resultante de volta para o AlloyDB.
- Processamento e resposta finais: o AlloyDB combina os dados externos com tabelas operacionais locais, conclui o processamento de consultas restante e retorna o resultado final ao aplicativo.
Considerações sobre o tipo de dados para consultas federadas
Ao consultar uma tabela externa do BigQuery no AlloyDB usando a federação de lakehouse, o planejador de consultas do AlloyDB interpreta os tipos de dados do BigQuery como tipos de dados correspondentes do PostgreSQL. É fundamental entender esses mapeamentos para escrever consultas corretas e para as definições de tabelas externas usadas pela extensão bigquery_fdw.
Se um tipo de dados do BigQuery não tiver um mapeamento direto ou exigir um tratamento especial, talvez seja necessário usar funções CAST explícitas nas consultas ou criar uma visualização no BigQuery que apresente os dados com tipos compatíveis.
Para uma lista de tipos de dados compatíveis e os tipos correspondentes do PostgreSQL, consulte Mapeamentos de tipos de dados.
Segurança e controle de acesso
O acesso aos dados do BigQuery no AlloyDB é gerenciado pelo IAM. É necessário conceder papéis específicos do IAM à conta de serviço do cluster do AlloyDB para definir quais conjuntos de dados e tabelas podem ser consultados. Isso ajuda a garantir que as consultas federadas sigam as políticas de governança de dados centralizadas da sua organização sem comprometer a segurança. Para mais informações, consulte Papéis necessários.
Push-down
É possível usar técnicas de pushdown de filtro e agregação, que aceleram as consultas e reduzem os custos filtrando ou resumindo dados no BigQuery antes que eles sejam movidos ou processados pelo AlloyDB. Essa abordagem minimiza o tráfego de rede e o uso da memória, permitindo analisar conjuntos de dados enormes de maneira rápida e eficiente sem exceder os limites de recursos.
Pushdown de filtro
O pushdown de filtro, também conhecido como pushdown de predicado, é uma técnica de otimização
que move a filtragem de dados o mais próximo possível da camada de armazenamento, movendo os filtros de consulta (usando a cláusula WHERE) do
AlloyDB para o BigQuery.
Com o pushdown de filtro, é possível usar consultas SQL com uma cláusula WHERE para acessar um subconjunto de dados da tabela remota. Esses dados também podem ser materializados em uma tabela local ou anexados como uma partição local a uma tabela do PostgreSQL.
As operações compatíveis com o pushdown de filtro incluem:
- Operadores de comparação padrão:
=,<,>,<=,>=,<> - Operadores lógicos:
AND,OReNOT - Correspondência de padrões:
LIKEeNOT LIKE - Verificações de nulos:
IS NULLeIS NOT NULL - Avaliação na lista:
INeNOT IN
Pushdown agregado
O pushdown agregado é uma otimização avançada de banco de dados que realiza cálculos, por exemplo, SUM, COUNT, AVG ou GROUP BY, o mais próximo possível da camada de armazenamento. Esse pushdown avalia as funções de resumo diretamente no BigQuery, o que pode reduzir significativamente o número de linhas retornadas ao AlloyDB.
As operações compatíveis com o pushdown agregado incluem:
SUMCOUNTAVGMINMAX
Pushdown de limite
O pushdown de limite (que inclui o pushdown OFFSET) é uma técnica de otimização que move as cláusulas LIMIT e OFFSET da consulta do AlloyDB para o BigQuery.
Isso permite que o BigQuery retorne apenas o subconjunto específico de linhas solicitado, o que reduz significativamente o tráfego de rede e a latência de consulta.
O pushdown de limite é aplicado automaticamente sempre que possível. Verifique se as seguintes condições são atendidas:
- A consulta não usa a opção
WITH TIESna cláusulaFETCH FIRST. - As expressões
LIMITeOFFSETsão constantes básicas ou expressões que podem ser avaliadas remotamente.
Custo e faturamento do BigQuery
O wrapper de dados externos do BigQuery depende do seguinte:
- Preços de computação do BigQuery
- Preços da API BigQuery Storage
Para mais informações, consulte Preços do BigQuery.
Projetos de ambiente de execução
No BigQuery, é possível armazenar os dados em um projeto e executar as consultas em outro. O projeto que executa as consultas e acumula os custos de computação é conhecido como projeto de ambiente de execução (ou projeto de faturamento).
Separar o projeto de ambiente de execução do projeto de armazenamento de dados permite isolar os custos de computação para centros de custo específicos, gerenciar cotas de forma independente e controlar os gastos em diferentes cargas de trabalho sem mover os dados subjacentes.
Ao configurar o AlloyDB para acessar dados do BigQuery, é possível especificar um projeto de ambiente de execução no nível do servidor (aplicando a todas as tabelas externas associadas) ou no nível da tabela individual. Se você não especificar um projeto de ambiente de execução, o AlloyDB usará por padrão o projeto que é proprietário dos dados.
Limitações
O AlloyDB e o BigQuery podem usar agrupamentos padrão diferentes, o que pode resultar em resultados de ordenação de dados ou comparação de strings que diferem entre os dois sistemas. Por exemplo, o agrupamento padrão do PostgreSQL nas versões 15, 16 e 17 pode processar a diferenciação de maiúsculas e minúsculas de maneira diferente durante a classificação do agrupamento padrão do BigQuery, que avalia estritamente as strings com base nos pontos de código Unicode.
Para qualquer parte de uma consulta executada remotamente no BigQuery, o agrupamento segue as configurações do BigQuery. Para reduzir conflitos de ordenação, considere usar a ordenação
C.UTF-8sem ICU no AlloyDB e a ordenação padrão (vazia) no BigQuery.As consultas que retornam uma grande quantidade de dados do BigQuery, após o pushdown, não são otimizadas.
Ao criar uma tabela externa, o AlloyDB não valida ativamente a existência ou o esquema da tabela remota do BigQuery.
Se uma consulta federada exigir a leitura de uma grande quantidade de dados, por exemplo, se os pushdowns de filtro não puderem ser aplicados, a consulta poderá falhar devido aos limites de tamanho da resposta da API BigQuery. Os limites máximos de tamanho da resposta do BigQuery ainda se aplicam. Para mais informações sobre esses limites, consulte Cotas e limites.
O PostgreSQL oferece suporte a maior precisão para cálculos intermediários, enquanto o BigQuery controla estritamente a precisão decimal. Essa diferença pode resultar em perda de precisão ou erros de estouro durante cálculos complexos. Para mais informações, consulte Tipos decimais.
O Database Migration Service não oferece suporte à migração de tabelas externas criadas usando a extensão
bigquery_fdw. Como solução alternativa, é possível excluir as tabelas externas do job de migração ou descartá-las antes de iniciar a migração e, em seguida, recriá-las no cluster de destino do AlloyDB após a conclusão da migração.Ao consultar tabelas externas usando a extensão
bigquery_fdw, o BigQuery avalia as permissões de acesso a dados com base na conta de serviço do cluster do AlloyDB. Mesmo que os usuários do banco de dados façam login usando a autenticação do banco de dados do IAM, as permissões de usuário individuais do IAM não são verificadas nas tabelas remotas do BigQuery. Para mais informações, consulte Conceder acesso do AlloyDB ao conjunto de dados do BigQuery.