Recommandations en matière de performances de la fédération Lakehouse

Cet article fournit des conseils pour améliorer les performances des requêtes de la Fédération Lakehouse.

Combiner plusieurs prédicats à l’aide de l’opérateur AND

Databricks Runtime tente de transmettre les prédicats au moteur de base de données à distance pour réduire le nombre d’enregistrements récupérés via le réseau. Si un prédicat ne peut pas être poussé vers le bas, la requête exécutée sur le moteur de base de données distant exclut le prédicat. Le filtrage doit donc être effectué à l’aide de Databricks Runtime. Toutefois, si une partie du filtre ne peut pas être appliquée, une autre partie du filtre peut toujours être appliquée si elle est associée par l’opérateur AND.

Exemple 1

Requête Databricks :

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

L’expression ILIKE ne peut pas être envoyée vers la base de données distante (par exemple, MySQL), car il n’existe aucune traduction appropriée. Le filtrage doit être effectué à l’aide de Databricks Runtime.

La requête envoyée à la base de données distante retourne tous les enregistrements :

SELECT * FROM catalog.schema.table

Exemple 2

Requête Databricks :

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

L’expression ILIKE ne peut pas être poussée vers la base de données distante (par exemple, MySQL), car il n’existe aucune traduction appropriée, mais la comparaison de dates peut être poussée vers le bas. Le filtrage de noms doit toujours être effectué à l’aide de Databricks Runtime, mais la comparaison de dates doit réduire le nombre d’enregistrements récupérés.

La requête envoyée à la base de données distante retourne un sous-ensemble d’enregistrements :

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

Vérifier quelle requête s’exécutera sur la base de données distante

Pour voir quelle requête sera envoyée à la base de données distante, exécutez la EXPLAIN commande FORMATTED .

Importante

La requête réelle peut différer de la requête dans la EXPLAIN FORMATTED sortie en raison de l’exécution de requête adaptative.

Définir la taille des lots récupérés à partir de la base de données distante

Vous pouvez configurer les connecteurs suivants, qui utilisent le protocole de transfert JDBC, pour contrôler la façon dont ils extraient des données à partir de systèmes distants.

• Databricks
• Microsoft SQL Server
• Microsoft Azure Synapse
• MySQL
• Oracle
• PostgreSQL
• Données Salesforce 360
• Teradata

La taille d’extraction JDBC détermine le nombre de lignes à extraire par aller-retour. Par défaut, la plupart des connecteurs JDBC récupèrent des données atomiquement. Cela peut entraîner la quantité de données supérieure à la mémoire disponible.

Pour éviter les erreurs de mémoire saturée, définissez le paramètre fetchSize. Lorsqu’il fetchSize est défini sur une valeur non nulle, le connecteur lit les données par lots. Le nombre maximal de lignes par lot est égal à la valeur de fetchSize. Databricks recommande de spécifier une valeur importante fetchSize (par exemple), 100,000car le temps d’exécution de requête global peut être prolongé si le nombre de lignes dans les lots est trop petit.

Ce paramètre permet aux nœuds Worker de lire les données par lots, mais pas en parallèle.

Voici les exigences de calcul à respecter :

• Vous devez utiliser le calcul sur Databricks Runtime 16.1 ou version ultérieure. Les entrepôts SQL doivent être Pro ou Serverless et doivent utiliser 2024.50.

SELECT * FROM mySqlCatalog.schema.table WITH ('fetchSize' 100000)

Définir le paramètre de taille de partition (Snowflake)

Snowflake permet d’extraire des données dans plusieurs partitions, ce qui permet l’engagement de plusieurs exécuteurs et traitement parallèle. Il est important de choisir une taille de partition appropriée en définissant le partition_size_in_mb paramètre. Ce paramètre spécifie la taille non compressée recommandée pour chaque partition. Pour réduire le nombre de partitions, spécifiez une valeur supérieure. La valeur par défaut est 100 (Mo).

Le partition_size_in_mb paramètre définit une taille recommandée ; la taille réelle des partitions peut varier.

Voici les exigences de calcul à respecter :

• Vous devez utiliser le calcul sur Databricks Runtime 16.1 ou version ultérieure. Les entrepôts SQL doivent être Pro ou Serverless et doivent utiliser 2024.50.

SELECT * FROM snowflakeCatalog.schema.table WITH ('partition_size_in_mb' 1000)

Activer les lectures parallèles pour les connecteurs JDBC

Les connecteurs qui prennent en charge le protocole de transfert JDBC peuvent lire les données en parallèle en partitionnant la requête. Vous pouvez configurer des lectures parallèles pour les connecteurs suivants :

• Databricks
• Microsoft SQL Server
• Microsoft Azure Synapse
• MySQL
• Oracle
• PostgreSQL
• Redshift
• Données Salesforce 360
• Teradata

Cela permet à plusieurs exécuteurs d’extraire des données simultanément, ce qui améliore considérablement les performances des tables volumineuses.

Pour activer les lectures parallèles, spécifiez les paramètres suivants :

• numPartitions: nombre de partitions à utiliser pour le parallélisme
• partitionColumn: nom d’une colonne numérique utilisée pour partitionner la requête
• lowerBound: valeur minimale de partitionColumn utilisée pour décider de la progression de la partition
• upperBound: La valeur maximale de partitionColumn utilisée pour décider du pas de la partition

Importante

Les valeurs lowerBound et upperBound sont utilisées uniquement pour décider du stride de la partition, non pour filtrer les lignes de la table. Toutes les lignes de la table seront partitionnées et retournées.

La colonne de partition doit être :

• Colonne numérique
• Distribué uniformément sur l'étendue
• Une colonne indexée pour améliorer les performances

Voici les exigences de calcul à respecter :

• Vous devez utiliser le calcul sur Databricks Runtime 17.1 ou version ultérieure. Les entrepôts SQL doivent être professionnels ou sans serveur et doivent utiliser la version 2025.25.

Dans l’exemple suivant, la requête sera fractionnée en 4 partitions parallèles en fonction de la id colonne, chaque partition traitant une plage d’environ 250 ID (en supposant qu’il existe un enregistrement unique pour chacun entre id et 1).1000

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

Associer une optimisation de données dans la fédération Lakehouse

Importante

Cette fonctionnalité est disponible en préversion publique.

Découvrez comment fonctionne la réduction de jointure dans la Databricks Lakehouse Federation.

Vue d'ensemble du mécanisme de jointure

Le pushdown de jointure est une technique d’optimisation des requêtes où Databricks envoie des opérations de jointure au moteur de base de données distant au lieu d’extraire des données et d’effectuer la jointure localement. Cela réduit considérablement le trafic réseau et améliore les performances des requêtes en tirant parti des fonctionnalités de jointure intégrées de la base de données distante.

Sources de données prises en charge

Les sources de données suivantes prennent en charge l'optimisation de jointure :

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

Cette fonctionnalité est généralement disponible et activée par défaut pour Redshift, Snowflake et BigQuery. Les limitations et exigences suivantes s’appliquent uniquement aux connecteurs Oracle, PostgreSQL, MySQL, SQL Server et Teradata.

Spécifications

• Vous devez utiliser le calcul sur Databricks Runtime 17.2 ou version ultérieure.
• Les entrepôts SQL doivent être Pro ou Serverless et doivent utiliser 2025.30.
• Dans la page Aperçus de l'interface utilisateur Databricks, vous devez activer l'option jointure pour les requêtes fédérées (Aperçu public).

Limites

• Seules les jointures internes, externes gauche et droite sont prises en charge.
• Les alias dans les sous-requêtes d’une jointure ne sont pris en charge que dans Databricks Runtime 17.3 et versions ultérieures.

Configuration requise pour la hiérarchie des nœuds

Pour qu’une jointure soit poussée vers le bas, tous les nœuds des branches enfants gauche et droite doivent également être propulsables. Les règles suivantes s’appliquent :

• Nœuds enfants pris en charge : seules les jointures, les filtres, les échantillons et les nœuds de scan peuvent apparaître sous une jointure dans le plan de requête pour que l'application réussisse.
• Nœuds enfants non pris en charge : si les opérations de limite, de décalage ou d’agrégation apparaissent dans la branche gauche ou droite sous une jointure, la jointure ne peut pas être poussée vers le bas.
• Les opérations sur les jointures : les opérations d’agrégation, de limite et de décalage peuvent être poussées vers le bas lorsqu’elles sont appliquées au-dessus d’une jointure.

Examples

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

Utilisez EXPLAIN FORMATTED pour vérifier que votre jointure est transférée :

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

Exemple de sortie montrant le pushdown de jointure réussie :

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

Dans ce résultat :

• id_1 est un alias généré automatiquement par Databricks pour résoudre l’ambiguïté lorsque les colonnes ont des noms en double.
• Les PushedFilters conditions de jointure réelles envoyées à la base de données distante sont représentées ci-dessus PushedJoins .
• PushedFilters dans chaque relation ([L] et [R]) indique des filtres supplémentaires appliqués à chaque table.