Cosa sono Trino e Presto e che differenza c'è?

Trino e Presto sono due motori di query SQL distribuiti, nati dallo stesso progetto, che eseguono query MPP (massively parallel processing) direttamente su dati che restano dove si trovano, senza doverli prima caricare in un database proprietario. Il principio è la separazione tra calcolo e storage: il motore si collega tramite connettori a fonti eterogenee, un data lake su object storage, un data warehouse, un database transazionale, persino un file system, e distribuisce l'esecuzione della query su più nodi in memoria, in parallelo. Il risultato pratico è la possibilità di scrivere un'unica query SQL che unisce righe provenienti da sistemi diversi, senza pipeline di copia intermedie. È lo stesso principio della data virtualization, applicato qui con un motore di calcolo pensato per l'analisi su grandi volumi piuttosto che per l'accesso puntuale a un singolo record. Su un data lakehouse costruito con un formato di tabella aperto, Trino o Presto sono spesso il motore di interrogazione che sfrutta quelle garanzie transazionali senza legarsi a una piattaforma proprietaria.

Leggi anche: Data Virtualization · Tecnica che interroga dati da più fonti come se fossero una sola, senza copiarli: uno strato intermedio traduce la query in tempo reale.

Genealogia: perché due nomi per lo stesso progetto

Presto nasce in Facebook nel 2012, opera di quattro ingegneri, Martin Traverso, Dain Sundstrom, David Phillips ed Eric Hwang, come sostituto di Apache Hive per query interattive su volumi enormi di dati; Facebook lo rilascia in open source nel novembre 2013. Nel gennaio 2019 i quattro fondatori lasciano Facebook e forkano il codice, fondando la Presto Software Foundation come ente indipendente: il fork prende inizialmente il nome di PrestoSQL, stesso codice e stesso team, governance diversa, in risposta a cambi di policy che a fine 2018 avevano dato ai committer Facebook privilegi maggiori sulla community open source. Nel settembre 2019 Facebook trasferisce PrestoDB alla Linux Foundation, che richiede e ottiene anche il marchio "Presto": né i creatori originali né i principali contributor vengono coinvolti in quella fondazione. Dopo trattative prolungate tra le due community, il team di PrestoSQL è costretto a cambiare nome: il 27 dicembre 2020 PrestoSQL diventa ufficialmente Trino. Community, codice e leadership restano gli stessi, cambia solo il nome. Oggi Trino, guidato dai creatori originali tramite la Trino Software Foundation, ha un ritmo di sviluppo nettamente più alto; PrestoDB resta ospitato dalla Linux Foundation, con Meta e IBM, che nel 2023 ha acquisito Ahana, fra i contributor principali. Nella pratica enterprise, quando si parla oggi di "Presto" spesso ci si riferisce in realtà a Trino, ed è la prima verifica da fare prima di scegliere quale adottare o quale citare in una richiesta di offerta.

Un esempio enterprise

Un gruppo retail con un data lake su S3 in formato Iceberg, un data warehouse cloud per la reportistica finanziaria e un database operativo per l'inventario può installare un cluster Trino davanti a tutte e tre le fonti: gli analisti scrivono una query SQL che unisce lo storico vendite dal lake con lo stock real-time dal database operativo, senza attendere una pipeline ETL notturna che copi l'inventario nel warehouse. Il costo di calcolo resta separato dallo storage, i nodi Trino si scalano in base al carico delle query e non ai volumi di dati, che restano fermi nelle rispettive fonti.

Quando sceglierlo, quando no

Trino o Presto convengono quando serve interrogare più fonti eterogenee con SQL federato senza spostare i dati, quando il caso d'uso è analitico esplorativo su grandi volumi in un data lakehouse, o quando serve un livello di query neutro sopra formati di tabella aperti senza legarsi a un motore proprietario. Non sono la scelta giusta per carichi transazionali, non gestiscono scritture concorrenti ad alta frequenza come farebbe un database OLTP, né per trasformazioni batch pesanti e ricorrenti, dove un motore di elaborazione dati come Spark, ottimizzato per job lunghi e shuffle massicci, resta più efficiente. Vanno usati con cautela anche per dashboard con alta concorrenza di utenti su query ripetute a bassa latenza: ogni query riparte dalle fonti originali, e centinaia di utenti simultanei possono saturare i sistemi sorgente molto prima di quanto farebbe una tabella pre-aggregata in un warehouse dedicato. In quei casi le alternative più adatte sono un data warehouse cloud tradizionale, un semantic layer con caching davanti alle query ricorrenti, o una combinazione delle due cose.