Hardwood 1.0 Substitui parquet-java Sem Dependências

Hardwood 1.0, um leitor Apache Parquet puro em Java construído do zero por Gunnar Morling no Confluent, foi enviado para Maven Central no final de junho. A biblioteca não tem dependências obrigatórias para arquivos descompactados ou compactados com gzip, exige apenas um único JAR para codecs Snappy/Zstd/LZ4/Brotli e paraleliza decodificação de páginas em todos os núcleos de CPU disponíveis por padrão. Em uma AWS m7i.2xlarge (8 vCPU / 32 GB RAM) verificando 48,7 milhões de linhas de táxi NYC em 830 MB de Parquet compactado, o leitor de coluna Hardwood alcança 16,5M linhas/seg. Em um núcleo único, a mesma carga de trabalho produz 3,9M linhas/seg—uma cifra que vale a pena notar porque isola ganhos de paralelismo de melhorias algorítmicas.

A linha de base é parquet-java 1.17.1, a implementação padrão do Apache. Essa biblioteca é single-threaded em seu núcleo e traz uma árvore de dependências pesada. Equipes construindo pipelines de recursos ou carregadores de dados de treinamento no Spark, Flink ou JVM simples absorveram esse custo ou mudaram para bindings C++ DuckDB/Arrow para escapar dele. Hardwood oferece um terceiro caminho: permaneça na JVM, mantenha o classpath enxuto e use o modelo de concorrência do JDK para escalar.

Morling entrega duas APIs que deliberadamente mantém separadas. A API de leitor de linhas oferece acesso a registros estruturados via chamadas tipadas—getLong, getString, getDate, getTimestamp em um cursor familiar—e lida com colunas aninhadas e repetíveis. A API de leitor de colunas expõe lotes de arrays primitivos para entrega a pools de workers ou loops vetorizados, com sobrecarga mínima por valor e alocação controlada pelo chamador. Avaliação de predicados executa de forma sem ramificações e lote-a-tempo para reduzir erros de previsão de ramificação de CPU durante varreduras filtradas. Ambas as APIs suportam projeção de colunas e push-down de predicados contra armazenamento de objetos remoto. O acesso S3 usa o cliente HTTP integrado do Java com uma implementação SigV4 customizada e sem AWS SDK.

A higiene da cadeia de suprimentos impulsiona o design. Hardwood usa System.Logger do Java 9 em vez de uma estrutura externa, eliminando área de superfície de conflito de classpath em deployments multi-tenant. A linha de base sem dependências também reduz a superfície de ataque SBOM—uma preocupação que se moveu de equipes de segurança para líderes de plataforma ML agora que pipelines de treinamento processam dados de clientes em escala. A política do GitHub afirma: "Contribuições assistidas por LLM são bem-vindas, mas vibe coding—aceitar mudanças geradas por IA sem entendê-las—não é." Isso sinaliza um padrão concreto de revisão de código.

Suporte de escrita é a única omissão: 1.0 fornece apenas um leitor. Suporte de escrita é o recurso principal para 1.1, com seu design ainda sob discussão no rastreador público de problemas. Equipes avaliando Hardwood para uma feature store ou pipeline de lakehouse precisam de um caminho de escrita separado—parquet-java ou um sidecar DuckDB—até que 1.1 saia. A CLI, um binário nativo GraalVM com uma TUI para inspeção de schema e metadados, é funcional e útil para validar integridade de arquivo sem iniciar um framework de processamento de dados.

O roadmap 1.0 inclui suporte a filtro Bloom, reutilização de String para colunas codificadas por dicionário e integração Apache Flink. Compatibilidade é um invariante rígido: qualquer arquivo analisável por parquet-java deve ser parseado com Hardwood, e deviações são rastreadas como bugs. Vinte contribuidores se juntaram ao projeto. Relatórios de mudança de API são publicados junto com o Javadoc em cada lançamento.

Se o throughput de leitura Parquet do seu pipeline JVM está vinculado à CPU e você está carregando o peso de dependência do parquet-java, compare Hardwood 1.0 contra sua carga de trabalho—apenas aguarde o suporte de escrita até 1.1.