Entendendo Parquet, Iceberg e o data lakehouse da BroadIn

Entendendo: Parquet, Iceberg e o data lakehouse da BroadIn

• Formas de armazenamento de dados (em arquivo e em memória)

  • Existem vários formatos de arquivo para acesso e armazenamento de dados
  • Alguns sistemas usam principalmente formatos de dados fechados, mas a maioria oferece suporte a formatos abertos
  • Os principais formatos de arquivo open source incluem Apache Avro, Parquet, ORC, Arrow, Feather, Protobuf etc.
  • Esses formatos fornecem especificações sobre como organizar os dados no layout binário real
  • Parquet oferece bom suporte a compressão, e Avro é adequado para ler blocos específicos de linhas
  • Oferecem suporte à evolução de esquema e à divisão de arquivos, algo essencial para processamento paralelo
  • É possível trabalhar com esses formatos em várias linguagens de programação e ferramentas

• Gerenciamento de dados em larga escala - Iceberg e Delta Lake

  • É necessário um modo de armazenar várias tabelas, evoluir esquemas individuais, particionar dados com eficiência e permitir que ferramentas externas leiam facilmente os esquemas
  • Hive, Iceberg e Delta Lake oferecem suporte a schema registry ou metastore
  • Iceberg e Delta Lake usam Parquet como formato de arquivo individual
  • Iceberg e Delta Lake não são mecanismos de consulta nem de armazenamento, e sim especificações abertas que permitem que mecanismos de consulta façam o trabalho
  • Tornam possíveis recursos como evolução de particionamento, evolução de esquema, compressão de dados, transações ACID, otimização eficiente de consultas e time travel

• O que são data lakes e data lakehouses?

  • Um data lake é onde as empresas armazenam grandes volumes de dados em formatos brutos, como arquivos OCR, Parquet ou CSV
  • Um data lakehouse é a combinação de recursos sobre um data lake que permite executar consultas SQL, configurar jobs em batch, definir governança de dados etc.
  • Um data lakehouse pode ser visto como uma versão de um data warehouse aberto
  • À medida que data warehouses como Snowflake e BigQuery passam a oferecer suporte a formatos de dados abertos como Iceberg, a fronteira entre data warehouses e data lakehouses está ficando menos nítida

Opinião do GN⁺

• Iceberg e Delta Lake desempenham um papel importante como camada de metadados para gerenciar grandes conjuntos de dados. Eles permitem gerenciamento eficiente dos dados e otimização de consultas, sendo úteis para cientistas e engenheiros de dados.
• Data lakehouses combinam as vantagens de data lakes e data warehouses, apresentando um novo paradigma para gerenciamento e análise de dados. Isso pode oferecer oportunidades para fortalecer ainda mais a tomada de decisão orientada por dados.
• Com o aumento do suporte ao Iceberg, espera-se que sistemas de gerenciamento e análise de dados se tornem gradualmente mais padronizados e interoperáveis. Isso deve trazer mais flexibilidade e eficiência na escolha e no uso de plataformas de dados.

[happing94]

Eu estava comparando Iceberg e Delta Lake, e ficou tudo organizado de forma bem clara assim. Minha visão e opinião eram quase iguais ao que está aqui. O benchmark executado online usou Spark, e embora o benchmark possa servir como referência, o Head of DevRel da Tabular escreveu que ele não tem grande significado. Para escolher como open source, parece que o iceberg é a única opção. O resumo é bom, mas seria ótimo se também houvesse links de referência.

[GN⁺]

Comentários no Hacker News

• Apache Iceberg e Delta Lake são frequentemente mencionados como formatos de tabela abertos, mas na prática há diferenças.

  • A especificação do formato de tabela do Apache Iceberg é clara o suficiente para que alguém familiarizado com sistemas de banco de dados não tenha grande dificuldade para construir e consultar tabelas Iceberg.
  • Já no caso da especificação do Delta Lake, é difícil entender o esforço necessário para implementar totalmente a especificação atual ou mantê-la continuamente atualizada.
  • A especificação do Delta Lake parece uma engenharia reversa da forma como a Databricks decidiu internamente implementar lakehouses para empresas Fortune 1000 decepcionadas com o Hadoop.
  • Não há muita confiança de que o Delta Lake realmente tenha valor como um ecossistema verdadeiramente aberto.

• No mundo dos bancos de dados, o fato de Delta, Iceberg e Hudi armazenarem dados em storage como o S3 em formatos open source representa uma grande mudança.

  • Isso significa que boa parte do storage e do processamento está sendo padronizada, facilitando a migração entre bancos de dados e permitindo que a maioria das ferramentas trabalhe com o mesmo conjunto de arquivos de forma transacionalmente estável.
  • Por exemplo, enquanto o Snowflake grava nos arquivos, um cientista de dados pode consultar os dados em tempo real em um notebook Jupyter, e o ClickHouse pode oferecer análises voltadas ao usuário sobre os mesmos dados.
  • Mesmo que uma empresa decida migrar de Snowflake para Databricks, isso não se torna um grande problema.
  • Hoje, consultar esses formatos no S3 ainda não é tão rápido quanto ingestão nativa, mas a pressão do mercado fará com que todos os fornecedores de banco de dados otimizem o desempenho.
  • É uma grande vitória para open source e abertura, permitindo que as empresas mantenham seus dados em formatos abertos e portáveis.
  • Os lakehouses também têm um impacto semelhante. Muitas empresas têm data lakes e data warehouses e precisam copiar dados entre os dois sistemas. Poder consultar o mesmo conjunto de dados e administrar apenas um sistema é igualmente importante.

• Já trabalho há anos com arquivos Parquet no S3, mas nunca entendi exatamente o que era o Iceberg. Ainda assim, esse artigo explica bem o Iceberg.

  • O Iceberg é um formato de metadados de banco de dados para o conjunto de dados subjacente, descrevendo esquema, particionamento etc.
  • Em um DBMS tradicional, esquema, mecanismo de consulta e formato de storage vêm como um único pacote.
  • Mas no big data, é possível construir os componentes do banco de dados do zero, misturando e combinando. Você pode usar Iceberg como formato de metadados, DuckDB como mecanismo de consulta, Parquet como formato de storage e S3 como meio de armazenamento.

• A melhor forma de salvar um dataframe Apache Arrow como arquivo em disco é usar Feather, mas também é possível convertê-lo para o formato Apache Parquet.

  • Para montar seu próprio lakehouse não JVM, você pode usar Iceberg como metadados, Parquet como dados, consultar com DuckDB usando tabelas Arrow e processar os dados via Arrow->Pandas ou Polars.
  • Se misturar Feather, a stack atual de lakehouse em Python não funciona.

• Já ouvi falar de data lake, mas "data lakehouse" soa como um lugar onde dados da elite vão pescar em barcos de dados durante o verão.

• Estou lidando com cerca de 100 TB de dados no GCP, usando BigQuery como mecanismo de consulta e particionamento Hive simples. Estou satisfeito por conseguir executar todas as consultas e pelo custo ser muito baixo, mas a latência é bem alta (embora isso não seja um grande problema na empresa).

  • Fico me perguntando se implementar Iceberg poderia melhorar isso. Alguém tem experiência com Iceberg?

• Estou muito empolgado com o Iceberg, mas da última vez que pesquisei, apenas a biblioteca do Spark era uma implementação, e o conector Iceberg do Trino dependia fortemente do Hive.

  • A indústria inteira está tendo dificuldade para se divorciar de tecnologias legadas como MapReduce, Hive e Spark.
  • Pretendo pesquisar Iceberg de novo e espero que essa área evolua. Hoje temos ferramentas e poder computacional para processar dados sem tecnologias legadas, e nem todo dado é big data.
  • Como resultado, "engenharia de dados" está se tornando cada vez mais parecida com desenvolvimento backend comum, e práticas gerais de desenvolvimento estão sendo aplicadas.
  • Espero muito que uma biblioteca Iceberg pura em Python apareça em breve.

• Há um questionamento sobre por que ninguém consegue explicar tudo isso de forma mais concreta. Seria preciso explicar como armazenar os dados, como conectar e consultar, e qual é a velocidade das consultas (em comparação com velocidade transacional versus velocidade "analítica").

• Em todos os benchmarks que vi online, o formato Delta Lake mostra desempenho muito melhor que o Iceberg.

  • A pergunta é se isso é algo fundamental da especificação ou se existe a possibilidade de o Iceberg reduzir essa diferença.

• Reconhece-se que o post do blog talvez não seja 100% abrangente nem o melhor ponto de partida para a maioria das pessoas.

  • Gosto da ideia de que a melhor maneira de aprender algo novo é explicá-lo novamente para outras pessoas, e comecei a aplicar isso também nas anotações do meu site.