Entender Parquet, Iceberg y los data lakehouses

Artículo original ↗ Discusión en Hacker News ↗

Los equipos de datos modernos están estandarizándose cada vez más en formatos de tabla abiertos como Apache Iceberg, Delta Lake y Hudi sobre archivos Parquet en almacenamiento de objetos, con el objetivo de desacoplar el almacenamiento de los motores de consulta y evitar el bloqueo con un proveedor. Los comentaristas sopesan las ventajas y desventajas de Iceberg y Delta en términos de apertura, soporte del ecosistema (especialmente fuera de JVM) y rendimiento real, señalando cómo actores importantes como Snowflake, Microsoft y Google se están alineando detrás de distintas opciones. Más allá de los detalles del formato, muchos sostienen que los lakehouses básicamente reempaquetan ideas clásicas de data warehouse (star schemas, ETL/ELT, gobernanza) sobre almacenamiento en la nube más barato, y que el modelado y la calidad de los datos siguen importando mucho más que el archivo específico o el formato de metadatos elegido.

Qué hacen los nuevos formatos de tabla

  • Parquet se considera ampliamente el almacenamiento columnar de facto para data lakes; Iceberg/Delta/Hudi añaden metadatos a nivel de tabla, evolución de esquemas, particionado y semántica ACID encima.
  • Esto desacopla componentes: por ejemplo, S3 para almacenamiento, Parquet para los datos, Iceberg/Delta para metadatos, y DuckDB/Spark/Trino/Snowflake/BigQuery como motores.

Apertura y gobernanza (Iceberg vs Delta vs Hudi)

  • Iceberg se considera un estándar abierto más limpio y bien especificado; la especificación de Delta se ve como compleja y fuertemente acoplada a la implementación de Databricks.
  • Algunos sostienen que Delta solo es “nominalmente” abierto: los cambios de la especificación están impulsados por un solo proveedor, y algunas funciones se retienen del código abierto.
  • Contraargumento: otros dicen que Delta ha sido suficientemente abierto en la práctica durante años, y que actores importantes como Microsoft están apostando fuertemente por él.
  • Varios señalan que Snowflake y BigQuery están añadiendo Iceberg (no Delta), lo que se interpreta como una señal de la neutralidad de Iceberg.

Ecosistema de herramientas y lenguajes

  • Históricamente, Iceberg estaba centrado en Spark/Hadoop; el soporte fuera de JVM (PyIceberg, extensión de DuckDB) está llegando, pero aún está madurando.
  • Delta tiene delta-rs para Python/Rust y hoy se percibe como más fácil fuera de la JVM, aunque su origen y gobernanza se debaten.
  • Trino ha eliminado dependencias de Hadoop/Hive; muchos ven que el ecosistema se está alejando gradualmente de las antiguas pilas de big data.

Data lakes, warehouses y lakehouses

  • Tema fuerte: los formatos son detalles de implementación; el valor real proviene del modelado (por ejemplo, star schemas), ETL/ELT y BI/informes.
  • Los data lakes por sí solos a menudo se convierten en “pantanos” con muchos datos en bruto y pocas conclusiones; los lakehouses reintroducen estructura tipo tabla y transacciones encima de almacenamiento de objetos barato.
  • Algunos argumentan que la mayoría de las empresas ni siquiera necesita data lakes, dadas las modestas cantidades de datos y los sistemas relacionales existentes.

Rendimiento, coste y portabilidad

  • Los formatos de tabla sobre almacenamiento de objetos prometen almacenamiento más barato y neutral respecto al proveedor, y la posibilidad de cambiar de motor de consulta con menos bloqueo.
  • Varios destacan que consultar lakes/lakehouses suele ser más lento que bases de datos columnares diseñadas específicamente; aceptable para muchas analíticas, problemático para BI interactivo.
  • Los proveedores afirman que buscan hacer que los formatos de tabla abiertos rindan casi como el almacenamiento nativo, pero se cuestiona si abandonarán sus internals propietarios.

Formatos de archivo y problemas prácticos

  • Feather vs Parquet: muchos prefieren Parquet por ser más a prueba de futuro e interoperable; usar Feather puede romper algunas pilas Python de lakehouse.
  • CSV se critica ampliamente por frágil; la adopción de Parquet se considera una gran victoria práctica.
  • Se mencionan formatos especializados como Lance y Zarr para casos de uso de baja latencia o multidimensionales, pero siguen siendo nicho frente a Parquet.