Escolher um formato de tabela de dados

Os engenheiros de dados enfrentam uma decisão crítica no início de cada pipeline de dados: qual formato de tabela deve armazenar seus dados? Essa opção afeta o desempenho da consulta, a confiabilidade da transação, a interoperabilidade com outras plataformas e a manutenção de longo prazo da arquitetura do lakehouse.

O Azure Databricks dá suporte a vários formatos de armazenamento, cada um projetado para cenários diferentes. Entender suas diferenças ajuda você a selecionar o formato certo para seus requisitos específicos.

Entender formatos de arquivo versus formatos de tabela

Antes de comparar opções, é importante distinguir entre formatos de arquivo e formatos de tabela. Um formato de arquivo como Parquet, CSV ou JSON define como os dados são armazenados fisicamente no disco. Um formato de tabela como Delta Lake ou Apache Iceberg se baseia em formatos de arquivo adicionando uma camada de metadados que rastreia transações, alterações de esquema e locais de arquivo de dados.

Tanto o Delta Lake quanto o Apache Iceberg usam Parquet como formato de arquivo subjacente. A principal diferença está na camada de metadados que permite recursos avançados, como transações ACID, viagem no tempo e evolução do esquema.

Como o Parquet armazena dados de forma diferente

O Parquet usa armazenamento colunar em vez de armazenamento baseado em linha. Essa diferença fundamental afeta significativamente o desempenho da consulta analítica.

Em formatos baseados em linha, como CSV, os dados são organizados por registro. Ler uma única coluna requer a verificação de todas as linhas do arquivo. Em formatos colunais como Parquet, os dados de cada coluna são armazenados juntos. Quando uma consulta precisa apenas de colunas específicas, Parquet lê apenas essas colunas e ignora totalmente o restante.

Parquet organiza dados em grupos de linhas, cada um contendo blocos de coluna. Cada parte de coluna armazena estatísticas, incluindo valores mínimos e máximos para esse segmento de dados. Quando você executa uma consulta com uma condição de filtro, o mecanismo de consulta verifica essas estatísticas primeiro. Se o valor do filtro estiver fora do intervalo mínimo/máximo de um grupo de linhas, o mecanismo ignorará a leitura da seção inteira.

Essa abordagem columnar fornece duas técnicas de otimização que melhoram drasticamente o desempenho da análise:

• Remoção de coluna: o mecanismo só lê as colunas que sua consulta referencia, reduzindo muito a E/S.
• Pushdown de predicado: as condições de filtro são avaliadas com base em estatísticas de colunas antes de ler os dados, ignorando totalmente os grupos de linhas irrelevantes.

Para cargas de trabalho analíticas que costumam acessar um subconjunto de colunas em muitas linhas, o Parquet supera significativamente formatos baseados em linhas.

Delta Lake como o formato padrão

Delta Lake é o formato de armazenamento padrão para todas as tabelas no Azure Databricks. Quando você cria uma tabela sem especificar um formato, o Azure Databricks usa automaticamente o Delta Lake.

O Delta Lake estende arquivos Parquet com um log de transações que registra todas as alterações na sua tabela. Esse log habilita vários recursos que o Parquet sozinho não fornece:

• Transações ACID: vários leitores e gravadores simultâneos podem acessar a mesma tabela sem corrupção de dados. Cada transação é concluída inteiramente ou não tem efeito.

• Viagem no tempo: consulte versões anteriores da tabela usando carimbos de data/hora ou números de versão. Reverter as alterações, se necessário.

• Aplicação e evolução de esquema: a tabela valida dados de entrada em relação ao esquema definido, evitando que dados corrompidos ou incompatíveis entrem no lakehouse. Quando os requisitos são alterados, você pode adicionar novas colunas, modificar tipos de dados ou renomear colunas sem reescrever dados existentes.

• Lote unificado e streaming: Use a mesma tabela como fonte de lote e como fonte ou destino de streaming.

O Delta Lake integra-se profundamente à plataforma do Azure Databricks. Recursos como agrupamento líquido e otimização preditiva estão disponíveis para tabelas Delta Lake e Apache Iceberg gerenciadas no catálogo do Unity. Change Data Feed é, no entanto, específico do Delta Lake e depende de seu log de transações.

Para a maioria dos cenários no Azure Databricks, o Delta Lake é a opção recomendada. Ele fornece os benefícios de desempenho do Parquet com garantias transacionais que os sistemas de dados de produção exigem.

Apache Iceberg para cenários multiplataforma

O Apache Iceberg é um formato de tabela aberta alternativo que o Azure Databricks dá suporte a tabelas gerenciadas e estrangeiras. Assim como o Delta Lake, o Iceberg fornece transações ACID, evolução de esquema e recursos de viagem no tempo desenvolvidos com base em arquivos Parquet.

A estrutura lógica hierárquica e bem definida do Iceberg a torna altamente flexível, suportando escalabilidade e otimizações avançadas. Ele dá suporte à remoção de manifesto, estatísticas em nível de arquivo, particionamento oculto e evolução de partição.

O principal motivo para escolher Iceberg é a interoperabilidade. Iceberg é amplamente adotado em todo o ecossistema de dados, incluindo plataformas como Snowflake, Amazon Athena, Trino, Apache Spark e Apache Flink. Se sua organização executar cargas de trabalho em várias plataformas que precisam ler e gravar as mesmas tabelas, o Iceberg fornecerá um formato comum que todas as plataformas entendem.

O Catálogo do Unity pode gerenciar as tabelas do Iceberg diretamente, permitindo que o Azure Databricks atenda como um catálogo do Iceberg para mecanismos externos. Você também pode ler tabelas Iceberg gerenciadas por outros catálogos, como AWS Glue ou Snowflake Horizon Catalog, usando conexões de tabelas externas.

Considere o Iceberg quando:

• Seus dados precisam ser acessados por vários mecanismos de processamento fora do Azure Databricks.
• Sua organização tem padronizado o Iceberg para compartilhamento de dados entre plataformas.
• Você está se integrando a sistemas que não dão suporte ao Delta Lake.

Para cargas de trabalho executadas principalmente no Azure Databricks, o Delta Lake continua sendo o formato recomendado devido a seus recursos mais profundos de integração e otimização de plataforma.

Quando os formatos baseados em linha se aplicam

CSV e JSON permanecem opções válidas para cenários específicos, embora sejam menos eficientes para análise em larga escala.

Use CSV ou JSON quando:

• Você estiver recebendo dados de sistemas externos nesses formatos como uma zona de destino inicial.
• Você precisa de dados legíveis por humanos para depuração ou inspeção rápida.
• Você está se integrando a sistemas que dão suporte apenas a formatos baseados em texto.
• Os volumes de dados são pequenos o suficiente para que as diferenças de desempenho sejam insignificantes.

Para armazenamento persistente de dados analíticos, converta arquivos CSV ou JSON de entrada em tabelas Delta Lake durante a ingestão. Essa conversão captura os ganhos de eficiência do armazenamento columnar ao adicionar garantias transacionais.

Aplicar critérios de decisão

Selecionar um formato de tabela depende de seus requisitos específicos. Comece com o Delta Lake como sua opção padrão e, em seguida, avalie as alternativas somente quando restrições específicas exigirem.

Sua escolha também depende dos padrões organizacionais. Se sua equipe de arquitetura tiver estabelecido convenções para formatos de tabela, alinhe-se com essas decisões para manter a consistência em sua plataforma de dados.