GH GambleHub

Compresión de datos analíticos

1) Por qué comprimir los datos analíticos

La compresión reduce el volumen de almacenamiento y el tráfico, acelera los escaneos mediante un IO más pequeño y una mejor capacidad de almacenamiento en caché. El precio es CPU y (a veces) la complejidad de las actualizaciones. El objetivo es optimizar «IO↔CPU↔tochnost↔stoimost» bajo sus SLO.

Métricas básicas:
  • 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) Capas donde vive la compresión

1. A nivel de formato: Parquet/ORC/Avro (páginas/stripes/columnas).
2. A nivel de encoding, columnas: Dictionary, RLE, Delta, FoR/Bit-packing, Gorilla/XOR.
3. A nivel de codec: ZSTD, Snappy, LZ4, Gzip.
4. A nivel de consulta/motor: vectorización, paso de página (min/max), bloom/zone-map.
5. En el nivel de almacenamiento: almacenamiento tered (hot/warm/cold), compactación, page cache.


3) Formatos de columna y sus ventajas

Parquet: páginas por columnas; soporte para diccionarios, RLE/Bit-packing, min/max statistics y null-count.
ORC: stripes con índices en streams, filtros de bloom; eficaz para escáneres largos.
Avro (row): conveniente para streaming/logs, peor para escaneos analíticos.

Práctica: para análisis predeterminado, use Parquet/ORC, incluya los estados de columna y dictionary donde la cardinalidad es baja/media.


4) Encoding de columnas (lossless)

Dictionary: reemplaza los valores por índices (ideal para una cardinalidad baja).
RLE (Encoding Run-Length): valores de → repetidos (value, run). Bueno para columnas ordenadas/agrupadas.
Delta/Delta-of-Delta: almacena diferencias (números/tiempo).
FoR (Frame-of-Reference) + Bit-packing: valor = base + offset; offset está lleno de N bits.
Gorilla/XOR (Time-series): almacena XOR de valores adyacentes con una longitud variable; Bueno para métricas.
Nullable-bitmasks: un flujo separado de null's aumenta CR.

Consejo: la preclasificación/clasificación por claves de filtrado mejora drásticamente los mapas RLE/zone-maps y CR.


5) Codecs de uso general

ZSTD: mejor CR a precio moderado CPU; soporta los niveles 1-22. Elección universal.
Snappy: CR rápido, bajo; adecuado para datos en caliente de alta frecuencia de lectura.
LZ4: aún más rápido Snappy, un CR similar; a menudo - para stream/logs/caches.
Gzip/Deflate: alto CR, alto precio CPU; rara vez se justifica en análisis interactivos.

Regla: capa caliente - Snappy/LZ4, caliente/frío - ZSTD (nivel 3-7).


6) Series temporales y registros

TSDB/BD de columna: Gorilla/XOR, Delta-RLE-Bitmap, Sparse-run para señales raras.
Registros: JSON→Parquet + ZSTD; normalice las llaves y los tipos (no almacene «string int»).
Downsampling y roll-ups (lossy): almacene las unidades por ventana (1m/5m/1h) en una capa caliente; crudo - en frío.
Las estructuras de Sketch: HLL (cardinalidad), TDigest/KLL (cuantili), CMS (frecuencias) son compactas pero aproximativas.


7) Lossless vs Lossy (cuando se puede perder la precisión)

Lossless - informes, finanzas, auditoría.
Lossy - monitoreo, análisis A/B en ventanas grandes, telemetría (con marcado explícito!).
Control de calidad: especifique un error válido (por ejemplo, P99 ± 0. 5 p.p.) y verificarlo en CI.


8) Partición, páginas y compactación

Lotes: por fecha/región/tenante → menos escáneres, mejor CR.
Tamaño de página/página: 64-256 KB por página, 64-512 MB por archivo - balance entre seek y CPU.
Compactación: combine archivos pequeños (pequeños archivos problem) - por encima de CR y velocidad.
Zone-maps/Bloom: aceleran los pases de página; son eficaces al ordenar por filtros.


9) Compresión y cifrado/privacidad

Orden de operaciones: primero compresión, luego cifrado. De lo contrario, CR ≈ 1.
El TDE/at-nat no interfiere con el CR (se cifra una unidad ya comprimida).
In-transit (TLS) no afecta al formato.
El enmascaramiento/tokenización PII antes de la compresión mantiene la entropía controlada.
Cuidado con el cifrado OPE/DET: puede empeorar CR y/o arriesgar la privacidad.


10) Costo y SLO (economía)

Almacenamiento: menos bytes → por debajo de $/TB-mo.
Compute: menos IO → escaneo más rápido; pero la descompresión gasta CPU.
Egress: menos bytes → menos tráfico/tiempo de copia.
Compromiso SLO: seleccione el codec/nivel para que 'p95 _ latency' permanezca en la ventana de destino.

Ejemplo de política (pseudo-YAML):
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ácticas para motores (ClickHouse/Snowflake/BigQuery/Redshift/Presto)

ClickHouse: CODEC 'y en altavoces (LZ4/ZSTD/DoubleDelta), ORDER BY para RLE/scans, TTL/compactación.
Snowflake/BigQuery: automatización de formatos/clustering; ayude a cluster by (fecha, tenant, llaves de filtro).
Redshift/Presto/Trino: Parquet/ORC con ZSTD, ajuste 'hive. exec. compress. output ', estadísticas y separación de archivos.


12) Pipelines: dónde habilitar la compresión

Ingest: batches comprimidos (ZSTD/LZ4) al escribir en el lago.
Transformación/DBT: cree objetivos de columna con el codec y la clasificación deseados.
Serve/OLAP: representaciones materializadas con el codec adecuado; pre-unidades para dashboards calientes.
Export: для CSV/JSON — gzip/zstd; es mejor darle a Parquet.


13) Pruebas y validación

Perfil AB: conjunto de consultas → comparar p50/p95, bytes scanned, tiempo CPU, CR.
Conjuntos de oro: Comprobación de la corrección después de la transcodificación/compaxia.
Repetsion perf tests: alertas si p95 ↑> X% después de cambiar el codec/nivel.
Reglas DQ: los tipos/rangos/NULL-rate no deben cambiar durante la encrucijada.


14) Políticas de retención y TTL

Tiered: hot (7-14 días) , warm (30-90 días). , cold (≥180 días). .
Downsampling: a medida que «se enfría», almacene los agregados/bocetos en lugar de los crudos.
Retention/Legal hold: no eliminar conflictos con las regulaciones; almacene directorios y versiones.


15) Antipattern

«Por todas partes el nivel Gzip 9 «: caro CPU, no hay beneficio.
Sin clasificación/clustering: los malos RLE/zone-maps → escaneados son caros.
JSON como formato de almacenamiento: conveniente para ingest, malo para analítica.
Archivos demasiado pequeños: inflan los metadatos/seek; CR está cayendo.
Cifrado a compresión: casi cero CR.
Lossy sin etiquetado: violación de confianza e informes.


16) Hoja de ruta para la implementación

1. Discovery: perfiles de consulta/datos, SLO y presupuestos.
2. MVP: Parquet + ZSTD/Snappy, Clasificación/Clusterización Básica, Compactación.
3. Tuning: niveles ZSTD, tamaños de página, cluster by, bloom/zone-maps.
4. Warm/Cold: tiered storage, downsampling/sketches, egress policy.
5. Hardening: pruebas de regresión, DQ, runbooks de transcodificación.


17) Lista de verificación antes del lanzamiento

  • Formato: Parquet/ORC; estadísticas/diccionarios incluidos.
  • Clustering por claves de filtrado; lotes por fecha/tenante.
  • Codecs: hot = Snappy/LZ4, warm/cold = ZSTD (3-7); p95 es normal.
  • Compactación personalizada; No hay archivos pequeños; tamaños de archivo/página de destino.
  • Los conjuntos DQ y golden son verdes; tipos/rangos guardados.
  • Cifrado después de la compresión; PII enmascarados; Retiro/Legal-hold respetado.
  • Las regresiones de perfume se monitorizan; alertas por p95/bytes scanned/CR.
  • La documentación de la política de retención y las instrucciones de transcodificación está lista.

18) Mini plantillas

DBT (tabla de Parquet con ZSTD y clústeres):
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
Política de Compakshna (pseudo):
yaml compaction:
target_file_mb: 256 small_file_threshold_mb: 32 schedule: "hourly"
Configuración de descarga (pseudo):
yaml timeseries:
raw:  keep: 14d rollup_1m: keep: 90d rollup_1h: keep: 365d rollup_1d: keep: 1825d

En pocas palabras: la compresión de los datos analíticos no es solo una estrategia holística: formato correcto, encoding de columnas, clasificación y partición, compactación y niveles de almacenamiento, respeto al cifrado y SLO. Un diseño competente ofrece un escaneo más rápido, una puntuación inferior y un rendimiento predecible, sin comprometer la confianza en los datos.

Contact

Póngase en contacto

Escríbanos ante cualquier duda o necesidad de soporte.¡Siempre estamos listos para ayudarle!

Iniciar integración

El Email es obligatorio. Telegram o WhatsApp — opcionales.

Su nombre opcional
Email opcional
Asunto opcional
Mensaje opcional
Telegram opcional
@
Si indica Telegram, también le responderemos allí además del Email.
WhatsApp opcional
Formato: +código de país y número (por ejemplo, +34XXXXXXXXX).

Al hacer clic en el botón, usted acepta el tratamiento de sus datos.