Snowpipe : chargement sans serveur pour les données en continu

Snowpipe : chargement sans serveur pour les données en continu

Les organisations d’aujourd’hui ont du mal à charger, intégrer et analyser les sources de données en continu sur lesquelles elles s’appuient pour faire progresser leurs activités. L’Internet des objets, les appareils mobiles, les scénarios adtech, les systèmes de télémétrie et la surveillance de la santé des applications ne sont que quelques-uns des scénarios à l’origine de cette tendance. Pour rester compétitives, les organisations ont besoin de ces données pour piloter leurs analyses en temps quasi réel.

Malgré l’augmentation rapide des données en streaming et l’évolutivité infinie du cloud, les solutions d’entreposage de données traditionnelles ne peuvent pas fournir une ingestion transparente pour les données en streaming. Ils nécessitent toujours des processus conçus à l’origine pour le chargement par lots, se produisant une ou plusieurs fois par jour. Cette latence inutile est un frein pour les analyses d’une organisation. Les solutions de contournement utilisant le micro-dosage offrent un certain soulagement, mais sont difficiles à mettre en œuvre et nécessitent un réglage minutieux. De même, l’informatique sans serveur est encore étrangère à la plupart des solutions d’entrepôt de données traditionnelles. En fait, la plupart des entrepôts de données cloud, qui sont des versions « cloud-washed » de solutions sur site, n’offrent pas une expérience sans serveur.



Snowpipe s’attaque à la fois au chargement continu pour les données en streaming et à l’informatique sans serveur pour le chargement des données dans Snowflake. Avec Snowpipe, les notifications d’événements AWS S3 déclenchent automatiquement Snowflake pour charger les données dans les tables cibles. Les requêtes Snowflake SQL récupèrent les données les plus récentes dans la minute qui suit leur arrivée dans le compartiment S3.

Le « tuyau » est un concept clé dans la surface que Snowpipe ajoute à Snowflake. Une définition de canal enveloppe l’instruction COPY familière pour le chargement de données avec Snowflake. La plupart de la sémantique de l’instruction COPY existante est transmise à un canal dans Snowpipe. La principale différence, cependant, est que les tuyaux surveillent en permanence de nouvelles données et chargent en permanence des données à partir de l’étape utilisée par le tuyau.

La surface de Snowpipe offre deux niveaux de contrôle différents pour les tuyaux. Dans la plupart des cas d’utilisation, Snowpipe peut s’appuyer sur les notifications Amazon SQS d’un compartiment S3 pour déclencher des chargements de données. Il nécessite une configuration unique pour un compartiment S3 et un ensemble de tables cibles. Cela prend généralement moins de 15 minutes à mettre en place. Il est entièrement basé sur la configuration, sans qu’il soit nécessaire d’écrire de code d’application autre que certaines instructions DDL Snowflake. Cette expérience est disponible en avant-première en décembre 2017. Le schéma suivant illustre cette approche :

snowpipe 1

Pour les cas d’utilisation qui nécessitent plus de contrôle ou une intégration plus approfondie dans les applications, Snowpipe fournit également une API REST programmatique pour informer Snowflake des nouvelles données dans S3. L’API REST est disponible aujourd’hui en avant-première pour les clients Snowflake dans la région USA Ouest. Le diagramme suivant montre une vue d’ensemble architecturale de cette approche :

snowpipe 2

Pour les deux expériences Snowpipe, Snowflake exécute et gère une flotte de serveurs qui effectuent de manière asynchrone le chargement réel des données dans les tables cibles. Ce parc de serveurs est entièrement interne à Snowflake, qui ajoute ou supprime automatiquement des serveurs du parc en fonction de la charge actuelle de Snowpipe. Les clients n’ont pas à se soucier de la surveillance ou de la gestion de la capacité de calcul lorsqu’ils utilisent Snowpipe pour leurs chargements de données.

Utilisation, facturation et coût de Snowpipe

Snowpipe utilise un modèle de facturation sans serveur. Les clients sont facturés en fonction de leur utilisation réelle des ressources de calcul plutôt que des réservations de capacité qui peuvent être inactives ou surutilisées. Au lieu de cela, Snowpipe suit la consommation de ressources des canaux dans un compte Snowflake donné pour les demandes de chargement traitées par le canal, avec une granularité par seconde/par cœur. L’utilisation enregistrée est ensuite traduite en crédits Snowflake familiers. L’utilisation de Snowpipe apparaît sous la forme de crédits Snowflake sur la facture, et les administrateurs de compte peuvent suivre l’utilisation de Snowpipe sur leurs pages de compte Snowflake au cours du mois. L’utilisation de Snowpipe est indiquée comme un entrepôt Snowflake spécial – indiqué par le logo Snowflake précédant le nom de l’entrepôt – dans le Entrepôt onglet dans Facturation et utilisation sur le portail Web Snowflake.

snowpipe 3

Une fonction de table appelée pipe_utilization_history dans Snowflake SQL vous permet d’explorer les détails d’utilisation de Snowpipe sur des périodes spécifiques ou pour des canaux spécifiques.

Essayez Snowpipe dès aujourd’hui et faites-nous part de vos commentaires. Snowpipe utilisant les notifications basées sur REST est disponible dès aujourd’hui. Vous pouvez trouver la documentation et les informations sur la façon de commencer ici.

Snowpipe avec auto-ingestion à l’aide de SQS est disponible en décembre. Si vous souhaitez participer à un aperçu privé de cette fonctionnalité, veuillez nous en informer. ici. MAssurez-vous de lire également la deuxième partie de ce blog sur Snowpipe ici.

Vous pouvez également essayer Snowflake gratuitement. S’inscrire et recevez 400 USD d’utilisation gratuite. Vous pouvez créer un bac à sable ou lancer une implémentation de production à partir du même environnement Snowflake.

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée.