TL;DR
De nombreuses entreprises utilisent aujourd'hui Snowflake et Databricks en parallèle, et elles ont besoin d'un seul et même endroit pour suivre les coûts des deux plateformes. Databricks est par ailleurs véritablement plus difficile à optimiser que la plupart des plateformes : plus de services, plus de paramètres de configuration, plus de façons pour les coûts d'évoluer sans raison apparente. Nous avons créé SELECT pour Databricks afin d'offrir aux équipes data la même visibilité sur les coûts et les mêmes capacités d'optimisation que celles développées pour Snowflake.
Chez SELECT, nous avons eu l'honneur d'accompagner plus de 250 clients Snowflake. Au fil du temps, une demande revenait sans cesse : pouvez-vous faire la même chose pour Databricks ?
Cette question a été le point de départ. Mais deux autres constats nous ont poussés à développer la visibilité et l'optimisation des coûts pour Databricks, et ils ont davantage pesé sur la manière dont nous l'avons construit.
Le multi-plateforme : la nouvelle norme pour la plupart des équipes
Parmi les comptes que nous accompagnons, utiliser Snowflake et Databricks ensemble est devenu la norme, et non l'exception. La répartition est généralement logique au regard des workloads : Snowflake pour l'analytique structurée, Databricks pour le compute intensif et le machine learning.
Les équipes qui utilisent les deux voulaient pouvoir comparer l'exécution de leurs workloads sur chaque plateforme et suivre l'ensemble de leurs dépenses de plateforme data au même endroit.
Databricks : beaucoup plus de paramètres à régler que Snowflake
Avec Snowflake, l'offre de compute est très simple et facile à prendre en main. Les virtual warehouses ne comportent que quelques paramètres de configuration à optimiser.
Databricks, c'est une tout autre histoire. Il existe plusieurs options de compute et manières d'exécuter des workloads (jobs compute, all purpose/interactive, serverless SQL, etc.), et chaque service propose nettement plus d'options de configuration. Taille du cluster, paramètres d'auto-scaling, choix du type d'instance, utilisation d'instances Spot : autant de décisions qui pèsent directement sur votre facture.
Plus de configuration signifie plus de surface d'optimisation. Mais aussi plus de risques de mal configurer quelque chose et de ne s'en apercevoir qu'une fois les coûts déjà partis à la hausse.
Ce dont nous sommes certains, c'est que la visibilité doit venir en premier. Impossible d'optimiser ce que l'on ne voit pas. SELECT pour Databricks commence là : une ventilation claire des dépenses réelles et des facteurs qui expliquent leur évolution dans le temps.
Une adoption de Databricks qui s'accélère dans les organisations
Databricks a démarré comme une plateforme spécialisée pour le ML et le data engineering. Elle a largement dépassé ce périmètre. De plus en plus d'équipes y exécutent des types de workloads variés, et l'adoption s'accélère au sein des organisations.
Une adoption rapide crée un problème bien connu : les dépenses augmentent avant que les processus pour les maîtriser ne soient en place. Les équipes ajoutent des workloads, les coûts grimpent, et personne n'a de vision claire de ce qui les fait monter jusqu'à ce que la facture dépasse les prévisions.
Nous avons observé le même phénomène avec Snowflake. Les équipes l'ont adopté rapidement, les coûts ont pris de l'avance sur la visibilité, puis le travail de compréhension et de maîtrise des dépenses a commencé. SELECT a été conçu exactement pour ce moment-là. La même histoire se répète aujourd'hui avec Databricks.
Ce que nous avons construit
SELECT pour Databricks offre aux équipes data une attribution des coûts par équipe, workspace, job et workload de requêtes. Chaque dollar peut être suivi, les utilisateurs sont automatiquement alertés en cas de hausse des dépenses grâce à notre détection d'anomalies basée sur le ML, puis peuvent en identifier automatiquement la cause profonde avec notre Copilot IA.
En plus d'une observabilité des coûts très complète, les utilisateurs peuvent réduire automatiquement leurs dépenses de compute, sans aucun effort, grâce à notre fonctionnalité Automated Savings, qui optimise en temps réel les SQL warehouses, les clusters all-purpose et les jobs compute, sans aucun impact sur les performances.
Pour voir SELECT en action, réservez un créneau avec nous sur : select.dev/demo.