Entendendo Parquet, Iceberg e data lakehouses

• As tecnologias de armazenamento de dados não formam um bloco único, mas se dividem em camadas diferentes, como formatos de arquivo, formatos em memória, camadas de metadados de tabela e arquiteturas de lakehouse
• Avro, Parquet, ORC e Arrow são formatos que definem o layout binário dos dados; o Parquet é forte em compressão colunar e processamento analítico, enquanto o Avro é mais adequado para processamento orientado a linhas
• Iceberg e Delta Lake não são formatos de arquivo, mas sim camadas superiores de metadados que permitem o gerenciamento de tabelas em grande escala sobre arquivos como Parquet
• Um data lakehouse é uma abordagem que adiciona recursos de warehouse como consultas SQL, jobs em lote e governança sobre arquivos brutos em armazenamentos como o S3
• Até warehouses como Snowflake e BigQuery estão passando a oferecer suporte a formatos abertos como Iceberg, e a fronteira entre data warehouse e lakehouse está ficando cada vez mais difusa

---

Diferença entre formato de arquivo e formato em memória

• Os formatos open source que tornam o armazenamento e o acesso a dados mais eficientes diferem entre si no modo de armazenamento e no local de uso
  • Apache Avro: binário, armazenamento em linhas (rowstore), arquivo
  • Apache Parquet: binário, armazenamento em colunas (columnstore), arquivo
  • Apache ORC: binário, armazenamento em colunas, arquivo
  • Apache Arrow: binário, armazenamento em colunas, memória
  • Protocol Buffers: linguagem neutra em relação à linguagem de programação para definição de estruturas de dados, e dependendo da implementação pode variar entre armazenamento em linhas ou em colunas
  • CSV: baseado em texto e com estrutura muito simples
• Ao salvar um DataFrame do Apache Arrow em um arquivo no disco, normalmente usa-se Feather, embora também seja possível convertê-lo para outros formatos, como Parquet
• Sistemas como Snowflake, Redshift, Athena e Hive oferecem suporte para leitura e escrita de formatos abertos e formatos de armazenamento proprietários, mas o alcance do suporte a formatos abertos pode variar entre os produtos

O que um formato realmente define

• Um formato de arquivo é uma especificação que determina como os dados são organizados no arranjo binário real
• O Parquet é forte em compressão, enquanto o Avro, por usar armazenamento em linhas, é mais adequado para ler blocos de linhas específicos
• Tanto Parquet quanto Avro oferecem suporte a evolução de esquema, permitindo modificar o esquema de novos dados sem reescrever todos os dados antigos
• Ambos os formatos também oferecem suporte a divisão de arquivos, algo importante para processamento paralelo de dados
• O repositório do Apache Parquet inclui a especificação real do formato de arquivo e uma implementação de referência em Java
• O Parquet pode ser lido e gravado por várias linguagens e ferramentas, e no Pandas também é possível salvar um DataFrame em um arquivo Parquet local com to_parquet
• Presto/Trino, Spark, DuckDB, Hive, Dremio, Impala, AWS Athena e Apache Drill são exemplos de engines capazes de trabalhar com arquivos Parquet

Por que só o formato de arquivo não basta para gerenciar grandes volumes de dados

• Um formato de arquivo individual define apenas o layout de um único arquivo, então não é suficiente para gerenciar conjuntos de dados grandes e em constante mudança
• Para armazenar muitas tabelas, evoluir o esquema de cada tabela, consultar estados em pontos no tempo, particionar com eficiência, permitir que ferramentas externas leiam esquemas e guardar estatísticas para otimização de consultas baseada em custo, é necessária uma camada superior
• Essa camada inclui um formato de tabela e um registro de esquemas ou metastore
• O Confluent Schema Registry oferece suporte a Avro e Protobuf, sendo mais adequado para dados de streaming que tendem ao armazenamento em linhas

Onde entram Hive, Iceberg e Delta Lake

• O Facebook lançou o Hive em 2009 junto com seu próprio formato de metadados de tabela, e depois o Hive passou a suportar vários formatos
• A Netflix desenvolveu o Iceberg para superar limitações de desempenho e escalabilidade do Hive
• A Databricks desenvolveu o Delta Lake como alternativa ao Iceberg e depois o publicou como open source
• Tanto Iceberg quanto Delta Lake usam Parquet como formato de arquivo individual
• Hive, Delta Lake e Iceberg oferecem conceitos equivalentes a registro de esquemas ou metastore
  • O HMS (Hive MetaStore) do Hive pode usar praticamente qualquer RDBMS
  • O Iceberg tem os Iceberg Catalogs
  • A Databricks tem o Unity Catalog
• Esses catálogos e metastores também podem ser usados para governança de dados, administrando quais equipes ou usuários podem acessar quais tabelas

Funções assumidas por Iceberg e Delta Lake

• Delta Lake e Iceberg não são engines de consulta nem engines de armazenamento em si, mas especificações abertas que permitem o funcionamento de engines de consulta
• Ambos resolvem o mesmo problema de maneiras diferentes, e há debate sobre abertura porque o Delta Lake tem menor diversidade de contribuidores do que o Iceberg
• O suporte ao Iceberg está crescendo rapidamente em vários data warehouses e lakehouses, como Redshift, BigQuery, Snowflake, Athena e Dremio
• Iceberg e Delta Lake oferecem os recursos necessários para operar tabelas em grande escala
  • particionamento
  • evolução de esquema
  • compressão de dados
  • transações ACID para alterações de esquema
  • otimização eficiente de consultas por meio de column pruning, pushdown de predicados e coleta de estatísticas
  • time travel para consultas em pontos no tempo
• O Iceberg oferece suporte a evolução de partições, permitindo mudar o método de particionamento da tabela ou a chave de shard sem reescrever todos os dados existentes
• Na Netflix, mudanças de particionamento eram uma grande dor, e esse foi um dos motivos para a criação do Iceberg

Formatos proprietários e a pressão por suporte ao Iceberg

• A especificação do Iceberg está ganhando popularidade rapidamente como formato suportado por vários sistemas
• Produtos que usam formatos proprietários sofrem pressão para manter o máximo de desempenho possível em seus próprios formatos e, ao mesmo tempo, oferecer suporte de alguma forma ao Iceberg ou ao Delta Lake
• O Iceberg pode se tornar um recurso de checklist que todo sistema de banco de dados acabará precisando suportar
• Por questões de desempenho, pode ser difícil para o Iceberg substituir completamente formatos de dados proprietários
• Quando um formato de dados é desenvolvido para apenas uma única engine de consulta, os desenvolvedores de banco de dados conseguem extrair máxima eficiência e inovar mais rapidamente

Data lake e data lakehouse

• Um data lake é onde a empresa armazena grandes volumes de dados na forma de arquivos brutos como Parquet e CSV
• Um data warehouse armazena dados de maneira mais estruturada, como tabelas SQL com esquema e esquemas de banco de dados
• Um data lakehouse combina ao data lake recursos como execução de consultas SQL, jobs em lote e configuração de governança de dados
• Com Iceberg, uma engine de consulta e outros componentes adicionais, é possível construir um data lakehouse sobre um data lake
• No passado, para ter esses recursos era preciso adotar um data warehouse ou um DBMS mais tradicional
• Um data lakehouse usa um blob store em nuvem como HDFS ou S3 como local de armazenamento de todos os dados, e otimiza a engine de consulta para operar rapidamente sobre esse armazenamento
• Databricks e Dremio são exemplos de produtos de data lakehouse
• À medida que warehouses como Snowflake e BigQuery adicionam formatos de dados abertos como Iceberg, a distinção entre data warehouse e data lakehouse fica ainda mais ambígua

[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⁺]

Opiniões no Hacker News

• Embora Apache Iceberg e Delta Lake sejam frequentemente agrupados como formatos de tabela abertos (Open Table Format), na prática parecem bem diferentes
  A especificação do Iceberg está em https://iceberg.apache.org/spec/, e alguém que conheça sistemas de banco de dados parece conseguir, sem grande dificuldade, criar uma implementação para construir e consultar tabelas Iceberg a partir dela
  Já no caso do Delta Lake, a especificação fica em https://github.com/delta-io/delta/blob/master/PROTOCOL.md, mas é difícil até estimar o volume de trabalho necessário para implementar completamente a especificação atual, e mais desanimador ainda acompanhar essa especificação enorme e em constante mudança
  Sinceramente, a especificação do Delta Lake parece um documento que fez engenharia reversa dos compromissos de implementação surgidos enquanto a Databricks construía rapidamente lakehouses para empresas Fortune 1000 traumatizadas pelo Hadoop
  Ainda não estou convencido de que adotar Delta Lake seja realmente entrar em um ecossistema aberto, e seria bom ter alguma base tranquilizadora sobre isso
  Além disso, o histórico no GitHub também não inspira confiança: https://github.com/delta-io/delta/commits/master/PROTOCOL.md
  Parece um fluxo em que recursos e correções arbitrários entram por PRs de engenheiros da Databricks e são aprovados logo em seguida por engenheiros seniores da Databricks

  • Concordo com tudo. A Databricks até tem o direito de deixar recursos como Bloom filter deliberadamente fora do Delta open source
    Mas, fazendo isso, não dá para dizer que é um formato aberto conduzido pela comunidade. A não ser que seja uma versão à la Animal Farm de “alguns lados são mais iguais que outros”
  • Implementei suporte a Delta do zero em um componente do Microsoft Fabric e senti que a “especificação” por si só é bastante insuficiente se você não fizer experimentos adicionais com a implementação do Spark
    Para usar recursos como colunas calculadas ou restrições de verificação, também é preciso dar suporte a expressões Spark SQL, e a documentação desse lado é ainda mais fraca
  • Também tenho a mesma impressão. Sou extremamente cauteloso com tudo o que a Databricks oferece
    Acho que é algo próximo de open source só no nome e que não deve ser confiado
    Também usei Delta Lake, e no uso real havia muitas limitações frustrantes e arestas afiadas. No fim, cancelamos completamente aquele projeto e, na época, também investiguei o Iceberg
    Iceberg e Hudi tinham um conjunto de recursos projetado de forma mais consistente, mas recebiam menos suporte; espero que isso melhore daqui para frente
  • Eu vinha acompanhando essa área havia um ou dois anos e me perguntava por que Iceberg era mais popular no open source; essa explicação ajuda
    Nos últimos seis meses, tive a impressão de que o Iceberg tinha dificuldade em oferecer ferramentas para usuários fora do ecossistema JVM, enquanto o Delta estava à frente. Nesse aspecto, o Delta é muito mais acessível
  • Usar JSON para alterações do Delta é realmente uma estupidez
    Para comparar, no SQL Server isso é implementado de forma muito melhor. As tabelas de armazenamento colunar (columnstore indexes, o equivalente interno do mecanismo a Parquet/ORC) são imutáveis, e o delta é armazenado em uma B-Tree para compressibilidade, acessibilidade e velocidade
    Em algum momento, o armazenamento colunar é desfragmentado, mesclado e reconstruído parcial ou totalmente, e a B-Tree é apagada e recomeça conforme novas alterações se acumulam
    Fazer isso com JSON é, para dizer o mínimo, sinal de uma época ruim
    Qualquer coisa parece melhor que Delta Lake, e Iceberg em especial parece melhor

• Bom texto. Trabalho há anos com arquivos Parquet sobre S3, mas não sabia exatamente o que era Iceberg; o artigo explica bem
  Iceberg é um formato de metadados de banco de dados que descreve o schema e o particionamento do conjunto de dados subjacente, entre outras coisas
  A maioria usa convenções de particionamento Hive como /key3=000/key2=002/, mas o Iceberg vai além ao expor mais estrutura ao mecanismo de consulta
  Em um DBMS tradicional como o Postgres, o schema, o mecanismo de consulta e o formato de armazenamento vêm em um único pacote
  Mas, em big data, você pode montar os componentes de banco de dados do zero e combiná-los entre si. Dá para usar Iceberg como formato de metadados, DuckDB como mecanismo de consulta, Parquet como formato de armazenamento e S3 como meio de armazenamento

• É uma grande mudança no mundo dos bancos de dados. Graças a Delta, Iceberg e Hudi, os dados geralmente ficam armazenados em formatos open source sobre o S3
  Quando boa parte do armazenamento e do processamento é padronizada, fica mais fácil migrar entre bancos de dados, e praticamente todas as ferramentas acabam conseguindo lidar com o mesmo conjunto de arquivos de forma transacionalmente segura
  Por exemplo, enquanto o Snowflake grava nos arquivos, um cientista de dados pode consultá-los em tempo real em um Jupyter notebook, e o ClickHouse pode oferecer análises para usuários sobre os mesmos dados mantendo garantias de consistência
  Depois, se a empresa decidir trocar Snowflake por Databricks, isso deixa de ser um problema tão grande
  Hoje, consultar esses formatos no S3 ainda não é tão rápido quanto o carregamento nativo, mas a pressão do mercado vai forçar todos os fornecedores de bancos de dados a otimizar desempenho e, no fim, isso deve se aproximar da performance dos dados carregados nativamente
  É uma grande vitória para abertura e open source, e para o fato de empresas manterem seus dados em formatos abertos e portáveis
  Lakehouses têm as mesmas implicações. Muitas empresas mantêm tanto um data lake quanto um data warehouse, e acabam copiando dados entre os dois
  Ter apenas um sistema para consultar e gerenciar o mesmo conjunto de dados também tem um impacto enorme
  É um momento muito interessante para estar na área de engenharia de dados

  • Apache Arrow e Substrait vêm trabalhando para tornar essa realidade possível
    No futuro, dá para ver planos de execução de consultas sendo enviados não só para vários engines em toda a nuvem, mas também para máquinas locais
  • A suposição de que todos os fornecedores de bancos de dados vão abandonar seus formatos internos de armazenamento e competir apenas na camada de computação ignora a infraestrutura de engenharia e os modelos de negócio que eles construíram ao longo de décadas
    No caso da Snowflake, talvez fosse melhor simplesmente encerrar o negócio e devolver bilhões de dólares aos investidores. Prender os dados ao próprio ecossistema é todo o modelo de negócio deles
    Fico curioso se há bons exemplos de padrões abertos que tenham feito empresas abrir mão de tecnologias proprietárias

• Discordo fortemente da afirmação de que “a melhor maneira de salvar um dataframe do Apache Arrow em um arquivo em disco é o Feather, e ele também pode ser convertido para Apache Parquet etc.”
  Se você quer construir diretamente um lakehouse que não seja baseado em JVM, a melhor configuração é usar Iceberg como metadados, Parquet como dados, DuckDB como engine de consulta e consultar como tabelas Arrow
  O custo de ler Parquet diretamente para Arrow é muito baixo e, depois, basta passar de Arrow para Pandas ou Polars. Isso pode ser feito diretamente ou por meio de um serviço baseado em Arrow Flight
  Se você colocar Feather nessa história, a stack atual de lakehouse em Python como um todo não funciona bem

  • Em algum momento eu achava que o Feather não tinha garantias de formato de longo prazo
    Talvez isso tenha mudado, mas Parquet ainda me parece a opção mais preparada para o futuro

• Eu já tinha ouvido falar de data lake, mas “data lakehouse” soa como um lugar onde dados da classe alta vão, no verão, passear de barco de dados e pescar dados

  • O nome é fácil de zoar, mas acho que o problema real existe
    Muitas empresas armazenam dados em data lakes e usam warehouses para oferecer BI a ferramentas como Tableau ou PowerBI. Aí acabam copiando dados entre os dois
    Um data lakehouse, que permite consultar diretamente o lake e aplicar transações e governança a um único conjunto de dados, pode simplificar bastante a stack e também reduzir custos
  • Para começo de conversa, nunca entendi o que “data lake” quer dizer além de “uma coleção heterogênea de arquivos de dados em grande volume”
  • Dar nomes é difícil, e espero que um dia o setor crie um nome melhor
    Toda vez que ouço ou leio isso, soa bem esquisito na minha cabeça

• Tenho expectativas especialmente altas para o Iceberg, porque é open source
  Mas, da última vez que olhei, a única implementação era uma biblioteca Spark, e o conector Iceberg do Trino (antigo Presto, um engine SQL) dependia fortemente do Hive
  Parecia que o setor inteiro estava tendo dificuldade para se divorciar do legado de MapReduce, Hive e, ouso dizer, Spark
  Não voltei a olhar o Iceberg desde então, mas pretendo fazer isso em breve, e realmente espero que essa área evolua
  Hoje já temos ferramentas e capacidade de computação para lidar com dados sem tecnologias legadas, e nem todo dado é big data
  Por isso, felizmente, a engenharia de dados está ficando cada vez mais parecida com o desenvolvimento backend comum, e práticas normais de desenvolvimento também estão se consolidando
  Espero que em um futuro muito próximo surja uma biblioteca Iceberg em Python puro

  • O Trino agora não depende mais de Hadoop/Hive em nenhum conector de data lake
    Foi necessário um esforço enorme para remover essa dependência
  • Comigo foi parecido. Gastei mais ou menos um mês do meu tempo livre tentando ajustar a stack antiga a ponto de conseguir simplesmente inserir dados, mas terminei insatisfeito
    Coloquei o Databend de pé em uma hora, e achei que, quando surgir uma implementação em Rust, a portabilidade em relação a Java/Hive vai melhorar, facilitando o uso de verdade daqui para frente

• Não sei por que não conseguem explicar tudo isso de forma mais concreta
  Seria bom falar de coisas como como os dados são armazenados, como são conectados e consultados, e quão rápidas são as consultas. Por exemplo, a diferença entre velocidade de transações e velocidade de consultas analíticas

• Atualmente lidamos com cerca de 100 TB de dados no GCP, usando o BigQuery como motor de consultas e um particionamento Hive simples como /key3=000/key2=002/
  Conseguimos executar todas as consultas que queremos, e o custo é extremamente baixo, então estamos satisfeitos
  Só que a latência está ficando bem alta, embora isso não seja tão crítico para nós. Ainda assim, fico curioso se adotar Iceberg melhoraria esse ponto
  Gostaria de saber se alguém tem experiência com isso e, no geral, essa arquitetura é realmente excelente

  • Há um bom resumo sobre esse tema: a seção “Optimizing read performance” em https://aws.amazon.com/blogs/big-data/choosing-an-open-table...
    O principal objetivo dessas tecnologias é gerenciar dados em grande escala, mas elas também ampliam recursos oferecidos por formatos brutos de armazenamento como Parquet. Então pode ajudar, mas é preciso avaliar se é realmente necessário
    Não usei BigQuery, mas pode haver recursos semelhantes
    Primeiro é preciso definir o que significa “latência” aqui e qual nível é “bem alto”
    Armazenamentos de dados analíticos são projetados para processamento em lote eficiente, e encontrar um único registro não é o objetivo principal dessa arquitetura. Para buscas rápidas, é necessário cache ou indexação
    Em alguns casos, simplesmente adicionar limit 1 a uma busca por um único registro pode resolver
    Verifique se vocês estão usando um formato eficiente de armazenamento de dados, como Parquet, e confira o tamanho dos arquivos para ver se não há o "problema dos arquivos pequenos"
    Depois, também é preciso verificar se estão usando os recursos relevantes do BigQuery. Antes e depois dessas checagens, rode explain nas consultas; se você não usar a chave de partição ou colunas indexadas, os resultados de busca não vão aparecer instantaneamente em nenhum sistema de big data
  • Nossa escala é cerca de 1/10 da de vocês, mas em visualização de dados os clientes naturalmente não têm paciência, então a velocidade das consultas é uma grande preocupação
    Se vocês não estiverem usando tabelas do BigQuery como entrada para computação de alto throughput, eu me concentraria em otimizar a ferramenta de BI ou em criar tabelas analíticas que evitem latência para o usuário final
    Por exemplo, recentemente materializamos junções de tabelas fato/dimensão e operações COALESCE para criar uma grande tabela dedicada a análise
    Conceitualmente ela fica “fora” da configuração comum de data warehouse, mas como existe dentro do dbt, conseguimos manter qualidade dos dados e linhagem
    Com isso, eliminamos cálculos fixos do Tableau e reduzimos em cerca de 95% o tempo de carregamento/agrupamento para o usuário final
  • Se você estiver usando o armazenamento nativo do BigQuery, Iceberg não deve deixar as consultas mais rápidas
    Se forem consultas federadas sobre GCS/S3, pode ficar mais rápido
  • Se não houver problema em migrar para AWS, isto parece bem interessante: https://www.boilingdata.com/

• Gostei muito da atitude de “este texto não será 100% abrangente, nem provavelmente o melhor ponto de partida para a maioria das pessoas. Isso porque estou escrevendo para mim mesmo. Sinto que a melhor forma de aprender algo novo é me forçar a explicá-lo novamente para outras pessoas”
  Também comecei a adotar essa abordagem no papel e nas notas do meu site

• Eu estava bem animado para me aprofundar na era do Iceberg para armazenamentos Parquet mais gerenciados
  Mas o suporte a I/O rápida com GPU (GPUDirect/cuFile) ainda está alguns anos atrasado
  Por isso, toda vez que tento levar isso a clientes para cargas de trabalho de IA, bato nesse obstáculo
  No fim, parece algo que vai acontecer, e a questão é mais “quando” do que “se é possível”. Vai ser muito bom quando der para ter as duas coisas ao mesmo tempo

  • Fiquei curioso sobre qual é o caso de uso. Armazenamento de dados de imagem?
    Para armazenamento de texto, Parquet hoje já é suficiente
    O PyTorch Data Loader e o TF Data oferecem clientes multithread que fazem leitura antecipada em paralelo, preenchem buffers de memória e depois transferem dados de/para a GPU
    Concordo que o S3 pode ser o gargalo aqui. Por isso usamos o HopsFS sobre o S3 como um cache NVMe global, distribuído e consistente
    A Anyscale também tem feito algo parecido com um cache NVMe local para S3
    Outro formato de arquivo interessante é o Lance, parecido com Parquet, mas voltado a dados de imagem. Ele inclui um índice extra de I/O aleatória rápida para localizar imagens dentro do arquivo