Kompresja danych analitycznych

1) Dlaczego kompresja danych analitycznych

Kompresja zmniejsza pamięć masową i ruch, prędkości skanuje z mniejszą ilością IO i lepszym buforowaniem. Ceną jest procesor i (czasami) złożoność aktualizacji. Celem jest optymalne dla Twoich SLO 'ów „IO i CPU”.

• Współczynnik kompresji (CR) = 'raw _ size/ compressed_size'.
• Skanowanie kosztu bytes_scanned/ throughput_storage + cpu_decode_time'.
• Koszt całkowity = 'storage _ cost + compute_cost + egress_cost'.

2) Warstwy, w których żyje kompresja

1. Na poziomie formatu: Parkiet/ORC/Avro (strony/paski/kolumny).
2. Na poziomie kodowania kolumny: Słownik, RLE, Delta, FoR/Bit-packing, Gorilla/XOR.
3. Na poziomie kodeka: ZSTD, Snappy, LZ4, Gzip.
4. Na poziomie zapytania/silnika: wektoryzacja, pomijanie strony (min/max), bloom/zone-map.
5. Na poziomie pamięci masowej: magazyn wielopoziomowy (gorący/ciepły/zimny), kompresja, pamięć podręczna strony.

3) Formaty kolumn i ich zalety

Parkiet: strony kolumn; wsparcie słownika, RLE/Bit-packing, min/max statystyki i null-count.
ORC: paski z indeksami na strumieniach, filtry kwitnienia; skuteczne dla długich skanów.
Avro (wiersz): wygodne dla strumienia/dzienników, gorsze dla skanów analitycznych.

Praktyka: W przypadku domyślnej analizy należy użyć parkietu/ORC, w tym statystyk kolumn i słownika, w którym kardynalność jest niska/średnia.

4) Kodowania kolumn (bez strat)

Słownik-Zamienia wartości na indeksy (idealne do niskiej kardynalności).
RLE (Run-Length Encoding) - duplikat → wartości (wartość, uruchom). Dobre dla sortowanych/klastrowanych kolumn.
Delta/Delta-of-Delta: sklepy różnice (liczby/razy).
FoR (Frame-of-Reference) + Bit-packing: value = base + offset; offset jest zapakowany z N bitami.
Gorilla/XOR (Time-series): przechowuje XOR sąsiednich wartości o zmiennej długości; Dobre dla metryk.
Nieważne maski bitowe: oddzielny strumień jąder zwiększa CR.

Wskazówka: Sortowanie klucza wstępnego/filtrującego znacznie poprawia mapy RLE/strefy i CR.

5) Kodeki ogólnego przeznaczenia

ZSTD: najlepszy CR w umiarkowanej CPU; obsługuje poziomy 1-22. Uniwersalny wybór.
Snappy: szybki, niski CR; nadaje się do gorących danych o wysokiej częstotliwości odczytu.
LZ4: Snappy jeszcze szybciej, podobny CR; często - dla strumieni/dzienników/buforów.
Gzip/Deflate: wysoki CR, wysoka cena procesora; rzadko uzasadnione w interaktywnej analizie.

Zasada: gorąca warstwa - Snappy/LZ4, ciepło/zimno - ZSTD (poziom 3-7).

6) Serie czasowe i dzienniki

Bazy danych TSDB/kolumn: Gorilla/XOR, Delta-RLE-Bitmap, Sparse-run dla rzadkich sygnałów.
Dzienniki: JSON → Parkiet + ZSTD; normalizować klucze i typy (nie przechowywać "string int').
Downsampling i roll-up (lossy): przechowywanie jednostek przez okna (1m/5m/1h) w gorącej warstwie; surowe - na zimno.
Struktury szkiców: HLL (kardynalność), TDigest/KLL (kwantyle), CMS (częstotliwości) - kompaktowe, ale przybliżone.

7) Lossless vs Lossy (kiedy można stracić dokładność)

Bez strat - sprawozdawczość, finanse, audyt.
Lossy - monitoring, analityka A/B na dużych oknach, telemetria (z wyraźnym oznaczeniem!).
Kontrola jakości: ustawić tolerancję (np. P99 ± 0. 5 pp) i sprawdzić w CI.

8) Podział, strony i zagęszczenie

Strony: według daty/region/najemca → mniej skanów, lepsze CR.
Rozmiar strony/pasek: 64-256 KB na stronę, 64-512 MB na plik - równowaga między poszukiwaniem a procesorem.
Zagęszczenie: połączyć problem małych plików - powyżej CR i prędkości.
Mapy strefy/Bloom: przyspieszenie pominięć strony; skuteczne w sortowaniu przez filtry.

9) Kompresja i szyfrowanie/prywatność

Kolejność operacji: najpierw kompresja, potem szyfrowanie. W przeciwnym razie, CR ≤ 1.
TDE/at-rest nie zakłóca CR (już skompresowany blok jest zaszyfrowany).
Tranzyt (TLS) nie wpływa na format.
Maskowanie/tokenizacja PII przed kompresją zapewnia możliwość zarządzania entropią.
Ostrożność z szyfrowaniem OPE/DET: może degradować CR i/lub ryzykować prywatność.

10) Koszt i SLO (ekonomia)

Przechowywanie: mniej bajtów → mniej niż $/TB-mo.
Obliczenie: mniej IO → szybsze skany; ale dekompresja marnuje procesor.
Egress: mniej bajtów → niższy czas ruchu/kopiowania.
Kompromis SLO: dopasować kodek/poziom tak, że „p95 _ latency” pozostaje w oknie docelowym.

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) Praktyki w odniesieniu do silników (ClickHouse/Snowflake/Wózek/Redshift/Presto)

ClickHouse: CODEC'i na głośnikach (LZ4/ZSTD/اDelta), ORDER BY for RLE/scans, TTL/compression.
Płatek śniegu/ Query: format/automatyzacja klastrowania; pomoc klastra przez (data, lokator, klawisze filtrujące).
Redshift/Presto/Trino: Parkiet/ORC z ZSTD, ustawienie 'hive. wykonanie kompresji. wyjście ", statystyki i podział plików.

12) Rurociągi: gdzie należy włączyć kompresję

Połknięcie: skompresowane partie (ZSTD/LZ4) podczas pisania do jeziora.
Przekształcenie/DBT: tworzenie celów kolumn z żądanym kodekiem i sortowaniem.
Serve/OLAP: zmaterializowane widoki z odpowiednim kodekiem; kruszywa wstępne do desek rozdzielczych na gorąco.
Eksport: мла CSV/JSON - gzip/zstd; Lepiej dać Parkiet.

13) Badanie i walidacja

Profile AB: zestaw zapytań → porównaj p50/p95, skanowane bajty, czas CPU, CR.
Złote zestawy: kontrola poprawności po rekodowaniu/kompresji.
Testy perf regionu: wpisy, jeśli p95> X% po zmianie kodeka/poziomu.
Zasady DQ: typy/zakresy/NULL-rate nie powinny zmieniać się podczas przeładunku.

14) Polityka retencji i TTL

Wielopoziomowe: gorące (7-14 dni), ciepłe (30-90 dni), zimne (≥ 180 dni).
Downsampling: Jak „ochłodzić”, przechowywać jednostki/szkice zamiast surowe.
Zatrzymanie/Posiadanie prawa: nie usuwać konfliktów z przepisami; przechowywać katalogi i wersje.

15) Antypattery

„Wszędzie Gzip poziom 9 „: drogie procesor, bez korzyści.
Brak sortowania/klastrowania: zły RLE/zone-maps → drogie skany.
JSON jako format pamięci masowej: wygodny do spożycia, zły dla analityki.
Zbyt małe pliki: nadmuchiwać metadane/szukać; CR spada.
Szyfrowanie przed kompresją: Prawie zero CR.
Lossy nieoznakowane: naruszenie zaufania i odpowiedzialności.

16) Plan działania w zakresie wdrażania

1. Discovery: profile zapytań/danych, SLO i budżety.
2. MVP: Parkiet + ZSTD/Snappy, podstawowe sortowanie/klastrowanie, zagęszczenie.
3. Dostrajanie: poziomy ZSTD, rozmiary stron, klaster według, bloom/zone-maps.
4. Ciepło/zimno: magazyn wielopoziomowy, downsampling/szkice, polityka wyjścia.
5. Utwardzanie: testy perfu regresji, DQ, wykresówki transkodujące.

17) Lista kontrolna przed zwolnieniem

• Format: Parkiet/ORC; statystyki/słowniki zawarte.
• Klaster przez filtrowanie klawiszy; strony według daty/najemcy.
• Kodeki: gorący = Snappy/LZ4, ciepły/zimny = ZSTD (3-7); p95 jest normalne.
• Kompresja jest skonfigurowana; brak małych plików; docelowe rozmiary pliku/strony.
• DQ i złote zestawy są zielone; typy/zakresy zapisane.
• Szyfrowanie po kompresji; PII zamaskowane; zatrzymanie/legalne trzymanie przestrzegane.
• Kontrolowane są regresje perf; wpisy przez p95/bajty skanowane/CR.
• Polityka przechowywania i dokumentacja instrukcji transkodowania jest gotowa.

18) Mini szablony

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

Bottom line: kompresja danych analitycznych to nie tylko „włączanie kodeka”, ale holistyczna strategia: poprawny format, kodowanie kolumn, sortowanie i partycjonowanie, poziomy kompresji i pamięci masowej, poszanowanie szyfrowania i SLO. Inteligentna konstrukcja zapewnia szybsze skany, niższe liczenia i przewidywalną wydajność - bez uszczerbku dla zaufania do danych.