Coûts pour Snowpipe Streaming Classic¶
Grâce au modèle de calcul sans serveur de Snowpipe Streaming, les utilisateurs peuvent diffuser n’importe quel volume de données sans avoir à gérer un entrepôt virtuel. Au lieu de cela, Snowflake fournit et gère les ressources de calcul, augmentant ou diminuant automatiquement la capacité en fonction de la charge streaming actuelle de Snowpipe Streaming.
Pour Snowpipe Streaming Classic, les comptes sont facturés en fonction du temps par seconde que le calcul sans serveur et l’ingestion de flux des clients actifs utilisent. Soyez attentif aux points suivants :
La migration des fichiers s’effectue de manière asynchrone par rapport à l’ingestion de flux.
La migration des fichiers peut parfois être précédée du clustering ou d’autres opérations DML.
La migration des fichiers n’a pas toujours lieu, ce qui permet de réduire les coûts de calcul.
Pour les tables Apache Iceberg™ gérées par Snowflake, la migration des fichiers s’opère de la même manière que la gestion des tables Iceberg pour créer de nouveaux fichiers Parquet compactés, si nécessaire.
Pour plus d’informations, voir le « Tableau des crédits de fonctionnalité sans serveur » dans la Table de consommation du service Snowflake.
Estimation des frais Snowpipe Streaming¶
Compte tenu du nombre de facteurs permettant de différencier les charges Snowpipe Streaming, il est très difficile pour Snowflake de fournir des exemples de coûts. La taille des enregistrements, le nombre d’enregistrements, les types de données, etc. peuvent affecter la consommation de ressources de calcul pour la migration de fichiers. Les frais client sont dictés uniquement par le nombre de clients qui écrivent activement des données sur Snowflake par seconde.
Nous vous suggérons de faire des tests en effectuant un chargement typique d’ingestion de streaming pour estimer les frais futurs. Pour voir un échantillon d’expérience d’ingestion de flux avec une estimation des coûts, consultez cette publication de blog.
Stockage temporaire des fichiers et facturation¶
Bien que l’API Snowpipe Streaming soit conçue pour écrire des lignes directement dans les tables Snowflake sans que les utilisateurs n’aient à mettre explicitement les fichiers en zone de préparation, dans Snowpipe Streaming Classic, les processus internes de Snowflake utilisent une zone de préparation interne transparente pour la mise en mémoire tampon temporaire des données. Snowpipe Streaming avec un SDK à l’architecture classique génère et télécharge des fichiers intermédiaires vers cette zone de préparation interne avant qu’ils ne soient transformés dans le format de fichier natif de Snowflake.
Snowflake vous facture le stockage consommé par ces fichiers temporaires dans la zone de préparation interne. Ce coût de stockage est distinct du coût de calcul sans serveur Snowpipe Streaming et apparaît sous le « coût de stockage » général sur votre facture Snowflake.
La période de conservation de ces fichiers temporaires dans la zone de préparation interne est directement associée à la durée de conservation des données pour la table cible (ou à la conservation au niveau du compte si aucune conservation de table spécifique n’est définie). Snowflake supprime automatiquement ces fichiers une fois qu’ils se trouvent en dehors de la fenêtre Time Travel définie. En règle générale, cette suppression intervient dans un délai d’un jour à compter de la date de sortie des données de la période de conservation. Les utilisateurs n’ont pas directement accès à ces fichiers de la zone de préparation interne, ni aucune visibilité sur ces derniers.
Clonage de tables avec Snowpipe Streaming¶
Lorsque les utilisateurs clonent une table qui reçoit activement des données via Snowpipe Streaming avec une architecture classique, ils peuvent observer une augmentation des coûts de stockage. Ce coût supplémentaire n’est pas dû à la duplication des fichiers de données sous-jacents. Snowflake effectue un clonage sans copie. En réalité, cela est dû au fait que les données en vol, c’est-à-dire les données qui ont été traitées par Snowpipe Streaming avec un SDK à l’architecture classique à l’architecture classique et qui sont temporairement stockées dans la zone de préparation interne, mais qui ne sont pas encore entièrement validées dans la table cible, nécessitent une migration des fichiers à la fois pour la table d’origine et pour le clone. Ce double traitement des fichiers temporaires augmente la consommation liée à la migration des fichiers et entraîne une utilisation accrue du stockage. Ce coût supplémentaire est généralement très faible, correspondant à environ 5 minutes de fichiers temporaires au maximum, mais il peut être plus important si le débit est très élevé et si le système connaît des retards dans ces migrations. Cette duplication contribue à augmenter la consommation de stockage.
En revanche, Snowpipe Streaming, avec son architecture hautes performances, offre un véritable clonage sans copie pour les tables qui reçoivent activement des données en continu. Grâce à l’architecture hautes performances, les opérations de clonage se comportent comme des clones de tables Snowflake standard. Cela signifie que seules les nouvelles données écrites après l’opération de clonage consomment du stockage supplémentaire. Les données en vol au moment du clonage ne sont pas soumises à cette double migration. Par conséquent, vous bénéficiez d’un clonage rentable pour les tables en continu.
Affichage de l’historique de chargement de données pour votre compte¶
Les administrateurs de compte (les utilisateurs ayant le rôle ACCOUNTADMIN) ou ceux ayant un rôle qui leur donne le privilège global MONITOR USAGE peuvent utiliser des commandes SQL pour voir la quantité de crédits facturés sur votre compte Snowflake sur une période donnée. Vous pouvez utiliser les vues suivantes pour interroger l’historique de données migrées dans des tables Snowflake, le temps passé à charger des données dans des tables Snowflake à l’aide de Snowpipe Streaming et les crédits consommés.
Pour voir les coûts totaux de Snowpipe Streaming, y compris les coûts de calcul et les coûts des clients, effectuez une requête dans l’historique de comptage lorsque l’adresse SERVICE_TYPE est définie sur SNOWPIPE_STREAMING.
Vue METERING_HISTORY (dans Account Usage).
Pour plus d’informations sur l’interrogation des coûts totaux Snowpipe Streaming, consultez un exemple SQL.
Pour voir des informations détaillées sur l’ingestion de clients et le calcul de la migration, vous pouvez effectuer des requêtes dans les vues suivantes :