Comprimarea datelor analitice

1) De ce comprima date analitice

Compresia reduce stocarea și traficul, vitezele scanează cu mai puțin IO și o mai bună cache. Prețul este CPU și (uneori) complexitatea actualizărilor. Scopul este „IO↔CPU↔tochnost↔stoimost” optimă pentru SLO-urile tale.

• Raportul de compresie (CR) = 'raw _ size/ compressed_size'.
• Cost de scanare ≈ bytes_scanned/ throughput_storage + cpu_decode_time'.
• Cost total = 'stocare _ cost + compute_cost + egress_cost'.

2) Straturi în care trăiește compresia

1. La nivel de format: Parchet/ORC/Avro (pagini/dungi/coloane).
2. La nivelul de codare al coloanei: Dicționar, RLE, Delta, FoR/Bit-packing, Gorilla/XOR.
3. La nivel de codec: ZSTD, Snappy, LZ4, Gzip.
4. La nivel de interogare/motor: vectorizare, pagina sărind peste (min/max), bloom/zone-map.
5. La nivel de depozitare: depozitare pe niveluri (cald/cald/rece), compresie, memorie cache pagină.

3) Formate de coloane și avantajele lor

Parchet: pagini coloană; suport dicționar, RLE/Bit-ambalare, min/max statistici și null-count.
ORC: benzi cu indici pe fluxuri, filtre de floare; eficient pentru scanări lungi.
Avro (rând): convenabil pentru flux/busteni, mai rău pentru scanări analitice.

Practică: Pentru analiza implicită, utilizați Parchet/ORC, includeți statisticile coloanelor și dicționarul în care cardinalitatea este scăzută/medie.

4) Codificări coloană (fără pierderi)

Dicționar-Înlocuiește valorile cu indici (ideal pentru cardinalitate scăzută).
RLE (Run-Length Encoding) - duplicat valori → (valoare, rula). Bun pentru coloane sortate/grupate.
Delta/Delta-of-Delta: stochează diferențe (numere/ori).
FoR (Frame-of-Reference) + Bit-packing: value = base + offset; offset este ambalat cu N biți.
Gorila/XOR (Time-series): stochează XOR de valori vecine cu lungime variabilă; bun pentru măsurători.
Nullable bitmasks: un flux separat de null-uri crește CR.

Sfat: Pre-gruparea/filtrarea cheii de sortare îmbunătățește dramatic RLE/zone-maps și CR.

5) Codec-uri de uz general

ZSTD: cel mai bun CR la preț moderat CPU; suportă nivelurile 1-22. Alegere universală.
Snappy: rapid, scăzut CR; potrivit pentru date fierbinți cu frecvență înaltă de citire.
LZ4: Snappy chiar mai repede, similar CR; de multe ori - pentru flux/busteni/cache.
Gzip/Deflate: CR ridicat, preț ridicat CPU; rareori justificate în analiza interactivă.

Regula: strat fierbinte - Snappy/LZ4, cald/rece - ZSTD (nivel 3-7).

6) Seria de timp și jurnalele

Baze de date TSDB/coloană: Gorilla/XOR, Delta-RLE-Bitmap, Rarse-run pentru semnale rare.
Jurnale: JSON→Parquet + ZSTD; normalizați cheile și tipurile (nu păstrați "string int').
Sub-eșantionare și roll-up-uri (lossy): depozitați unități de ferestre (1m/5m/1h) într-un strat fierbinte; crud - în frig.
Structuri schiță: HLL (cardinalitate), TDistest/KLL (cantități), CMS (frecvențe) - compact, dar aproximativ.

7) Lossless vs Lossy (când puteți pierde precizia)

Fără pierderi - raportare, finanțe, audit.
Lossy - monitorizare, analiza A/B pe ferestre mari, telemetrie (cu marcaj explicit!).
Controlul calității: setați toleranța (de ex. P99 ± 0. 5 pp) și verificați-l în CI.

8) Partiționare, pagini și compactare

Părți: până la data/regiune/chiriaș → mai puține scanări, mai bine CR.
Dimensiunea paginii/bandă: 64-256 KB pe pagină, 64-512 MB pe fișier - echilibru între căutare și procesor.
Compactare: combina problema fișierelor mici - peste CR și viteza.
Zone-maps/Bloom: accelerați săriturile pe pagină; eficiente în sortarea după filtre.

9) Compresie și criptare/confidențialitate

Ordinea operațiunilor: prima compresie, apoi criptare. În caz contrar, CR ≈ 1.
TDE/at-rest nu interferează cu CR (un bloc deja comprimat este criptat).
In-transit (TLS) nu afectează formatul.
PII mascare/tokenization înainte de compresie păstrează entropia ușor de gestionat.
Atenție la criptarea OPE/DET: poate degrada CR și/sau risca confidențialitatea.

10) Cost și SLO (economie)

Depozitare: mai puțini octeți → mai puțin de $/TB-mo.
Calcul: mai puțin IO → scanări mai rapide; dar decompresia iroseşte procesorul.
Ieșire: mai puțini octeți → timp de trafic/copiere mai mic.
Compromis SLO: potriviți codecul/nivelul astfel încât „p95 _ latency” să rămână în fereastra țintă.

yaml hot:
format: parquet codec: snappy target_p95_ms: 1000 max_scan_mb: 2048 warm:
format: parquet codec: zstd:4 target_p95_ms: 2500 compaction: daily cold:
format: parquet codec: zstd:7 glacier: true retention: 365d

11) Practici pentru motoare (ClickHouse/Fulg de zăpadă/BigQuery/Deplasare spre roșu/Presto)

ClickHouse: CODEC 'și pe difuzoare (LZ4/ZSTD/DoubleDelta), COMANDĂ pentru RLE/scanări, TTL/compresie.
Fulg de nea/BigQuery: format/automatizare grupare; ajutor cluster de (data, chiriaș, chei de filtrare).
Deplasare spre roșu/Presto/Trino: Parchet/ORC cu ZSTD, setare 'stup. exec. compress. ieșire ", statistici și divizarea fișierelor.

12) Conducte: în cazul în care pentru a include compresie

Ingera: loturi comprimate (ZSTD/LZ4) atunci când se scrie la lac.
Transformați/DBT: creați obiective de coloană cu codecul dorit și sortarea.
Serviți/OLAP: vizualizări materializate cu un codec adecvat; pre-agregate pentru tablouri de bord fierbinți.
Export: для CSV/JSON - gzip/zstd; mai bine să dea la parchet.

13) Testarea și validarea

Profilare AB: un set de cereri de comparare → p50/p95, octeți scanați, timp procesor, CR.
Seturi de aur: verificarea corectitudinii după recodare/comprimare.
Teste perf regiune: alerte dacă p95 ↑> X% după schimbarea codec/nivel.
Reguli DQ: tipurile/intervalele/rata NULL nu trebuie să se schimbe la reîncărcare.

14) Politici de retenție și TTL

Nivelat: cald (7-14 zile), cald (30-90 zile), rece (≥180 zile).
Sub-eșantionare: Pe măsură ce „răciți”, depozitați unități/schițe în loc de crude.
Păstrare/Păstrare legală: nu înlăturați conflictele cu reglementările; stoca directoare și versiuni.

15) Antipattern

„Peste tot nivelul Gzip 9 „: procesor scump, nici un beneficiu.
Fără sortare/grupare: RLE/zone-hărți proaste → scanări scumpe.
JSON ca format de stocare: convenabil pentru ingerare, rău pentru analiză.
Fișiere prea mici: umflați metadatele/căutați; CR cade.
Criptare pre-comprimare: CR aproape zero.
Lossy nemarcat: încălcarea încrederii și responsabilității.

16) Foaia de parcurs privind implementarea

1. Descoperire: profiluri de interogare/date, SLO-uri și bugete.
2. MVP: Parchet + ZSTD/Snappy, sortare/grupare de bază, compactare.
3. Tuning: nivelurile ZSTD, dimensiunile paginii, cluster by, bloom/zone-maps.
4. Cald/rece: depozitare pe niveluri, sub-eșantionare/schițe, politici de ieșire.
5. Întărire: teste de regresie perf, DQ, transcodare runbooks.

17) Lista de verificare înainte de lansare

• Format: Parchet/ORC; statistici/dicționare incluse.
• Gruparea prin filtrarea cheilor; părți după dată/chiriaș.
• Codec-uri: fierbinte = Snappy/LZ4, cald/rece = ZSTD (3-7); p95 este normal.
• Compresia este configurată; fără fișiere mici; dimensiunile fișierului/paginii țintă.
• DQ și seturile de aur sunt verzi; tipuri/intervale salvate.
• Criptare după compresie; PII mascat; păstrare/deținere legală respectată.
• Regresiile Perf sunt monitorizate; alerte prin p95/octeți scanați/CR.
• Politica de stocare și transcodarea documentației instrucțiunilor este gata.

18) Mini șabloane

sql create table if not exists analytics.sales_daily cluster by (event_date, tenant_id)
as select from {{ ref('sales_daily_view') }};
-- в конфиге модели: materialized=table, file_format=parquet, compression=zstd

yaml compaction:
target_file_mb: 256 small_file_threshold_mb: 32 schedule: "hourly"

yaml timeseries:
raw:  keep: 14d rollup_1m: keep: 90d rollup_1h: keep: 365d rollup_1d: keep: 1825d

Linia de fund: compresia analitică a datelor nu este doar „porniți codecul”, ci o strategie holistică: formatul corect, codarea coloanelor, sortarea și partiționarea, nivelurile de compresie și stocare, respectul pentru criptare și SLO. Designul inteligent oferă scanări mai rapide, număr mai mic și performanță previzibilă - fără a compromite încrederea în date.