Per rafforzare ulteriormente il nostro impegno nel fornire una copertura leader del settore della tecnologia dei dati, VentureBeat è entusiasta di accogliere Andrew Brust e Tony Baer come collaboratori regolari. Guarda i loro articoli nella pipeline di dati.
Questa è la seconda di una serie in due parti. Leggi la parte 1 che analizza come Databricks e Snowflake si stanno avvicinando alla competizione testa a testa.
Come abbiamo notato ieri, giugno è stato un mese piuttosto lungo per gli standard post-lockdown, poiché MongoDB, Snowflake e Databricks hanno organizzato ciascuno i loro eventi annuali in rapida successione. Storicamente, ciascuno di questi fornitori potrebbe essersi incrociato nelle stesse imprese, ma in genere con circoscrizioni diverse. Quindi, non hanno gareggiato direttamente l’uno contro l’altro.
Nonostante i recenti ribassi dei mercati finanziari, ciascuna di queste società è considerata tra gli attori in crescita più caldi sul lato della piattaforma di dati cloud, con valutazioni (private o di mercato) che vanno nelle decine di miliardi di dollari. Mentre Databricks è ancora privato, MongoDB e Snowflake hanno le loro IPO alle spalle.
Contents
Posizioni dei giocatori
Ognuno di loro si sta posizionando come piattaforme di destinazione predefinite per l’azienda. Databricks e Snowflake a questo punto sono sui rispettivi radar competitivi e ieri abbiamo dato la nostra opinione sulla partita a scacchi che stanno giocando. In questa puntata, esaminiamo cosa deve fare ogni giocatore per fare appello all’impresa più ampia. Sebbene ci siano differenze nei mercati di destinazione, in particolare con MongoDB, c’è un filo comune per tutti e tre: per crescere ulteriormente, dovranno espandersi oltre le loro zone di comfort.
Allora, quali sono queste zone di comfort? Databricks e Snowflake provengono da diverse parti del mondo dell’analisi, mentre MongoDB si è concentrato sui casi d’uso operativi. Storicamente, ognuno di loro ha fatto appello a un pubblico diverso. Databricks per data engineer e data scientist, Snowflake per business e analisti di dati e MongoDB per sviluppatori di app.
Ma le recenti mosse di tutti e tre i fornitori stanno iniziando a violare quei silos. Cominciamo con la distribuzione. Dei tre, MongoDB è l’unico con presenza on-premise (gli altri due sono giochi puramente cloud), ma a soli cinque anni dall’inizio del suo servizio di database cloud Atlas, i ricavi dell’azienda ora sono principalmente basati sul cloud. Mentre MongoDB probabilmente non sarà mai un gioco puro cloud, il cloud sta guidando distintamente il suo futuro.
Poi ci sono le operazioni. Con Snowflake che aggiunge un motore di elaborazione delle transazioni leggero e MongoDB che ha fatto le prime mosse per iniziare ad affrontare l’analisi oltre la visualizzazione, ci è stato chiesto di chiedere qualche settimana fa se fossero in rotta di collisione. La nostra opinione? A breve termine, sono ancora in universi separati, ma a lungo termine, mai dire mai.
Per quanto riguarda l’analisi, abbiamo notato ieri, Databricks e Snowflake sono più espliciti sull’espansione reciproca.
Tuttavia, mentre MongoDB rimane il più esplicito sull’attenersi al suo lavoro a maglia come database operativo, sotto la superficie sta facendo le prime mosse per venire a patti con le persone del database relazionale e immergersi nell’analisi.
I punti di partenza
Diamo un’occhiata ai messaggi emersi da ciascuno dei vertici del mese scorso. MongoDB voleva raddoppiare gli sviluppatori. Nel keynote del CTO Mark Porter, ha parlato del volume crescente di nuove applicazioni che usciranno nei prossimi anni e, con esso, della necessità di approcci opportuni che consentano agli sviluppatori di superare gli ostacoli alla produzione delle app. In Snowflake, si trattava di rafforzare il “cloud di dati” come destinazione ampliandone la portata, sia nell’elaborazione delle transazioni che nell’apprendimento automatico. E per Databricks, si trattava di benchmark, governance e capacità di lignaggio che dimostrano che la casa del lago di dati è pronta per la prima serata e sfrutta la propria strategia open source.
I punti di partenza di ogni giocatore mettono in prospettiva le loro ambizioni. La missione ufficiale di MongoDB è consentire alle aziende di operare come “società di software”. Ciò riflette il fatto che il collegio elettorale di MongoDB è stato tradizionalmente sviluppatori di software e che devono essere in grado di essere produttivi se le loro organizzazioni vogliono operare alla velocità delle società di software. Un messaggio ricorrente di tale strategia è che i database tradizionali si sono rivelati degli ostacoli, a causa della natura rigida dello schema relazionale e dell’impossibilità di ridimensionarli.
Per Snowflake, si tratta di prendere di mira gli analisti aziendali e di dati che si affidano ai data warehouse con una reinvenzione cloud-native che affronta le barriere della facilità d’uso, della scalabilità e della condivisione dei dati.
E per Databricks, si tratta di sfruttare l’ampiezza e la scala del data lake con un ambiente di sviluppo ed esecuzione zuppa di noccioline basato su Apache Spark, Photon e Delta Lake.
I prossimi passi
È qui che diventa fondamentale uscire dalla zona di comfort. Esaminiamo ogni provider individualmente.
MongoDB
Per MongoDB, non si tratta solo di sviluppatori di app, ma anche di database, come abbiamo sottolineato nel nostro articolo il mese scorso. Affinché MongoDB diventi la piattaforma dati operativa predefinita per le nuove applicazioni, deve andare oltre l’essere una società di sviluppo per diventare anche una società di dati.
MongoDB ha fatto alcune prime mosse in questa direzione, come aumentare il suo gioco di sicurezza e scrivere un motore di query SQL autentico. L’azienda ha bisogno di fare cambiamenti culturali più profondi, come allontanarsi dal messaggio che denigra l’SQL e le pratiche di database obsolete. MongoDB risponde che anche gli sviluppatori di database relazionali dovrebbero fare il pivot, o almeno accettare il fatto che il modello del documento non significa allontanarsi dalle competenze e dalle discipline che hanno sviluppato. La piattaforma MongoDB supporta la convalida dello schema. Ma lo schema tende a essere variabile nella maggior parte delle implementazioni di MongoDB, quindi vorremmo vedere sforzi più mirati in futuro per lo sviluppo di capacità di derivazione dei dati che potrebbero tenere traccia dell’evoluzione dello schema.
Ad ogni modo, il nostro messaggio a MongoDB rimane: non alienare un collegio elettorale chiave (sviluppatori di database SQL) di cui avrai bisogno per estendere la tua impronta aziendale. Ci piacerebbe vedere un’azione più positiva in futuro.
Fiocco di neve
Per Snowflake, è convincente i data scientist che Snowpark dovrebbe essere un ambiente di esecuzione efficace per i loro modelli. L’azienda ha una nuova partnership con Anaconda, che cura le librerie Python, per ottimizzarle per l’esecuzione in Snowpark. Ma i dubbiosi rimangono; ad esempio, H2O.ai sostiene che è più efficiente mordere il proiettile ed eseguire modelli di apprendimento automatico nei loro cluster in grado di eseguire processi multithread, quindi inviare i risultati a Snowflake.
Da quando ha introdotto Snowpark un paio di anni fa, Snowflake ha migliorato la sua capacità di ridimensionare in modo ottimale le risorse per le funzioni definite dall’utente (UDF) scritte in linguaggi come Java o Python.
Naturalmente, il recente annuncio di Unistore pone l’analisi operativa nel mirino di Snowflake. Tuttavia, non consideriamo questo come un vasto accaparramento di terre per un nuovo collegio elettorale poiché la società non sta cercando SQL Server, Oracle o MongoDB del mondo.
Mattoni di dati
Per Databricks, si tratta di rendere il data lakehouse più adatto alle aziende e agli analisti di database. Queste persone lavorano con la modellazione dei dati e gli strumenti di BI, non con i notebook; ci deve essere un altro percorso di ingresso che fornisca una vista che faccia sembrare Delta Lake più simile a un data warehouse.
E gli analisti aziendali si aspettano prestazioni coerenti sia per le query interattive che per i rapporti batch. I benchmark TPC-DS sono progettati in base ai carichi di lavoro di analisi/supporto decisionale, ma come con le valutazioni del consumo di carburante EPA, i risultati possono variare. È significativo che la fase successiva di Photon sia la riduzione delle latenze in condizioni di query più tipiche, insieme all’ampliamento del supporto di formati di tabelle e file oltre, rispettivamente, Delta Lake e Parquet.
Unendo tutto per una strategia vincente
Il fil rouge è che, partendo da diversi punti di partenza, ogni provider deve collegarsi a nuove circoscrizioni. La chiave non sarà solo la tecnologia, ma la cultura e la strutturazione del core business. È necessario reclutare squadre di go-to-market, sul campo e di supporto che possano parlare con i diversi collegi elettorali. I dibattiti sulla purezza devono uscire dalla porta.
MongoDB può parlare con persone di database relazionali e sviluppatori? Snowflake parlerà il linguaggio dei data scientist e Databricks può coltivare la folla di BI? Questi non sono punti di discussione che vedrai in un comunicato stampa.
La missione di VentureBeat deve essere una piazza cittadina digitale per i decisori tecnici per acquisire conoscenze sulla tecnologia aziendale trasformativa e le transazioni. Saperne di più sull’appartenenza.
