Compactação de dados analíticos

1) Por que comprimir dados analíticos

A compactação reduz o armazenamento e o tráfego, acelera o escâner com menos IO e melhor capacidade de armazenamento. Preço - CPU e (às vezes) dificuldade de atualização. O objetivo é otimizar o «» sob o seu 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) Camadas onde vive a compressão

1. Nível de formato: Parquet/ORC/Avro (páginas/strip/colunas).
2. No nível de encoding da coluna: Dictionary, RLE, Delta, FoR/Bit-packing, Gorilla/XOR.
3. Nível de codec: ZSTD, Snappy, LZ4, Gzip.
4. Nível de consulta/motor: vetorização, omissão de página (min/max), bloom/zona-map.
5. Nível de armazenamento: armazenamento tiered (hot/warm/cold), compacto, page cache.

3) Formatos invertebrados e suas vantagens

Parquet: páginas por coluna; suporte a dicionários, RLE/Bit-packing, estatístico min/max e null-count.
ORC: strip com índices em striptease, filtros bloom; Eficaz para longas raias.
Avro (row): Conveniente para strim/logs, pior para as raias analíticas.

Prática: Para analistas padrão, use Parquet/ORC, inclua column stats e dictionary onde a cardealidade é baixa/média.

4) Encodings de coluna (lossless)

Dictionary: substitui os valores por índices (ideal para baixa cardealidade).
RLE (Run-Length Encoding): valores de → repetidos (value, run). Bom para colunas triadas/clusterizadas.
Delta/Delta-of-Delta: armazena diferenças (números/hora).
FoR (Frame-of-Reference) + Bit-packing: valor = base + offset; offset empacotado com N bits.
Gorilla/XOR (Time-Series): armazena o XOR dos valores adjacentes com comprimento variável; Bom para as métricas.
Nullable-bitmaschi: fluxo de null 'ov separado aumenta CR.

Conselho: clusterização prévia/triagem por chave de filtragem melhora drasticamente RLE/zona-maps e CR.

5) Codecs de uso geral

ZSTD: melhor CR com preço moderado de CPU; suporta níveis 1-22. Escolha universal.
Snappy: CR rápido, baixo; adequado para dados quentes com alta taxa de leitura.
LZ4: ainda mais rápido que o Snappy, semelhante ao CR; muitas vezes para strim/logs/dinheiro.
Gzip/Deflate: CR alto, alto preço CPU; raramente absolvido num analista interativo.

Regra: camada quente - Snappy/LZ4, quente/frio - ZSTD (level 3-7).

6) Filas e logs temporários

TSDB/BB invertebrado Gorilla/XOR, Delta-RLE-Bitmap, Sparse-run para sinais raros.
Logi: JSON→Parquet + ZSTD; normalize chaves e tipos (não guarde «int de linha»).
Downsampling e roll-ups (lossy): armazene as máquinas por janelas (1m/5m/1h) em camada quente; crus, no frio.
Estruturas sketch: HLL (cardealidade), TDigest/KLL (Quantili), CMS (frequências) - compactos, mas aproximados.

7) Lossless vs Lossy (quando você pode perder precisão)

Lossless - relatórios, finanças, auditorias.
Lossy - monitoramento, A/B-analista em grandes janelas, telemetria (com marcação explícita!).
Controle de qualidade: defina uma margem de erro válida (por exemplo, P99 £0. 5 p.p.) e verificá-la na CI.

8) Particionamento, páginas e compacto

Partições: por data/região/tenante, menos raias, melhor CR.
Tamanho da página/stripe: 64-256 KB por página, 64-512 MB por arquivo - equilíbrio entre seek e CPU.
Compacto: junte arquivos pequenos (small files perfem) - acima de CR e velocidade.
Zona-maps/Bloom: acelera as passagens de página; Eficiência na triagem por filtro.

9) Compressão e criptografia/privacidade

Primeiro compactação, depois criptografia. Senão CR ≈ 1.
O TDE/at-rest não impede o CR (o bloco já comprimido).
In-transit (TLS) não afeta o formato.
A camuflagem/tocagem do PII antes da compressão mantém a entropia controlada.
Cuidado com a criptografia OPE/DER: pode piorar CR e/ou arriscar privacidade.

10) Custo e SLO (economia)

Armazenamento: menos bytes → abaixo de $/TB-mo.
Compute: menor do que o IO → mais rápido que o scan; mas a descompressão gasta CPU.
Egress: menos bytes → menos tráfego/tempo de cópia.
Compromisso SLO: Coloque o codec/nível para manter 'p95 _ latency' na janela de destino.

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) Práticas para motores (ClickHouse/Snowflake/BigQuery/Redshift/Presto)

ClickHouse: CODEC 'e em colunas (LZ4/ZSTD/DoubleDelta), ORDER BY para RLE/raias, TTL/compacto.
Snowflake/BigQuery: automação de formatos/clusterização; ajude cluster by (data, tenant, chave de filtro).
Redshift/Presto/Trino: Parquet/ORC com ZSTD, configuração 'hive. exec. compress. output ', estatísticas e divisão de arquivos.

12) Pipas: onde ligar compressão

Ingest: Batches comprimidos (ZSTD/LZ4) ao gravar em lake.
Transfer/DBT: Crie alvos invertebrados com o codec e a triagem desejados.
Serve/OLAP: Visualizações materializadas com codec adequado; Pré-regatas para dashboards quentes.
Export: для CSV/JSON — gzip/zstd; É melhor dar ao Parquet.

13) Testes e validação

Perfil AB: conjunto de solicitações → comparar p50/p95, bytes scanned, CPU time, CR.
Kits Golden: Verificação de correção após transcodificação/compasso.
Regressão perf testes: alerts, se p95 ↑> X% após mudança de codec/nível.
Regras DQ: tipos/intervalo/NULL-rate não devem ser alterados na transferência.

14) Políticas de armazenamento e TTL

Tiered: hot (7-14 dias) , warm (30-90 dias) , cold (≥180 dn.) .
Downsampling: À medida que «resfriar», armazene as unidades/esboços em vez de crude.
Retenção/Legal hold: Não remova conflitos regulatórios; guarde os diretórios e versões.

15) Antipattern

«Gzip level 9 em todo o lado «: CPU caro, sem benefícios.
Sem triagem/clusterização: RLE/zona-maps ruins → raios caros.
JSON como formato de armazenamento: conveniente para ingest, ruim para analistas.
Arquivos pequenos demais: inflam metadados/seek; O CR está a cair.
Criptografia antes da compressão: CR quase zero.
Lossy sem marcação: quebra de confiança e relatórios.

16) Mapa de trânsito de implementação

1. Discovery: perfis de pesquisa/dados, SLO e orçamentos.
2. MVP: Parquet + ZSTD/Snappy, triagem básica/clusterização, compactação.
3. Tuning: níveis de ZSTD, tamanho de página, cluster by, bloom/zona-maps.
4. Warm/Cold: tiered armazenamento, downsampling/desenhos, políticas egress.
5. Hardening: testes de perf, DQ, revestimento runbooks.

17) Folha de cheque antes do lançamento

• Formato: Parquet/ORC; estatísticas/dicionários incluídos.
• Clusterização por chave de filtragem; partitações por data/tenante.
• Codecs: hot = Snappy/LZ4, warm/cold = ZSTD (3-7); p95 está bem.
• O compacto está configurado; não há small files; tamanhos de destino de arquivos/páginas.
• DQ e golden kits são verdes; os tipos/faixas estão salvos.
• Criptografia após compressão; PII camuflados; Retensh/Legal-hold foram respeitados.
• As perf-regressão são monóticas; alertas p95/bytes scanned/CR.
• A documentação da política de armazenamento e instruções de transcodificação está pronta.

18) Mini-modelos

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

Resultado: compressão de dados analíticos não é apenas «incluir codec», mas uma estratégia integral: formato correto, encoding de colunas, triagem e particionamento, compactação e níveis de armazenamento, respeito à criptografia e SLO. O design adequado dá mais rapidez ao scan, conta mais baixa e produtividade previsível - sem comprometimento na confiança dos dados.