Decoupling consapevole fino a che punto è troppo lontano per lo storage, il calcolo e lo stack dati moderno?

Fino a che punto è troppo lontano per lo storage, il calcolo e lo stack dati moderno?

Sebbene non esista una risposta corretta, c’è probabilmente un punto ottimale per la maggior parte delle piattaforme dati delle organizzazioni. Continua a leggere per scoprire dove potrebbe essere.

Foto di Kelly Sikkema su Unsplash

Gli ingegneri dei dati hanno scoperto i vantaggi dello “sconnettersi consapevolmente” nello stesso periodo di Gwyneth Paltrow e Chris Martin nel 2014.

Ovviamente, invece di partner di vita, gli ingegneri stavano iniziando a separare con entusiasmo l’archiviazione e l’elaborazione con tecnologie emergenti come Snowflake (2012), Databricks (2013) e BigQuery (2010).

Questo aveva vantaggi incredibili sia dal punto di vista dei costi che della scala rispetto ai database in loco. Un responsabile dell’ingegneria dei dati in una società Fortune 500 ha espresso il dolore delle limitazioni in loco dicendo:

“I nostri analisti non erano in grado di eseguire le query che volevano eseguire quando volevano eseguirle. Il nostro data warehouse era fuori servizio per 12 ore al giorno perché dovevamo regolarmente spegnerlo per le trasformazioni e il caricamento dei dati… L’unico termine che posso usare per descrivere questo processo è doloroso.”

A distanza di un decennio, una considerevole quantità di innovazione nell’industria della gestione dei dati ruota attorno a come le diverse piattaforme dati stanno accoppiando o separando l’archiviazione e l’elaborazione (ma non preoccuparti, includo esempi nella prossima sezione). Strettamente correlato a ciò è come queste stesse piattaforme stanno raggruppando o scomponendo servizi dati correlati, dall’ingestione e trasformazione dei dati alla governance e monitoraggio dei dati.

Perché queste cose sono correlate e, cosa ancora più importante, perché i leader dei dati dovrebbero preoccuparsene?

Bene, il tessuto connettivo che alimenta e integra questi servizi si trova spesso nei metadati dei formati delle tabelle (archiviazione) e nei log delle query/lavori (elaborazione). Il modo in cui questi aspetti vengono gestiti all’interno della tua piattaforma dati avrà un ruolo importante nelle sue prestazioni, costi, facilità d’uso, ecosistema di partner e futura sostenibilità.

Chiedersi che tipo di piattaforma dati e che livello di separazione è corretto è come chiedersi qual è il modo giusto per formattare il proprio codice SQL: dipenderà in larga misura dalle preferenze personali e dai requisiti professionali, tuttavia c’è un piccolo range di possibilità che soddisferà la maggior parte.

Credo – in questo momento attuale – che tale range per le piattaforme dati segua il concetto medio aureo di Aristotele. La maggioranza sarà meglio servita da opzioni nel mezzo dello spettro, mentre operare su uno degli estremi sarà riservato a pochi con casi d’uso molto specializzati.

Esaminiamo da vicino il panorama attuale e le recenti evoluzioni prima di analizzare più da vicino perché potrebbe essere così.

Lo Spettro delle Piattaforme Dati di Archiviazione ed Elaborazione

Immagine cortesia dell'autore.

Qualche voce rumorosa ha fatto notizia con un movimento del tipo “il cloud è costoso, torniamo alle nostre server rack”. Sebbene possa essere una strategia legittima per alcuni, è una minoranza in rapido declino.

Proprio la settimana scorsa, il Pragmatic Engineer ha messo in luce il throttling del tasso di Twitter e problemi significativi nell’esperienza dell’utente che probabilmente sono derivati dal trasferimento dei modelli di apprendimento automatico da GCP e dal loro affidamento esclusivo sui loro tre data center.

La capacità di scalare e utilizzare l’archiviazione e l’elaborazione in modo indipendente è molto più conveniente in termini di costi e prestazioni, ma avere queste funzioni separate all’interno della stessa piattaforma dati ha anche vantaggi.

La media delle query SQL non ottimizzate eseguite come parte di una richiesta di analisi ad hoc di solito viene eseguita molto più velocemente in queste piattaforme che sono state ottimizzate per funzionare bene fin dall’inizio. Un’architettura più separata che separa l’elaborazione e l’archiviazione a livello di piattaforma può essere molto conveniente in caso di carichi di lavoro pesanti, ma ciò presuppone che un personale altamente addestrato dedichi tempo all’ottimizzazione di tali carichi di lavoro.

Le piattaforme dati con archiviazione e elaborazione combinate ma separate forniscono anche un’esperienza utente più robusta e integrata in diversi compiti chiave dei dataops. Prendi ad esempio la governance dei dati. Queste piattaforme forniscono un meccanismo centralizzato per il controllo degli accessi, mentre le architetture separate richiedono la federazione dei ruoli su più motori di query, un compito non banale.

L’approccio disaccoppiato ma combinato è la magia che ha reso una delle recensioni più comuni di Snowflake quella di “Tutto funziona semplicemente”. Non è sorprendente che Snowflake abbia recentemente raddoppiato con Unistore per i carichi di lavoro transazionali e abbia aperto Snowpark per supportare Python e altri carichi di lavoro di data science (calcolo).

Databricks ha visto una crescita incredibile con il suo focus sul framework di elaborazione Spark, ma non è nemmeno una coincidenza che abbia raggiunto un nuovo livello di crescita dopo l’aggiunta di metadati e transazioni simili ad ACID all’interno delle tabelle Delta e le funzionalità di governance all’interno del Catalogo Unity. Di recente hanno anche raddoppiato e fatto in modo che quando si scrive su una tabella Delta (archiviazione) i metadati all’interno di quella tabella siano scritti in formati leggibili da Delta, Apache e Hudi.

Piattaforme Sfidanti

Ecco perché è interessante notare che molte delle più recenti tecnologie emergenti di data engineering stanno iniziando a separare l’archiviazione e il calcolo a livello di fornitore. Ad esempio, Tabular si definisce un “data warehouse senza testa” o “tutto ciò di cui hai bisogno in un data warehouse tranne il calcolo”.

Andando oltre, alcune organizzazioni stanno migrando verso tabelle Apache Iceberg all’interno di un data lake con una gestione “fai da te” dell’infrastruttura di backend e utilizzando un motore di interrogazione separato come Trino. Questo è più comune nei casi d’uso rivolti ai clienti che richiedono query interattive altamente performanti ed economiche.

DuckDB combina archiviazione e calcolo, ma sacrifica il calcolo quasi infinito dello stack di dati moderno, a favore della semplicità dello sviluppatore e della riduzione dei costi.

Quindi la domanda rimane, queste innovazioni sono destinate a sostituire le piattaforme dati cloud native esistenti?

Anche in questo caso, la risposta dipenderà da chi sei. DuckDB è uno strumento incredibilmente popolare che molti data analyst amano, ma probabilmente non sarà la base su cui costruire la tua piattaforma dati. In definitiva, stiamo assistendo, e credo che continueremo a vedere, una distribuzione che assomiglia a questa:

Immagine cortesia dell'autore.

Spiegherò il motivo guardando l’intero stack di dati moderno e i tipi di piattaforme dati attraverso un paio di dimensioni chiave.

Grado e scopo della consolidazione

I fornitori B2B fanno riferimento con rispetto tutto il tempo alla “finestra unica”. C’è valore nel avere più servizi sotto un unico ombrello? Dipende dalla qualità di ciascun servizio e da come si correla alle tue esigenze.

Il valore della finestra unica deriva realmente dall’unificazione di informazioni che altrimenti sarebbero separate in una singola storia, o da azioni separate che dovrebbero essere un singolo flusso di lavoro. Prendiamo Microsoft 365 come esempio di questo concetto.

È utile avere il video e la posta elettronica integrati nella loro applicazione di collaborazione Teams poiché sono aspetti fondamentali del processo di pianificazione delle riunioni e delle videoconferenze. È altrettanto utile avere Sway all’interno della loro suite di app? Di nuovo, dipende dalle tue esigenze per la generazione di rapporti interattivi.

Tornando all’universo dei dati, il calcolo e l’archiviazione sono vitali per quella singola storia (chi, cosa, quando, dove, perché, come dei dataops) e i flussi di lavoro chiave per aspetti come: costo, qualità e gestione dell’accesso. Per questo motivo, queste piattaforme avranno ecosistemi di partner più robusti e integrazioni più fluide. Questo sarà probabilmente un criterio chiave per te, a meno che tu non sia il tipo di persona che usava telefoni Windows e Fire anziché iPhone e Android.

Adam Woods, CEO di Choozle, ha parlato al nostro team l’anno scorso dell’importanza che attribuisce a un ecosistema di partner robusto e strettamente integrato attorno alla sua piattaforma dati.

“Mi piace che… il mio stack dati sia sempre aggiornato e non devo mai applicare una patch. Siamo in grado di reinvestire il tempo che sviluppatori e analisti di database avrebbero speso preoccupandosi degli aggiornamenti e dell’infrastruttura nella creazione di esperienze eccezionali per i clienti”, ha detto.

Certo, ci sono sempre eccezioni alla regola. Un vero data lake, un data warehouse senza testa o un’altra piattaforma più complessa possono essere ideali se si hanno casi particolari su larga scala.

Deve il tuo livello semantico, la qualità dei dati, il controllo degli accessi, il catalogo, il BI, la trasformazione, l’ingestione e altri strumenti essere tutti inclusi nella stessa piattaforma? Credo che ci siano prospettive valide in questo ambito, ma come ogni altro dipartimento, la maggior parte dei team dati avrà una collezione di strumenti che si adattano meglio alle loro esigenze.

Riassumendo:

  • La maggior parte dei leader dei dati vorrà dare priorità all’utilizzo di una piattaforma dati che abbia sia servizi di calcolo che di archiviazione in grado di facilitare una “singola storia” e supportare un ecosistema di partner diversificato.

Prestazioni vs facilità d’uso

In generale, più è personalizzabile una piattaforma, migliori possono essere le sue prestazioni in una vasta gamma di casi d’uso… e più difficile è da utilizzare. Questo è un compromesso inevitabile e che si fa quando si separano i servizi di archiviazione e di calcolo tra fornitori diversi.

Quando si pensa alla “facilità d’uso” di una piattaforma dati, è utile considerare non solo l’utilizzo quotidiano della piattaforma, ma anche la semplicità dell’amministrazione e della personalizzazione.

Nella mia esperienza, molte squadre si concentrano eccessivamente sulle prestazioni della piattaforma. Le nostre competenze tecniche ci portano immediatamente a confrontare le piattaforme come se fossero automobili: “Qual è la potenza per questo carico di lavoro? E per quello?”

Non fraintendetemi, una piattaforma dati ottimizzata può tradursi in risparmi annuali di milioni di euro. È importante. Ma se si assumono ingegneri aggiuntivi per gestire le configurazioni di S3 o se è necessario avviare un progetto di diversi mesi ogni trimestre per integrare nuovi aspetti del business nella piattaforma dati, ciò comporta un costo elevato.

Si può osservare la stessa dinamica decisionale con le soluzioni open-source. Il costo iniziale è trascurabile, ma il costo in termini di tempo per mantenere l’infrastruttura può essere rilevante.

I costi della soluzione e i costi di salario dell’ingegneria non sono la stessa cosa, e questa falsa equivalenza può creare problemi in futuro. Ci sono due motivi:

  • Assumendo che l’utilizzo rimanga statico (una precisazione importante), i costi della soluzione rimangono generalmente gli stessi mentre l’efficienza aumenta. Questo perché i fornitori di servizi SaaS continuano a introdurre nuove funzionalità. D’altra parte, l’efficienza di un’implementazione più manuale diminuirà nel tempo, poiché i membri chiave lasceranno l’organizzazione e nuovi membri del team dovranno essere integrati.
  • Quando si passa la maggior parte del tempo a mantenere l’infrastruttura, il team dati inizia a perdere di vista l’obiettivo. L’obiettivo si sposta lentamente dal massimizzare il valore aziendale al mantenimento dell’infrastruttura in condizioni ottimali. Sempre più riunioni riguardano l’infrastruttura. Le competenze specialistiche nell’infrastruttura di nicchia assumono un’importanza sproporzionata e questi specialisti diventano più prominenti all’interno dell’organizzazione. La cultura organizzativa conta ed è spesso plasmata dai compiti principali e dai problemi che il team sta risolvendo.

Questo secondo punto è stato enfatizzato in particolare da Michael Sheldon, responsabile dei dati presso Swimply.

“Poiché il nostro team dati aveva il mandato di supportare l’intera azienda, avevamo bisogno di una stack dati in grado di risolvere due problemi principali”, ha detto Michael. “Il primo, centralizzare tutti i dati provenienti da tutte le diverse parti dell’azienda in un unico luogo stabile che tutti potessero utilizzare e consultare come fonte di verità. E il secondo, consentirci di avere abbastanza tempo per concentrarci realmente sulle intuizioni e non solo sull’infrastruttura dei dati stessi.”

Stanno parlando di infrastruttura o di valore aziendale? Foto di Desola Lanre-Ologun su Unsplash

Naturalmente, ci saranno momenti in cui il caso d’uso aziendale richiederà prestazioni elevate.

Un prodotto dati per la frode con carte di credito con latenza elevata è semplicemente uno spreco di tempo. Un’applicazione rivolta ai clienti che mostra la rotella che gira a vuoto non sarà accettabile, e probabilmente richiederà l’implementazione di un motore di interrogazione ad alte prestazioni. Tuttavia, nella maggior parte dei casi, il data warehouse o il data lakehouse gestito scalano perfettamente. Verificate sempre i requisiti che dicono il contrario.

Riassunto:

  • Anche se la facilità d’uso e le prestazioni sono variabili interrelate che devono essere bilanciate, la maggior parte dei responsabili dei dati preferirà avere una preferenza per la facilità d’uso a causa dei relativamente nascosti costi di manutenzione e cultura. Il vostro vantaggio competitivo si trova più spesso nell’arricchire e applicare i dati di prima parte piuttosto che nel mantenere infrastrutture complesse.

In difesa del MDS

So che è di moda criticare la moderna stack dati (e potrebbe non essere necessaria per fare progressi), ma nonostante tutte le sue imperfezioni, sarà la scelta migliore per la maggior parte dei team dati. È un mix ideale di generazione rapida di valore e di investimento a lungo termine.

Molte delle tecnologie emergenti hanno un valore significativo, sebbene con casi d’uso più specifici. Sarà interessante vedere come si evolveranno e modificheranno la pratica dell’ingegneria dei dati.

Tuttavia, sebbene il calcolo e l’archiviazione debbano operare e scalare separatamente, avere questi servizi e i relativi metadati all’interno della stessa piattaforma è semplicemente troppo potente e con troppi vantaggi per essere trascurato.

Seguimi su VoAGI per altre storie sulla leadership dei dati, applicazioni della scienza dei dati e argomenti correlati. Iscriviti per ricevere le mie storie direttamente nella tua casella di posta.