Komprimierung analytischer Daten

1) Warum analytische Daten komprimieren

Die Komprimierung reduziert Speicherplatz und Datenverkehr, beschleunigt Scans durch weniger IO und bessere Cache-Fähigkeit. Der Preis ist die CPU und (manchmal) die Komplexität der Updates. Das Ziel ist das optimale „IO↔CPU↔tochnost↔stoimost“ für Ihre SLOs.

• 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) Schichten, in denen Kompression lebt

1. Auf Formatebene: Parkett/ORC/Avro (Seiten/Stripes/Spalten).
2. Auf der Encoding-Ebene der Spalte: Dictionary, RLE, Delta, FoR/Bit-packing, Gorilla/XOR.
3. Auf Codec-Ebene: ZSTD, Snappy, LZ4, Gzip.
4. Auf der Abfrage-/Engine-Ebene: Vectoring, Seitensprung (min/max), bloom/zone-map.
5. Auf Speicherebene: tiered storage (hot/warm/cold), compaction, page cache.

3) Säulenformate und ihre Vorteile

Parkett: Seiten nach Spalten; Unterstützung für Wörterbücher, RLE/Bit-packing, min/max statistics und null-count.
ORC: Stripes mit Indizes auf Streams, Bloom-Filter; wirksam für lange Scans.
Avro (Zeile): bequem für Stream/Logs, schlechter für analytische Scans.

Übung: Verwenden Sie für Standardanalysen Parkett/ORC, aktivieren Sie column stats und dictionary, wenn die Kardinalität niedrig/mittel ist.

4) Codierung von Spalten (lossless)

Wörterbuch: Ersetzt Werte durch Indizes (ideal für niedrige Kardinalität).
RLE (Run-Length Encoding): sich wiederholende → (value, run). Gut für sortierte/gruppierte Spalten.
Delta/Delta-of-Delta: speichert die Differenzen (Zahlen/Zeit).
FoR (Frame-of-Reference) + Bit-packing: Wert = base + offset; offset ist mit N Bits gepackt.
Gorilla/XOR (Zeitreihe): speichert die XOR der benachbarten Werte mit variabler Länge; gut für Metriken.
Nullbare Bitmasks: Ein separater Null '-Stream erhöht den CR.

Tipp: Das Pre-Clustering/Sortieren nach Filterschlüsseln verbessert RLE/Zone-Maps und CR drastisch.

5) Allzweck-Codecs

ZSTD: bester CR bei moderatem CPU-Preis; unterstützt die Ebenen 1-22. Eine universelle Wahl.
Snappy: schneller, niedriger CR; geeignet für heiße Daten mit hoher Leserate.
LZ4: noch schneller Snappy, ähnlich CR; häufig - für Stream/Logs/Caches.
Gzip/Deflate: hoher CR, hoher CPU-Preis; selten in der interaktiven Analyse gerechtfertigt.

Regel: Heiße Schicht - Snappy/LZ4, warm/kalt - ZSTD (Level 3-7).

6) Zeitreihen und Protokolle

TSDB/column DB: Gorilla/XOR, Delta-RLE-Bitmap, Sparse-Run für seltene Signale.
Logs: JSON→Parquet + ZSTD; Schlüssel und Typen normalisieren (nicht „String int“ speichern).
Downsampling und Roll-ups (lossy): Speichern Sie die Aggregate nach Fenster (1m/5m/1h) in einer heißen Schicht; roh - in der Kälte.
Sketch-Strukturen: HLL (Kardinalität), TDigest/KLL (Quantile), CMS (Frequenzen) - kompakt, aber approximativ.

7) Lossless vs Lossy (wenn Sie die Genauigkeit verlieren können)

Lossless - Reporting, Finanzen, Wirtschaftsprüfung.
Lossy - Überwachung, A/B-Analyse an großen Fenstern, Telemetrie (mit expliziten Markierungen!).
Qualitätskontrolle: Stellen Sie den zulässigen Fehler ein (z. B. P99 ± 0. 5 PP) und überprüfen Sie es in CI.

8) Partizipation, Seiten und Kompositionen

Parties: nach Datum/Region/Tenant → weniger Scans, besser CR.
Seitengröße/Stripe: 64-256 KB pro Seite, 64-512 MB pro Datei - Balance zwischen Seek und CPU.
Compaction: Kombinieren Sie kleine Dateien (kleines Dateiproblem) - über CR und Geschwindigkeit.
Zone-Maps/Bloom: beschleunigen Seitenlücken; wirksam beim Sortieren nach Filtern.

9) Komprimierung und Verschlüsselung/Privatsphäre

Die Reihenfolge der Operationen: erst komprimieren, dann verschlüsseln. Der CR ≈ 1.
TDE/at-rest stört den CR nicht (der bereits komprimierte Block wird verschlüsselt).
In-transit (TLS) hat keinen Einfluss auf das Format.
Die Maskierung/Tokenisierung der PII vor der Kompression hält die Entropie beherrschbar.
Vorsicht bei OPE/DET-Verschlüsselung: Kann den CR beeinträchtigen und/oder die Privatsphäre gefährden.

10) Kosten und SLO (Wirtschaft)

Speicher: weniger Bytes → unter $/TB-mo.
Compute: Weniger IO → schnellere Scans aber Dekompression verschwendet CPU.
Egress: weniger Bytes → weniger Verkehr/Zeit Kopien.
SLO-Kompromiss: Codec/Level so anpassen, dass' p95 _ latency 'im Zielfenster bleibt.

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) Praktiken für Motoren (ClickHouse/Snowflake/BigQuery/Redshift/Presto)

ClickHouse: CODEC ™ und auf den Lautsprechern (LZ4/ZSTD/DoubleDelta), ORDER BY für RLE/Scans, TTL/Compaction.
Snowflake/BigQuery: Format-Automatisierung/Clustering; Hilfe cluster by (Datum, Tenant, Filterschlüssel).
Redshift/Presto/Trino: Parkett/ORC mit ZSTD, Einstellung 'hive. exec. compress. output', Statistiken und Dateitrennung.

12) Piplines: Wo man Kompression einschließt

Ingest: Komprimierte Batches (ZSTD/LZ4) beim Schreiben in einen See.
Transform/DBT: Erstellen Sie Säulenziele mit dem richtigen Codec und Sortierung.
Serve/OLAP: materialisierte Ansichten mit geeignetem Codec; Voreinheiten für heiße Dashboards.
Export: для CSV/JSON — gzip/zstd; Es ist besser, Parkett zu geben.

13) Prüfung und Validierung

AB-Profiling: Eine Reihe von Abfragen → p50/p95, Bytes gescannt, CPU-Zeit, CR verglichen werden.
Golden-Kits: Überprüfung der Korrektheit nach Transcodierung/Compacking.
Regression perf tests: Alerts, wenn p95 ↑> X% nach Codec/Level-Änderung.
DQ-Regeln: Typen/Bereiche/NULL-Rate darf sich beim Verschieben nicht ändern.

14) Aufbewahrungs- und TTL-Richtlinien

Tiered: heiß (7-14 Tage) , warm (30-90 Tage) cold (≥180 Tage) .
Downsampling: Wenn Sie „abkühlen“, speichern Sie die Einheiten/Skizzen anstelle von roh.
Retention/Legal Hold: Kollisionen mit Vorschriften nicht entfernen; Verzeichnisse und Versionen speichern.

15) Antipatterns

„Überall Gzip Level 9 „: teure CPU, kein Vorteil.
Keine Sortierung/Clustering: schlechte RLE/zone-maps → Scans sind teuer.
JSON als Speicherformat: praktisch für ingest, schlecht für Analytics.
Zu kleine Dateien: Aufblähen von Metadaten/seek; CR fällt.
Verschlüsselung vor Komprimierung: fast null CR.
Lossy ohne Kennzeichnung: Vertrauensbruch und Berichterstattung.

16) Fahrplan für die Umsetzung

1. Discovery: Anforderungs-/Datenprofile, SLOs und Budgets.
2. MVP: Parkett + ZSTD/Snappy, Basic Sorting/Clustering, Compaction.
3. Tuning: ZSTD-Level, Seitengrößen, Cluster by, bloom/zone-maps.
4. Warm/Kalt: Tiered Storage, Downsampling/Skizzen, Egress-Policies.
5. Hardening: Regressions-Perf-Tests, DQ, runbooks transcoding.

17) Checkliste vor Veröffentlichung

• Format: Parkett/ORC; Statistiken/Wörterbücher enthalten.
• Clustering durch Filterschlüssel; Parties nach Datum/Tenant.
• Codecs: hot = Snappy/LZ4, warm/cold = ZSTD (3-7); p95 ist normal.
• Compaction konfiguriert; keine kleinen Dateien; Zieldatei-/Seitengrößen.
• DQ und Golden-Sets grün; Typen/Bereiche werden gespeichert.
• Verschlüsselung nach der Komprimierung; PII sind maskiert; retention/Legal-hold eingehalten werden.
• Perf-Regressionen werden überwacht; alerts von p95/bytes scanned/CR.
• Die Dokumentation der Aufbewahrungsrichtlinie und der Umcodierungsanweisungen ist fertig.

18) Mini-Vorlagen

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

Fazit: Bei der Komprimierung analytischer Daten geht es nicht nur um „Enable Codec“, sondern um eine ganzheitliche Strategie: Das richtige Format, Codierung der Spalten, Sortierung und Partitionierung, Komprimierung und Speicherebenen, Respekt vor Verschlüsselung und SLO. Ein kompetentes Design sorgt für schnellere Scans, niedrigere Punktzahl und vorhersehbare Leistung - ohne Kompromisse beim Vertrauen in die Daten.