Aller au contenu principal
Dernière mise à jour le

Recommandations en matière de performances de Lakehouse Federation

Cet article fournit des conseils pour améliorer les performances des requêtes Lakehouse Federation.

Combinez plusieurs prédicats à l'aide de l'opérateur AND.​

Databricks Runtime essaie de pousser les prédicats vers le moteur de base de données distant afin de 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 query exécutée sur le moteur de base de données distant exclut le prédicat, de sorte que le filtrage doit être effectué à l'aide de Databricks Runtime. Cependant, si une certaine partie du filtre ne peut pas être poussée vers le bas, une autre partie du filtre peut toujours l'être si elles sont reliées par l'opérateur AND.

Filtrer avec un prédicat non poussable​

Exécutez la query suivante dans un Notebook ou l’éditeur de query Databricks SQL pour filtrer les enregistrements par nom à l’aide de l’expression ILIKE :

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

L'expression ILIKE ne peut pas être transmise à 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 query envoyée à la base de données distante renvoie tous les enregistrements :

SQL
SELECT * FROM catalog.schema.table

Filtrer avec des prédicats poussables et non poussables​

Exécutez la query suivante dans un Notebook ou l'éditeur de requêtes Databricks SQL pour filtrer les enregistrements par nom et par date :

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

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

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

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

Vérifiez quelle query s’exécutera sur la base de données distante​

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

info

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

Définissez la taille des lots récupérés de la base de données distante​

Vous pouvez configurer les connecteurs suivants qui utilisent le protocole de transfert JDBC pour contrôler la manière dont ils récupèrent les données des systèmes distants.

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

La taille de récupération JDBC détermine le nombre de lignes à récupérer par aller-retour. Par default, la plupart des connecteurs JDBC récupèrent les données de manière atomique. Cela pourrait entraîner que la quantité de données dépasse la mémoire disponible.

Pour éviter les erreurs de mémoire insuffisante, définissez le paramètre fetchSize. Lorsque fetchSize est défini sur une valeur non nulle, le connecteur lit les données en batches. Le nombre maximal de lignes par batch est égal à la valeur de fetchSize. Databricks recommande de spécifier une valeur fetchSize élevée (par exemple, 100,000), car le temps d'exécution global de la query peut être prolongé si le nombre de lignes en batchs est trop faible.

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

Compute requis :

  • Vous devez utiliser le compute sur Databricks Runtime 16.1 ou une version ultérieure. Les SQL warehouses doivent être Pro ou Serverless et doivent utiliser 2024.50.
SQL
SELECT * FROM mySqlCatalog.schema.table WITH ('fetchSize' 100000)

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

Snowflake permet la récupération de données dans plusieurs partitions, ce qui permet l'engagement de plusieurs exécuteurs et le traitement parallèle. Choisissez une taille de partition appropriée en définissant le paramètre partition_size_in_mb. Ce parameter spécifie la taille décompressée recommandée pour chaque partition. Pour réduire le nombre de partitions, spécifiez une valeur plus élevée. La valeur par default est 100 (Mo).

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

Compute requis :

  • Vous devez utiliser le compute sur Databricks Runtime 16.1 ou une version ultérieure. Les SQL warehouses doivent être Pro ou Serverless et doivent utiliser 2024.50.
SQL
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 query. Vous pouvez configurer des lectures parallèles pour les connecteurs suivants :

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

Cela permet à plusieurs exécuteurs de récupérer des données simultanément, améliorant considérablement les performances des grandes tables.

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

  • numPartitions: Le nombre de partitions à utiliser pour le parallélisme
  • partitionColumn: Le nom d'une colonne numérique utilisée pour partitionner la query
  • lowerBound: Valeur minimale de partitionColumn utilisée pour décider l'étendue de la partition
  • upperBound: La valeur maximale de partitionColumn utilisée pour décider du pas de partition
info

Les valeurs lowerBound et upperBound sont utilisées uniquement pour déterminer le pas de partition, et non pour filtrer les lignes de la table. Toutes les lignes de la table sont partitionnées et renvoyées.

La colonne de partition devrait être :

  • Une colonne numérique
  • Uniformément réparti sur la plage
  • Une colonne indexée pour de meilleures performances

Compute requis :

  • Vous devez utiliser le compute sur Databricks Runtime 17.1 ou version ultérieure. Les SQL Warehouse doivent être Pro ou Serverless et doivent utiliser 2025,25.

Dans l'exemple suivant, la query est divisée en 4 partitions parallèles basées sur la colonne id, chaque partition traitant une plage d'environ 250 ID (en supposant qu'il y ait un seul enregistrement pour chaque id entre 1 et 1000).

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

Utiliser une vue de base de données source avec des lectures parallèles​

remarque

Les lectures parallèles ne sont pas prises en charge lors de l'interrogation d'une vue créée par Databricks qui référence une table fédérée. Créez la vue dans la base de données source à la place.

Pour utiliser des lectures parallèles avec une vue, créez la vue dans la base de données source plutôt que dans Databricks.

Dans la base de données source :

SQL
CREATE VIEW my_source_database_view AS SELECT * FROM source_database_schema.table;

Puis, depuis Databricks, query la vue en utilisant des parameters de lecture parallèles :

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

Joint pushdown dans Lakehouse Federation​

info

Aperçu

Cette fonctionnalité est en aperçu public.

Découvrez comment le pushdown de jointure fonctionne dans Databricks Lakehouse Federation.

Présentation du report des jointures​

Le pushdown de jointure est une technique d'optimisation des queries où Databricks délègue les opérations de jointure au moteur de base de données distant au lieu de récupérer les données et d'effectuer la jointure localement. Cela réduit considérablement le trafic réseau et améliore les performances des queries en exploitant les capacité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 le pushdown de jointure :

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

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

Exigences​

  • Vous devez utiliser le compute sur Databricks Runtime 17.2 ou version ultérieure.
  • Les SQL warehouses doivent être Pro ou Serverless et doivent utiliser 2025,30.
  • Sur la page **Aperçus** de l'interface utilisateur Databricks, vous devez activer l'option **Join Pushdown pour les requêtes fédérées (aperçu public)**.

Limitations​

  • Seules les jointures internes, externes gauches et externes droites sont prises en charge.
  • Les alias dans les enfants d'une jointure ne sont pris en charge que dans Databricks Runtime 17.3 et versions supérieures.

Exigences de la hiérarchie des nœuds​

Pour qu'une jointure puisse être transférée, tous les nœuds des branches enfants gauche et droite doivent également être transférables. Les règles suivantes s'appliquent :

  • Nœuds enfants pris en charge : seuls les nœuds de jointure, de filtre, d'échantillonnage et de scan peuvent apparaître sous une jointure dans le plan de requête pour que la descente d'opérations réussisse.
  • Nœuds enfants non pris en charge : Si des opérations de limite, de décalage ou d'agrégation apparaissent dans la branch gauche ou droite en dessous d'une jointure, la jointure ne peut pas être déplacée vers le bas.
  • Opérations en plus des jointures : les opérations d'agrégation, de limite et de décalage peuvent être répercutées lorsqu'elles sont appliquées en plus d'une jointure.

Identifier les modèles de jointure pris en charge et non pris en charge​

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

Observabilité​

Utilisez EXPLAIN FORMATTED pour vérifier que votre jointure est poussée vers le bas :

SQL
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 un pushdown de jointure réussi :

== 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 cette sortie :

  • id_1 est un alias que Databricks génère automatiquement pour résoudre une ambiguïté lorsque les colonnes ont des noms en double.
  • Les PushedFilters au-dessus PushedJoins représentent les conditions de jointure réelles transmises à la base de données distante.
  • Le PushedFilters de chaque relation ([L] et [R]) montre des prédicats de filtre supplémentaires appliqués à chaque table.
Sur cette page