L’idée de cet article a émergé lors d’une mission chez un client impliquant des technologies basées sur le Cloud, notamment Snowflake. Lors de la mise en place de l’architecture cible, j’ai pu rencontrer certains problèmes d’observabilité concernant un outil de Snowflake : Snowpipe. Pour faire simple, cet outil permet d’automatiser le chargement de données vers Snowflake, dès que ces dernières sont disponibles dans un stage. Un stage est une zone de préparation, interne ou externe a Snowflake (S3, GCS, Azure, etc) et visant à accueillir des données devant être chargées. Lorsque l’on charge des données, il est important de bénéficier d’une visibilité claire de ce qui est fait, afin de savoir si toute la donnée s’est importée correctement dans notre data warehouse. Malheureusement, il n'existe pas aujourd'hui de moyen simple de superviser Snowpipe. Je vais donc proposer une solution relative à l’observabilité des ingestions de Snowpipe, pour potentiellement aider les prochaines personnes qui seront dans mon cas.

Pour pouvoir aborder les points qui m’intéressent, je vais me baser sur un petit cas d’utilisation simulant le comportement de la stack logicielle du projet. Les outils utilisés sont les suivants :

• S3 : Il s'agit de l’un des services les plus connus d’AWS. ll permet de stocker un grand nombre d’objets et de bénéficier de plusieurs niveaux d’évolutivité, de disponibilité des données, de sécurité et de performances.
• Snowflake : C’est un data warehouse basé sur le cloud. C’est plus particulièrement Snowpipe qui nous intéresse ici. Snowpipe permet de charger des données à partir de zones de préparations (telles qu’un bucket S3), et de les rendre disponibles automatiquement sans avoir à exécuter manuellement des instructions COPY. Je ne vais pas rentrer dans les détails de la mise en place de cet outil sachant que sa documentation est très bien faite. Voici le lien vers cette dernière.
• Apache Superset : Il s’agit d’un outil de visualisation et d’exploration de données open-source que j’ai choisi pour ce sujet. Je ne vais pas non plus rentrer dans les détails de cet outil, pour cela vous pouvez vous orienter vers l'article de Romain LE GOAS passant en revue cet outil : Apache Superset : un logiciel de visualisation à suivre

Le contexte pour monitorer Snowpipe sera le suivant :

Nous possédons une table dans Snowflake qui recense des informations sur des personnes. Nous souhaitons alimenter cette table via des fichiers CSV que nous allons déposer dans un bucket S3. La mise en place préalable de Snowpipe permet de charger ces fichiers dès qu’ils sont déposés. Voici un schéma représentant l’architecture mise en place.

‌‌

Visibilité sur Snowpipe

Comme dit précédemment, lorsque l’on charge un certain nombre de données, il est important de bénéficier d’une visibilité claire de ce qui est fait. Je vais donc ici essayer de présenter un moyen simple d’y arriver lors de l’utilisation de Snowpipe.

Dans notre cas, le pipe est nommé 'TEST_SNOWPIPE_PIPE', et notre table est nommée 'TEST_SNOWPIPE_TABLE'. Afin d’étudier l’impact de notre pipe, nous disposons de plusieurs requêtes impliquant ces ressources.

SELECT system$pipe_status('TEST_SNOWPIPE_PIPE')

Cette requête renvoie un JSON qui décrit l’état de notre pipe. On y retrouve des informations sur l’état du pipe (Running, Stopped, Paused, etc ...), le nombre de fichiers en attente de traitement dans le pipe, le timestamp du dernier envoi de fichier, etc. Grâce à cette requête on a de la visibilité sur un certain nombre d'informations qui sont importantes. Néanmoins ce n’est pas suffisant.

SELECT * FROM table(information_schema.copy_history(
                table_name=>'TEST_SNOWPIPE_TABLE', 
                start_time=> dateadd(day, -14, current_timestamp())));

‌                        

Cette requête est relativement explicite. Elle permet de récupérer l’historique de copy qui a été réalisé sur notre table datant des 14 derniers jours. Cet historique présente de nombreuses informations impliquées lors du copy : le nom du fichier, le nom du “stage”, le nom du pipe, de la table, le nombre d’erreurs, le message d’erreur, si le fichier a été chargé ou non, etc. C’est réellement à partir de cet historique que l’on peut avoir une vision complète de ce qui est fait. Je charge des fichiers dans le pipe. Voici l'output de ces requêtes :

{
"executionState":"RUNNING",
"pendingFileCount":2,
"notificationChannelName":"arn:aws:sqs:eu-west-1:520339422657:sf-snowpipe-AIDAJ56TQ6CMECLI20KHY62Kj04wv8JZbpnoPPK1991Q", 
"numOustandingMessagesOnChannel":7, "lastReceivedMessageTimestamp":"2021-06-24T09:14:07.31Z",
"lastForwardedMessageTimestamp":"2021-06-24T09:14:07.355Z"
}

‌‌NB : Il y a 20 colonnes dans l’historique, la capture d’écran n’est donc pas exhaustive.

On s'aperçoit que ces requêtes mettent en lumière beaucoup d’éléments et que les informations essentielles se perdent parmi l'amas d’informations.

Visualisation de Snowpipe

‌‌Pour monitorer Snowpipe, il faut créer des vues, et utiliser un outil de visualisation capable de se brancher à Snowflake, et capable de monitorer ces vues. Bonne nouvelle, notre outil de visualisation Superset possède un connecteur permettant de se brancher à Snowflake. Il suffit d’ajouter “snowflake-sqlalchemy” aux “requirements” de superset pour pouvoir être compatible.

Dans Superset, la première étape est de créer une database faisant le lien entre Superset et Snowflake. Cela fait, on peut ensuite créer des datasets basés sur cette connexion et récupérer les tables et les vues existantes.

Voici un exemple de dashboard simple que j’ai réalisé avec Superset. Ce dernier a surtout pour but de montrer qu’il est bien possible de mettre à disposition les informations importantes relatives à Snowpipe très rapidement et simplement.

‌‌Ici, on récupère tout simplement notre vue initiale contenant l’historique des “copy”. On peut réaliser des visualisations simples sur le nombre de lignes chargées par exemple ou tout simplement cibler les erreurs.

Conclusion

Snowpipe est un outil très intéressant et utile pour automatiser le chargement de fichiers dans Snowflake. Il est nécessaire d’effectuer certaines actions pour avoir un minimum de visibilité sur ses actions et son état. Pour simplifier la visibilité de cet outil et des potentiels problèmes qu’il peut rencontrer, le plus simple est d’utiliser un outil de visualisation et/ou de reporting compatible avec Snowflake, et de requêter des vues Snowflake.

‌‌‌‌