Modulul 9 se închide cu aceeași formă cu care s-au închis Modulul 5 și Modulul 8: o singură companie, un deceniu de postări de inginerie publicate, un set de pattern-uri care se transferă la echipe cu ordine de mărime mai mici. De data asta compania este Pinterest, iar subiectul este costul. Pinterest a rulat un program de reducere a costurilor de mai mulți ani pe platforma lor de date, a scris despre el deschis pe blogul lor de inginerie și a produs unul dintre cele mai curate exemple publice despre cum o organizație mare de date taie efectiv o factură de cloud la jumătate fără să dărâme platforma.
Lecțiile se mapează pe pârghiile pe care Modulul 9 le-a acoperit: storage tiering (lecția 65 din planul acestui modul), right-sizing de compute și alegerea de instanțe (lecția 66), optimizarea de query-uri (lecția 67), formatul de fișier și partiționarea (lecția 68), FinOps și chargeback (lecția 69) și meta-întrebarea de negociere-și-rebuild (lecția 71). Pinterest a tras majoritatea dintre ele simultan, în aproximativ acea ordine, iar numerele publicate adună economii în zonă de zeci-și-sute de milioane de dolari anual. Lecția arhitecturală este că niciuna dintre pârghiile individuale nu este nouă; este disciplina aplicării lor ca program continuu mai degrabă decât ca un cleanup unic, cea care produce rezultatul.
Scala și punctul de plecare
Numerele publicate ale Pinterest se schimbă în timp. Ordinul de mărime aproximativ la mijlocul anilor 2020: în jur de cinci sute de milioane de utilizatori activi lunar, un data warehouse de mai mulți petabytes pe Amazon S3, zeci de mii de batch jobs pe zi și sute de data engineers, analiști și data scientists care interacționează cu platforma. Cheltuiala anuală de infrastructură de date a urcat în zona de zeci până la joase sute de milioane de dolari, cu AWS ca furnizor primar de cloud.
Presiunea care a pornit programul este presiunea cu care se confruntă fiecare companie în creștere rapidă. Platforma de date creștea mai rapid decât restul afacerii. Use case-uri noi (recomandări, ads, content moderation, experimentare) au generat conducte noi, care au generat mai mult storage, mai mult compute și mai multe query-uri. Factura creștea super-liniar cu venitul exact în momentul în care compania avea nevoie de disciplină de marjă. Optimizarea costurilor a trecut de la „ceva la care echipa de platformă ar trebui să se gândească” la „o prioritate strategică cu atenție executivă”.
Blogul de inginerie Pinterest (https://medium.com/pinterest-engineering, consultat 2026-05-01) poartă relatarea publică a programului. Postările se grupează în jurul optimizării de storage pe S3 și Iceberg, muncă de cost-eficiență pe Spark, optimizare de query și pipeline și migrarea bazată pe Graviton. Cifrele exacte de economii nu sunt întotdeauna dezvăluite la dolar, dar afirmațiile direcționale sunt explicite: aproximativ jumătate din costul de infrastructură de date a fost eliminat pe parcursul programului, cu proiecte individuale contribuind cu zeci de procente fiecare.
Storage tiering și compactare
Prima și cea mai mare tranșă de economii a venit din storage. Data lake-urile de mai mulți petabytes acumulează două patologii care se compun în timp. Datele reci stau pe același nivel de storage scump ca datele calde, deși sunt citite o dată pe trimestru, dacă chiar atât. Iar datele aterizează pe S3 ca multe fișiere mici, pentru că așa se comportă streaming-ul și output-ul implicit al Spark, iar fișierele mici sunt scumpe de operat la scală.
Munca de storage a Pinterest, descrisă în postările de pe blogul de inginerie despre adopția Iceberg și optimizarea costurilor S3, a atacat ambele. Mișcările principale au fost:
Tiering după pattern-ul de acces. Tabelele și partițiile cu date vechi, rar citite, au fost mutate de pe S3 Standard pe nivelurile S3 Infrequent Access și Glacier, unde costul de storage per gigabyte este o fracțiune din Standard. Captura este că Glacier introduce latență de retrieval și taxe per request, deci politica de tiering trebuie să fie informată de log-uri reale de acces, nu de presupuneri. Pinterest a construit tracking-ul de acces, apoi a reglat politica astfel încât tiering-ul să mute date doar după ce pattern-ul de acces a justificat-o. Asta este conceptual simplu și operațional fastidios, motiv pentru care majoritatea echipelor sar peste până când factura forțează problema.
Compactare de fișiere mici. Un pipeline care emite zece mii de fișiere Parquet mici per partiție produce un folder care e scump de listat, scump de interogat și scump de citit. Layer-ul de compactare al Pinterest (rulând peste Apache Iceberg, pe care l-au adoptat masiv, parțial bazându-se pe proiectul open-source de la Netflix acoperit în lecția 40) rescrie periodic fișierele mici în mai puține, mai mari. Economiile au venit din două locuri: mai puține request-uri S3 GET și LIST la momentul query-ului (taxele de request sunt o linie reală pe workload-uri de mai mulți petabytes) și execuție de query mai rapidă (mai puține fișiere înseamnă mai puține task-uri paralele și mai puțin overhead de coordonare).
Adopția formatului de tabel Iceberg. Layer-ul de metadate al Iceberg permite partition pruning, citiri bazate pe snapshot-uri și schema evolution pe care layout-urile de tabel mai vechi de tip Hive nu le pot avea. Efectul de cost apare ca mai puține fișiere scanate per query (pentru că planner-ul poate prune-ui la nivel de metadate) și planuri de query mai bune (pentru că statisticile sunt acurate). Schimbarea de format este muncă de infrastructură care se plătește înapoi în cost de compute mai mic pe fiecare query care rulează contra tabelelor migrate.
Politici de lifecycle. Snapshot-uri vechi, fișiere orfane și metadate Iceberg istorice se acumulează. Fără o politică de ștergere, stau pe S3 pentru totdeauna. Automatizarea de lifecycle a Pinterest le curăță, iar economiile sunt pură reducere de overhead.
Programul combinat de storage a produs economii cu procente cu două cifre pe linia de storage și o economie suplimentară semnificativă pe partea de compute pentru că query-urile au devenit mai rapide. Pattern-ul arhitectural: tratează storage-ul ca pe un sistem care trebuie operat, nu ca pe un substrat pasiv care doar acumulează tot ce scriu pipeline-urile.
Eficiență Spark și Graviton
Partea de compute a programului a fost descrisă în postări despre munca de eficiență Spark a Pinterest și migrarea spre instanțe AWS Graviton bazate pe ARM.
Right-sizing. Multe job-uri Spark erau supra-aprovizionate. Dimensiunile clusterelor fuseseră alese prin ghicire, rulate o dată și niciodată revizuite. O parcurgere sistematică prin cele mai mari job-uri a găsit că o fracțiune semnificativă rulau cu de două-până-la-cinci ori numărul de executori de care aveau nevoie. Reducerea supra-aprovizionării este conceptual trivială și operațional rară, pentru că nimeni nu are timpul sau dashboard-urile să știe care job-uri sunt supra-aprovizionate fără un program explicit. Pinterest a construit dashboard-urile și a rulat programul, iar economiile pe compute au fost substanțiale.
Spot instances. Workload-urile batch care tolerează întreruperea (majoritatea ETL și majoritatea ML feature engineering) pot rula pe AWS Spot la șaizeci-până-la-optzeci la sută reducere față de prețul on-demand. Captura este că instanțele Spot pot fi recuperate cu doar două minute de preaviz, deci workload-ul trebuie să fie checkpointable sau restartable. Pinterest a mutat o cotă mare din workload-ul lor batch Spark pe Spot, cu orchestratorul (acoperit în lecția 57 din Modulul 8) gestionând retry-uri când capacitatea dispărea. Economiile sunt directe: același workload, factură mult mai mică.
Migrarea Graviton (ARM). Instanțele AWS Graviton rulează pe procesoare ARM și oferă aproximativ douăzeci la sută mai bun price-performance decât echivalentele x86 pentru multe workload-uri. Migrarea nu e gratis: software-ul trebuie reconstruit sau re-împachetat pentru ARM, performanța trebuie validată și edge case-urile (biblioteci native, JNI bindings, agenți de vendor) trebuie gestionate. Pinterest și-a publicat experiența de mutare a workload-urilor Spark pe Graviton, inclusiv capcanele în jurul JVM tuning-ului și dependențelor native. Rezultatul a fost o reducere de cost structurală pe fiecare workload care a migrat, ceea ce este un alt fel de economie decât reglarea unui singur job: se compune peste întreaga flotă atât timp cât rulează clusterul.
Potrivire de tip de instanță. Dincolo de ARM, programul a inclus potrivirea tipurilor de instanță cu forma workload-ului. Agregări heavy pe memorie pe instanțe optimizate pentru memorie. Build-uri de feature de machine-learning heavy pe compute pe instanțe optimizate pentru compute. Scanări heavy pe storage pe instanțe cu NVMe local. Implicitul „folosește orice ne dă m5.xlarge” lasă bani pe masă; potrivirea deliberată îi recâștigă.
Programul de compute a livrat cea mai mare linie unică de economii din efortul global. Lecția este că risipa de compute, ca și risipa de storage, este rar vizibilă fără un program proiectat să o expună.
Optimizarea de query: abordarea top-N
A treia tranșă a venit din optimizarea de query, dar cu o disciplină pe care multe echipe o ratează. Într-un warehouse cu zeci de mii de query-uri recurente, distribuția de cost este puternic înclinată. O mână de query-uri (top cincizeci, uneori top zece) reprezintă o cotă disproporționată din compute-ul total. Optimizarea cozii lungi produce economii mici, împrăștiate; optimizarea capului produce economii vizibile, cumulative.
Abordarea Pinterest, descrisă în postările lor de inginerie despre eficiența warehouse-ului, a fost explicit top-N. Instrumentează fiecare query cu atribuire de cost. Sortează după cost total (frecvență înmulțită cu cost per rulare). Ia top cincizeci. Predă-le unei echipe de optimizare de query. Rescrie, repartiționează, adaugă indexurile sau sort key-urile potrivite, schimbă ordinea de join, împinge predicate-urile în jos, taie coloanele neutilizate, materializează subquery-urile scumpe. Treci la următorul lot.
Mecanica este de muncitor și rezultatele sunt disproporționate față de efort. O singură rescriere a unui query zilnic care scanează un petabyte economisește costul acelei scanări în fiecare zi, în fiecare an, până când cineva schimbă schema de bază. Compunerea este severă în direcția corectă. Aceleași ore de inginerie împrăștiate peste coada lungă ar fi produs o zecime din economii.
Pattern-ul se transferă. Fiecare warehouse de analytics are o listă de query-uri top-N. Fiecare echipă de date care nu a rulat exercițiul are risipă în capul acelei liste. Prima parcurgere prin top cincizeci este de obicei săptămâna cu cel mai mare leverage de muncă pe cost pe care un data engineer o poate face.
Right-sizing pentru clustere și warehouse-uri
Dincolo de Spark, programul Pinterest a atins sistemele always-on. Warehouse-urile (Trino, servicii de tip Snowflake), cluster-ele de notebook-uri, backend-urile de BI și pipeline-urile de streaming poartă toate cost de bază care rulează indiferent dacă cineva le folosește sau nu. Parcurgerea de right-sizing pe acestea a țintit trei lucruri.
Idle scaling. Cluster-ele care rulau douăzeci-și-patru-șapte, dar vedeau încărcare doar zece ore pe zi au fost scalate în jos sau oprite în fereastra de idle. Economiile sunt directe, iar riscul operațional este mic dacă scale-up-ul este automatizat. Sistemele unde asta este cel mai greu sunt cele cu cache-uri stateful care au nevoie de timp să se încălzească; pentru acelea, trade-off-ul este căldura cache-ului versus costul, iar răspunsul depinde de workload.
Dimensionare bazată pe concurență. Warehouse-urile dimensionate pentru concurență de vârf care apare o dată pe zi costau prețuri de vârf pentru douăzeci-și-trei de ore de off-peak. Auto-scaling-ul, unde este suportat, a abordat asta. Unde nu este suportat, redimensionarea programată a făcut-o.
Izolarea workload-ului după SLA. Query-urile interactive critice au fost separate de workload-urile batch și ad-hoc, astfel încât cluster-ul interactiv să poată fi dimensionat pentru concurență scăzută și responsivitate înaltă, în timp ce cluster-ul batch să poată fi dimensionat pentru throughput înalt și să tolereze cozi. Amestecarea lor forța ambele să fie dimensionate pentru încărcarea combinată în cazul cel mai rău, ceea ce e mai scump decât suma a două clustere dimensionate corespunzător.
Pattern-ul: plătește pentru ce folosești, când folosești. Implicitele rareori se potrivesc cu asta; configurarea deliberată o face.
The kill list
Cea mai puțin tehnică și cea mai subapreciată parte a programului este parcurgerea de audit-și-șterge. Fiecare organizație matură de date are dashboard-uri pe care nimeni nu le deschide, pipeline-uri care calculează output-uri pe care nimeni nu le consumă și tabele care nu au fost interogate de un an. Costă bani pe nimic și se acumulează pentru că crearea lor este ușoară și deprecierea lor este treaba altcuiva.
Programul Pinterest a inclus o kill list explicită. Dashboard-urile fără view-uri în nouăzeci de zile au fost marcate. Pipeline-urile ale căror output-uri nu aveau cititori downstream au fost marcate. Tabelele cu zero query-uri într-o fereastră de audit au fost marcate. Marcajele au mers la owneri, care fie au justificat asset-ul, fie au fost de acord cu ștergerea lui. Faza de ștergere a recâștigat bani reali, atât direct (compute-ul și storage-ul asset-ului mort), cât și indirect (costul operațional de monitorizare și mentenanță).
Pattern-ul este universal. Orice echipă care rulează de mai mult de doi ani are asset-uri pe care nimeni nu le folosește și pe care nimeni nu s-a apucat să le șteargă. Kill list-ul este cel mai ieftin exercițiu de economisire pe platformă și este cel pe care majoritatea echipelor îl sar.
Vizibilitate de cost și chargeback
Substratul cultural al întregului program este vizibilitatea. Niciuna dintre economiile individuale nu este posibilă fără dashboard-uri care arată, pe echipă și pe produs, cât costă platforma de date. Fără acele dashboard-uri, fiecare discuție de cost este anecdotică, fiecare prioritizare este politică, iar echipa care se oferă voluntară să optimizeze poartă povara singură.
Pinterest, ca majoritatea organizațiilor mari de date, a construit dashboard-uri care atribuie costul de compute, storage și request echipelor care l-au generat. Modelul de atribuire poate fi chargeback (bugetul echipei plătește efectiv pentru ce a folosit) sau showback (echipa vede ce a folosit, dar echipa de platformă plătește). Modelul specific al Pinterest este intern; postările publice subliniază vizibilitatea însăși, nu mecanica financiară.
Efectul este ce economiștii numesc internalizarea externalității. Când o echipă poate vedea că dashboard-ul lor costă compania o sută de mii de dolari pe lună, tinde să se întrebe dacă dashboard-ul merită atât. Tinde să optimizeze query-urile, să partiționeze tabelele mai bine, să arhiveze datele vechi și să șteargă asset-urile neutilizate. Rolul echipei de platformă se schimbă de la a fi singurul optimizator la a fi cel care permite optimizarea de către fiecare echipă.
Rezultatul cumulativ
Afirmația publicată este că programul de mai mulți ani a tăiat costul de infrastructură de date aproximativ la jumătate, contra unei contrafaptice de creștere neconstrânsă. În termeni absoluți, asta este o cifră de economii în zona zecilor de milioane de dolari anual, în funcție de perioadă și baseline. Economiile sunt persistente: storage tiering-ul, migrarea Graviton, kill list-ul și right-sizing-ul continuă să plătească atât timp cât rulează sistemele.
Efectul cumulativ contează mai mult decât orice linie individuală. Niciuna dintre pârghii nu este nouă. Toate sunt documentate în whitepapers de cloud-vendor, în documentație de proiect open-source și în postările publice ale altor jumătate de duzină de companii. Ce a făcut Pinterest a fost să le aplice sistematic, ca un program continuu mai degrabă decât un cleanup unic, iar compunerea a produs rezultatul de titlu.
Lecțiile
Cinci concluzii, în aceeași formă pe care cazul Netflix din Modulul 5 (lecția 40), cazul Uber din Modulul 6 (lecția 48) și cazul Airbnb din Modulul 8 (lecția 64) au folosit-o.
Optimizarea costurilor este propria sa disciplină de inginerie. A o trata ca pe un proiect ratează jumătate din economii. A o trata ca pe un program continuu, cu owneri dedicați, dashboard-uri și o cadență de review trimestrială, produce rezultate care se compun. Relatarea publicată a Pinterest este, mai mult decât orice altceva, o relatare a disciplinei, nu a tehnicilor individuale.
Regula 80/20 se aplică dur. Majoritatea economiilor vin dintr-un număr mic de schimbări cu leverage înalt. Rescrieri de query top-N, right-sizing-ul celui mai mare cluster, tiering-ul celui mai mare tabel. Restul este incremental. O echipă care pornește de la zero ar trebui să se concentreze pe puținele oportunități cele mai mari și să accepte că coada lungă va dura mai mult să fie recoltată.
Fă costul vizibil pe echipă și pe produs. Dashboard-urile sunt precondiția pentru orice altceva. Fără ele, optimizarea este anecdotă și politică. Cu ele, este inginerie. Dashboard-urile nu sunt glamour de construit și sunt piesa cu cel mai mare leverage de infrastructură FinOps pe care majoritatea echipelor o pot livra.
Kill list-ul de job-uri pe care nimeni nu le rulează este bani reali. Fiecare organizație de date are dashboard-uri, pipeline-uri și tabele pe care nimeni nu le folosește. Auditează-le, marchează-le, șterge-le pe cele care nu se pot justifica. Aceasta este cea mai ieftină tranșă de economii și este cea pe care majoritatea echipelor nu au rulat-o.
Spot și Graviton sunt bani reali când workload-urile le tolerează. Ambele tehnologii sunt mature în 2026. Spot este o reducere de șaizeci-până-la-optzeci la sută pe compute batch, condiționată de checkpointability. Graviton este o îmbunătățire structurală de douăzeci la sută, condiționată de portabilitate software. Costurile de migrare sunt reale și unice; economiile sunt recurente și se compun peste fiecare workload care rulează pe infrastructura migrată.
Referințe încrucișate înapoi în Modulul 9
Programul Pinterest exersează fiecare pârghie pe care Modulul 9 a introdus-o. Storage tiering-ul și compactarea sunt forma operațională a pattern-urilor de layout de stocare de mai devreme din modul. Eficiența Spark, Spot și Graviton sunt pârghiile de right-sizing de compute. Rescrierile de query top-N sunt optimizarea de query în forma sa cu cel mai mare leverage. Dashboard-urile de cost și chargeback-ul sunt cultura FinOps care face restul sustenabil. Kill list-ul este igiena de lifecycle de asset care închide bucla. Meta-întrebarea build-versus-buy din lecția 71 este framing-ul sub care un program ca acesta este aprobat în primul rând: când factura este suficient de mare încât să o optimizezi merită timpul unei echipe dedicate.
Formele se transferă la echipe care rulează a suta parte din workload. O echipă mică de date cu o factură lunară cu șase cifre are aceleași pârghii, în aceleași proporții, doar cu numere absolute mai mici. Disciplina este aceeași; curba de economii este aceeași; efectul cumulativ este același.
Modulul 9 se închide aici
Modulul 9 a fost despre a face platforma de date sustenabilă pe axa costului. Layout-ul de stocare, right-sizing-ul de compute, optimizarea de query-uri, alegerile de format, cultura FinOps, relațiile cu vendorii și programul cumulativ care le leagă pe toate. O platformă care e fiabilă, dar scumpă, va fi în cele din urmă tăiată. O platformă care e ieftină, dar nefiabilă, costă afacerea mai mult decât economisește. Cele două axe sunt legate, iar tehnicile din acest modul sunt cum o echipă matură le ține pe amândouă.
Modulul 10 se deschide ieșind din platforma de date și intrând în întrebarea mai largă despre cum un sistem își împarte responsabilitatea peste servicii. Prima lecție acoperă microserviciile: termenul, beneficiile reale, costurile pe care primii susținători le-au subestimat și pendulul care s-a întors spre monoliții modulari în multe dintre cazurile unde microserviciile au fost odată răspunsul implicit. Deciziile arhitecturale arată diferit de deciziile de platformă de date din ultimele nouă module, dar logica de bază este aceeași: fiecare alegere este un trade-off, iar treaba este să știi care axă contează pentru sistemul din fața ta.
Citări și lecturi suplimentare
- Blog Pinterest Engineering,
https://medium.com/pinterest-engineering(consultat 2026-05-01). Colecția de postări publice despre reducerea costurilor de platformă de date, adopția Iceberg, eficiența Spark și migrarea Graviton pe care această lecție o sintetizează. - Pinterest Engineering, postări despre eficiența platformei de date și optimizarea costurilor (consultat 2026-05-01). Afirmațiile direcționale de economii și descompunerea programului în faze de storage, compute, query și lifecycle vin din acest corp de muncă.
- Proiectul Apache Iceberg,
https://iceberg.apache.org/(consultat 2026-05-01). Documentație despre partition pruning, expirarea snapshot-urilor și compactarea fișierelor mici, primitivele de bază pe care se sprijină programul de storage al Pinterest. - Documentația Apache Spark,
https://spark.apache.org/docs/latest/(consultat 2026-05-01). Referință pentru pârghiile de configurare și tuning (executor sizing, comportament de shuffle, dynamic allocation) pe care munca de eficiență Spark le atinge. - Documentația AWS Graviton,
https://aws.amazon.com/ec2/graviton/(consultat 2026-05-01). Referința de vendor pentru afirmația de price-performance și considerațiile de migrare relevante pentru tranșa Graviton. - Documentația claselor de storage AWS S3,
https://aws.amazon.com/s3/storage-classes/(consultat 2026-05-01). Nivelurile de preț și semantica de retrieval pe care operează programul de storage tiering. - Documentația AWS Spot Instances,
https://aws.amazon.com/ec2/spot/(consultat 2026-05-01). Prețurile și semantica de întrerupere care guvernează migrarea Spot.