Entendendo Parquet, Iceberg e Data Lakehouses
Equipes modernas de dados estão cada vez mais padronizando formatos abertos de tabela como Apache Iceberg, Delta Lake e Hudi sobre arquivos Parquet em object storage, com o objetivo de desacoplar armazenamento de mecanismos de consulta e evitar lock-in de fornecedor. Comentadores avaliam trade-offs entre Iceberg e Delta em termos de abertura, suporte do ecossistema (especialmente fora do JVM) e desempenho no mundo real, observando como grandes players como Snowflake, Microsoft e Google estão se alinhando a opções diferentes. Por trás dos detalhes dos formatos, muitos argumentam que os lakehouses basicamente reempacotam ideias clássicas de data warehouse (star schemas, ETL/ELT, governança) sobre armazenamento em nuvem mais barato, e que modelagem e qualidade de dados ainda importam muito mais do que o arquivo específico ou o formato de metadados escolhido.
O que os Novos Formatos de Tabela Fazem
- Parquet é amplamente visto como o armazenamento colunar de facto para data lakes; Iceberg/Delta/Hudi adicionam metadados no nível da tabela, evolução de esquema, particionamento e semântica ACID por cima.
- Isso desacopla componentes: por exemplo, S3 para armazenamento, Parquet para dados, Iceberg/Delta para metadados, DuckDB/Spark/Trino/Snowflake/BigQuery como mecanismos.
Abertura e Governança (Iceberg vs Delta vs Hudi)
- Iceberg é visto como um padrão aberto mais limpo e bem especificado; o spec do Delta é visto como complexo e fortemente acoplado à implementação da Databricks.
- Alguns argumentam que o Delta é apenas “nominalmente” aberto: mudanças no spec guiadas por um único fornecedor, alguns recursos retidos do open source.
- Ponto contrário: outros dizem que o Delta tem sido aberto o suficiente na prática por anos, e grandes players como a Microsoft estão apostando fortemente nele.
- Vários observam que Snowflake e BigQuery estão adicionando Iceberg (não Delta), interpretando isso como um sinal da neutralidade do Iceberg.
Ecossistema de Ferramentas e Linguagens
- Historicamente, Iceberg era centrado em Spark/Hadoop; suporte fora do JVM (PyIceberg, extensão do DuckDB) está chegando, mas ainda amadurecendo.
- Delta tem delta-rs para Python/Rust e é percebido como mais fácil fora do JVM hoje, embora sua origem e governança sejam debatidas.
- Trino removeu dependências de Hadoop/Hive; muitos veem o ecossistema avançando gradualmente além das antigas stacks de big data.
Data Lakes, Warehouses e Lakehouses
- Tema forte: os formatos são detalhes de implementação; o valor real vem da modelagem (por exemplo, star schemas), ETL/ELT e BI/relatórios.
- Data lakes sozinhos muitas vezes viram “pântanos”, com muitos dados brutos e poucos insights; lakehouses reintroduzem estrutura semelhante a tabelas e transações por cima de armazenamento barato em object storage.
- Alguns argumentam que a maioria das empresas nem precisa de lakes, dado o tamanho modesto dos dados e os sistemas relacionais existentes.
Performance, Custo e Portabilidade
- Formatos de tabela em object storage prometem armazenamento mais barato, neutro em relação ao fornecedor, e a capacidade de trocar mecanismos de consulta com menos lock-in.
- Vários destacam que consultar lakes/lakehouses geralmente é mais lento do que bancos de dados colunares feitos sob medida; aceitável para muitas análises, problemático para BI interativo.
- Fornecedores afirmam que pretendem fazer formatos de tabela abertos performarem perto do armazenamento nativo, mas questiona-se se abandonarão internals proprietários.
Formatos de Arquivo e Questões Práticas
- Feather vs Parquet: muitos preferem Parquet por ser mais futuro-prova e interoperável; usar Feather pode quebrar algumas stacks de lakehouse em Python.
- CSV é amplamente criticado por ser frágil; a adoção de Parquet é vista como um grande ganho prático.
- Formatos especializados como Lance e Zarr são mencionados para casos de uso de baixa latência ou multidimensionais, mas ainda são nicho em relação ao Parquet.