Snowpipe Streaming : architecture à haute performance¶

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.

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

  Note

  Nous vous recommandons d’utiliser le SDK snowpipe-streaming comme choix principal et par défaut. L’API REST n’est pas optimisée pour les scénarios de débit élevé.

• 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 en 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 des schémas.

• Autorisation des transformations : Permet la manipulation des données en vol (par exemple, le filtrage, la réorganisation des colonnes, les expressions simples) en incorporant la syntaxe de transformation de la commande COPY.

• Prise en charge des fonctions de table : Prise en charge de l’ingestion de 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 leur mappage avec les colonnes de la table cible, ce qui permet la validation du schéma côté serveur.

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.

Limites et considérations¶

• Option ON_ERROR de Snowpipe : L’option ON_ERROR de STREAMING Snowpipe prend uniquement en charge CONTINUE.

• Architectures prises en charge (Rust Core) : Arm64 Mac, Windows, Arm64-linux et X86_64-linux.

• Exigences Linux : Si vous utilisez le SDK sous Linux, votre système doit disposer au minimum de la version 2.28 de la bibliothèque glibc.

• Environnement de déploiement : Seuls les déploiements sur AWS sont pris en charge.

• Tables en cluster (ingestion) : Bien que les tables en cluster puissent être des tables cibles, aucun clustering ne se produira pendant le processus d’ingestion.

• Réplication : La réplication n’est pas prise en charge.

• ALTER PIPE SET PIPE_EXECUTION_PAUSED = true : Si openChannel échoue lorsqu’il est mis en pause, l’ingestion peut ne pas s’arrêter immédiatement.

• Rôle d’autorisation : Le rôle par défaut est utilisé pour l’autorisation. La possibilité de spécifier d’autres rôles est planifiée pour l’avenir.

• Fuseau horaire : Le SDK utilisera automatiquement la valeur UTC. Les utilisateurs ne pourront pas modifier ce paramètre.

• Restriction relative aux charges utiles vides : Le SDK et l’API REST ne prennent pas en charge la soumission d’ensembles de lignes contenant une charge utile vide. Les soumissions doivent inclure au moins une ligne de données pour une ingestion réussie.

• Visibilité du message d’erreur : Bien que les messages d’erreur soient disponibles dans la réponse relative à l’état du canal, ils ne s’affichent pas dans la nouvelle vue de l’historique du canal.