Juin était plutôt un mois selon les exigences post-confinement. Non seulement les occasions en direct sont revenues avec vengeance après quelques années de marathons Zoom illimités, mais le début de l’été a vu une confluence d’occasions du trio sans doute le plus populaire du monde de l’information : dans l’ordre séquentiel, MongoDB, Snowflake et Databricks.
Il peut y avoir des différences nettes et subtiles dans chacune de leurs trajectoires, mais le fil conducteur est que chacune aspire à devenir la plate-forme d’information cloud (CDP) par défaut de la prochaine génération. Et cela établit le prochain acte pour tous les 3 : , Bien que nous ayons beaucoup à dire de notre rapport de voyage de juin avec le trio de points chauds de l’information, nous allons diviser notre analyse en deux parties. Aujourd’hui, nous allons nous concentrer sur le jeu vidéo d’échecs entre Databricks et Snowflake. Demain, dans la partie 2, nous expliquerons pourquoi les 3 entreprises doivent sortir de leur zone de confort si elles veulent devenir les plateformes d’information incontournables de la prochaine génération pour l’entreprise.
Le data lakehouse définit l’ordre du jour
Nous avons noté qu’avec l’analyse et le traitement des transactions, respectivement, MongoDB et Snowflake pourraient éventuellement être en conflit. Mais pour l’instant, il s’agit de la lutte à venir pour les cœurs et les esprits dans l’analyse entre Databricks et Snowflake, où nous limiterons notre conversation ici.
Le le grand contexte est la fusion de l’entrepôt d’informations et du lac d’informations. Environ 5 ans plus tôt, Databricks a créé le terme « data lakehouse », qui a ensuite touché une corde sensible. Presque tout le monde dans le monde de l’information, d’Oracle, Teradata, Cloudera, Talend, Google, HPE, Fivetran, AWS, Dremio et même Snowflake, a dû faire part de ses réactions. Databricks et Snowflake sont issus respectivement des mondes du lac de données et de l’entreposage de données, et les deux se rencontrent maintenant avec la maison du lac. Ils ne sont pas les seuls, mais les deux ont probablement les bases à la croissance la plus rapide.
Le Lakehouse n’est que le chemin vers la fin pour Databricks et Snowflake, car ils cherchent à devenir les informations et les analyses. emplacement pour l’entreprise.
Pour simplifier à l’extrême, Snowflake invite la foule Databricks avec Snowpark, tant qu’ils veulent que leurs routines Java, Python ou Scala s’exécutent en tant que fonctions SQL. La clé de Snowpark est que les data scientists et les ingénieurs n’ont pas à modifier leur code.
Pendant ce temps, Databricks invite le public de Snowflake avec un tout nouveau moteur d’interrogation SQL bien plus pratique et performant que l’original Lueur SQL. Ironiquement, dans ces échauffourées, Glow est actuellement sur la touche : Snowpark ne prend pas (encore) en charge l’exécution de Spark, tandis que le tout nouveau Databricks SQL, construit sur le moteur d’interrogation Photon, n’utilise pas Spark.
La question technique pour les deux entreprises est de savoir comment dessiner le développeur Python. Pour Snowflake, la préoccupation est de savoir si les fonctions définies par l’utilisateur (UDF) sont le cours le plus performant, et ici, l’entreprise achète Anaconda, qui optimise ses bibliothèques pour qu’elles s’exécutent dans Snowpark. Databricks traite de la même préoccupation, étant donné que Spark a été écrit en Scala, qui a traditionnellement eu l’avantage en termes de performances. Cependant, avec Python, les distinctions peuvent se réduire. Notre société pense que Snowflake inclura éventuellement une capacité d’exécution native dans la base de données de Python et peut-être des charges de travail Stimulate, mais cela nécessitera une ingénierie considérable et ne se produira pas du jour au lendemain.
Pendant ce temps, Databricks complète le data lakehouse, élargit les capacités de son nouveau moteur de recherche tout en incluant une brochure Unity comme base de la gouvernance, avec des contrôles d’accès précis, un arbre généalogique des données et un audit, et tirer parti des combinaisons de partenaires pour une gouvernance et une gestion des politiques innovantes. Andrew Brust a fourni une analyse approfondie des nouvelles fonctionnalités de Delta Lake et des travaux associés tels que Project Lightspeed dans sa couverture de l’événement Databricks le mois dernier.
Qui est le plus ouvert, et est-ce important ?
Databricks et Snowflake varient également en open source. Cela peut être un principe subjectif, et nous ne sommes pas prêts à revoir l’argument une fois de plus.
Qu’il suffise de dire que Databricks déclare qu’il est beaucoup plus ouvert que Snowflake, à condition que ses racines avec le travail Apache Glow. Il indique les entreprises qui exploitent Presto, Trino, Do It Yourself Apache Spark ou des installations commerciales de stockage d’informations directement sur Delta sans payer Databricks. Et cela étend le même argument au partage d’informations, comme nous le noterons ci-dessous. Pour régler l’argument sur l’ouverture, Databricks a révélé que les fonctions restantes de Delta Lake sont désormais open source.
En attendant, Snowflake ne s’excuse pas d’avoir adhéré au mode exclusif traditionnel, car il maintient que c’est le moyen le plus fiable de rendre sa plate-forme cloud performante. Les API de Snowpark sont ouvertes à tous, et si vous ne souhaitez pas conserver les données dans les tables Snowflake, il s’agit simplement d’une prise en charge ouverte des soumissions Parquet gérées par Apache Iceberg open source en tant que format de table de lac de données. Bien sûr, cela conduit à plus de conflits concernant le stockage de table de lac d’informations open source le plus ouvert : Delta Lake ou Iceberg (OK, n’oubliez pas Apache Hudi). Voici un avis extérieur, même s’il n’est pas vraiment objectif.
Databricks fait de l’open source un élément crucial de sa différenciation. Si l’on exclut des entreprises comme Percona (qui rend ses services fournissant un support pour l’open source), il est rare qu’une plate-forme soit 100 % open source. Et pour Databricks, les inclus tels que ses notebooks et le moteur Photon alimentant Databricks SQL sont strictement exclusifs. Comme s’il y avait quelque chose de mal à cela.
Maintenant, la bataille au corps à corps
Les entrepôts de données sont en fait connus pour offrir des performances prévisibles, tandis que les lacs de données sont connus pour leur capacité à mettre à l’échelle et prendre en charge les informations polyglottes et la capacité d’exécuter des analyses approfondies et exploratoires et une modélisation complexe. Le data lakehouse, un concept présenté par Databricks il y a près de cinq ans, est censé offrir le meilleur des deux mondes, et à son crédit, le terme a été adopté par une grande partie du reste du marché. La préoccupation opérationnelle est la suivante : les Data Lakehouses peuvent-elles fournir les SLA cohérents produits par les entrepôts d’informations ? C’est le contexte derrière la promotion de Delta Lake par Databricks, qui ajoute une structure de table aux données enregistrées dans des fichiers Parquet open source.
Cela a préparé le terrain pour les critères TPC-DS de Databricks l’automne dernier, qu’Andrew Brust mis en perspective, et bien sûr, Snowflake a répondu. Lors de la conférence, le PDG de Databricks, Ali Ghodsi, a mis à jour les résultats. Le voir vanter les références compétitives par rapport à Snowflake a ravivé des souvenirs relaxants de Larry Ellison déversant sur Amazon Redshift avec Autonomous Database. Nous prenons généralement des normes avec des grains de sel, nous n’insisterons donc pas sur des chiffres spécifiques ici. Il suffit de dire que Databricks revendique des performances de coût exceptionnelles par rapport à Snowflake par ordre de grandeur lors de l’accès aux fichiers Parquet. De toute évidence, la question de savoir si cela reflète l’agent de configuration pour les charges de travail BI est une question dont les professionnels doivent discuter.
Ce qui est intéressant, c’est que Databricks a montré qu’il n’était pas religieusement lié à Spark. En fait, voici un fait agréable : nous avons découvert qu’environ 30 % des travaux exécutés sur Databricks ne sont pas stimulés.
Le moteur de questions Photon récemment publié est une réécriture totale, plutôt qu’une amélioration de Glow SQL. Ici, Databricks a remplacé le code Java, les constructions JVM et le moteur d’exécution Spark par le C éprouvé utilisé par tous les noms familiers. C est beaucoup plus déshabillé que Java et la JVM et est encore plus efficace dans la gestion de la mémoire. L’ancien est à nouveau flambant neuf.
Partager des informations, répartir l’empreinte
C’est un domaine dans lequel Snowflake définit le programme. Il a présenté le concept moderne de partage d’informations dans le cloud il y a environ cinq ans avec le partage de données, qui a été postulé sur les entreprises de ligne internes partageant l’accès et l’analyse sur exactement le même corps de données sans avoir besoin de le déplacer.
L’idée était gagnant-gagnant pour Snowflake puisqu’elle fournissait un moyen d’étendre son empreinte au sein de sa clientèle, et parce que la majeure partie des revenus de Snowflake provient du calcul, et non du stockage, plus de partage de données signifie plus utiliser et plus calculer. Par conséquent, les hyperscalers ont pris le train en marche, ajoutant des ensembles de données à leurs places de marché.
Avance rapide vers le présent et le partage de données retarde le pivot de Snowflake de l’entrepôt de données cloud au cloud d’informations. En particulier, le cloud Snowflake doit être la destination de votre organisation pour l’analyse. Un attrait essentiel du partage de données Snowflake est que, si les informations se trouvent exactement dans la même région du même cloud, elles n’ont pas à être déplacées ou dupliquées. Au lieu de cela, le partage d’informations concerne l’approbation des approbations. Le revers de la médaille est que le partage d’informations internes et externes de Snowflake peut s’étendre à toutes les zones de cloud et à divers clouds, car il prend en charge la duplication requise.
La mise à niveau actuelle vers Snowflake Data Marketplace, qui est désormais renommé Snowflake Marketplace, est que les fournisseurs de données peuvent monétiser leurs données et, dans un tout nouvel ajout, leurs UDF au moyen d’un cadre d’application natif, qui accrédite que ces régimes s’exécuteront dans Snowpark. Ils peuvent vendre l’accès aux données et aux applications natives présentes dans Snowflake sans avoir à payer de commission à Snowflake. L’essentiel est que cela se produise dans le jardin clos de Snowflake, car le marché ne couvre que les données et les applications résidant dans Snowflake.
Le mois dernier, Databricks a apporté sa réponse, révélant l’ouverture de marchés d’informations internes et externes. Contrairement à Snowflake, il s’exécute dans une zone et un cloud uniques, car le service Databricks ne dispose pas actuellement de fonctions de réplication interrégionales ou intercloud. Le marché dépasse les ensembles de données pour inclure des conceptions, des cahiers et d’autres artefacts. L’une des caractéristiques du marché Databricks est les salles blanches de données, dans lesquelles les entreprises conservent un contrôle total sur les célébrations qui peuvent effectuer quelle analyse sur leurs données sans exposer d’informations délicates telles que les informations personnellement identifiables (PII), une capacité que Snowflake avait déjà.
Il existe un certain nombre de distinctions fondamentales entre les marchés Snowflake et Databricks, indiquant la politique et le stade de développement. La distinction politique a à voir avec la monétisation, une capacité que Snowflake a simplement ajoutée tandis que Databricks s’est intentionnellement abstenu. Le point de vue de Databricks est que les fournisseurs de services d’information ne partageront probablement pas les données au moyen d’offres de cartes de paiement désintermédiées, mais dépendront plutôt d’accords directs entre les fournisseurs et les clients.
La politique de non-intervention de Databricks vis-à-vis des données et des artefacts sur son marché englobe les frais d’admission, ou plus particulièrement, leur absence. Databricks déclare que les fournisseurs et les clients de son marché n’ont pas besoin d’être des clients Databricks.
Jusqu’à récemment, Databricks et Snowflake ne se rencontraient pas vraiment car ils ciblaient différents publics : Databricks se concentrant sur les ingénieurs de l’information et des scientifiques des données établissant des modèles et des transformations d’informations, résolvant des blocs-notes, tandis que Snowflake a attiré des experts en affaires et en informations grâce à des outils ETL et BI pour l’enquête, la visualisation et la création de rapports. Il s’agit d’un autre cas de l’ampleur du calcul et du stockage dans le cloud qui amenuise les barrières technologiques entre les lacs d’informations et l’entreposage d’informations, et avec elle, les barrières entre les différentes circonscriptions.
Demain, nous allons regarde le contraire de la formule. Databricks et Snowflake se transforment en emplacements de données, tout comme MongoDB. Ce sont chacune des sociétés de bases de données à forte croissance, et elles devront chacune s’efforcer en dehors de leurs zones de commodité pour y arriver.
Restez à l’écoute.
L’objectif de VentureBeat est d’être une place publique numérique permettant aux décideurs techniques d’acquérir des connaissances sur l’innovation et les transactions d’entreprise transformatrices. En savoir plus sur l’abonnement.
.
Toute l’actualité en temps réel, est sur L’Entrepreneur
