DP-900: como compreender formatos de dados e compressão em armazéns analíticos

Vou ensinar a competência: compreender formatos de dados (row vs column) e técnicas de compressão em cargas de trabalho analíticas no Azure. Isto é importante no exame DP-900 porque demonstras conhecimento sobre desempenho e custos em soluções analíticas (por exemplo, Azure Synapse, Azure Data Lake). Na prática, escolher o formato e a compressão certos reduz I/O, acelera queries e diminui custos de armazenamento.

O que precisas de saber

Existem dois modelos básicos para armazenar dados: row-based (por linha) e columnar (por coluna). Bases de dados transaccionais usam normalmente row-based (ex.: OLTP) porque escrevem/leem linhas individuais. Cargas analíticas (OLAP) beneficiam de formatos columnar porque queries agregam/varrem colunas específicas.

Formatos de ficheiro comuns no ambiente Azure/Data Lake:

• CSV/JSON: simples, row-oriented, sem compressão nativa (fáceis para ingestão, caros para análises de grande escala).
• Parquet/ORC: columnar, optimizados para analytics, permitem compressão por coluna, predicate pushdown e leitura parcial de colunas.
• Avro: row-oriented mas com esquema e compressão; bom para mensagens e streaming.

A compressão reduz espaço e I/O. Existem dois tipos principais:

• Compressão de blocos/column-wise (p.ex., Snappy, Zlib, Zstandard): aplicada dentro de ficheiros columnar, muito eficiente para colunas com valores repetidos.
• Compressão de transporte (p.ex., Gzip): aplicada a ficheiros inteiros; boa para transferência, menos eficiente em leitura analítica porque impede leitura parcial.

Resultados práticos: usar Parquet + compressão columnar (Snappy ou Zstandard) costuma reduzir os dados lidos e melhorar a velocidade das queries em Synapse/Databricks/Power BI que consomem ficheiros no Data Lake.

Como funciona na prática

Exemplo prático imaginário: tens logs de telemetria com 50 colunas e 1 TB de dados no formato CSV. Uma query analítica típica lê apenas 4 colunas. Com CSV vais ler ficheiros inteiros (1 TB). Convertendo para Parquet com compressão, o tamanho pode cair para 100–200 GB e o motor lerá apenas as colunas necessárias, reduzindo I/O e custo.

Fluxo de transformação recomendado para Data Lake/analytics:

1. Ingere os dados brutos (raw) tal como recebidos (CSV/JSON) numa zona raw no Azure Data Lake.
2. Faz limpeza e transformação com uma ferramenta (Azure Data Factory, Synapse Pipelines, Databricks).
3. Escreve o resultado em Parquet/ORC com compressão adequada numa zona curated/analytics.
4. Configura partição (por exemplo, data=YYYY-MM-DD) para reduzir a quantidade de leitura e facilitar queries 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 opções de compressão:

• Snappy: equilíbrio entre compressão e velocidade; bom predefinido para Parquet em muitos motores.
• Zstandard (zstd): melhor compressão que Snappy com boa velocidade, útil quando o armazenamento é crítico.
• Gzip: alta compressão, mas custos em CPU e impede leitura parcial eficiente; evita-se para análise interactiva.

Erros comuns

1) Escolher CSV/JSON para dados analíticos de grande dimensão — aumenta I/O e custos. CSV/JSON são óptimos para ingestão mas não para consulta analítica em larga escala.

2) Compressão excessiva sem avaliar CPU — escolher codecs muito pesados (p.ex., Gzip no máximo) pode reduzir espaço, mas aumentar a latência nas queries interactivas e o custo de CPU ao descomprimir.

3) Não particionar quando apropriado — ficheiros Parquet não resolvem tudo: sem partição, mesmo com columnar, podes ler muitos ficheiros desnecessários. Particiona por campos usados frequentemente em filtros (data, região, id_de_cliente quando aplicável).

Como praticar

Pratica convertendo dados de exemplo para Parquet e testando queries em Synapse, Databricks ou Azure Data Explorer (quando suportado). A Microsoft disponibiliza recursos oficiais para estudo: usa o Practice Assessment OFICIAL gratuito da Microsoft para DP-900 e a study guide oficial (ambos gratuitos) para validar conhecimentos e ver o âmbito das skills measured. Não uses dumps; recorre a estes recursos oficiais para te preparares.

Exercício prático sugerido:

1. Carrega um conjunto de dados aberto (p.ex., logs ou dataset público) para um contentor do Azure Data Lake.
2. Usa um notebook em Synapse ou Databricks para ler o CSV, transformar e escrever Parquet particionado com Snappy.
3. Executa duas queries: uma que lê várias colunas e outra que lê apenas uma coluna; compara tempos e bytes lidos.

Em resumo

• Parquet/ORC (formatos columnar) são preferíveis para cargas analíticas: reduzem I/O e aceleram agregações.
• Escolhe codecs de compressão equilibrados (Snappy ou Zstandard) para optimizar espaço e latência.
• Particionamento adequado (por data/região) reduz leituras desnecessárias e melhora a performance.
• Pratica com os recursos oficiais da Microsoft: o Practice Assessment e a study guide gratuitos para DP-900.