Hardwood 1.0 Reemplaza parquet-java Sin Dependencias

Hardwood 1.0, un lector Apache Parquet puro en Java construido desde cero por Gunnar Morling en Confluent, se lanzó a Maven Central a finales de junio. La biblioteca no tiene dependencias obligatorias para archivos sin comprimir o comprimidos con gzip, requiere solo un JAR individual para codecs Snappy/Zstd/LZ4/Brotli y paraleliza la decodificación de páginas en todos los núcleos de CPU disponibles de forma predeterminada. En una AWS m7i.2xlarge (8 vCPU / 32 GB RAM) escaneando 48,7 millones de filas de taxis de NYC en 830 MB de Parquet comprimido, el lector de columnas de Hardwood logra 16,5M filas/seg. En un solo núcleo, la misma carga de trabajo produce 3,9M filas/seg—una cifra que vale la pena notar porque aísla las ganancias de paralelismo de las mejoras algorítmicas.

La línea de base es parquet-java 1.17.1, la implementación estándar de Apache. Esa biblioteca es single-threaded en su núcleo y trae un árbol de dependencias pesado. Los equipos que construyen pipelines de características o cargadores de datos de entrenamiento en Spark, Flink o JVM simple han absorbido ese costo o se han desplazado a enlaces C++ DuckDB/Arrow para escapar de él. Hardwood ofrece un tercer camino: permanece en JVM, mantén el classpath delgado y usa el modelo de concurrencia de JDK para escalar.

Morling envía dos APIs que deliberadamente mantiene separadas. La API de lector de filas proporciona acceso a registros estructurados a través de llamadas tipadas—getLong, getString, getDate, getTimestamp en un cursor familiar—y maneja columnas anidadas y repetibles. La API de lector de columnas expone lotes de arrays primitivos para entrega a pools de workers o bucles vectorizados, con sobrecarga mínima por valor y asignación controlada por el llamador. La evaluación de predicados se ejecuta sin ramificaciones y lote por lote para reducir errores de predicción de rama de CPU durante escaneos filtrados. Ambas APIs admiten proyección de columnas y push-down de predicados contra almacenamiento de objetos remoto. El acceso S3 utiliza el cliente HTTP integrado de Java con una implementación SigV4 personalizada y sin AWS SDK.

La higiene de la cadena de suministro impulsa el diseño. Hardwood usa System.Logger de Java 9 en lugar de un framework externo, eliminando el área de superficie de conflicto de classpath en despliegues multi-tenant. La línea de base sin dependencias también reduce la superficie de ataque SBOM—una preocupación que ha pasado de equipos de seguridad a líderes de plataforma ML ahora que los pipelines de entrenamiento procesan datos de clientes a escala. La política de GitHub establece: "Las contribuciones asistidas por LLM son bienvenidas, pero vibe coding—aceptar cambios generados por IA sin entenderlos—no." Esto señala un estándar concreto de revisión de código.

La compatibilidad de escritura es la única omisión: 1.0 envía solo un lector. La compatibilidad de escritura es la característica principal para 1.1, con su diseño aún en discusión en el rastreador de problemas público. Los equipos que evalúan Hardwood para una feature store o pipeline de lakehouse necesitan una ruta de escritura separada—parquet-java o un sidecar DuckDB—hasta que se lance 1.1. La CLI, un binario nativo de GraalVM con una TUI para inspección de esquema y metadatos, es funcional y útil para validar la integridad del archivo sin iniciar un framework de procesamiento de datos.

La hoja de ruta 1.0 incluye compatibilidad con filtro Bloom, reutilización de String para columnas codificadas por diccionario e integración Apache Flink. La compatibilidad es un invariante estricto: cualquier archivo analizable por parquet-java debe analizarse con Hardwood, y las desviaciones se rastrean como bugs. Veinte colaboradores se han unido al proyecto. Los informes de cambios de API se publican junto con el Javadoc en cada lanzamiento.

Si el rendimiento de lectura de Parquet de tu pipeline JVM está limitado por CPU y llevas el peso de dependencia de parquet-java, compara Hardwood 1.0 contra tu carga de trabajo—solo espera a la compatibilidad de escritura hasta 1.1.