Dataschaakspel: Databricks vs. Snowflake, deel 1

Juni was een behoorlijke maand voor post-lockdown-normen. Niet alleen keerden live-evenementen met wraak terug na een paar jaar eindeloze Zoom-marathons, maar het begin van de zomer zag een samenvloeiing van evenementen van misschien wel het populairste trio van de datawereld: in sequentiële volgorde, MongoDB, Sneeuwvlok en Databricks.

Er kunnen grote en subtiele verschillen zijn in elk van hun trajecten, maar de rode draad is dat elk ervan ernaar streeft het standaard enterprise clouddataplatform (CDP) van de volgende generatie te worden. En dat vormt de volgende handeling voor alle drie: elk van hen zal buiten hun belangrijkste kiesdistricten moeten reiken om hun zakelijke aantrekkingskracht te vergroten.

Omdat we veel te zeggen hebben over ons reisverslag van juni met het trio van gegevenshotshots, gaan we onze analyse in twee delen splitsen. Vandaag concentreren we ons op het schaakspel tussen Databricks en Snowflake. Morgen, in deel 2, zullen we beargumenteren waarom alle drie de bedrijven uit hun comfortzone moeten stappen als ze de volgende generatie go-to-dataplatforms voor de onderneming willen worden.

Het data lakehouse bepaalt de agenda

We merkten op dat met respectievelijk analyse en transactieverwerking MongoDB en Snowflake uiteindelijk op een ramkoers. Maar voor nu draait het allemaal om de komende strijd om de harten en geesten in analyses tussen Databricks en Snowflake, en dat is waar we onze discussie hier zullen beperken.

De grote context is de convergentie van datawarehouse en data lake. Ongeveer vijf jaar geleden bedacht Databricks de term ‘data lakehouse’, die vervolgens een gevoelige snaar raakte. Bijna iedereen in de datawereld, van Orakel, Teradata, Cloudera, talent, Google, HPE, Fivetran, AWS, drama en zelfs Sneeuwvlok moesten inhaken op hun reacties. Databricks en Snowflake kwamen respectievelijk uit de data lake- en datawarehousing-werelden, en beide komen elkaar nu tegen met de lakehouse. Ze zijn niet de enigen, maar beide hebben misschien wel de snelst groeiende bases.

De Lakehouse is gewoon het middel tot het doel voor zowel Databricks als Snowflake, aangezien ze de data- en analysebestemming voor de onderneming willen worden.

Om het te simplificeren, nodigt Snowflake de Databricks-menigte uit met Snowpark, zolang ze bereid zijn om hun Java-, Python- of Scala-routines als SQL-functies te laten uitvoeren. De sleutel tot Snowpark is dat datawetenschappers en ingenieurs hun code niet hoeven te wijzigen.

Ondertussen nodigt Databricks de Snowflake-menigte uit met een nieuwe SQL-query-engine die veel functioneler en performanter is dan de originele Spark SQL. Ironisch genoeg staat Spark in deze schermutselingen momenteel aan de zijlijn: Snowpark ondersteunt (nog) geen Spark-uitvoering, terwijl de nieuwe Databricks SQL, gebouwd op de Photon-query-engine, Spark niet gebruikt.

De strikvraag voor beide bedrijven is hoe de Python-programmeur te tekenen. Voor Snowflake is de vraag of door de gebruiker gedefinieerde functies (UDF’s) het meest performante pad zijn, en hier kan het bedrijf investeert in Anaconda, dat zijn bibliotheken optimaliseert voor gebruik in Snowpark. Databricks staat voor dezelfde vraag, aangezien Spark is geschreven in Scala, dat van oudsher de prestatievoorsprong had. Maar met Python, de verschillen kan vernauwen. We zijn van mening dat Snowflake uiteindelijk de mogelijkheid zal toevoegen voor native uitvoering in de database van Python- en misschien Spark-workloads, maar dat vereist aanzienlijke engineering en zal niet van de ene op de andere dag gebeuren.

Ondertussen rondt Databricks het data lakehouse af, breidt het de mogelijkheden van zijn nieuwe query-engine uit en voegt het een Unity-catalogus toe als de basis voor governance, met fijnmazige toegangscontroles, data-afstamming en auditing, en gebruik makend van partnerintegraties voor geavanceerd bestuur en beleid beheer. Andrew Brust op voorwaarde dat de diepe duik over de nieuwe mogelijkheden voor Deltameer en gerelateerde projecten zoals Project Lightspeed in zijn verslag van het Databricks-evenement vorige maand.

Wie is er meer open, en maakt het uit?

Databricks en Snowflake verschillen ook op open source. Dit kan een subjectief concept zijn, en we zijn niet van plan om het debat opnieuw te bekijken.

Het volstaat te zeggen dat Databricks beweert dat het veel opener is dan Snowflake, gezien zijn wortels bij het Apache Spark-project. Het verwijst naar bedrijven die Presto, Trino, DIY Apache Spark of commerciële datawarehouses rechtstreeks op Delta runnen zonder Databricks te betalen. En het breidt hetzelfde argument uit tot het delen van gegevens, zoals we hieronder zullen opmerken. Om het argument over openheid te beslechten, kondigde Databricks aan dat de resterende functies van Delta Lake nu open source zijn.

Ondertussen verontschuldigt Snowflake zich niet voor het vasthouden aan de traditionele propriëtaire modus, omdat het beweert dat dit de meest effectieve manier is om zijn cloudplatform performant te maken. Maar de API’s van Snowpark staan ​​open voor iedereen, en als je geen gegevens in Snowflake-tabellen wilt opslaan, is er zojuist ondersteuning geopend voor Parquet-bestanden die worden beheerd door open-source Apache ijsberg als het data lake-tabelformaat. Dat leidt natuurlijk tot meer discussies over welke open-source data lake-tafelopslag het meest open is: Delta Lake of Iceberg (OK, vergeet niet Apache Hudi). Hier is een mening van buitenafzelfs als het niet echt onbevooroordeeld is.

Databricks maakt van open source een belangrijk onderdeel van zijn differentiatie. Maar met uitzondering van bedrijven zoals Sorry (waardoor het bedrijf ondersteuning voor open source levert), is het zeldzaam dat een platform 100% open source is. En voor Databricks zijn functies zoals de notebooks en de Photon-engine die Databricks SQL aanstuurt, strikt eigendom van het bedrijf. Alsof daar iets mis mee is.

Nu de man-tegen-man-gevechten

Datawarehouses staan ​​bekend om het leveren van voorspelbare prestaties, terwijl datameren bekend staan ​​om hun vermogen om polyglot data te schalen en te ondersteunen en om het vermogen om diepgaande, verkennende analyses en complexe modellering uit te voeren. Het data lakehouse, een concept dat bijna vijf jaar geleden door Databricks werd geïntroduceerd, is bedoeld om het beste van twee werelden te bieden, en het strekt tot eer dat de term door een groot deel van de rest van de industrie is overgenomen. De bruikbare vraag is: kunnen data lakehouses de consistente SLA’s leveren die door datawarehouses worden geproduceerd? Dat is de context achter Databricks’ promotie van Delta Lake, dat een tabelstructuur toevoegt aan gegevens die zijn opgeslagen in open-source Parquet-bestanden.

Dat zette de toon voor de TPC-DS-benchmarks van Databricks laatste valwelke Andrew Brust in perspectief gezeten uiteraard, Sneeuwvlok reageerde. Tijdens de conferentie heeft Databricks CEO Ali Ghodsi de resultaten bijgewerkt. Kijken hoe hij de . verheerlijkt concurrerende benchmarks vs. Snowflake hernieuwde gezellige herinneringen aan Larry Ellison aan het lossen op Amazon Redshift met Autonomous Database. We nemen benchmarks doorgaans met een korreltje zout, dus we zullen hier niet stilstaan ​​bij exacte cijfers. Het volstaat te zeggen dat Databricks superieure prijsprestaties claimt ten opzichte van Snowflake in orde van grootte bij het openen van Parquet-bestanden. Of dit representatief is voor configuraties die representatief zijn voor BI-workloads, is natuurlijk een kwestie voor experts om te bespreken.

Wat interessant is, is dat Databricks aantoonde dat het niet religieus verbonden was met Spark. Hier is eigenlijk een leuk feit: we hebben geleerd dat ongeveer 30% van de workloads die op Databricks worden uitgevoerd, geen Spark zijn.

Bijvoorbeeld de nieuw uitgebrachte foton query-engine is een volledige herschrijving in plaats van een verbetering van Spark SQL. Hier verving Databricks de Java-code, JVM-constructies en de Spark-uitvoeringsengine door de beproefde C++ die door alle bekende namen wordt gebruikt. C++ is veel uitgekleder dan Java en de JVM en is veel efficiënter in het beheren van geheugen. Het oude is weer nieuw.

Dit is een gebied waar Snowflake de agenda bepaalt. Het introduceerde ongeveer vijf jaar geleden het moderne concept van het delen van gegevens in de cloud met de datasharehousedie was gebaseerd op interne lijnorganisaties die toegang en analyses op dezelfde gegevens delen zonder deze te hoeven verplaatsen.

Het idee was een win-winsituatie voor Snowflake omdat het een manier bood om zijn voetafdruk binnen zijn klantenbestand uit te breiden, en aangezien het grootste deel van Snowflake’s inkomsten afkomstig is van rekenkracht, niet van opslag, betekent meer delen van gegevens meer gebruik en meer rekenkracht. Vervolgens sprongen de hyperscalers op de kar en voegden datasets toe aan hun marktplaatsen.

Snel vooruit naar het heden en het delen van gegevens is achter Snowflake’s spil van cloud datawarehouse naar datacloud. In het bijzonder zou Snowflake cloud de bestemming van uw organisatie voor analyses moeten zijn. Een belangrijk voordeel van het delen van Snowflake-gegevens is dat, als de gegevens zich binnen dezelfde regio van dezelfde cloud bevinden, deze niet hoeven te worden verplaatst of gerepliceerd. In plaats daarvan gaat het delen van gegevens over het verlenen van machtigingen. De keerzijde is dat Snowflake’s interne en externe gegevensuitwisseling zich kan uitstrekken over cloudregio’s en verschillende clouds, omdat het de noodzakelijke replicatie ondersteunt.

De nieuwste update van Snowflake Data Marketplace, die nu is omgedoopt tot Snowflake Marketplace, is dat gegevensproviders inkomsten kunnen genereren met hun gegevens en, in een nieuwe toevoeging, hun UDF’s via een Systeemeigen applicatieframework, wat bevestigt dat deze routines binnen Snowpark zullen worden uitgevoerd. Ze kunnen toegang tot de gegevens en native apps in Snowflake verkopen zonder commissie aan Snowflake te hoeven betalen. De sleutel is dat dit moet gebeuren binnen de ommuurde tuin van Snowflake, aangezien de markt alleen gegevens en apps omvat die zich in Snowflake bevinden.

Vorige maand kwam Databricks met zijn antwoord en kondigde de opening aan van interne en externe datamarktplaatsen. In tegenstelling tot Snowflake draait het binnen een enkele regio en cloud, omdat de Databricks-service momenteel geen replicatiefuncties voor meerdere regio’s of meerdere clouds heeft. De markt gaat verder dan datasets en omvat modellen, notebooks en andere artefacten. Een van de kenmerken van Databricks-marktplaats is: data cleanroomswaarin providers volledige controle behouden over welke partijen welke analyse op hun gegevens kunnen uitvoeren zonder gevoelige gegevens zoals persoonlijk identificeerbare informatie (PII) bloot te leggen, een mogelijkheid die Snowflake al had.

Er zijn verschillende basisverschillen tussen de Snowflake- en Databricks-marktplaatsen, die het beleid en de ontwikkelingsfase weerspiegelen. Het beleidsverschil gaat over het genereren van inkomsten, een mogelijkheid die Snowflake zojuist heeft toegevoegd, terwijl Databricks met opzet heeft afgezien. Databricks is van mening dat gegevensaanbieders waarschijnlijk geen gegevens zullen delen via niet-bemiddelde creditcardtransacties, maar in plaats daarvan zullen vertrouwen op directe overeenkomsten tussen aanbieders en consumenten.

Het hands-off-beleid van Databricks voor gegevens en artefacten op zijn markt strekt zich uit tot de toegangsprijs, of meer specifiek, het ontbreken ervan. Databricks zegt dat providers en consumenten op zijn markt geen Databricks-abonnees hoeven te zijn.

Tot voor kort kwamen Databricks en Snowflake elkaar niet echt tegen omdat ze zich op verschillende doelgroepen richtten: Databricks gericht op data-ingenieurs en datawetenschappers die modellen en datatransformaties ontwikkelen, werken met notebooks, terwijl Snowflake een beroep deed op business en data-analisten via ETL en BI tools voor query’s, visualisatie en rapportage. Dit is een ander geval van de enorme schaal van rekenkracht en opslag in de cloud die technologische barrières tussen datameren en datawarehousing wegvaagt, en daarmee de barrières tussen verschillende achterban.

Morgen kijken we naar de andere kant van de vergelijking. Databricks en Snowflake vormen zichzelf tot databestemmingen, net als MongoDB. Het zijn stuk voor stuk snelgroeiende databasebedrijven, en ze zullen elk hun comfortzone moeten verlaten om daar te komen.

Blijf kijken.

Dit is de eerste van een tweedelige serie. De post van morgen zal de volgende stappen schetsen die Databricks, MongoDB en Snowflake zouden moeten nemen om een ​​beroep te doen op de bredere onderneming.