Performance des requêtes sur les tables dynamiques¶
Cette section explique comment concevoir votre pipeline pour obtenir de bonnes performances au moment de la requête. Vos données prennent diverses formes lorsqu’elles passent par différents systèmes :
Données source : à l’origine, les données sont générées par des entités du monde réel et collectées dans des systèmes de première ligne. Ces données sont ensuite ingérées dans Snowflake via des processus ETL.
Données brutes : après l’ingestion, les données sont stockées dans des tables Snowflake, où elles sont transformées en une forme plus adaptée à l’analyse.
Données modélisées : ces transformations résultent en un ensemble de modèles, qui présentent des concepts familiers aux consommateurs pour l’analyse.
L’ensemble de ces étapes constitue votre pipeline. Les tables dynamiques fonctionnent dans les étapes de transformation, mais vous devez considérer leurs performances dans le contexte de votre pipeline global.
Compréhension de la matérialisation¶
Les performances des requêtes d’analyse sont déterminées par la conception et la mise en œuvre des transformations des données brutes en données modélisées. Si la définition de ces transformations comme un ensemble de vues sur des données brutes est techniquement correcte, elle risque de ne pas répondre aux besoins en termes de performances et de coût.
Pour y remédier, certains ou tous les modèles de données pourraient avoir besoin d’être matérialisés en calculant à l’avance leurs résultats, en les stockant pour un accès rapide et en les tenant à jour. Les tables dynamiques facilitent cette matérialisation, mais vous devez encore décider lequel de vos modèles doit être matérialisé.
Limite de matérialisation¶
La division entre la partie matérialisée et non matérialisée de la transformation est appelée limite de matérialisation. Les facteurs suivants entrent généralement en ligne de compte dans le choix de la limite de matérialisation :
Latence ou niveau d’actualisation : le niveau d’actualisation des données que vous fournissez, c’est-à-dire le degré d’obsolescence de vos résultats. La limite de matérialisation n’a généralement pas d’effet important sur ce facteur.
Temps de réponse : la matérialisation d’une plus grande partie de votre pipeline réduit le temps de réponse. Le niveau d’actualisation est toujours au moins égal au temps de réponse de vos requêtes, mais peut être beaucoup plus long.
Coût : le coût de votre charge de travail est associé aux éléments suivants :
Coût de la matérialisation : ce coût évolue en fonction de la quantité de données contenues dans les sources et de la complexité des transformations.
Coût du calcul des transformations non matérialisées lors de l’analyse : ce coût évolue en fonction du nombre de requêtes analytiques et de leur complexité.
Coût du stockage : ce coût comprend à la fois les données brutes et les données matérialisées.
La matérialisation d’un plus grand nombre de données modélisées accélère les temps de réponse et réduit les coûts d’analyse, mais peut augmenter les coûts de matérialisation. Pour trouver la meilleure limite de matérialisation, il faut trouver un équilibre entre les facteurs ci-dessus. En général, vous pouvez obtenir de bons résultats en matérialisant la plus petite quantité de données possible tout en respectant vos exigences en matière de temps de réponse.
Fonctionnement de la matérialisation¶
Une fois que vous avez défini votre limite de matérialisation, vous pouvez créer des tables dynamiques et des vues en conséquence. Vous pouvez optimiser les performances des transformations non matérialisées comme n’importe quelle autre requête Snowflake. Une fois interrogées, les tables classiques et dynamiques fonctionnent de manière similaire, ce qui vous permet d’utiliser des techniques standard telles que la normalisation, la préagrégation et le clustering pour améliorer les performances.
Pour plus d’idées, consultez la liste de vérification des performances des requêtes.