DP-900: cómo comprender formatos de datos y compresión en almacenes analíticos

Voy a enseñar la competencia: comprender formatos de datos (row vs column) y técnicas de compresión en cargas de trabajo analíticas en Azure. Esto es importante en el examen DP-900 porque demuestras conocimiento sobre rendimiento y costes en soluciones analíticas (por ejemplo, Azure Synapse, Azure Data Lake). En la práctica, elegir el formato y la compresión correctos reduce I/O, acelera las consultas y disminuye los costes de almacenamiento.

Qué necesitas saber

Existen dos modelos básicos para almacenar datos: row-based (por fila) y columnar (por columna). Bases de datos transaccionales usan normalmente row-based (ej.: OLTP) porque escriben/leen filas individuales. Cargas analíticas (OLAP) se benefician de formatos columnar porque las consultas agregan/recorren columnas específicas.

Formatos de archivo comunes en el entorno Azure/Data Lake:

• CSV/JSON: simples, row-oriented, sin compresión nativa (fáciles para ingestión, caros para análisis a gran escala).
• Parquet/ORC: columnar, optimizados para analytics, permiten compresión por columna, predicate pushdown y lectura parcial de columnas.
• Avro: row-oriented pero con esquema y compresión; bueno para mensajes y streaming.

La compresión reduce espacio y I/O. Hay dos tipos principales:

• Compresión por bloques/column-wise (p.ej., Snappy, Zlib, Zstandard): aplicada dentro de archivos columnar, muy eficiente para columnas con valores repetidos.
• Compresión de transporte (p.ej., Gzip): aplicada a archivos completos; buena para transferencia, menos eficiente en lectura analítica porque impide la lectura parcial.

Resultados prácticos: usar Parquet + compresión columnar (Snappy o Zstandard) suele reducir los datos leídos y mejorar la velocidad de las consultas en Synapse/Databricks/Power BI que consumen archivos en el Data Lake.

Cómo funciona en la práctica

Ejemplo práctico imaginario: tienes logs de telemetría con 50 columnas y 1 TB de datos en formato CSV. Una consulta analítica típica lee solo 4 columnas. Con CSV vas a leer archivos enteros (1 TB). Convirtiendo a Parquet con compresión, el tamaño puede caer a 100–200 GB y el motor leerá solo las columnas necesarias, reduciendo I/O y coste.

Flujo de transformación recomendado para Data Lake/analytics:

1. Ingiera los datos brutos (raw) tal como se reciben (CSV/JSON) en una zona raw en Azure Data Lake.
2. Realiza limpieza y transformación con una herramienta (Azure Data Factory, Synapse Pipelines, Databricks).
3. Escribe el resultado en Parquet/ORC con compresión adecuada en una zona curated/analytics.
4. Configura particionado (por ejemplo, data=YYYY-MM-DD) para reducir la cantidad de lectura y facilitar consultas por intervalo.

# Exemplo conceptual em PySpark: escrever Parquet com Snappy
df.write
  .mode('overwrite')
  .partitionBy('date')
  .option('compression','snappy')
  .parquet('/mnt/datalake/analytics/telemetry/')

Notas sobre opciones de compresión:

• Snappy: equilibrio entre compresión y velocidad; buen valor por defecto para Parquet en muchos motores.
• Zstandard (zstd): mejor compresión que Snappy con buena velocidad, útil cuando el almacenamiento es crítico.
• Gzip: alta compresión, pero costes en CPU e impide lectura parcial eficiente; se evita para análisis interactivo.

Errores comunes

1) Elegir CSV/JSON para datos analíticos de gran tamaño — aumenta I/O y costes. CSV/JSON son excelentes para ingestión pero no para consulta analítica a gran escala.

2) Compresión excesiva sin evaluar CPU — elegir códecs muy pesados (p.ej., Gzip al máximo) puede reducir espacio, pero aumentar la latencia en las consultas interactivas y el coste de CPU al descomprimir.

3) No particionar cuando procede — los archivos Parquet no lo solucionan todo: sin partición, incluso con columnar, puedes leer muchos archivos innecesarios. Particiona por campos usados frecuentemente en filtros (date, región, id_de_cliente cuando aplique).

Cómo practicar

Practica convirtiendo datos de ejemplo a Parquet y probando consultas en Synapse, Databricks o Azure Data Explorer (cuando esté soportado). Microsoft proporciona recursos oficiales para estudio: usa el Practice Assessment OFICIAL gratuito de Microsoft para DP-900 y la study guide oficial (ambos gratuitos) para validar conocimientos y ver el alcance de las skills measured. No uses dumps; recurre a estos recursos oficiales para prepararte.

Ejercicio práctico sugerido:

1. Carga un conjunto de datos abierto (p.ej., logs o dataset público) a un contenedor del Azure Data Lake.
2. Usa un notebook en Synapse o Databricks para leer el CSV, transformar y escribir Parquet particionado con Snappy.
3. Ejecuta dos consultas: una que lea varias columnas y otra que lea solo una columna; compara tiempos y bytes leídos.

En resumen

• Parquet/ORC (formatos columnar) son preferibles para cargas analíticas: reducen I/O y aceleran agregaciones.
• Elige códecs de compresión equilibrados (Snappy o Zstandard) para optimizar espacio y latencia.
• Particionado adecuado (por date/región) reduce lecturas innecesarias y mejora el rendimiento.
• Practica con los recursos oficiales de Microsoft: el Practice Assessment y la study guide gratuitos para DP-900.