Condividi tramite

Raccomandazioni sulle prestazioni di Lakehouse Federation

Questo articolo fornisce indicazioni per migliorare le prestazioni delle query di Lakehouse Federation.

Combinare più predicati usando l'operatore AND

Databricks Runtime tenta di spingere giù i predicati verso il motore di database remoto per ridurre il numero di record recuperati attraverso la rete. Se un predicato non può essere trasferito al motore di database remoto, la query eseguita su di esso esclude tale predicato, quindi il filtraggio deve essere eseguito usando Databricks Runtime. Tuttavia, se non è possibile applicare una determinata parte del filtro, un'altra parte del filtro può comunque essere applicata se sono unite dall'operatore AND.

Esempio 1

Query di Databricks:

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

Non è possibile eseguire il push dell'espressione ILIKE nel database remoto , ad esempio MySQL, perché non è disponibile alcuna traduzione appropriata. Il filtro deve essere eseguito usando Databricks Runtime.

La query inviata al database remoto restituisce tutti i record:

SELECT * FROM catalog.schema.table

Esempio 2

Query di Databricks:

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

Non è possibile trasmettere l'espressione ILIKE al database remoto, ad esempio MySQL, perché non esiste una traduzione appropriata, ma il confronto tra le date può essere elaborato. Il filtro dei nomi deve comunque essere eseguito usando Databricks Runtime, ma il confronto tra date dovrebbe ridurre il numero di record recuperati.

La query inviata al database remoto restituisce un subset di record:

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

Controllare quale query verrà eseguita nel database remoto

Per vedere quale query verrà inviata al database remoto, eseguire il EXPLAIN comando FORMATTED .

Importante

La query effettiva potrebbe differire dalla query nell'output a causa dell'EXPLAIN FORMATTED.

Impostare le dimensioni dei batch recuperati dal database remoto

È possibile configurare i connettori seguenti, che usano il protocollo di trasferimento JDBC, per controllare come recuperano i dati dai sistemi remoti.

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

La dimensione di prelievo JDBC determina il numero di righe da recuperare per ogni ciclo. Per impostazione predefinita, la maggior parte dei connettori JDBC recupera i dati in modo atomico. Ciò potrebbe causare il superamento della memoria disponibile a causa della quantità di dati.

Per evitare errori di memoria insufficiente, impostare il parametro fetchSize. Quando fetchSize è impostato su un valore diverso da zero, il connettore legge i dati in batch. Il numero massimo di righe per batch è uguale al valore di fetchSize. Databricks consiglia di specificare un valore di grandi dimensioni fetchSize , ad esempio 100,000, perché il tempo di esecuzione complessivo della query può essere prolungato se il numero di righe in batch è troppo piccolo.

Questo parametro consente ai nodi di lavoro di leggere i dati in batch, ma non in parallelo.

Requisiti di calcolo:

  • È necessario usare il calcolo in Databricks Runtime 16.1 o versione successiva. I warehouse SQL devono essere Pro o Serverless e devono usare 2024.50.
SELECT * FROM mySqlCatalog.schema.table WITH ('fetchSize' 100000)

Impostare il parametro della dimensione della partizione (Snowflake)

Snowflake consente di recuperare i dati in più partizioni, permettendo il coinvolgimento di più executor e l'elaborazione in parallelo. È importante scegliere una dimensione di partizione appropriata impostando il partition_size_in_mb parametro . Questo parametro specifica le dimensioni non compresse consigliate per ogni partizione. Per ridurre il numero di partizioni, specificare un valore maggiore. Il valore predefinito è 100 (MB).

Il partition_size_in_mb parametro imposta una dimensione consigliata. Le dimensioni effettive delle partizioni possono variare.

Requisiti di calcolo:

  • È necessario usare il calcolo in Databricks Runtime 16.1 o versione successiva. I warehouse SQL devono essere Pro o Serverless e devono usare 2024.50.
SELECT * FROM snowflakeCatalog.schema.table WITH ('partition_size_in_mb' 1000)

Abilitare le letture parallele per i connettori JDBC

I connettori che supportano il protocollo di trasferimento JDBC possono leggere i dati in parallelo partizionando la query. È possibile configurare letture parallele per i connettori seguenti:

  • Databricks
  • Microsoft SQL Server
  • Microsoft Azure Synapse
  • MySQL
  • Oracolo
  • PostgreSQL
  • spostamento verso il rosso
  • Salesforce Data 360
  • Teradata

Ciò consente a più executor di recuperare i dati contemporaneamente, migliorando significativamente le prestazioni per tabelle di grandi dimensioni.

Per abilitare le letture parallele, specificare i parametri seguenti:

  • numPartitions: numero di partizioni da usare per il parallelismo
  • partitionColumn: nome di una colonna numerica utilizzata per partizionare la query
  • lowerBound: Il valore minimo di partitionColumn usato per decidere la partizione dello stride
  • upperBound: valore massimo di partitionColumn usato per decidere lo stride della partizione

Importante

I valori lowerBound e upperBound vengono utilizzati solo per decidere lo stride di partizione, non per filtrare le righe nella tabella. Tutte le righe della tabella verranno partizionate e restituite.

La colonna della partizione deve essere:

  • Colonna numerica
  • Distribuito uniformemente nell'intervallo
  • Colonna indicizzata per prestazioni migliori

Requisiti di calcolo:

  • È necessario usare il calcolo in Databricks Runtime 17.1 o versione successiva. I warehouse SQL devono essere pro o serverless e devono usare 2025.25.

Nell'esempio seguente la query verrà suddivisa in 4 partizioni parallele in base alla id colonna, con ogni partizione che elabora un intervallo di circa 250 ID (presupponendo che sia presente un singolo record per ognuno id tra 1 e 1000).

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

Partecipare al pushdown in Lakehouse Federation

Importante

Questa funzionalità è in Anteprima Pubblica.

Scopri come funziona il pushdown di join in Databricks Lakehouse Federation.

Panoramica del pushdown di join

La tecnica del "join pushdown" è un metodo di ottimizzazione delle query in cui Databricks inoltra le operazioni di join al motore di database remoto anziché recuperare e unire localmente i dati. Ciò riduce significativamente il traffico di rete e migliora le prestazioni delle query sfruttando le funzionalità di join predefinite del database remoto.

Origini dati supportate

Le fonti dati seguenti supportano il join pushdown:

  • Oracolo
  • PostgreSQL
  • MySQL
  • SQL Server
  • Teradata
  • spostamento verso il rosso
  • Snowflake
  • BigQuery

Questa funzionalità è disponibile a livello generale e abilitata per impostazione predefinita per Redshift, Snowflake e BigQuery. Le limitazioni e i requisiti seguenti si applicano solo ai connettori Oracle, PostgreSQL, MySQL, SQL Server e Teradata.

Requisiti

  • È necessario usare il calcolo in Databricks Runtime 17.2 o versione successiva.
  • I warehouse SQL devono essere Pro o Serverless e devono usare 2025.30.
  • Nella pagina Anteprime dell'interfaccia utente di Databricks è necessario attivare/disattivare il pushdown di join per le query federate (anteprima pubblica).

Limitazioni

  • Solo sono supportati i join inner, left-outer e right-outer.
  • Gli alias negli elementi figlio di un join sono supportati solo in Databricks Runtime 17.3 e versioni successive.

Requisiti della gerarchia dei nodi

Affinché un join venga spinto, anche tutti i nodi nei rami figlio sinistro e destro devono essere pushabili. Si applicano le seguenti regole:

  • Nodi figlio supportati: solo i join, i filtri, le campionature e i nodi di scansione possono apparire sotto un join nel piano di query affinché il pushdown abbia successo.
  • Nodi figlio non supportati: Se sono presenti operazioni di limite, offset o aggregazione nel ramo sinistro o destro sotto un join, non è possibile eseguire il push del join.
  • Operazioni su join: le operazioni di aggregazione, limite e offset possono essere spostate verso il basso quando vengono applicate sopra un join.

Esempi

-- 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 (:re[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

Observability

Usare EXPLAIN FORMATTED per verificare che il tuo join viene spostato verso il basso:

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

Esempio di output che mostra il pushdown riuscito del join.

== 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]

In questo output:

  • id_1 è un alias generato automaticamente da Databricks per risolvere l'ambiguità quando le colonne hanno nomi duplicati.
  • Il PushedFilters sopra PushedJoins rappresenta le condizioni di join effettive che vengono inviate al database remoto.
  • I predicati di filtro aggiuntivi applicati a ogni tabella sono visualizzati in PushedFilters per ciascuna relazione ([L] e [R]).
  • Last updated on