Actualisation incrémentielle par les opérateurs

Le tableau suivant indique comment chaque opérateur est incrémenté (c’est-à-dire comment il est transformé en un nouveau fragment de requête qui génère des modifications au lieu de résultats complets), ainsi que ses performances et d’autres facteurs importants à prendre en compte.

Opérateur

Incrémentation

Considérations

SELECT <expressions scalaires>

Incrémentation en appliquant des expressions aux lignes modifiées.

Bonnes performances, pas de considérations particulières.

WHERE <expressions scalaires>

Incrémentation en évaluant le prédicat sur chaque ligne modifiée, et en n’incluant que celles pour lesquelles le prédicat est vrai.

Les performances sont généralement bonnes. Le coût est linéairement proportionnel à l’ampleur des changements.

L’actualisation d’une table dynamique à l’aide d’une expression WHERE très sélective peut nécessiter un temps de fonctionnement de l’entrepôt, même si la table dynamique résultante ne change pas. En effet, un entrepôt peut être nécessaire pour déterminer quelles modifications des sources satisfont le prédicat.

FROM <table de base>

Incrémenté en analysant les micro-partitions qui ont été ajoutées ou supprimées de la table depuis la dernière actualisation.

Le coût augmente de façon linéaire avec le volume de données dans les micropartitions ajoutées ou supprimées.

Recommandations :

  • Limitez le volume des modifications par actualisation à environ 5 % de la table source.

  • Soyez prudent avec les DMLs qui affecte de nombreuses micro-partitions.

<requête> UNION ALL <requête>

Incrémentation en prenant l’union de tous les changements de chaque côté.

Bonnes performances, pas de considérations particulières.

WITH <CTE liste> <requête>

Incrémentation en calculant les changements de chaque expression de table commune.

WITH facilite la lecture des requêtes complexes, mais prenez garde à ne pas rendre trop complexe la définition d’une seule table dynamique. Pour plus d’informations, voir Lier des pipelines de tables dynamiques et Optimisation des performances du mode d’actualisation incrémentielle pour les tables dynamiques complexes.

Agrégats scalaires

Les agrégats scalaires ne sont actuellement pas incrémentés de manière efficace. Lorsque leurs données changent, ils sont entièrement recalculés.

GROUP BY <clés>

Incrémentation en recalculant les agrégats pour chaque clé de groupe qui a changé.

Veillez à ce que les données sources soient mises en cluster par les clés de groupes et que les modifications ne représentent qu’une petite partie (environ <5 %) des clés de groupes.

Si la clé de regroupement contient une expression composée plutôt qu’une colonne de base, les actualisations incrémentielles auront peut-être besoin d’analyser une grande quantité de données. Pour réduire la taille de ces analyses, matérialisez l’expression dans une table dynamique, puis appliquez l’opération de regroupement sur la colonne matérialisée dans une autre table dynamique.

Prenons par exemple l’instruction composée suivante :

CREATE DYNAMIC TABLE sums
  AS
    SELECT date_trunc(minute, ts), sum(c1) FROM table
    GROUP BY 1;
Copy

L’instruction ci-dessus peut être optimisée comme suit :

CREATE DYNAMIC TABLE intermediate
  AS
    SELECT date_trunc(minute, ts) ts_min, c1 FROM table;
Copy
CREATE DYNAMIC TABLE sums
  AS
    SELECT ts_min, sum(c1) FROM intermediate
    GROUP BY 1;
Copy

DISTINCT

Équivalent à GROUP BY ALL sans fonctions agrégées.

Il s’agit souvent d’une opportunité d’optimisation substantielle.

Il est courant d’utiliser DISTINCT dans toutes les requêtes afin d’éviter d’introduire accidentellement des doublons. Dans le cas d’une actualisation incrémentielle, les opérations DISTINCT consomment des ressources de manière récurrente, car les doublons doivent être vérifiés à chaque actualisation.

Lorsqu’il s’agit d’optimiser les performances, il est facile de trouver et de supprimer les DISTINCTs redondants. Vous pouvez y parvenir en éliminant les doublons en amont et en examinant attentivement les cardinalités des jointures.

<fn> OVER <fenêtre>

Incrémentation en recalculant la fonction de fenêtre pour chaque clé de partition qui a changé.

Assurez-vous que votre requête comporte une clause PARTITION BY et que les données sources sont mises en cluster par clés de partition. Veillez également à ce que les modifications ne concernent qu’une petite partie (environ <5 %) des partitions.

<gauche> INNER JOIN <droite>

Incrémentation en joignant les changements du côté gauche avec le côté droit, puis en joignant les changements du côté droit avec le côté gauche.

Si l’un des côtés de la jonction est petit, la performance est probablement bonne. Si l’un des côtés de la jointure change fréquemment, le clustering de l’autre côté par la clé de jointure peut améliorer les performances.

<gauche> [{LEFT | RIGHT | FULL }] OUTER JOIN <droite>

Incrémentation par factorisation dans une jointure interne union-all-ed avec un ou deux NOT EXISTS pour calculer NULLs pour les non-correspondances. Cette requête factorisée est ensuite incrémentée.

La jointure interne est incrémentée comme indiqué. Les inexistants sont incrémentés en vérifiant si les clés modifiées d’un côté existaient déjà de l’autre côté.

Recommandations :

  • Si l’un des côtés de la jointure change fréquemment, le clustering de l’autre côté par la clé de jointure peut améliorer les performances.

  • Placez la table qui change le plus fréquemment sur le côté gauche.

  • Essayez de réduire les changements du côté opposé à OUTER. Ainsi, pour LEFT OUTER, réduisez les changements sur le côté droit.

  • Pour les jointures FULL, la localité est très importante.

LATERAL FLATTEN

Incrémenté en appliquant l’opérateur d’aplatissement aux lignes modifiées.

Les performances sont généralement bonnes. Le coût est linéairement proportionnel à l’ampleur des changements. Mêmes considérations générales que pour l’opérateur FROM <table de base>.
Langage: Français