Snowpipe Streaming : meilleures pratiques¶

Optimisation des coûts¶

Comme meilleure pratique, nous recommandons d’appeler l’API avec moins de clients Snowpipe Streaming qui écrivent plus de données par seconde. Utilisez l’application Java ou Scala pour agréger des données provenant de plusieurs sources telles que des IoT dispositifs ou des capteurs, puis utilisez Snowflake Ingest SDK pour appeler l’API et charger les données à des débits plus élevés. Le API regroupe efficacement les données de plusieurs tables cibles dans un compte.

Un seul client Snowpipe Streaming peut ouvrir plusieurs canaux pour envoyer des données, mais le coût du client n’est facturé que par client actif. Le nombre de canaux n’a pas d’incidence sur le coût du client. Par conséquent, nous vous recommandons d’utiliser plusieurs canaux par client pour optimiser les performances et les coûts.

L’utilisation des mêmes tables pour l’ingestion par lots et par streaming peut également entraîner une réduction des coûts de calcul de Snowpipe Streaming en raison d’opérations de migration de fichiers anticipées. Si le clustering automatique est également activé sur la même table que celle dans laquelle Snowpipe Streaming effectue les insertions, les coûts de calcul pour la migration des fichiers peuvent être réduits. L’opération de clustering optimisera et migrera les données dans la même transaction.

Recommandations sur les performances¶

Pour des performances optimales dans les déploiements à haut débit, nous recommandons les actions suivantes :

• Si vous chargez plusieurs lignes, l’utilisation de insertRows sera plus efficace et plus rentable que d’appeler insertRow plusieurs fois, car il y a moins de temps passé sur les verrous.

  • Maintenez la taille de chaque lot de lignes transmis à insertRows en dessous de 16 MB compressés.

  • La taille optimale des lots de lignes est comprise entre 10 et 16 MB.

• Transmettez les valeurs des colonnes TIME, DATE, et toutes les colonnes TIMESTAMP comme l’un des types pris en charge du paquet java.time.

• Lors de la création d’un canal à l’aide de OpenChannelRequest.builder, définissez OnErrorOption sur OnErrorOption.CONTINUE, et vérifiez manuellement la valeur de retour de insertRows pour les erreurs d’ingestion potentielles. Cette approche conduit actuellement à de meilleures performances qu’en s’appuyant sur des exceptions levées lors de l’utilisation de OnErrorOption.ABORT.

• Lorsque vous définissez le niveau de journalisation par défaut sur DEBUG, assurez-vous que les enregistreurs suivants continuent de journaliser sur INFO : leur sortie DEBUG est très verbeuse, ce qui peut entraîner une forte dégradation de la performance.

  • net.snowflake.ingest.internal.apache.parquet

  • org.apache.parquet

• Les canaux doivent durer longtemps lorsqu’un client insère activement des données, et ils doivent être réutilisés, car les informations de jeton de décalage sont conservées. Ne fermez pas les canaux après l’insertion de données, car les données à l’intérieur des canaux sont automatiquement vidées en fonction de l’heure configurée dans MAX_CLIENT_LAG.

Recommandations en matière de latence¶

Avec les versions 2.0.4 et ultérieures du SDK Snowflake Ingest, vous pouvez utiliser MAX_CLIENT_LAG pour configurer la latence du vidage de données. Par défaut, Snowpipe Streaming vide les données chaque seconde. La configuration de MAX_CLIENT_LAG vous permet de passer outre et de définir la latence de vidage souhaitée, entre 1 seconde et 10 minutes.

Dans les scénarios à faible débit où peu de données sont générées, il se peut que vous n’envoyiez qu’une ligne ou 1 KB de données par seconde. Cela peut allonger le temps de compilation de la requête lorsque de nombreuses petites partitions doivent être résolues pour renvoyer les résultats de votre requête, en particulier lorsque la requête est déclenchée avant que le processus de migration ne compacte les partitions. En augmentant la valeur de MAX_CLIENT_LAG, Snowpipe Streaming peut mettre en mémoire tampon les lignes insérées pendant la durée configurée et créer des partitions de meilleure taille. La performance des requêtes et la migration s’en trouvent considérablement améliorées.

Par conséquent, définissez MAX_CLIENT_LAG à un niveau aussi élevé que le permet votre objectif de latence. Par exemple, si vous avez une tâche qui s’exécute toutes les minutes pour fusionner ou transformer vos données en continu, il serait optimal de définir MAX_CLIENT_LAG à 50 ou 55 secondes.