Compression des données analytiques

1) Pourquoi compresser les données analytiques

La compression réduit le stockage et le trafic, accélère les scans grâce à moins d'IO et une meilleure cachabilité. Prix - CPU et (parfois) la complexité des mises à jour. L'objectif est l'optimum « IO↔CPU↔tochnost↔stoimost » sous votre SLO.

• Compression Ratio (CR) = `raw_size / compressed_size`.
• Scan Cost ≈ bytes_scanned / throughput_storage + cpu_decode_time`.
• Total Cost = `storage_cost + compute_cost + egress_cost`.

2) Couches où vit la compression

1. Au niveau du format : Parquet/ORC/Avro (pages/strips/colonnes).
2. Au niveau encodage colonne : Dictionary, RLE, Delta, FoR/Bit-packing, Gorilla/XOR.
3. Au niveau du codec : ZSTD, Snappy, LZ4, Gzip.
4. Au niveau requête/moteur : vectorisation, passe de page (min/max), bloom/zone-map.
5. Au niveau du stockage : stockage tiered (hot/warm/cold), compaxing, page cache.

3) Les formats de colonne et leurs avantages

Parquet : pages par colonnes ; support des dictionnaires, RLE/Bit-packing, statisticien min/max et null-count.
ORC : strips avec index sur les strimes, filtres bloom ; efficace pour les longs scans.
Avro (row) : pratique pour les strim/logs, pire pour les scans analytiques.

Pratique : pour l'analyse par défaut, utilisez Parquet/ORC, incluez column stats et dictionary lorsque la cardinalité est faible/moyenne.

4) Encodages de colonnes (lossless)

Dictionary : remplace les valeurs par des indices (idéal pour une faible cardinalité).
RLE (Run-Length Encoding) : valeurs de → répétées (value, run). Bon pour les colonnes triées/groupées.
Delta/Delta-of-Delta : stocke les différences (nombres/temps).
FoR (Frame-of-Reference) + Bit-packing : valeur = base + offset ; offset emballé avec N bits.
Gorilla/XOR (Time-series) : stocke des XOR de valeurs voisines de longueur variable ; bon pour les métriques.
Nullable-bitmasks : un flux null's séparé augmente le CR.

Conseil : Le pré-regroupement/tri par clé de filtrage améliore considérablement RLE/zone-maps et CR.

5) Codecs à usage général

ZSTD : le meilleur CR avec un prix CPU modéré ; soutient les niveaux 1 à 22. Un choix universel.
Snappy : rapide, CR faible ; Convient aux données chaudes à haute fréquence de lecture.
LZ4 : encore plus rapide que Snappy, CR similaire ; souvent pour les strim/logs/caches.
Gzip/Deflate : CR élevé, prix CPU élevé ; rarement justifié en analyse interactive.

Règle : couche chaude - Snappy/LZ4, chaude/froide - ZSTD (niveau 3-7).

6) Séries chronologiques et logs

TSDB/OBD de colonne : Gorilla/XOR, Delta-RLE-Bitmap, Sparse-run pour les signaux rares.
Logs : JSON→Parquet + ZSTD ; normaliser les clés et les types (ne pas stocker « chaîne int »).
Downsampling et roll-ups (lossy) : stocker les agrégats le long des fenêtres (1m/5m/1h) dans une couche chaude ; Crus - dans le froid.
Structures de sketch : HLL (cardinalité), TDigest/KLL (quantili), CMS (fréquences) - compacts mais approximatifs.

7) Lossless vs Lossy (quand vous pouvez perdre la précision)

Lossless - rapports, finances, audit.
Lossy - surveillance, analyse A/B sur les grandes fenêtres, télémétrie (marquée explicitement !).
Contrôle de la qualité : définir l'erreur admissible (p. ex. P99 ± 0. 5 pp) et la vérifier à CI.

8) Lot, pages et compacts

Lots : par date/région/tenant, moins de scans →, mieux que CR.
Taille de page/strip : 64-256 Ko par page, 64-512 Mo par fichier - équilibre entre seek et CPU.
Compaxchn : Combiner les petits fichiers (petit fichier problème) - plus haut CR et vitesse.
Zone-maps/Bloom : accélérer les sauts de page ; efficace dans le tri par filtres.

9) Compression et cryptage/vie privée

Ordre des opérations : d'abord la compression, puis le cryptage. Sinon, CR ≈ 1.
TDE/at-rest n'interfère pas avec le CR (un bloc déjà compressé est crypté).
In-transit (TLS) n'affecte pas le format.
Le masquage/tokenization du PII avant compression maintient l'entropie contrôlée.
Attention avec le cryptage OPE/DET : peut dégrader le CR et/ou risquer la vie privée.

10) Coût et SLO (économie)

Stockage : moins d'octets → en dessous de $/TB-mo.
Compute : moins d'IO → plus rapide que le scan ; mais la décompression dépense le CPU.
Egress : moins d'octets → moins de trafic/temps de copie.
Compromis SLO : sélectionnez le codec/niveau pour que 'p95 _ latency' reste dans la fenêtre cible.

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) Pratiques pour les moteurs (ClickHouse/Snowflake/BigQuery/Redshift/Presto)

ClickHouse : CODEC 'et sur les colonnes (LZ4/ZSTD/DoubleDelta), ORDER BY pour RLE/scans, TTL/compacte.
Snowflake/BigQuery : automatisation des formats/clustering ; aidez le cluster par (date, tenant, clés de filtre).
Redshift/Presto/Trino : Parquet/ORC avec ZSTD, configuration 'hive. exec. compress. output ', statistiques et fractionnement des fichiers.

12) Piplines : où inclure la compression

Ingest : Batches compressées (ZSTD/LZ4) lors de l'écriture dans le lac.
Bou/DBT : créez des cibles de colonne avec le bon codec et le tri.
Serve/OLAP : représentations matérialisées avec un codec approprié ; Préagrégats pour les dashboards chauds.
Export: для CSV/JSON — gzip/zstd; mieux vaut donner Parquet.

13) Tests et validation

Profilage AB : un ensemble de requêtes → comparer p50/p95, bytes scanné, temps CPU, CR.
Kits Golden : Vérifiez l'exactitude après le transcodage/compaxe.
Région perf tests : alertes si p95 ↑> X % après changement de codec/niveau.
Règles DQ : les types/plages/taux NULL ne doivent pas changer lors du transfert.

14) Politiques de stockage et TTL

Tiered : hot (7-14 dn.) , warm (30-90 jours) , cold (≥180 dn.) .
Downsampling : au fur et à mesure du « refroidissement », stockez les agrégats/croquis au lieu du brut.
Pension/Legal Hold : ne supprimez pas les conflits avec la réglementation ; conservez les catalogues et les versions.

15) Anti-modèles

« Partout Gzip level 9 « : cher CPU, pas d'avantages.
Pas de tri/clustering : les mauvais RLE/zone-maps → les scans sont chers.
JSON comme format de stockage : pratique pour ingest, mauvais pour l'analyse.
Fichiers trop petits : gonflent les métadonnées/seek ; Le CR tombe.
Chiffrement avant compression : CR quasi nul.
Lossy sans marquage : abus de confiance et de déclaration.

16) Feuille de route pour la mise en œuvre

1. Discovery : profils de demandes/données, SLO et budgets.
2. MVP : Parquet + ZSTD/Snappy, tri/clustering de base, compaxing.
3. Tuning : niveaux ZSTD, tailles de page, cluster by, bloom/zone-maps.
4. Warm/Cold : stockage tiered, downsampling/croquis, politiques egress.
5. Hardening : tests de perf de régression, DQ, runbooks de transcodage.

17) Chèque-liste avant la sortie

• Format : Parquet/ORC ; les statistiques/dictionnaires sont inclus.
• Clustering par clé de filtrage ; lots par date/tenant.
• Codecs : hot = Snappy/LZ4, warm/cold = ZSTD (3-7) ; p95 est normal.
• La compacte est personnalisée ; pas de petits fichiers ; tailles cibles des fichiers/pages.
• Les ensembles DQ et golden sont verts ; types/plages conservées.
• Cryptage après compression ; Les PII sont masqués ; Retensh/Legal-hold sont respectés.
• Les régressions de perf sont surveillées ; alertes par p95/bytes scanné/CR.
• La documentation de la politique de stockage et des instructions de transcodage est prête.

18) Mini-modèles

sql create table if not exists analytics. sales_daily cluster by (event_date, tenant_id)
as select from {{ ref('sales_daily_view') }};
-- in model config: 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

Résultat : la compression des données analytiques n'est pas seulement un « encodage », mais une stratégie holistique : format correct, encodage des colonnes, tri et partitionnement, compactage et niveaux de stockage, respect du cryptage et SLO. Une conception intelligente permet de scanner plus rapidement, en dessous de la facture et des performances prévisibles - sans compromis dans la confiance dans les données.