Snowpipe Streaming : architecture à haute performance¶

Exigences du logiciel¶

Java

Nécessite Java 11 ou supérieur.

• Référentiel SDK Maven : SDK Java Snowpipe Streaming

• Référence d’API : Référence du SDK Java

Python

Requiert la version 3.9 de Python ou une version ultérieure.

• Référentiel SDK PyPI : SDK Python Snowpipe Streaming

• Référence d’API : Référence du SDK Python

Fonctionnalités clés¶

• Débit et temps de latence :

  • Débit élevé : Conçu pour prendre en charge des vitesses d’ingestion allant jusqu’à 10 GB/s par table.

  • Informations en temps quasi réel : Réalise des temps de latence de bout en bout entre l’acquisition et la requête dans un délai de 5 à 10 secondes.

• Facturation :

  • Facturation simplifiée, transparente et basée sur le débit. Pour plus d’informations, voir Architecture haute performance de Snowpipe Streaming : Comprendre vos coûts.

• Ingestion flexible :

  • SDK Java et SDK Python : Utilisez le nouveau SDK snowpipe-streaming avec un noyau client basé sur Rust pour améliorer les performances côté client et réduire l’utilisation des ressources.

  • REST API : Fournit un chemin d’ingestion direct, simplifiant l’intégration pour les charges de travail légères, les données des appareils de l’IoT et les déploiements de bord.

  Note

  Nous vous recommandons de commencer par le SDK Snowpipe Streaming sur l’API REST pour bénéficier de l’amélioration des performances et de l’expérience de démarrage.

• Optimisation du traitement des données :

  • Transformations en vol : Prise en charge du nettoyage et du remodelage des données pendant l’ingestion à l’aide de la syntaxe de commande COPY dans l’objet PIPE.

  • Amélioration de la visibilité des canaux : Meilleure connaissance du statut de l’ingestion, principalement grâce à la vue de l’historique du canal dans Snowsight et à une nouvelle API GET_CHANNEL_STATUS.

Cette architecture est recommandée pour :

• L’ingestion cohérente de charges de travail en flux à haut volume.

• Des analyses et des tableaux de bord en temps réel pour une prise de décision rapide.

• L’intégration efficace des données provenant des appareils IoT et des déploiements en périphérie.

• Les organisations qui recherchent des prix transparents, prévisibles et basés sur le débit pour l’ingestion de flux.

Nouveaux concepts : L’objet PIPE¶

Tout en héritant des concepts de base tels que les canaux et les jetons de décalage de Snowpipe Streaming Classic, cette architecture introduit l’objet PIPE en tant qu’élément central.

L’objet PIPE est un objet Snowflake nommé qui sert de point d’entrée et de niveau de définition pour toutes les données en flux reçues. Il fournit les éléments suivants :

• Définition du traitement des données : Définit la manière dont les données de flux sont traitées avant d’être validées dans la table cible, y compris la mise en mémoire tampon côté serveur pour les transformations ou le mappage de schémas.

• Activation des transformations : Permet de manipuler les données en temps réel (par exemple, filtrage, réorganisation des colonnes, expressions simples) en incorporant une syntaxe de transformation des commandes COPY.

• Prise en charge des fonctionnalités de table : Gère l’ingestion dans des tables avec des clés de clustering définies, des colonnes de valeurs DEFAULT et des colonnes AUTOINCREMENT (ou IDENTITY).

• Gestion des schémas : Aide à définir le schéma attendu des données de flux entrantes et de son mappage vers les colonnes de la table cible, permettant ainsi la validation du schéma côté serveur.

  

Default pipe¶

To simplify the setup process for Snowpipe Streaming, Snowflake provides a default pipe for every target table. This lets you start streaming data immediately without needing to manually execute CREATE PIPE DDL statements.

The default pipe is implicitly available for any table and offers a simplified, fully managed experience:

• On-demand creation: The default pipe is created on demand only after the first successful pipe-info or open-channel call is made against the target table. Customers can only view or describe the pipe (using SHOW PIPES or DESCRIBE PIPE) after it has been instantiated by one of these calls.

• Naming convention: The default pipe follows a specific, predictable naming convention:

  • Format: <TABLE_NAME>-STREAMING

  • Example: If your target table is named MY_TABLE, the default pipe is named MY_TABLE-STREAMING.

• Fully Snowflake managed: This default pipe is fully managed by Snowflake. Customers can’t perform any changes to it, such as CREATE, ALTER, or DROP the default pipe.

• Visibility: Despite being automatically managed, customers can inspect the default pipe as they would a normal pipe. Customers can view it by using the SHOW PIPES, DESCRIBE PIPE, SHOW CHANNELS commands, and is also included in the Account Usage metadata views: ACCOUNT_USAGE.PIPES, ACCOUNT_USAGE.METERING_HISTORY, or ORGANIZATION_USAGE.PIPES.

The default pipe is designed for simplicity and has certain limitations:

• No transformations: The internal mechanism for the default pipe uses MATCH_BY_COLUMN_NAME in the underlying copy statement. It doesn’t support specific data transformations.

• No pre-clustering: The default pipe doesn’t support pre-clustering for the target table.

If your streaming workflow requires specific transformations — for example, casting, filtering, or complex logic — or you need to utilize pre-clustering, you must manually create your own named pipe. For more information, see CREATE PIPE.

When you configure the Snowpipe Streaming SDK or REST API, you can reference the default pipe name in your client configuration to begin streaming. For more information, see Tutoriel : Prise en main du SDK de l’architecture haute performance de Snowpipe Streaming and Premiers pas avec l’API REST Snowpipe Streaming : Un tutoriel cURL et JWT.

Pré-clustering de données lors de l’ingestion¶

Snowpipe Streaming peut regrouper les données en vol pendant l’ingestion, ce qui améliore les performances des requêtes sur vos tables cibles. Cette fonctionnalité trie vos données directement lors de l’ingestion avant leur validation. Le tri de vos données de cette manière optimise l’organisation pour des requêtes plus rapides.

Pour tirer parti du pré-clustering, votre table cible doit comporter des clés de clustering définies. Vous pouvez ensuite activer cette fonctionnalité en définissant le paramètre CLUSTER_AT_INGEST_TIME sur TRUE dans votre instruction COPY INTO lors de la création ou du remplacement de votre canal Snowpipe Streaming.

Pour plus d’informations, voir CLUSTER_AT_INGEST_TIME. Cette fonctionnalité n’est disponible que sur l’architecture hautes performances.

Différences par rapport à Snowpipe Streaming Classic¶

Pour les utilisateurs habitués à l’architecture classique, l’architecture haute performance apporte les modifications suivantes :

• Nouveau SDK et nouvelles APIs : Exige le nouveau SDK snowpipe-streaming (SDK Java et API REST), ce qui nécessite des mises à jour du code client pour la migration.

• Exigence de l’objet PIPE : L’ensemble de l’ingestion des données, de la configuration (par exemple, les transformations) et de la définition des schémas est géré par l’objet PIPE côté serveur, ce qui constitue un changement par rapport à la configuration plus axée sur le client de Classic.

• Association de canaux : Les applications clientes ouvrent des canaux sur un objet PIPE spécifique, et non directement sur une table cible.

• Validation du schéma : Passe d’une application principalement côté client (SDK classique) à une application côté serveur par Snowflake, basée sur l’objet PIPE.

• Exigences en matière de migration : Exige de modifier le code de l’application client pour le nouveau SDK et de définir les objets PIPE dans Snowflake.