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 :
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éfinissezOnErrorOptionsurOnErrorOption.CONTINUE, et vérifiez manuellement la valeur de retour deinsertRowspour 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 deOnErrorOption.ABORT.Maintenez la taille de chaque lot de lignes transmis à
insertRowsen dessous de 16 MB.Si vous chargez plusieurs lignes, l’utilisation de
insertRowssera plus performante et plus rentable que d’appelerinsertRowplusieurs fois, car il y a moins de temps passé sur les verrous.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.parquetorg.apache.parquet