Architecture classique Snowpipe Streaming

Important

  • Avis préalable : L’architecture classique Snowpipe Streaming est entièrement prise en charge aujourd’hui, mais elle devrait devenir obsolète à l’avenir.

  • Action : Aucun changement immédiat n’est requis. Vos charges de travail actuelles sont sécurisées et continuent d’être entièrement prises en charge.

  • Chronologie : Snowflake prévoit de publier une annonce formelle d’obsolescence à la mi-2026. Cette étape fait référence à la date de l’annonce uniquement. Après l’annonce d’obsolescence, une période de migration de 18 mois commence avant la date de fin de vie.

  • Recommandation : utilisez l’architecture hautes performances pour toutes les nouvelles implémentations.

Pour voir tous les détails, consulter les FAQs et obtenir des conseils sur la migration, consultez l’avis d’obsolescence à venir.

L’architecture classique de Snowpipe Streaming offre une méthode éprouvée et efficace pour l’ingestion continue de données basées sur des lignes, à faible latence, directement dans les tables Snowflake. Cette mise en œuvre, appelée Snowpipe Streaming Classic dans la documentation, reste un choix fiable pour diverses charges de travail en flux, telles que les données d’événements d’application, les relevés de capteurs de l’Internet des objets (IoT) et la capture de données de changement à faible latence (CDC).

Snowpipe Streaming Classic utilise le site snowflake-ingest-java SDK et opère sans le concept explicite d’objet PIPE pour la gestion du flux de données qui est au cœur de l’architecture haute performance de Snowpipe Streaming. Au lieu de cela, dans Snowpipe Streaming Classic, les canaux sont configurés plus directement contre les tables, offrant une approche familière et établie pour le flux de données dans Snowflake.

Exigences du logiciel

Pour découvrir les différences entre les architectures classique et hautes performances, consultez Différences d’API.

Application client personnalisée

L’API nécessite une interface d’application Java personnalisée qui peut accepter des lignes de données et gérer les erreurs qui se produisent. Vous devez vous assurer que l’application fonctionne en continu et peut redémarrer en cas de défaillance. Pour un lot de lignes donné, les API prennent en charge l’équivalent de ON_ERROR = CONTINUE | SKIP_BATCH | ABORT.

  • CONTINUE : continuer à charger les lignes de données acceptables et renvoyer toutes les erreurs.

  • SKIP_BATCH : ignorer le chargement et renvoyer toutes les erreurs si une erreur est rencontrée dans l’ensemble du lot de lignes.

  • ABORT (paramètre par défaut) : abandonner l’ensemble du lot de lignes et lever une exception à la première erreur rencontrée.

Pour Snowpipe Streaming Classic, l’application effectue des validations de schéma en utilisant la réponse des méthodes insertRow (ligne unique) ou insertRows (ensemble de lignes). Pour découvrir le traitement des erreurs pour l’architecture hautes performances, consultez Traitement des erreurs.

Charger des données dans des tables Apache Iceberg™

Avec la version 3.0.0 et ultérieures du SDK Snowflake Ingest, Snowpipe Streaming peut ingérer des données dans les tables Apache Iceberg gérées par Snowflake. Le SDK Snowpipe Ingest Java prend en charge le chargement dans les tables Snowflake standard (non-Iceberg) et les tables Iceberg.

Pour plus d’informations, voir Snowpipe Streaming Classic avec tables Apache Iceberg™.

Migration vers des fichiers optimisés dans l’architecture classique

Le API écrit les lignes des canaux dans les blobs du stockage cloud, qui sont ensuite transférés dans la table cible. Initialement, les données streamées écrites dans une table cible sont stockées dans un format de fichier intermédiaire temporaire. À ce stade, la table est considérée comme une «  table mixte « , car les données partitionnées sont stockées dans un mélange de fichiers natifs et intermédiaires. Un processus automatisé en arrière-plan fait migrer les données des fichiers intermédiaires actifs vers des fichiers natifs optimisés pour les requêtes et les opérations DML, selon les besoins.

Réplication dans l’architecture classique

Le Streaming Snowpipe prend en charge la réplication et le basculement des tables Snowflake remplies par Snowpipe Streaming et ses décalages de canaux associés d’un compte source vers un compte cible dans différentes régions et sur les plateformes Cloud.

Pour plus d’informations, voir Réplication et Streaming Snowpipe.