Il Modulo 9 si chiude con la stessa forma con cui si sono chiusi il Modulo 5 e il Modulo 8: una sola azienda, un decennio di post di engineering pubblicati, un insieme di pattern che si trasferiscono a team di ordini di grandezza più piccoli. Questa volta l’azienda è Pinterest, e il tema è il costo. Pinterest ha portato avanti un programma pluriennale di cost reduction sulla propria data platform, ne ha scritto apertamente sul suo engineering blog, e ha prodotto uno degli esempi pubblici più puliti di come una grande data org tagli davvero a metà la propria bolletta cloud senza smontare la piattaforma.
Le lezioni si mappano sulle leve che il Modulo 9 ha coperto: storage tiering (lezione 65 nel piano di questo modulo), compute right-sizing e scelta delle istanze (lezione 66), query optimisation (lezione 67), file format e partitioning (lezione 68), FinOps e chargeback (lezione 69), e la meta-domanda di negoziare-o-ricostruire (lezione 71). Pinterest le ha tirate quasi tutte insieme, più o meno in quell’ordine, e i numeri pubblicati sommano risparmi nell’ordine delle decine di milioni di dollari l’anno. La lezione architetturale è che nessuna delle leve singole è originale; quello che produce il risultato è la disciplina di applicarle come programma continuativo invece che come pulizia una tantum.
La scala e il punto di partenza
I numeri pubblicati di Pinterest cambiano nel tempo. L’ordine di grandezza approssimativo a metà anni 2020: circa cinquecento milioni di utenti attivi mensili, un data warehouse multi-petabyte su Amazon S3, decine di migliaia di batch job al giorno, e centinaia di data engineer, analyst e data scientist che interagiscono con la piattaforma. La spesa annuale di data infrastructure si aggirava tra le decine e il basso centinaio di milioni di dollari, con AWS come cloud provider principale.
La pressione che ha fatto partire il programma è la pressione che ogni azienda in rapida crescita affronta. La data platform stava crescendo più in fretta del resto del business. Nuovi use case (raccomandazioni, advertising, content moderation, sperimentazione) trainavano nuove pipeline, che trainavano più storage, più compute, e più query. La bolletta cresceva in modo super-lineare rispetto al fatturato esattamente nel momento in cui l’azienda aveva bisogno di disciplina sui margini. La cost optimisation è passata dall’essere “qualcosa a cui il platform team dovrebbe pensare” a “una priorità strategica con attenzione executive”.
Il Pinterest engineering blog (https://medium.com/pinterest-engineering, consultato 2026-05-01) contiene il racconto pubblico del programma. I post si raggruppano intorno a storage optimisation su S3 e Iceberg, lavoro di cost-efficiency su Spark, query e pipeline optimisation, e migrazione su Graviton. Le cifre esatte di risparmio non sono sempre dichiarate al dollaro, ma le rivendicazioni direzionali sono esplicite: circa la metà del costo di data infrastructure è stata tirata fuori nel corso del programma, con singoli progetti che contribuiscono ognuno per decine di percento.
Storage tiering e compaction
La prima e più grande tranche di risparmi è venuta dallo storage. I data lake multi-petabyte accumulano nel tempo due patologie che si compongono. I dati cold stanno sullo stesso tier di storage costoso dei dati hot, anche se vengono letti una volta a trimestre, ammesso che vengano letti. E i dati arrivano su S3 come tanti piccoli file, perché è così che si comportano lo streaming e l’output di default di Spark, e i file piccoli sono costosi su cui operare a scala.
Il lavoro sullo storage di Pinterest, descritto nei post del blog di engineering sull’adozione di Iceberg e sulla S3 cost optimisation, ha attaccato entrambe. Le mosse principali sono state:
Tiering per access pattern. Tabelle e partizioni con dati vecchi e raramente letti sono stati spostati da S3 Standard verso S3 Infrequent Access e Glacier, dove il costo di storage per gigabyte è una frazione di quello dello Standard. Il rovescio della medaglia è che Glacier introduce latenza di retrieval e tariffe per richiesta, quindi la policy di tiering deve essere informata dagli access log reali, non da congetture. Pinterest ha costruito l’access tracking, poi ha calibrato la policy in modo che il tiering spostasse i dati solo dopo che l’access pattern lo giustificasse. È concettualmente semplice e operativamente fastidioso, ed è per questo che la maggior parte dei team lo salta finché la bolletta non li costringe.
Compaction dei file piccoli. Una pipeline che emette diecimila piccoli file Parquet per partizione produce una folder costosa da listare, costosa da interrogare, e costosa da leggere. Il compaction layer di Pinterest (che gira sopra Apache Iceberg, adottato pesantemente in parte attingendo dal progetto open-source di Netflix coperto nella lezione 40) periodicamente riscrive i file piccoli in file meno numerosi e più grandi. I risparmi vengono da due posti: meno richieste S3 GET e LIST in fase di query (le request fee sono una voce reale nei workload multi-petabyte), e query execution più veloce (meno file significa meno task paralleli e meno overhead di coordinamento).
Adozione del table format Iceberg. Il metadata layer di Iceberg abilita partition pruning, snapshot-based read, ed evoluzione di schema che le table layout vecchio stile Hive non possono offrire. L’effetto sui costi si vede come meno file scansionati per query (perché il planner può fare pruning a livello di metadata) e migliori query plan (perché le statistiche sono accurate). Il cambio di formato è un lavoro infrastrutturale che si ripaga in minor compute cost su ogni query che gira contro le tabelle migrate.
Lifecycle policy. Vecchi snapshot, orphan file, e metadata Iceberg storici si accumulano. Senza una deletion policy stanno su S3 per sempre. L’automazione di lifecycle di Pinterest li ripulisce, e i risparmi sono pura riduzione di overhead.
Il programma combinato di storage ha prodotto risparmi a doppia cifra percentuale sulla voce storage, e un risparmio aggiuntivo significativo sul lato compute perché le query sono diventate più veloci. Il pattern architetturale: trattare lo storage come un sistema da operare, non come un substrato passivo che accumula tutto ciò che le pipeline scrivono.
Efficienza Spark e Graviton
Il lato compute del programma è stato descritto in post sul lavoro di Spark efficiency di Pinterest e sulla migrazione verso istanze AWS Graviton basate su ARM.
Right-sizing. Molti job Spark erano sovra-provisionati. Le dimensioni dei cluster erano state scelte a occhio, eseguite una volta, e mai più riviste. Una passata sistematica sui job più grandi ha trovato che una frazione significativa girava con due-cinque volte il numero di executor di cui aveva bisogno. Ridurre l’over-provisioning è concettualmente banale e operativamente raro, perché nessuno ha il tempo o le dashboard per sapere quali job sono sovra-provisionati senza un programma esplicito. Pinterest ha costruito le dashboard e ha fatto girare il programma, e i risparmi sul compute sono stati sostanziali.
Spot instance. I batch workload che tollerano l’interruzione (la maggior parte dell’ETL e la maggior parte del feature engineering ML) possono girare su AWS Spot al sessanta-ottanta percento di sconto rispetto al pricing on-demand. Il rovescio della medaglia è che le istanze Spot possono essere reclamate con due minuti di preavviso, quindi il workload deve essere checkpointable o restartable. Pinterest ha spostato una fetta consistente del proprio batch Spark workload su Spot, con l’orchestrator (coperto nella lezione 57 del Modulo 8) che gestisce i retry quando la capacity sparisce. I risparmi sono diretti: stesso workload, bolletta molto più piccola.
Migrazione Graviton (ARM). Le istanze AWS Graviton girano su processori ARM e offrono circa il venti percento di price-performance migliore rispetto agli equivalenti x86 per molti workload. La migrazione non è gratis: il software va ricompilato o ripacchettizzato per ARM, le performance vanno validate, e i casi limite (librerie native, binding JNI, vendor agent) vanno gestiti. Pinterest ha pubblicato la propria esperienza nello spostare workload Spark su Graviton, inclusi i gotcha intorno al tuning della JVM e alle dipendenze native. Il risultato è stata una riduzione strutturale del costo su ogni workload migrato, che è un tipo di risparmio diverso dal tunare un singolo job: si compone su tutta la fleet finché il cluster gira.
Matching del tipo di istanza. Oltre ad ARM, il programma ha incluso il matching del tipo di istanza alla forma del workload. Aggregazioni memory-heavy su istanze memory-optimised. Build di feature ML compute-heavy su istanze compute-optimised. Scan storage-heavy su istanze con NVMe locale. Il default “usa qualunque cosa ci dia un m5.xlarge” lascia soldi sul tavolo; il matching deliberato li recupera.
Il programma compute ha consegnato la singola voce di risparmio più grande dell’intero sforzo. La lezione è che lo spreco di compute, come quello di storage, raramente è visibile senza un programma progettato per esporlo.
Query optimisation: l’approccio top-N
La terza tranche è venuta dalla query optimisation, ma con una disciplina che molti team si perdono. In un warehouse con decine di migliaia di query ricorrenti, la distribuzione del costo è fortemente sbilanciata. Una manciata di query (le top cinquanta, a volte le top dieci) rappresenta una quota sproporzionata del compute totale. Ottimizzare la coda lunga produce risparmi piccoli e sparpagliati; ottimizzare la testa produce risparmi visibili e cumulativi.
L’approccio di Pinterest, descritto nei post di engineering sulla warehouse efficiency, era esplicitamente top-N. Strumentare ogni query con cost attribution. Ordinare per costo totale (frequenza moltiplicata per costo per esecuzione). Prendere le top cinquanta. Consegnarle a un team di query-optimisation. Riscrivere, ripartizionare, aggiungere gli indici giusti o le sort key, cambiare il join order, spingere i predicati giù, potare le colonne inutilizzate, materializzare le subquery costose. Passare al batch successivo.
I meccanismi sono da artigiani e i risultati sono fuori proporzione rispetto allo sforzo. Una singola riscrittura di una query giornaliera che scansiona un petabyte risparmia il costo di quella scansione ogni giorno, ogni anno, finché qualcuno non cambia lo schema sottostante. Il compounding è severo nella direzione giusta. Le stesse ore di engineering sparpagliate sulla coda lunga avrebbero prodotto un decimo dei risparmi.
Il pattern si trasferisce. Ogni warehouse di analytics ha una lista di query top-N. Ogni data team che non ha fatto questo esercizio ha spreco nella testa di quella lista. La prima passata sulle top cinquanta è di solito la settimana a più alta leva di lavoro sui costi che un data engineer può fare.
Right-sizing di cluster e warehouse
Oltre a Spark, il programma di Pinterest ha toccato i sistemi always-on. Warehouse (Trino, servizi Snowflake-like), notebook cluster, BI backend, e streaming pipeline portano tutti un costo di baseline che gira che qualcuno li stia usando o no. La passata di right-sizing su questi sistemi ha mirato a tre cose.
Idle scaling. Cluster che giravano ventiquattro-su-sette ma vedevano carico solo per dieci ore al giorno sono stati scalati al ribasso o fermati durante la finestra idle. I risparmi sono diretti, e il rischio operativo è basso se lo scale-up è automatizzato. I sistemi dove questo è più difficile sono quelli con cache stateful che richiedono tempo per scaldarsi; per quelli, il trade-off è calore della cache contro costo, e la risposta dipende dal workload.
Sizing basato sulla concurrency. I warehouse dimensionati per la peak concurrency che capita una volta al giorno costavano prezzi peak per ventitré ore di off-peak. L’auto-scaling, dove supportato, ha affrontato questo. Dove non supportato, lo ha fatto il resizing schedulato.
Workload isolation per SLA. Le query interactive critiche sono state separate dai workload batch e ad-hoc, in modo che il cluster interactive potesse essere dimensionato per low concurrency e alta responsività, mentre il cluster batch poteva essere dimensionato per alto throughput e tollerare il queueing. Mescolarli costringeva entrambi a essere dimensionati per il carico combinato peggiore, che è più costoso della somma di due cluster dimensionati appropriatamente.
Il pattern: pagare per quello che usi, quando lo usi. I default raramente corrispondono a questo; la configurazione deliberata sì.
La kill list
La parte meno tecnica e più sottovalutata del programma è la passata di audit-and-delete. Ogni data org matura ha dashboard che nessuno apre, pipeline che calcolano output che nessuno consuma, e tabelle che non sono state interrogate da un anno. Costano soldi per niente, e si accumulano perché crearle è facile e deprecarle è compito di qualcun altro.
Il programma di Pinterest includeva una kill list esplicita. Le dashboard senza view in novanta giorni venivano flaggate. Le pipeline i cui output non avevano lettori downstream venivano flaggate. Le tabelle con zero query in una finestra di audit venivano flaggate. I flag andavano agli owner, che o giustificavano l’asset o concordavano la sua eliminazione. La fase di deletion ha recuperato soldi veri, sia direttamente (il compute e lo storage dell’asset morto) sia indirettamente (il costo operativo di monitorarlo e mantenerlo).
Il pattern è universale. Qualsiasi team che gira da più di due anni ha asset che nessuno usa e che nessuno è riuscito a cancellare. La kill list è l’esercizio di cost-saving più economico sulla piattaforma, ed è quello che la maggior parte dei team salta.
Cost visibility e chargeback
Il fondamento culturale di tutto il programma è la visibilità. Nessuno dei singoli risparmi è possibile senza dashboard che mostrano, per team e per prodotto, quanto sta costando la data platform. Senza quelle dashboard, ogni discussione sui costi è aneddotica, ogni prioritizzazione è politica, e il team che si offre volontario per ottimizzare porta da solo il peso.
Pinterest, come la maggior parte delle grandi data org, ha costruito dashboard che attribuiscono compute, storage, e request cost ai team che li hanno generati. Il modello di attribution può essere chargeback (il budget del team paga davvero per quello che ha usato) o showback (il team vede quello che ha usato ma il platform team paga). Il modello specifico di Pinterest è interno; i post pubblici enfatizzano la visibilità in sé, non i meccanismi finanziari.
L’effetto è quello che gli economisti chiamano internalizzare l’esternalità. Quando un team può vedere che la sua dashboard sta costando all’azienda centomila dollari al mese, tende a chiedersi se la dashboard valga quella cifra. Tende a ottimizzare le query, partizionare meglio le tabelle, archiviare i dati vecchi, e cancellare gli asset inutilizzati. Il ruolo del platform team passa dall’essere l’unico ottimizzatore all’essere l’abilitatore dell’ottimizzazione da parte di ogni team.
Il risultato cumulativo
La rivendicazione pubblica è che il programma pluriennale ha tagliato il costo di data infrastructure circa a metà, contro una controfattuale di crescita non vincolata. In termini assoluti, è una cifra di risparmio nelle alte decine di milioni di dollari l’anno, a seconda del periodo e della baseline. I risparmi sono persistenti: lo storage tiering, la migrazione su Graviton, la kill list, e il right-sizing continuano tutti a pagare finché i sistemi girano.
L’effetto cumulativo conta più di qualunque voce singola. Nessuna delle leve è originale. Tutte sono documentate nei whitepaper dei cloud vendor, nella documentazione dei progetti open-source, e nei post pubblici di mezza dozzina di altre aziende. Quello che Pinterest ha fatto è stato applicarle sistematicamente, come un programma continuativo invece che come una pulizia una tantum, e il compounding ha prodotto il risultato di prima pagina.
Le lezioni
Cinque takeaway, nella stessa forma che hanno usato il caso Netflix del Modulo 5 (lezione 40), il caso Uber del Modulo 6 (lezione 48), e il caso Airbnb del Modulo 8 (lezione 64).
La cost optimisation è una sua disciplina di engineering a sé stante. Trattarla come un progetto fa perdere metà dei risparmi. Trattarla come un programma continuativo, con owner dedicati, dashboard, e una cadenza di review trimestrale, produce risultati che si compongono. Il racconto pubblico di Pinterest è, più di ogni altra cosa, un racconto della disciplina, non delle singole tecniche.
La regola 80/20 si applica forte. La maggior parte dei risparmi viene da un piccolo numero di cambiamenti ad alta leva. Riscritture delle query top-N, right-sizing del cluster più grande, tiering della tabella più grossa. Il resto è incrementale. Un team che parte da zero dovrebbe concentrarsi sulle poche opportunità più grandi e accettare che la coda lunga richiederà più tempo per essere raccolta.
Rendi il costo visibile per team e per prodotto. Le dashboard sono la precondizione per tutto il resto. Senza, l’ottimizzazione è aneddoto e politica. Con, è engineering. Le dashboard non sono affascinanti da costruire, e sono il pezzo di infrastruttura FinOps a più alta leva che la maggior parte dei team può spedire.
La kill list di job che nessuno fa girare è denaro vero. Ogni data org ha dashboard, pipeline, e tabelle che nessuno usa. Auditale, flaggale, cancella quelle che non si possono giustificare. Questa è la tranche di risparmi più economica, ed è quella che la maggior parte dei team non ha fatto girare.
Spot e Graviton sono soldi veri quando i workload li tollerano. Entrambe le tecnologie sono mature nel 2026. Spot è uno sconto del sessanta-ottanta percento sul batch compute, vincolato dalla checkpointability. Graviton è un miglioramento strutturale del venti percento, vincolato dalla portabilità del software. I costi di migrazione sono reali e una tantum; i risparmi sono ricorrenti e si compongono su ogni workload che gira sull’infrastruttura migrata.
Cross-reference dentro il Modulo 9
Il programma Pinterest esercita ogni leva che il Modulo 9 ha introdotto. Storage tiering e compaction sono la forma operativa dei pattern di storage layout dalle lezioni precedenti del modulo. Spark efficiency, Spot, e Graviton sono le leve di compute right-sizing. Le riscritture top-N delle query sono query optimisation nella sua forma a più alta leva. Le cost dashboard e il chargeback sono la cultura FinOps che rende sostenibile il resto. La kill list è l’igiene di asset-lifecycle che chiude il cerchio. La meta-domanda build-versus-buy della lezione 71 è il framing sotto cui un programma del genere viene approvato in primo luogo: quando la bolletta è abbastanza grande che ottimizzarla vale il tempo di un team dedicato.
Le forme si trasferiscono a team che girano un centesimo del workload. Un piccolo data team con una bolletta mensile a sei cifre ha le stesse leve, nelle stesse proporzioni, solo con numeri assoluti più piccoli. La disciplina è la stessa; la curva dei risparmi è la stessa; l’effetto cumulativo è lo stesso.
Il Modulo 9 si chiude qui
Il Modulo 9 è stato sul rendere la data platform sostenibile sull’asse del costo. Storage layout, compute right-sizing, query optimisation, scelte di formato, cultura FinOps, rapporti con i vendor, e il programma cumulativo che li lega insieme. Una piattaforma che è affidabile ma costosa alla fine verrà tagliata. Una piattaforma che è economica ma inaffidabile costa al business più di quanto risparmi. I due assi sono collegati, e le tecniche in questo modulo sono il modo in cui un team maturo tiene entrambi.
Il Modulo 10 si apre uscendo dalla data platform e entrando nella domanda più ampia di come un sistema divida la responsabilità tra servizi. La prima lezione copre i microservizi: il termine, i benefici reali, i costi che i primi sostenitori avevano sottopesato, e il pendolo che è tornato a oscillare verso i monoliti modulari in molti dei casi dove i microservizi erano una volta la risposta di default. Le decisioni architetturali hanno un aspetto diverso dalle decisioni di data platform delle ultime nove moduli, ma la logica sottostante è la stessa: ogni scelta è un trade-off, e il lavoro è sapere quale asse conta per il sistema che hai davanti.
Citazioni e ulteriori letture
- Pinterest Engineering blog,
https://medium.com/pinterest-engineering(consultato 2026-05-01). La collezione di post pubblici su data platform cost reduction, adozione di Iceberg, Spark efficiency, e migrazione Graviton che questa lezione riassume. - Pinterest Engineering, post su data platform efficiency e cost optimisation (consultati 2026-05-01). Le rivendicazioni direzionali di risparmio e la suddivisione del programma in fasi storage, compute, query, e lifecycle vengono da questo corpus di lavoro.
- Apache Iceberg project,
https://iceberg.apache.org/(consultato 2026-05-01). Documentazione su partition pruning, snapshot expiration, e small-file compaction, le primitive sottostanti su cui si appoggia il programma di storage di Pinterest. - Apache Spark documentation,
https://spark.apache.org/docs/latest/(consultato 2026-05-01). Riferimento per le leve di configurazione e tuning (executor sizing, comportamento di shuffle, dynamic allocation) che il lavoro di Spark efficiency tocca. - AWS Graviton documentation,
https://aws.amazon.com/ec2/graviton/(consultato 2026-05-01). Riferimento del vendor per la rivendicazione di price-performance e le considerazioni di migrazione rilevanti per la tranche Graviton. - AWS S3 storage classes documentation,
https://aws.amazon.com/s3/storage-classes/(consultato 2026-05-01). I tier di pricing e la semantica di retrieval su cui opera il programma di storage tiering. - AWS Spot Instances documentation,
https://aws.amazon.com/ec2/spot/(consultato 2026-05-01). La semantica di pricing e di interruzione che governa la migrazione Spot.