Apache Iceberg Storage e Pandas Analytics: Parte I

Geralmente gosto de experimentar coisas novas, e com a tecnologia não é diferente. Então, decidi pesquisar mais a fundo a mecânica por trás do Apache Iceberg, e especificamente a implementação do Python, o PyIceberg.

Apache Iceberg with Industrial Piping

Eu estava analisando especificamente alguns itens-chave que geralmente fazem parte das práticas de gerenciamento de dados, independentemente da tecnologia:

• Controles de qualidade de dados: posso validar esquemas no mínimo com digitação de dados, mas de preferência com inspeção de valor.

  
  

• Integridade de dados: você pode evitar duplicatas, aplicar chaves e manter algum nível de integridade referencial quando os dados são vinculados entre estruturas de dados

  
  

  
  

  
  

  
  

• Acesso a dados: você consegue gerenciar a segurança com acesso em nível de linha e o tempo de acesso é robusto para que as recuperações e cargas sejam razoáveis, ou seja, expectativas médias para usuários, serviços e aplicativos

  
  

• Gerenciamento de metadados: posso ter esquemas que podem evoluir por meio de várias versões e talvez me fornecer a capacidade de reverter/desfazer alterações.

Se você é novo no PyIceberg, saiba que ele é uma implementação Python do Apache Iceberg sem a necessidade de uma JVM. É de código aberto, então o repositório do PyIceberg no GitHub está aqui e o suporte da comunidade pode ser encontrado aqui . O projeto começou como uma extensão para o Apache Spark, depois para o Flink e o Hive.

Fundação Apache Arrow

Sua mecânica de E/S de dados é baseada no Apache Arrow , um projeto lançado para definir uma especificação para dados tabulares e sua troca entre sistemas, especificamente na área de análise em memória. O Arrow foi inicialmente escrito em C e, posteriormente, portado para várias outras linguagens (veja "Implementações" no link da página inicial acima).

Na parte inferior do link da página inicial, você verá links adicionais para livros de receitas para C++ , Java , Python e R , para começar a usar as implementações dessas linguagens. Também está disponível a portabilidade para linguagens e kits de ferramentas populares como C#, Rust, Ruby e MATLAB.

Se você usa atualmente ou planeja usar os formatos Apache Parquet ou ORC, provavelmente descobrirá que bibliotecas de fornecedores de nuvem ou mecanismos de consulta originam e encapsulam as bibliotecas Arrow como base inicial para as extensões específicas de cada provedor.

Extensões de IA/ML

Existem extensões CUDA para a comunidade de IA/ML, mas esperamos que você fique longe de realizar transformações e manipulações de dados em recursos caros de GPU. Você será mais econômico e terá um processamento mais eficiente.

Acredito que a falta de separação de responsabilidades para essas tarefas focadas em dados seja um dos impulsionadores da demanda por GPUs e da falta de consumo de CPU para treinamento e execução de modelos de IA/ML. Não se trata tanto de uma falta de reconhecimento de que a separação é necessária, mas do tempo que leva para projetá-la e entregá-la; ou seja, ela não acontece.

GPUs não são processadores de uso geral, como CPUs, e são mais adequadas (pelo menos até o momento) para cálculos de algoritmos e visualização — foram inventadas para computar pontos em um triângulo em paralelo para exibição gráfica. A NVIDIA oferece uma introdução ao tópico sobre desempenho de GPU . Uma visão geral básica de processadores baseados em células (dos quais GPUs são um exemplo) do Laboratório de Supercomputação de Ohio (2007) está abaixo:

2007_tech_notes_jun_jul.pdf

Fazer download de PDF • 196KB

Os casos de uso específicos para o uso de processadores baseados em células são a principal lição, visto que, em termos de desenvolvimento, a maioria dos engenheiros tem carreiras focadas em um único processador e não em múltiplos. As habilidades de separação de carga de trabalho para recursos computacionais específicos precisam ser desenvolvidas e aprimoradas (fim do tópico do interlúdio).

Apache Iceberg sob as cobertas

A abordagem geral para metadados e armazenamento de dados é garantir a imutabilidade, o que é definitivamente uma vantagem. Por quê? Em resumo, a simultaneidade e o desempenho do acesso a dados são melhor dimensionados com implementações de imutabilidade (quando bem feitas), além de fornecer rastreabilidade à medida que o esquema e os dados evoluem. Se você é usuário de produtos RDBMS, o conhecido problema de fragmentação de dados (metadados) e índices pode exigir ciclos de vigilância e manutenção. Isso é especialmente impactante em casos analíticos (ROLAP) ou híbridos (OLTP + histórico longo), mas desaparece com implementações de imutabilidade.

Como indiquei ou sugeri acima, o Iceberg encapsula e utiliza diversas bibliotecas diferentes de projetos Apache da Arrow, Parquet, ORC e AVRO. Estas se concentram principalmente em operações de E/S, sejam elas de persistência na memória ou baseadas em arquivo. O Iceberg também faz uso considerável do Pydantic para implementação de metadados em Python.

Os "modelos" para estruturas de esquema são construídos e validados usando o Pydantic, e os objetos de metadados são armazenados em um catálogo usando um repositório persistente. O repositório persistente pode ser acessado via REST, um SGBD SQL, repositório na memória, Apache Hive, AWS Glue ouarquivos . A visão geral, obtida de https://iceberg.apache.org/spec/ , está abaixo para fornecer uma visão visual de como ele está organizado. Alguns detalhes adicionais a serem destacados na figura abaixo: O arquivo de metadados é um arquivo Apache AVRO e as listas de manifestos estão no formato JSON. As propriedades de validação de esquema em conjunto com o Pydantic são provavelmente o motivo pelo qual essa combinação foi escolhida.

Metadados e Qualidade de Dados

A organização de metadados começa no nível do namespace e é uma separação lógica ou contextual dos dados. Você pode fazer referências entre namespaces ao acessar dados, se necessário. Objetos de tabela são criados "sob" um namespace e fornecem os tipos de implementação para esquemas que você pode encontrar aqui . Se você precisar armazenar dados geoespaciais, o Iceberg oferece suporte a tipos geométricos e geográficos, além de oferecer suporte a CRS (Sistema de Referência de Coordenadas) e interpolação de arestas na camada de metadados. Particionamento de dados e linhagem de linhas também estão disponíveis, e o número de registros mantidos para detalhar a linhagem pode ser definido ao criar o catálogo.

Para ilustrar melhor o diagrama acima, incluí a saída do arquivo de console das tabelas Iceberg que criei para a implementação de exemplo na Parte II. Criei uma pasta "warehouse" no meu dispositivo, e a listagem começa no namespace "docs". Ela detalha os dados e metadados de "forecast".

Namespace and Table Organization

Data and Metadata for Forecasts Object

A implementação do Pydantic, especialmente ao usar o modo "estrito" (metadados e dados), abrange os tópicos "Metadados" e "Qualidade dos Dados" no início do artigo. Você também obtém controles de versão de esquema nos metadados, até o nível de coluna, e possui mecanismos muito bons para ajudar na evolução do esquema. Os metadados do Iceberg fornecem muitas variações que são implementadas usando o equivalente de "restrições" em RDBMS (não a DDL de tabela literal). Você obtém validação de tipo, designação de campo obrigatória e inspeção de tamanho e precisão, mas não aplica uma lista de valores personalizada a campos específicos.

Na minha experiência, o uso de listas de valores tende a ser mais comum em padrões de projeto OLTP do que em casos OLAP (analíticos) para um RDBMS, e claramente o Apache Iceberg foi projetado para casos de uso analítico e não para processamento de transações. No geral, é um bom começo em termos de qualidade de dados e metadados. Os atributos de valores "padrão" oferecem a capacidade de implementar um equivalente de "chave" substituto ou usar IDs de campo "identificadores" .

Ele não oferece um equivalente a uma chave primária ou única, que é um tipo de restrição de banco de dados que garante a unicidade independentemente de haver um índice associado. Também não há indexação gerenciada pelo usuário, mas se você já for usuário de qualquer um dos formatos de arquivo mencionados anteriormente, isso não é novidade e não é esperado que exista. Garantir a unicidade é responsabilidade do "usuário". Você pode impor a unicidade dentro de uma struct, por exemplo, mas isso depende de você; o Iceberg não fará isso por você.

Segurança em nível de linha

As áreas desafiadoras para o Apache Iceberg são RWA (segurança de acesso em nível de linha) e integridade de dados. Estou avaliando o que está "integrado" às bibliotecas, não como você pode construir uma solução para resolver esses problemas usando ferramentas adicionais.

A segurança RWA não está integrada às bibliotecas. Existem algumas linhagens muito boas para recursos de linha e metadados, que podem ajudar no diagnóstico de problemas de qualidade de dados e fornecer recursos de mudança ao longo do tempo. Estes últimos podem ser muito úteis em um caso de uso de séries temporais. Mas a segurança RWA tende a ser um requisito de segurança corporativa; esperamos que a integração com LDAP apareça em algum momento para permitir isso.

Integridade de dados

Os recursos de integridade de dados não são realmente o foco do Iceberg, talvez porque a tendência no acesso a dados de IA/ML tenha sido desnormalizar tabelas de dados para que chaves estrangeiras não sejam realmente necessárias, ou seja, uma tabela grande. Isso surge em casos de uso de análise mais tradicionais, onde há várias tabelas que exigem links de relacionamento (físicos ou virtuais), então seria um complemento útil para esses casos. Mesmo que seja apenas informativo para rastrear em metadados, ele impulsiona a validação. É uma área negligenciada no Iceberg.

Acesso a dados

Usuários que atualmente utilizam qualquer um dos formatos do Apache Arrow mencionados anteriormente sabem o que estão obtendo com cada um deles. Para grandes quantidades de armazenamento de dados, o Parquet tende a ser usado com frequência para conjuntos de dados grandes a muito grandes, especialmente se o particionamento for necessário para garantir tempos de resposta de consulta razoáveis. Fiz uma pequena implementação, que detalharei na Parte II do artigo, onde tempos de resposta simples são registrados. Mas, como muitos sabem, o Parquet, especialmente se/quando bem particionado, é muito responsivo a solicitações de consulta. Seu formato em colunas é especialmente bem projetado para se adequar e atender a casos de uso de análise.

Na próxima parte do artigo, vou mostrar uma implementação simples usando o Apache Iceberg e dados financeiros com algumas agregações do Python.