ApsaraDB for SelectDB:Filtre d'exécution

HashJoinNode
     |                    |
     | 1,000,000          | 200
     |                    |
OlapScanNode         OlapScanNode
     ^                    ^
     | 1,000,000          | 200
    T1 (fact)            T2 (dimension)

HashJoinNode
     |                    |
     | 6,000              | 200
     |                    |
OlapScanNode         OlapScanNode
     ^                    ^
     | 1,000,000          | 200
    T1 (fact)            T2 (dimension)

HashJoinNode
     |                    |
     | 6,000              | 200
     |                    |
OlapScanNode         OlapScanNode
     ^                    ^
     | 6,000              | 200
    T1 (fact)            T2 (dimension)

Concepts clés

Table de gauche : table située du côté gauche d'une jointure, utilisée pour l'opération de sondage. La réorganisation des jointures peut modifier la position des tables.

Table de droite : table située du côté droit d'une jointure, utilisée pour construire la table de hachage. La réorganisation des jointures peut également modifier cette position.

Fragment : unité d'exécution de requête. Le nœud frontend (FE) divise une instruction SQL en fragments et les distribue aux nœuds backend (BE) du cluster distribué.

Cas d'utilisation des filtres d'exécution

Les filtres d'exécution sont particulièrement efficaces lorsque :

• La table de gauche est nettement plus grande que la table de droite. La génération d'un filtre consomme de la mémoire et des ressources de calcul ; cette opération n'est rentable qu'à grande échelle.

• Le résultat de la jointure est beaucoup plus petit que la table de gauche, ce qui signifie que le filtre peut éliminer la majorité des lignes de la table de gauche.

Si la table de droite est volumineuse ou si le résultat de la jointure est presque aussi grand que la table de gauche, les filtres d'exécution peuvent ajouter une surcharge sans apporter de bénéfice.

Types de filtres

ApsaraDB for SelectDB prend en charge cinq types de filtres d'exécution :

Paramètres

runtime_filter_mode

Contrôle la portée de propagation des filtres entre les fragments d'exécution de requête.

• **LOCAL** : le producteur du filtre (HashJoinNode) et le consommateur (OlapScanNode) doivent se trouver dans le même fragment. Adapté aux jointures par diffusion. Surcharge réduite.

• **GLOBAL** : les filtres sont fusionnés et transférés entre les fragments via le réseau. Nécessaire pour les jointures par brassage (shuffle joins) où le producteur et le consommateur se trouvent dans des fragments différents.

Le mode GLOBAL couvre tous les scénarios gérés par LOCAL, ainsi que les jointures par brassage. Basculez vers LOCAL si la surcharge liée à la fusion et à la transmission des filtres dépasse les gains obtenus lors de l'analyse pour une jointure par brassage spécifique. Définissez la valeur sur OFF pour désactiver entièrement les filtres d'exécution.

Pour plus de détails sur la conception technique de la fusion de filtres entre fragments, consultez ISSUE 6116.

runtime_filter_type

Spécifiez un seul type ou combinez-en plusieurs :

-- By name (comma-separated, quoted)
SET runtime_filter_type = "BLOOM_FILTER,IN,MIN_MAX";

-- Equivalent numeric form (1=IN, 2=BLOOM_FILTER, 4=MIN_MAX)
SET runtime_filter_type = 7;

Comportement du prédicat IN :

• Utilise une stratégie de fusion pour l'exécution distribuée.

• Lorsque IN et d'autres types de filtres sont spécifiés simultanément et que la table de droite reste dans la limite définie par runtime_filter_max_in_num, le système abandonne les autres filtres. En effet, un prédicat IN étant exact, les filtres supplémentaires n'apportent aucun avantage. Cette optimisation s'applique uniquement lorsque le producteur et le consommateur se trouvent dans le même fragment.

Comportement du filtre de Bloom :

• Présente un taux de faux positifs non nul, ce qui signifie qu'il peut laisser passer certaines lignes non correspondantes. Les résultats restent corrects ; seule l'efficacité du filtrage est affectée.

• Peut être propagé vers le moteur de stockage, mais uniquement pour les colonnes clés de la table de gauche. Sans propagation au niveau du stockage, les performances se dégradent souvent.

• Évitez d'utiliser des filtres de Bloom sur des colonnes à faible sélectivité ou sur de petites tables de gauche.

Comportement du filtre MinMax :

• Particulièrement efficace lorsque les plages de valeurs des tables de droite et de gauche ne se chevauchent pas (par exemple, le maximum de la table de droite est inférieur au minimum de la table de gauche, ou inversement).

• Sur les colonnes numériques (INT, BIGINT, DOUBLE), le chevauchement des plages réduit son efficacité à zéro.

• Sur les colonnes non numériques (VARCHAR), il dégrade généralement les performances.

Comportement de IN_OR_BLOOM_FILTER :

• Utilise un prédicat IN lorsque le nombre de lignes de la table de droite est inférieur à 102 400 ; bascule vers un filtre de Bloom au-delà de ce seuil.

• Ajustez le seuil à l'aide de runtime_filter_max_in_num.

Comportement du filtre Bitmap :

• Applicable uniquement lorsque la sous-requête IN renvoie une colonne bitmap.

• Nécessite le moteur vectorisé.

runtime_filter_wait_time_ms

Le nœud OlapScanNode attend jusqu'à cette durée pour chaque filtre d'exécution assigné avant de commencer une analyse. Avec trois filtres, l'attente maximale correspond à trois fois cette valeur.

Les filtres qui arrivent dans la fenêtre d'attente sont propagés vers le moteur de stockage. Ceux qui arrivent après le début de l'analyse sont appliqués comme filtres d'expression sur les données déjà analysées. Bien qu'efficaces, ils sont moins performants qu'une propagation au niveau du stockage.

Conseils d'ajustement :

• Clusters chargés exécutant des jointures longues : augmentez cette valeur afin que les filtres aient le temps d'être construits et transmis avant le début de l'analyse.

• Clusters peu chargés exécutant de nombreuses petites requêtes : diminuez cette valeur pour éviter d'ajouter une latence inutile à des requêtes qui se terminent en quelques secondes.

Si un cluster est très sollicité et exécute de nombreuses requêtes gourmandes en ressources ou longues, prolongez la durée d'attente pour éviter que les requêtes complexes ne manquent des opportunités d'optimisation. À l'inverse, si la charge du cluster est légère et qu'il exécute de nombreuses petites requêtes ne durant que quelques secondes, réduisez la durée d'attente pour éviter d'ajouter une latence d'une seconde à chaque requête.

runtime_filters_max_num

Limite le nombre de filtres de Bloom par requête. Les prédicats IN et les filtres MinMax ne sont pas comptabilisés.

Lorsque la limite est dépassée, le système conserve les filtres de Bloom ayant la sélectivité la plus élevée, c'est-à-dire ceux susceptibles de filtrer le plus grand nombre de lignes :

Selectivity = HashJoinNode cardinality / HashJoinNode left child cardinality

N'ajustez ce paramètre que lors de l'optimisation de requêtes de jointure lentes entre de grandes tables.

Paramètres de taille du filtre de Bloom

Le FE calcule la longueur du filtre de Bloom lors de la planification de la requête. Tous les filtres de Bloom des nœuds HashJoinNode d'une même requête doivent avoir la même longueur pour pouvoir être fusionnés.

• Si la cardinalité de la table de droite est disponible dans les statistiques, le FE estime la taille optimale et l'arrondit à la puissance de 2 supérieure.

• Si la cardinalité n'est pas disponible, le FE utilise runtime_bloom_filter_size comme valeur par défaut.

• runtime_bloom_filter_min_size et runtime_bloom_filter_max_size bornent la taille finale, quelle que soit l'estimation.

Des filtres de Bloom plus grands traitent les colonnes à haute cardinalité avec plus de précision, mais consomment davantage de mémoire. Si la précision du filtrage est insuffisante pour une colonne à haute cardinalité (millions de valeurs distinctes), augmentez runtime_bloom_filter_size et testez les performances résultantes.

Ajustez la taille du filtre de Bloom par requête, et non globalement.

CREATE TABLE test (t1 INT) DISTRIBUTED BY HASH (t1) BUCKETS 2;
INSERT INTO test VALUES (1), (2), (3), (4);

CREATE TABLE test2 (t2 INT) DISTRIBUTED BY HASH (t2) BUCKETS 2;
INSERT INTO test2 VALUES (3), (4), (5);

EXPLAIN SELECT t1 FROM test JOIN test2 WHERE test.t1 = test2.t2;

+-------------------------------------------------------------------+
| Explain String                                                    |
+-------------------------------------------------------------------+
| PLAN FRAGMENT 0                                                   |
|  OUTPUT EXPRS:`t1`                                                |
|                                                                   |
|   4:EXCHANGE                                                      |
|                                                                   |
| PLAN FRAGMENT 1                                                   |
|  OUTPUT EXPRS:                                                    |
|   PARTITION: HASH_PARTITIONED: `default_cluster:ssb`.`test`.`t1`  |
|                                                                   |
|   2:HASH JOIN                                                     |
|   |  join op: INNER JOIN (BUCKET_SHUFFLE)                         |
|   |  equal join conjunct: `test`.`t1` = `test2`.`t2`              |
|   |  runtime filters: RF000[in] <- `test2`.`t2`                   |
|   |                                                               |
|   |----3:EXCHANGE                                                 |
|   |                                                               |
|   0:OlapScanNode                                                  |
|      TABLE: test                                                  |
|      runtime filters: RF000[in] -> `test`.`t1`                    |
|                                                                   |
| PLAN FRAGMENT 2                                                   |
|  OUTPUT EXPRS:                                                    |
|   PARTITION: HASH_PARTITIONED: `default_cluster:ssb`.`test2`.`t2` |
|                                                                   |
|   1:OlapScanNode                                                  |
|      TABLE: test2                                                 |
+-------------------------------------------------------------------+

SET enable_profile = true;

RuntimeFilter:in:
    HasPushDownToEngine: true    -- filter reached the storage engine
    AWaitTimeCost: 0ns           -- no wait; filter arrived before scan started
    EffectTimeCost: 2.76ms       -- time spent applying the filter

RowsVectorPredFiltered: 9,320,008   -- rows discarded by the filter
VectorPredEvalTime: 364.39ms        -- time spent on filter evaluation