kalafoto - Fotolia
Ingestion, transformation, streaming : Snowflake accélère le rythme
Le fournisseur américain continue d’empiler les fonctionnalités sur sa plateforme de gestion de données avec un fort accent mis sur l’ingestion et la transformation de données.
S’il concentre principalement ses efforts sur l’ajout de fonctionnalités d’IA, Snowflake n’en oublie pas ses fondamentaux.
Lors de sa conférence Build cette semaine, il a présenté la disponibilité générale (ou imminente) de plusieurs fonctionnalités ciblant les ingénieurs de données. Son objectif demeure l’unification d’un maximum de charges de travail sur sa plateforme. Tout en bousculant, au passage, la concurrence.
Snowflake se concentre sur l’ingestion et la transformation de données…
D’abord, l’éditeur poursuit le déploiement de son service d’intégration de données, Openflow. Basé sur Apache NiFi et le rachat de Datavolo, l’outil aura « bientôt » le droit, en « GA » (General Availability), à l’option Snowflake Deployment. En clair, les clients n’ont plus déployé eux-mêmes l’outil sur AWS ou Azure. Une suite de commandes permet d’installer OpenFlow depuis Snowpark Container Services, l’instrumentation de Kubernetes et de Docker au besoin de l’éditeur.
Après l’ingestion, la transformation. Snowpark Connect for Apache Spark doit permettre d’exécuter des DataFrame et des requêtes Spark SQL directement sur le « Data Cloud ».
Les ingénieurs et les data scientists peuvent utiliser des notebooks Jupyter (au sein de Snowflake ou non), Apache Airflow, Snowpark, ou encore Visual Studio Code.
Il s’agit « d’éliminer la gestion des clusters Spark » et les coûts de sortie des données. Une solution qui serait 3 fois plus rapide qu’un cluster Spark self-managed. Elle offrirait une réduction de 30 % du coût total de possession.
Snowflake cherche là à supplanter Databricks sur son terrain de jeu de prédilection. Tout en sachant pertinemment qu’il ne couvre qu’une portion des fonctionnalités du moteur de traitement mis sur pied par les cofondateurs de Databricks.
Dans la même veine, l’éditeur a annoncé la disponibilité générale de dbt on Snowflake. En clair, il est possible de gérer et exécuter les pipelines de transformation dbt à même la plateforme. Il n’est plus nécessaire de déployer des instances AWS ou Azure séparées. Là, il s’agit d’une alternative à dbt Cloud.
… si possible en temps réel
À cela s’ajoute un nouveau type de tables, bientôt en disponibilité générale. Les tables et les entrepôts « interactifs » sont optimisés pour l’ingestion et l’interrogation de données « sous la seconde ». Ici, Snowflake s’appuie sur des flux de données Apache Kafka et le moteur Snowpipe Streaming.
Il faut toutefois que les requêtes demeurent simples. Ensemble, les deux dispositifs permettraient d’alimenter des tableaux de bord en quasi temps réel, des API, ou les charges de travail hautement concurrentes. L’éditeur avait déjà proposé les tables dynamiques, servant à rafraîchir rapidement les données. Ici, il cherche principalement à fluidifier les projets de BI opérationnelle ou de machine learning en temps réel.
Pour les développeurs, Snowflake met en place un espace de travail unifié, organisé en dossiers et en fichiers qui prend en charge les commandes SQL, les notebooks Python, les applications Streamlit et les pipelines de données. Il s’agit de centraliser les outils et les flux de travail à partir de ces workspaces rattachés à des dépôts Git (eux même potentiellement connecté à VS Code). En clair, les profils techniques peuvent pousser l’ensemble des actifs qu’ils conçoivent vers un seul environnement accessible aux métiers. Une initiative lancée en 2023.
En préversion publique, une interface utilisateur doit permettre d’analyser les données à la recherche de problème de qualité, dont les biais, la fraîcheur, la précision, les valeurs manquantes, etc. Ici, la fonctionnalité est liée au système de lineage de la plateforme. L’objectif semble de proposer une fonctionnalité proche du Trust Score de Qlik Talend. « Nous avons introduit un certain nombre de fonctionnalités, à la fois dans le moteur de base et dans notre interface utilisateur, afin de permettre à nos clients de créer facilement des règles sur la qualité des données », précise Christian Kleinerman. « Il s’agit de savoir quand un jeu de données n’est pas conforme à certains critères ».
Le fail-over des tables Iceberg arrive
Enfin, place aux administrateurs. Snowflake a annoncé la disponibilité générale d’une fonction de reprise après sinistre pour les tables Iceberg. Les objets et les bases de données sont copiés sur plusieurs régions cloud entre un compte Snowflake principal et un autre, secondaire. « Nous n’avons pas fait exprès, mais le moment est opportun », affirme Christian Kleinerman. « Beaucoup de nos clients ont été en mesure d’appliquer le fail-over lors de la panne [d’AWS] et faire de cet incident un non-événement. Ils veulent la même chose pour les tables Iceberg ».
La prise en charge multirégion d’AWS PrivateLink et du trafic sortant pour Google Private Connect Service en disponibilité générale participe à cet effort. Les administrateurs peuvent d’ailleurs paramétrer des règles de gestion réseau depuis la console Snowflake.
En outre, Performance Explorer permet d’acquérir des métriques plus précises sur la santé des environnements Snowflake, le volume de requêtes, les changements effectués sur les warehouses et les tables.
Un « rythme d’innovation effréné » ?
Alors qu’il déclinait sa feuille de route sur deux ans (de la sortie d’une fonction en préversion privée à sa disponibilité générale), l’éditeur semble accélérer le mouvement.
« Si vous considérez ce que nous avons fait au cours des six-douze derniers mois, le rythme de l’innovation chez Snowflake est effréné », affirme Christian Kleinerman en réponse à une question du MagIT. « Bon nombre des technologies en disponibilité générale cette semaine ont été introduites pour la première fois il y a six mois ou moins de six mois », assure-t-il. « Et ce qui est intéressant, c’est que nous avons une multitude d’innovations supplémentaires en cours que nous espérons présenter à nos clients dans le courant de l’année prochaine ».
Beaucoup d’entre elles concernent l’IA et l’IA agentique. Moins la gestion de données pure et dure. « Nous sommes en phase avec les priorités et tendances de l’industrie, et nous continuerons à les saisir pour servir nos clients ».
Il y a toutefois des fonctionnalités clés qui arrivent plus tardivement, du fait de cette course à l’échalote. Par exemple, l’accès unifié aux moteurs externes, dont Apache Spark, Flink, Python, Trino vient de passer en préversion privée. Cet ajout avait été présenté l’année dernière. Ces moteurs ne peuvent que lire les données des tables Iceberg managées à travers l’API REST d’Iceberg et Apache Polaris. La possibilité pour ces moteurs d’écrire des données sur les tables dans la plateforme est encore en cours de développement. C’est pourtant la clé d’une véritable ouverture de la plateforme.
Enfin, certains clients et partenaires attendent encore des améliorations des tables hybrides.
