Optimizarea costului de storage: tiering, lifecycle, compactare

Lecția 65 a încadrat factura cloud ca un aisberg, cu storage-ul ca una dintre cele mai mari linii de sub linia vizibilă a apei. Lecția aceasta ia acea linie de storage și merge în adâncime. Trei pârghii poartă majoritatea economiilor: tiering-ul datelor între storage classes după frecvența accesului, automatizarea acelei mișcări cu lifecycle policies, și compactarea fișierelor mici în altele mai mari astfel încât numărul de fișiere să nu mai conducă costurile de request și metadata. O a patra pârghie, ștergerea pur și simplu a ce nu e necesar, e cea care e neglijată pentru că nimeni nu e plătit să șteargă lucruri.

Lecția e ancorată în S3 pentru că S3 e object store-ul dominant și pentru că AWS are cele mai multe detalii publice de prețuri. Aceleași forme se aplică tier-urilor Azure Blob Storage (Hot, Cool, Cold, Archive) și storage classes Google Cloud Storage (Standard, Nearline, Coldline, Archive). Numele claselor diferă; modelul e identic.

Realitatea 90/10

O constatare consistentă peste workload-urile de analiză e că aproximativ 10 la sută din date reprezintă 90 la sută din accesări. Cea mai recentă săptămână de evenimente conduce majoritatea dashboard-urilor. Cel mai nou artefact de model primește tot traficul de inferență. Facturile trimestrului trecut sunt interogate pentru raportarea de sfârșit de trimestru și apoi devin liniștite. Datele anului anterior sunt în mare parte dormante, interogate doar pentru comparații anuale sau pull-uri de compliance.

Aceasta e baza pentru tiering. Stocarea celor 90 la sută dormante pe aceeași storage class ca cele 10 la sută hot înseamnă plata unor tarife premium pentru date reci. Argumentul economic pentru tiering e direct: storage classes reci sunt cu 50 până la 90 la sută mai ieftine decât tier-ul standard, datele dormante n-au nevoie de acces în milisecunde, iar mica taxă de acces pentru retrieval-ul rar e umbrită de economiile de storage pe grosul datelor.

Capcana e că economiile depind de tiparul de acces care se potrivește cu presupunerea. Un workload care se dovedește a scana toate datele anului trecut o dată pe lună pentru un raport de reglementare poate ajunge să plătească mai mult sub o politică cold-tier decât ar plăti pe Standard, pentru că taxele de retrieval și costurile de request mănâncă economiile de storage. Prima sarcină a unei strategii de tiering e să măsoare accesul, nu să presupună.

S3 storage classes

AWS expune o rețea de storage classes optimizate pentru tipare diferite de acces. Prețurile sunt aproximative și variază pe regiune; cifrele de mai jos folosesc prețurile de listă din US East 1 din mijlocul lui 2026 (https://aws.amazon.com/s3/pricing/, consultat 2026-05-01) pentru comparație relativă, nu bugetare absolută.

Standard. În jur de 2,3 cenți per gigabyte pe lună. Default-ul. Acces în milisecunde, SLA de disponibilitate de 99,99 la sută, durabilitate multi-AZ. Tier-ul potrivit pentru date hot.

Intelligent-Tiering. Același cost per gigabyte ca Standard pentru tier-ul de acces frecvent, cu mișcare automată către tier-uri cu cost mai mic (Infrequent Access, Archive Instant Access, Archive Access, Deep Archive Access) bazat pe accesul observat. Se aplică o mică taxă de monitorizare per obiect. Tier-ul potrivit când tiparele de acces sunt impredictibile sau variază între obiecte, pentru că S3 face munca de tiering.

Standard-IA. În jur de 1,25 cenți per gigabyte pe lună, cu o taxă de retrieval per GB de aproximativ 1 cent și o durată minimă de stocare de 30 de zile. Bun pentru date accesate lunar dar care încă au nevoie de acces în milisecunde.

One Zone-IA. În jur de 1 cent per gigabyte pe lună. Același model de retrieval și durată minimă ca Standard-IA, dar datele trăiesc într-un singur AZ. Acceptabil pentru date re-creabile (output-uri intermediare de analiză, copii secundare de media) unde riscul de pierdere a unui AZ e tolerabil.

Glacier Instant Retrieval. În jur de 0,4 cenți per gigabyte pe lună. Retrieval în milisecunde, dar cu o taxă de retrieval per GB mai mare (în jur de 3 cenți per GB) și un minim de 90 de zile. Tier-ul potrivit pentru date de arhivă care încă trebuie să fie interogabile la cerere, cum ar fi arhivele de compliance pe care un auditor le-ar putea cere.

Glacier Flexible Retrieval. În jur de 0,36 cenți per gigabyte pe lună. Retrieval-ul durează minute până la ore, cu taxe de retrieval care scalează cu viteza (Expedited, Standard, Bulk). Util pentru backup-uri și date long-tail unde așteptarea unei ore pentru retrieval e acceptabilă.

Glacier Deep Archive. În jur de 0,099 cenți per gigabyte pe lună, cel mai ieftin tier pe AWS. Retrieval-ul durează 12 ore sau mai mult în tier-ul standard, mai rapid cu Bulk Expedited. Tier-ul potrivit pentru date păstrate exclusiv pentru compliance, unde întrebarea „o ai” contează și „cât de repede o putem obține” nu.

Structura de prețuri e intenționată: cu cât e mai ieftină rata pe lună, cu atât e mai mare costul per retrieval și mai lungă durata minimă. Aritmetica care determină tier-ul potrivit pentru un dataset dat e „care e frecvența de retrieval așteptată, și la ce frecvență costul de retrieval depășește economiile de storage”.

Lifecycle policies

S3 lifecycle policies sunt automatizarea care face tiering-ul practic. O regulă de lifecycle spune, în formă declarativă, „mută obiectele din acest prefix de la Standard la Standard-IA după 30 de zile, la Glacier Instant Retrieval după 90 de zile, la Deep Archive după 365 de zile, și șterge după 7 ani”. Regula rulează pe propriul orar; echipa nu trebuie să scrie cod pentru a migra obiectele între tier-uri.

flowchart LR
    Hot["Hot data<br/>0-30 days<br/>Standard"] --> Warm["Warm data<br/>30-90 days<br/>Standard-IA"]
    Warm --> Cold["Cold data<br/>90-365 days<br/>Glacier IR"]
    Cold --> Frozen["Archive<br/>1-7 years<br/>Glacier Deep"]
    Frozen --> Deleted["Deleted<br/>after 7 years"]

Lifecycle policy e singura intervenție de cost cu cel mai mare ROI disponibilă pe o factură S3 tipică, pentru că nu necesită schimbări de aplicație și rulează pentru totdeauna odată configurată. Majoritatea echipelor care n-au trecut printr-un engagement FinOps fie n-au lifecycle policies, fie au politici default care mută obiectele la IA după 30 de zile și niciodată mai departe. Versiunea disciplinată plimbă datele prin trei sau patru tier-uri bazat pe măsurări de acces, și șterge datele care au depășit cerința de retenție.

O configurație comună care prinde majoritatea economiilor pe un bucket de analiză:

Zilele 0 până la 30: Standard. Hot, accesate frecvent, interogate de cele mai recente dashboard-uri.
Zilele 30 până la 90: Standard-IA. Warm, interogate ocazional pentru comparații lună-pe-lună.
Zilele 90 până la 365: Glacier Instant Retrieval. Cold, interogate pentru rarul pull trimestrial sau de compliance.
Ziua 365 înainte: Glacier Deep Archive. Frozen, păstrate pentru perioada legală de retenție și improbabil să fie cerute.
După perioada de retenție: șterse.

Pragurile exacte depind de workload. O echipă cu SLA-uri zilnice pe prospețimea datelor probabil extinde fereastra Standard. O echipă cu cicluri trimestriale de raportare probabil extinde fereastra Standard-IA astfel încât query-ul trimestrial să lovească încă tier-ul de acces în milisecunde. Tiparul e: măsoară mai întâi, setează praguri, și revizuiește anual.

Capcana costurilor de retrieval Glacier

Cel mai comun mod în care o strategie de tiering merge prost e mutarea datelor la Glacier și apoi necesitatea de a le aduce înapoi. Glacier Flexible Retrieval și Deep Archive au ambele taxe substanțiale de retrieval per GB și taxe de request, plus durata minimă de stocare de 90 de zile sau 180 de zile. O echipă care mută un terabyte la Deep Archive și aduce înapoi jumătate din el o săptămână mai târziu plătește storage-ul la rata Deep Archive, taxa de ștergere timpurie pentru retrieval-ul înainte de durata minimă, taxa de retrieval per GB, și taxa de egress per GB dacă datele părăsesc AWS. Totalul poate depăși ce ar fi costat datele pe Standard pentru aceeași perioadă.

Tiparul care declanșează asta: vine o cerință de reglementare, echipa își dă seama că datele arhivate trebuie produse pentru un audit, și costul de retrieval se descoperă după ce s-a întâmplat. Soluția e să modelezi costul de retrieval în decizia de tiering înainte de a configura politica. O regulă utilă de degetar: dacă un dataset are mai mult de 5 la sută șansă să fie cerut pe an, Glacier Instant Retrieval sau Standard-IA e de obicei o potrivire mai bună decât Deep Archive.

Compactare Parquet

Tiering-ul de storage class atacă partea per gigabyte a facturii. Numărul de fișiere atacă partea per request. Cele două sunt legate: un dataset hot-tier de un milion de fișiere Parquet mici costă aproape la fel în storage ca câteva mari, dar numărul de request-uri, timpul de listing și overhead-ul de query fac versiunea cu fișiere mici dramatic mai scumpă de folosit.

„Problema fișierelor mici” apare natural în ingestia de streaming și ETL incremental. Fiecare micro-batch scrie propriul fișier Parquet. După un an, tabelul constă din milioane de fișiere medii de câteva sute de kilobytes fiecare. Fiecare query trebuie să listeze și să deschidă fiecare fișier, să-i parseze metadatele și să unifice rezultatele. Spark și Trino au amândouă curbe de degradare bine documentate odată ce numărul de fișiere trece de câteva sute de mii. Peste un milion, timpii de query devin impredictibili și taxele de request devin o linie vizibilă pe factură.

Soluția e compactarea: un job periodic care citește multe fișiere mici, sortează și grupează rândurile potrivit, și le scrie ca mai puține fișiere mai mari. Mărimea țintă a fișierului pentru workload-uri analitice e tipic 256 MB până la 1 GB per fișier Parquet. Compactarea face compromis între costul rulării job-ului și economiile din reducerea numărului de fișiere și a overhead-ului de metadata, și pentru orice dataset interogat zilnic economiile domină în câteva săptămâni.

flowchart LR
    Tiny["10,000 small Parquet files<br/>~100 KB each<br/>1 GB total"] --> Compact["Compaction job<br/>read, merge, rewrite"]
    Compact --> Large["4 large Parquet files<br/>~256 MB each<br/>1 GB total"]

Job-ul de compactare în sine poate fi scump, pentru că citește și rescrie aceleași date. Economiile lucrează pentru că economiile sunt pe fiecare query ulterior, nu doar pe următorul. Un job zilnic de compactare care rulează o oră economisește secunde pe fiecare query pentru anul următor, plus reduce costul per request pe fiecare citire.

Optimizare automată în Iceberg și Delta

Lecția 37 a introdus formatele de tabel lakehouse. Funcționalitățile lor de optimizare automată sunt răspunsul modern la problema fișierelor mici, și încorporează compactarea în formatul în sine în loc să o lase la utilizator.

Iceberg. Specificația Iceberg suportă operațiuni de rewrite ca concepte de prim rang, și engine-uri precum Spark și Trino pot rula operațiuni OPTIMIZE sau rewrite_data_files împotriva unui tabel Iceberg pentru a compacta fișiere mici, sorta după chei de clustering, și elimina rândurile șterse. Snowflake și Databricks expun amândouă Iceberg gestionat cu optimizare automată ca funcționalitate de serviciu.

Delta Lake. Delta are comanda OPTIMIZE, cu clauze opționale ZORDER BY pentru clustering multi-dimensional. Runtime-ul Databricks oferă auto-compaction și adaptive file sizing, unde engine-ul în sine decide când să compacteze pe baza distribuției mărimilor de fișier pe care le observă. Funcționalitatea de auto-compaction e documentată în docs Databricks (https://docs.databricks.com/en/delta/optimizations/auto-optimize.html, consultat 2026-05-01).

Hudi. Hudi are operațiuni de clustering și compactare, cu moduri atât inline (în timpul scrierilor) cât și offline (programate). Hudi a fost formatul cel mai explicit despre tratarea compactării ca preocupare de prim rang, pentru că modelul merge-on-read efectiv o cere.

Pentru o echipă care folosește unul dintre aceste formate, optimizarea automată ar trebui pornită mai degrabă decât oprită. Costul rulării compactării pe orar e mic comparat cu costul interogării unui milion de fișiere mici timp de un an, și timpul de inginerie economisit prin neconstruirea unei compactări custom e semnificativ.

Șterge ce nu-ți trebuie

Cel mai ieftin gigabyte e cel nestocat. Fiecare discuție de storage se întoarce în cele din urmă la practica disciplinată de a șterge datele care au depășit cerința de retenție, au fost generate de experimente care n-au mers nicăieri, trăiesc în medii de development pe care nu le folosește nimeni, sau au fost copiate „la nevoie” și niciodată citite din nou.

Motivele pentru care asta e neglijat sunt predictibile. Ștergerea pare riscantă: cineva ar putea avea nevoie de date mâine, și a explica un fișier lipsă e mai greu decât a absorbi o linie mică pe o factură. Ștergerea nu e o funcționalitate pe care vreo echipă e plătită s-o livreze. Costul datelor păstrate e distribuit pe linia de storage, unde niciun gigabyte individual nu e vizibil. Și o echipă care n-a trecut printr-un engagement de cost nu are memoria musculară de a întreba „ar trebui ăsta să mai existe”.

Disciplina matură include:

Politici de retenție pe fiecare dataset, setate de owner-ul datelor, exprimate ca regulă de lifecycle cu o acțiune finală de ștergere.
Un pas de curățare pe mediile dev și staging, unde snapshot-urile, volumele EBS, bucket-urile S3 și backup-urile de bază de date se acumulează până când cineva rulează un audit.
Review-uri la nivel de bucket pe o cadență trimestrială, căutând bucket-uri pe care nu le deține nimeni și prefixuri în care nu s-a scris de ani.
Igienă de versionare: bucket-urile S3 cu versionare activată acumulează fiecare versiune anterioară a fiecărui obiect, și o regulă lifecycle lipsă pe versiunile non-curente poate dubla sau tripla factura în tăcere. Soluția e o politică ce expiră versiunile non-curente după o fereastră definită.

Costul de storage e problema rară de inginerie unde a nu face nimic are un cost care se compune. Bucket-ul crește, factura crește, și costul auditului care ar fi trebuit să se întâmple anul trecut se acumulează ca anul următor de cheltuială inutilă.

Ce acoperă lecția următoare

Lecția 67 ia axa de compute. Instanțe Spot și preemptible pentru workload-urile care tolerează întreruperi, autoscaling făcut bine versus capcanele autoscaling-ului care produc thrash și pierdere de vârfuri, right-sizing ca disciplină de bază pe care majoritatea echipelor n-au făcut-o de un an, și capacitate rezervată pentru baseline-ul predictibil care justifică un angajament multi-anual. Compute-ul e linia cu cel mai mult folclor în jurul ei, și lecția taie până la pârghiile care chiar mișcă factura.

Citări și lecturi suplimentare

AWS, S3 pricing, https://aws.amazon.com/s3/pricing/ (consultat 2026-05-01). Referința canonică de prețuri pentru toate storage classes menționate mai sus.
AWS, S3 storage classes, https://aws.amazon.com/s3/storage-classes/ (consultat 2026-05-01). Rezumatul de pagină marketing al claselor, util pentru ghidarea de tipare de acces.
AWS, S3 lifecycle configuration, https://docs.aws.amazon.com/AmazonS3/latest/userguide/object-lifecycle-mgmt.html (consultat 2026-05-01). Referința pentru sintaxa și comportamentul lifecycle policy.
Databricks, Auto-optimize on Delta Lake, https://docs.databricks.com/en/delta/optimizations/auto-optimize.html (consultat 2026-05-01). Documentația pentru auto-compaction și optimised writes în Delta.
Apache Iceberg, table maintenance documentation, https://iceberg.apache.org/docs/latest/maintenance/ (consultat 2026-05-01). Referința pentru rewrite_data_files, expirarea snapshot-urilor și alte operațiuni de mentenanță.
Apache Hudi, compaction documentation, https://hudi.apache.org/docs/compaction/ (consultat 2026-05-01). Referință pentru compactare inline și programată în Hudi.
FinOps Foundation, „Storage cost optimization”, https://www.finops.org/wg/storage-cost-optimization/ (consultat 2026-05-01). Resurse de working group despre practicile de tiering de storage în comunitatea FinOps.