Pular para o conteúdo principal

recomendações de desempenho da lakehouse Federation

Este artigo fornece orientações para melhorar o desempenho das consultas da Lakehouse Federation.

Combine vários predicados usando o operador AND​

O Databricks Runtime tenta enviar predicados ao mecanismo de banco de dados remoto para reduzir o número de registros buscados pela rede. Se um predicado não puder ser enviado, a consulta executada no mecanismo de banco de dados remoto excluirá o predicado, portanto a filtragem deverá ser feita usando o Databricks Runtime. Entretanto, se uma determinada parte do filtro não puder ser empurrada para baixo, outra parte do filtro ainda poderá ser empurrada para baixo se elas forem unidas pelo operador AND .

Exemplo 1​

Consulta do Databricks:

SQL
SELECT * FROM foreign_catalog.schema.table WHERE name ILIKE 'john'

A expressão ILIKE não pode ser enviada para o banco de dados remoto (por exemplo, MySQL) porque não há uma tradução apropriada. A filtragem deve ser feita usando o Databricks Runtime.

A consulta enviada ao banco de dados remoto retorna todos os registros:

SQL
SELECT * FROM catalog.schema.table

Exemplo 2​

Consulta do Databricks:

SQL
SELECT * FROM foreign_catalog.schema.table WHERE name ILIKE 'john' AND date > '2025-05-01'

A expressão ILIKE não pode ser enviada para o banco de dados remoto (por exemplo, MySQL) porque não há uma tradução apropriada, mas a comparação de datas pode ser enviada. A filtragem de nomes ainda precisa ser feita usando o Databricks Runtime, mas a comparação de datas deve reduzir o número de registros sendo buscados.

A consulta enviada ao banco de dados remoto retorna um subconjunto de registros:

SQL
SELECT * FROM catalog.schema.table WHERE date > '2025-05-01'

Verifique qual consulta será executada no banco de dados remoto​

Para ver qual consulta será enviada ao banco de dados remoto, execute o comando EXPLAIN FORMATTED .

info

A consulta real pode ser diferente da consulta na saída EXPLAIN FORMATTED devido à execução adaptável da consulta.

Defina o tamanho dos lotes obtidos do banco de dados remoto​

Você pode configurar os seguintes conectores, que usam o protocolo de transferência JDBC, para controlar como eles buscam dados de sistemas remotos.

  • Databricks
  • Microsoft SQL Server
  • Microsoft Azure Synapse
  • MySQL
  • Oracle
  • PostgreSQL
  • Redshift
  • Salesforce Data 360
  • Teradata

O tamanho da busca do JDBC determina o número de linhas a serem buscadas por viagem de ida e volta. Em default, a maioria dos conectores JDBC busca dados atomicamente. Isso pode fazer com que a quantidade de dados exceda a memória disponível.

Para evitar erros de falta de memória, defina o parâmetro fetchSize. Quando fetchSize é definido como um valor diferente de zero, o conector lê os dados em lotes. O número máximo de linhas por lote é igual ao valor de fetchSize. A Databricks recomenda especificar um valor fetchSize grande (por exemplo, 100,000) porque o tempo total de execução da consulta pode ser prolongado se o número de linhas em lotes for muito pequeno.

Esse parâmetro permite que os nós do worker leiam os dados em lotes, mas não em paralelo.

Requisitos de computação:

  • O senhor deve usar o site compute em Databricks Runtime 16.1 ou acima. SQL O warehouse deve ser Pro ou sem servidor e deve usar o 2024.50.
SQL
SELECT * FROM mySqlCatalog.schema.table WITH ('fetchSize' 100000)

Definir o parâmetro de tamanho da partição (Snowflake)​

Snowflake permite a busca de dados em várias partições, o que possibilita o envolvimento de vários executores e o processamento paralelo. É importante escolher um tamanho de partição apropriado definindo o parâmetro partition_size_in_mb. Esse parâmetro especifica o tamanho descompactado recomendado para cada partição. Para reduzir o número de partições, especifique um valor maior. O valor de default é 100 (MB).

O parâmetro partition_size_in_mb define um tamanho recomendado; o tamanho real das partições pode variar.

Requisitos de computação:

  • O senhor deve usar o site compute em Databricks Runtime 16.1 ou acima. SQL O warehouse deve ser Pro ou sem servidor e deve usar o 2024.50.
SQL
SELECT * FROM snowflakeCatalog.schema.table WITH ('partition_size_in_mb' 1000)

Habilite leituras paralelas para conectores JDBC​

Os conectores que suportam o protocolo de transferência JDBC podem ler dados em paralelo, dividindo a consulta. Você pode configurar leituras paralelas para os seguintes conectores:

  • Databricks
  • Microsoft SQL Server
  • Microsoft Azure Synapse
  • MySQL
  • Oracle
  • PostgreSQL
  • Redshift
  • Salesforce Data 360
  • Teradata

Isso permite que vários executores busquem dados simultaneamente, melhorando significativamente o desempenho para tabelas grandes.

Para ativar leituras paralelas, especifique os seguintes parâmetros:

  • numPartitions: O número de partições a serem usadas para paralelismo
  • partitionColumn: o nome de uma coluna numérica usada para particionar a consulta
  • lowerBound: O valor mínimo de partitionColumn usado para decidir o passo da partição
  • upperBound: O valor máximo de partitionColumn usado para decidir o passo da partição
info

Os valores lowerBound e upperBound são usados somente para decidir a distância da partição, não para filtrar as linhas na tabela. Todas as linhas na tabela serão particionadas e retornadas.

A coluna de partição deve ser:

  • Uma coluna numérica
  • Distribuído uniformemente em toda a gama
  • Uma coluna indexada para melhor desempenho

Requisitos de computação:

  • É necessário utilizar compute em Databricks Runtime 17.1 ou superior. SQL O armazém deve ser profissional ou de propriedade do cliente ( serverless ) e deve utilizar 2025.25.

No exemplo a seguir, a consulta será dividida em 4 partições paralelas com base na coluna id, com cada partição processando um intervalo de aproximadamente 250 IDs (supondo que haja um único registro para cada id entre 1 e 1000).

SQL
SELECT * FROM mySqlCatalog.schema.table WITH (
  'numPartitions' 4,
  'partitionColumn' 'id',
  'lowerBound' 1,
  'upperBound' 1000
)

junte-se ao pushdown na Federação Lakehouse​

info

Visualização

Este recurso está em Visualização Pública.

Aprenda como o pushdown join funciona no Databricks lakehouse Federation.

visão geral do pushdown de junção​

join pushdown é uma técnica de otimização de consultas em que Databricks envia operações join para o mecanismo de banco de dados remoto em vez de buscar dados e executar a join localmente. Isso reduz significativamente o tráfego de rede e melhora o desempenho da consulta aproveitando os recursos join integrados do banco de dados remoto.

Fonte de dados suportada​

A seguinte fonte de dados suporta join pushdown:

  • Oracle
  • PostgreSQL
  • MySQL
  • SQL Server
  • Teradata
  • Redshift
  • Snowflake
  • BigQuery

Este recurso está disponível ao público em geral e habilitado por default para Redshift, Snowflake e BigQuery. As seguintes limitações e requisitos se aplicam somente aos conectores Oracle, PostgreSQL, MySQL, SQL Server e Teradata.

Requisitos​

  • Você deve usar compute no Databricks Runtime 17.2 ou superior.
  • SQL Warehouse deve ser Pro ou sem servidor e deve usar 2025.30.
  • Na página Visualizações da interface do usuário Databricks , você deve ativar a opção Join Pushdown para consultas federadas (visualização pública) .

Limitações​

  • Somente junções interna, externa esquerda e externa direita são suportadas.
  • Aliases nos filhos de uma join são suportados somente no DBR 17.3 e acima.

Requisitos de hierarquia de nós​

Para que uma join seja empurrada para baixo, todos os nós nos ramos filhos esquerdo e direito também devem ser empurrados. As seguintes regras se aplicam:

  • Nós filhos suportados : somente nós de junção, filtros, amostra e varredura podem aparecer abaixo de uma join no plano de consulta para que o pushdown seja bem-sucedido.
  • Nós filhos não suportados : se operações de limite, deslocamento ou agregação aparecerem no ramo esquerdo ou direito abaixo de uma join, a join não poderá ser empurrada para baixo.
  • operações no topo da junção : operações de agregação, limite e deslocamento podem ser empurradas para baixo quando aplicadas no topo de uma join.

Exemplos​

SQL
-- Supported: Join two table scans
SELECT *
FROM table1
INNER JOIN table2
ON col_from_table1 = col_from_table2 + 1

-- Supported: Join two table scans with a nested select query
SELECT *
FROM (SELECT a FROM table1) q1
INNER JOIN (SELECT a FROM table2) q2
ON q1.a = q2.a + 1

-- Supported: Child subqueries with aliases in projection (DBR 17.3+)
SELECT *
FROM (SELECT a AS a1 FROM table1) t1
INNER JOIN (SELECT a AS a2 FROM table2) t2
ON t1.a1 = t2.a2 + 1

-- Supported: Join with filters below
SELECT *
FROM (SELECT * FROM table1 WHERE a > 10) t1
INNER JOIN (SELECT * FROM table2 WHERE b < 20) t2
ON t1.id = t2.id

-- Supported: Aggregate on top of join
SELECT COUNT(*)
FROM table1 t1
INNER JOIN table2 t2
ON t1.id = t2.id

-- Not supported: Join on top of aggregate
SELECT *
FROM (SELECT id, COUNT(*) as cnt FROM table1 GROUP BY id) t1
INNER JOIN table2 t2
ON t1.id = t2.id

-- Not supported: Join on top of limit
SELECT *
FROM (SELECT * FROM table1 LIMIT 100) t1
INNER JOIN table2 t2
ON t1.id = t2.id

Observabilidade​

Use EXPLAIN FORMATTED para verificar se sua join está sendo enviada para baixo:

SQL
EXPLAIN FORMATTED
SELECT *
FROM foreign_catalog.schema.table1 t1
INNER JOIN foreign_catalog.schema.table2 t2
ON t1.id = t2.id

Exemplo de saída mostrando pushdown join bem-sucedido:

== Physical Plan ==
*(1) Scan JDBCRelation
PushedFilters: [id = id_1],
PushedJoins:
   [L]: Relation: foreign_catalog.schema.table1
        PushedFilters: [ID IS NOT NULL]
   [R]: Relation: foreign_catalog.schema.table2
        PushedFilters: [ID IS NOT NULL]

Nesta saída:

  • id_1 é um alias que o Databricks gera automaticamente para resolver ambiguidade quando colunas têm nomes duplicados.
  • O PushedFilters acima PushedJoins representa as condições join reais que estão sendo enviadas ao banco de dados remoto.
  • O PushedFilters em cada relação ([L] e [R]) mostra predicados de filtro adicionais aplicados a cada tabela.
Última atualização em