Entender Parquet, Iceberg y los data lakehouses

• Las tecnologías de almacenamiento de datos no son una sola pieza, sino que se dividen en capas distintas como el formato de archivo, el formato en memoria, la capa de metadatos de tablas y la arquitectura de lakehouse
• Avro, Parquet, ORC y Arrow son formatos que definen el diseño binario de los datos; Parquet destaca en compresión por columnas y procesamiento analítico, mientras que Avro es más adecuado para procesamiento por filas
• Iceberg y Delta Lake no son formatos de archivo, sino una capa superior de metadatos que permite la gestión de tablas a gran escala sobre archivos como Parquet
• Un data lakehouse consiste en agregar funciones de warehouse como consultas SQL, trabajos por lotes y gobernanza sobre archivos crudos en almacenamientos como S3
• Incluso warehouses como Snowflake y BigQuery están soportando formatos abiertos como Iceberg, por lo que la frontera entre data warehouse y lakehouse se está volviendo cada vez más difusa

---

La diferencia entre formatos de archivo y formatos en memoria

• Los formatos open source que hacen más eficiente el almacenamiento y acceso a datos difieren tanto en su forma de almacenamiento como en dónde se usan
  • Apache Avro: binario, almacenamiento por filas (rowstore), archivo
  • Apache Parquet: binario, almacenamiento por columnas (columnstore), archivo
  • Apache ORC: binario, almacenamiento por columnas, archivo
  • Apache Arrow: binario, almacenamiento por columnas, memoria
  • Protocol Buffers: lenguaje neutral para definir estructuras de datos, y según la implementación puede variar entre almacenamiento por filas o por columnas
  • CSV: basado en texto y con una estructura muy simple
• Para guardar un dataframe de Apache Arrow como archivo en disco, normalmente se usa Feather, aunque también puede convertirse a otros formatos como Parquet
• Sistemas como Snowflake, Redshift, Athena y Hive soportan lectura y escritura de formatos abiertos y formatos de almacenamiento cerrados, pero el alcance del soporte a formatos abiertos puede variar según el producto

Lo que realmente define un formato

• Un formato de archivo es una especificación que define cómo se ordenan los datos en la disposición binaria real
• Parquet es fuerte en compresión, mientras que Avro, al usar almacenamiento por filas, es más adecuado para leer bloques de filas específicas
• Tanto Parquet como Avro soportan evolución de esquema, lo que permite modificar el esquema de datos nuevos sin reescribir todos los datos existentes
• Ambos formatos también soportan división de archivos, algo importante para el procesamiento paralelo de datos
• El repositorio de Apache Parquet incluye la especificación real del formato de archivo y una implementación de referencia en Java
• Parquet puede leerse y escribirse desde múltiples lenguajes y herramientas, y en Pandas también se puede guardar un DataFrame como archivo Parquet local con to_parquet
• Presto/Trino, Spark, DuckDB, Hive, Dremio, Impala, AWS Athena y Apache Drill son ejemplos de motores capaces de trabajar con archivos Parquet

Por qué un formato de archivo no basta para gestionar datos a gran escala

• Los formatos de archivo individuales solo definen el diseño de un único archivo, por lo que no bastan para gestionar datasets grandes que cambian continuamente
• Para almacenar muchas tablas, manejar la evolución de esquema por tabla, consultas a un punto en el tiempo, particionamiento eficiente, lectura de esquemas por herramientas externas y almacenamiento de estadísticas para optimización de consultas basada en costos, se necesita una capa superior
• Esa capa incluye un formato de tabla y un registro de esquemas o metastore
• Confluent Schema Registry soporta Avro y Protobuf, y es más adecuado para datos de streaming con tendencia al almacenamiento por filas

El lugar de Hive, Iceberg y Delta Lake

• Facebook publicó Hive en 2009 junto con su propio formato de metadatos de tablas, y con el tiempo Hive pasó a soportar varios formatos
• Netflix desarrolló Iceberg para superar los límites de rendimiento y escalabilidad de Hive
• Databricks desarrolló Delta Lake como alternativa a Iceberg y luego lo publicó como open source
• Tanto Iceberg como Delta Lake usan Parquet como formato de archivo individual
• Hive, Delta Lake e Iceberg soportan conceptos equivalentes a un registro de esquemas o metastore
  • El HMS (Hive MetaStore) de Hive puede usar en la práctica casi cualquier RDBMS
  • Iceberg tiene Iceberg Catalogs
  • Databricks tiene Unity Catalog
• Estos catálogos y metastore también pueden usarse para la gobernanza de datos, como administrar qué equipos o usuarios pueden acceder a determinadas tablas

Qué funciones cumplen Iceberg y Delta Lake

• Delta Lake e Iceberg no son en sí mismos motores de consulta ni motores de almacenamiento, sino especificaciones abiertas que permiten que los motores de consulta funcionen
• Ambos resuelven el mismo problema de maneras distintas, y existe debate sobre la apertura de Delta Lake porque tiene menos diversidad de contribuidores que Iceberg
• El soporte para Iceberg está creciendo rápidamente en muchos data warehouses y lakehouses como Redshift, BigQuery, Snowflake, Athena y Dremio
• Iceberg y Delta Lake ofrecen las funciones necesarias para operar tablas a gran escala
  • Particionamiento
  • Evolución de esquema
  • Compresión de datos
  • Transacciones ACID para cambios de esquema
  • Optimización eficiente de consultas mediante poda de columnas, pushdown de predicados y recolección de estadísticas
  • Time travel para consultas a un punto en el tiempo
• Iceberg soporta evolución de particiones, lo que permite cambiar la estrategia de particionamiento o la shard key de una tabla sin reescribir todos los datos existentes
• En Netflix, cambiar el particionamiento era una gran dificultad y fue una de las razones para crear Iceberg

Formatos cerrados y la presión por soportar Iceberg

• La especificación de Iceberg está ganando popularidad rápidamente como un formato soportado por múltiples sistemas
• Los productos que usan formatos cerrados enfrentan presión para seguir ofreciendo el mayor rendimiento posible con su propio formato, pero también para soportar Iceberg o Delta Lake de alguna manera
• Iceberg podría convertirse en una función de checklist que todos los sistemas de bases de datos eventualmente deban soportar
• Por razones de rendimiento, puede ser difícil que Iceberg reemplace por completo a los formatos de datos cerrados
• Si se desarrolla un formato de datos solo para un único motor de consultas, los desarrolladores de bases de datos pueden exprimir al máximo la eficiencia e innovar más rápido

Data lakes y data lakehouses

• Un data lake es donde una empresa almacena grandes volúmenes de datos como archivos crudos en formatos como Parquet o CSV
• Un data warehouse almacena los datos de una manera más estructurada, como tablas SQL con esquema y esquemas de base de datos
• Un data lakehouse combina en el data lake capacidades como ejecución de consultas SQL, trabajos por lotes y configuración de gobernanza de datos
• Usando Iceberg junto con un motor de consultas y otros componentes adicionales, se puede construir un data lakehouse sobre un data lake
• Antes, para tener estas capacidades había que adoptar un data warehouse o un DBMS más tradicional
• Los data lakehouses usan HDFS o un blob store en la nube como S3 como ubicación de almacenamiento para todos los datos, y optimizan el motor de consultas para funcionar rápidamente sobre ese almacenamiento
• Databricks y Dremio son ejemplos de productos de data lakehouse
• A medida que warehouses como Snowflake y BigQuery agregan formatos de datos abiertos como Iceberg, la distinción entre data warehouse y data lakehouse se vuelve cada vez más borrosa

[happing94]

Estaba comparando Iceberg y Delta Lake, y veo que aquí quedó todo bien ordenado.
Mi punto de vista y mi opinión eran casi los mismos.
El benchmark que se ejecutó en línea usó Spark, y aunque puede servir como referencia, el Head of DevRel de Tabular escribió que no tiene mucho significado.
Si hay que elegir como open source, parece que iceberg es la única opción.
El resumen está bien, pero también estaría bien que hubiera enlaces de referencia.

[GN⁺]

Opiniones de Hacker News

• Aunque Apache Iceberg y Delta Lake suelen agruparse como formatos de tabla abiertos (Open Table Format), en realidad se ven bastante diferentes
  La especificación de Iceberg está en https://iceberg.apache.org/spec/, y alguien que conozca sistemas de bases de datos podría verla y, al parecer, implementar sin demasiada dificultad algo que cree y consulte tablas Iceberg
  En cambio, la de Delta Lake está en https://github.com/delta-io/delta/blob/master/PROTOCOL.md, y cuesta incluso estimar la cantidad de trabajo necesaria para implementar por completo la especificación actual; seguirle el paso a esta enorme especificación que cambia constantemente parece aún más abrumador
  Sinceramente, la especificación de Delta Lake se lee como un documento que aplica ingeniería inversa a los compromisos de implementación que surgieron cuando Databricks construía rápidamente un lakehouse para empresas Fortune 1000 quemadas por Hadoop
  Todavía no me convence que adoptar Delta Lake realmente signifique entrar en un ecosistema abierto, y me gustaría tener fundamentos tranquilizadores al respecto
  Además, el historial de GitHub tampoco tranquiliza: https://github.com/delta-io/delta/commits/master/PROTOCOL.md
  Parece un flujo en el que funciones y correcciones arbitrarias llegan como PR de un ingeniero de Databricks, y un ingeniero sénior de Databricks las aprueba de inmediato

  • Totalmente de acuerdo. Que Databricks deje a propósito fuera de Delta open source algunas funciones como Bloom filter también está en su derecho
    Pero entonces no pueden afirmar que es un formato abierto impulsado por la comunidad. A menos que sea la versión de Animal Farm de que “algunos son más iguales que otros”
  • Implementé desde cero soporte para Delta en un componente de Microsoft Fabric, y sentí que la “especificación” por sí sola se quedaba bastante corta si no experimentabas además con la implementación de Spark
    Para usar funciones como columnas calculadas o restricciones de verificación, también hay que soportar expresiones de Spark SQL, y la documentación de esa parte es todavía peor
  • Me da la misma impresión. Soy extremadamente cauteloso con todo lo que ofrece Databricks
    Me parece que es casi open source solo de nombre, y que no hay que confiarse
    También usé Delta Lake, y en el uso real encontré muchos límites frustrantes y aristas filosas. Al final abandonamos por completo ese proyecto, y en ese momento también investigué Iceberg
    Iceberg y Hudi tenían un conjunto de funciones diseñado de forma más coherente, pero recibían menos soporte; espero que eso mejore en el futuro
  • Llevo uno o dos años siguiendo este campo y me preguntaba por qué Iceberg es más popular en open source; esta explicación ayuda
    Durante los últimos seis meses tuve la impresión de que Iceberg tiene dificultades para ofrecer herramientas para usuarios fuera del ecosistema JVM, mientras que Delta va por delante. En ese sentido, Delta es mucho más accesible
  • Usar JSON para los cambios de Delta es realmente una tontería
    En comparación, SQL Server lo implementa mucho mejor. Las tablas de almacenamiento orientado a columnas (columnstore indexes, el equivalente interno del motor a Parquet/ORC) son inmutables, y el delta se guarda en un B-Tree por compresión, accesibilidad y velocidad
    En algún momento, el almacenamiento por columnas se desfragmenta, fusiona o reconstruye, parcial o totalmente, y el B-Tree se elimina y vuelve a empezar a medida que se acumulan nuevos cambios
    Hacer esto con JSON es, por decirlo suavemente, una señal de una mala época
    Cualquier cosa parece mejor que Delta Lake, y en particular Iceberg se ve mejor

• Buen artículo. Llevo años trabajando con archivos Parquet sobre S3, pero no sabía exactamente qué era Iceberg; el artículo lo explica bien
  Iceberg es un formato de metadatos de base de datos que describe el esquema y el particionamiento del conjunto de datos subyacente, entre otras cosas
  La mayoría usa convenciones de particionamiento de Hive como /key3=000/key2=002/, pero Iceberg va más allá al exponer más estructura al motor de consultas
  En un DBMS tradicional como Postgres, el esquema, el motor de consultas y el formato de almacenamiento vienen en un solo paquete
  Pero en big data, puedes ensamblar los componentes de la base de datos desde cero y combinarlos entre sí. Puedes usar Iceberg como formato de metadatos, DuckDB como motor de consultas, Parquet como formato de almacenamiento y S3 como medio de almacenamiento

• En el mundo de las bases de datos, esto es un gran cambio. Porque gracias a Delta, Iceberg y Hudi, los datos suelen almacenarse en un formato open source sobre S3
  Si una parte importante del almacenamiento y el procesamiento se estandariza, moverse entre bases de datos se vuelve más fácil, y casi todas las herramientas eventualmente podrán manejar el mismo conjunto de archivos de forma transaccionalmente segura
  Por ejemplo, mientras Snowflake escribe en los archivos, un científico de datos puede consultarlos en tiempo real desde un Jupyter notebook, y ClickHouse puede ofrecer análisis para usuarios sobre los mismos datos manteniendo garantías de consistencia
  Después, si la empresa decide cambiar de Snowflake a Databricks, ya no será un problema tan grande
  Hoy consultar estos formatos desde S3 todavía no es tan rápido como la carga nativa, pero por presión del mercado todos los vendors de bases de datos se verán obligados a optimizar el rendimiento y al final se acercarán al desempeño de los datos cargados de forma nativa
  Es una gran victoria para la apertura, el open source y para que las empresas mantengan sus datos en formatos abiertos y portables
  El lakehouse tiene las mismas implicancias. Muchas empresas tienen tanto un data lake como un data warehouse, y terminan copiando datos entre ambos
  Tener un solo sistema para consultar y administrar el mismo conjunto de datos también tiene un impacto enorme
  Es una época muy interesante para estar en el área de ingeniería de datos

  • Apache Arrow y Substrait han venido trabajando para hacer realidad esto
    En el futuro se ve un escenario en el que, al ejecutar consultas, se puedan enviar planes de ejecución no solo a varios motores en la nube, sino también a máquinas locales
  • Asumir que todos los vendors de bases de datos van a abandonar sus formatos internos de almacenamiento y competir solo en la capa de cómputo ignora la infraestructura de ingeniería y los modelos de negocio que construyeron durante décadas
    En el caso de Snowflake, quizá les convendría más cerrar el negocio y devolver miles de millones de dólares a sus inversionistas. Mantener los datos atados a su ecosistema es todo su modelo de negocio
    Me pregunto si hay buenos ejemplos de estándares abiertos que hayan llevado a empresas a abandonar tecnología propietaria

• No estoy para nada de acuerdo con la afirmación de que “la mejor forma de guardar un dataframe de Apache Arrow como archivo en disco es Feather, y también se puede convertir a Apache Parquet, etc.”
  Si quieres crear un lakehouse no basado en JVM, la mejor configuración es usar Iceberg como metadatos, Parquet como datos, DuckDB como motor de consultas y consultar como tablas Arrow
  El costo de leer Parquet directamente en Arrow es muy bajo, y luego se lo puedes pasar a Arrow→Pandas o Polars. Puede ser de forma directa o mediante un servicio basado en Arrow Flight
  Si metes Feather ahí, todo el stack actual de lakehouse en Python deja de funcionar bien

  • En algún momento pensé que Feather no tenía garantías de formato a largo plazo
    Tal vez eso haya cambiado ahora, pero Parquet todavía me parece la opción más preparada para el futuro

• Había oído hablar de data lakes, pero “data lakehouse” suena como un lugar al que los datos de clase alta van en verano a pasear en data boats y pescar datos

  • Es fácil burlarse del nombre, pero creo que el problema real sí existe
    Muchas empresas guardan datos en un data lake y usan un warehouse para ofrecer BI a herramientas como Tableau o PowerBI. Entonces terminan copiando datos entre ambos
    Un data lakehouse, que permite consultar directamente el lake y aplicar transacciones y gobernanza sobre un único conjunto de datos, puede simplificar mucho el stack y reducir costos
  • Para empezar, nunca entendí qué significaba “data lake” aparte de “colección de archivos de datos grandes y heterogéneos”
  • Poner nombres es difícil, y ojalá algún día la industria invente uno mejor
    Cada vez que lo escucho o lo leo, me suena bastante raro en la cabeza

• Tengo expectativas especialmente altas para Iceberg, porque es open source
  Pero la última vez que lo revisé, la única implementación era una librería de Spark, y el conector Iceberg de Trino —antes Presto, motor SQL— dependía fuertemente de Hive
  Parecía que a toda la industria le costaba divorciarse del legado de MapReduce, Hive y, me atrevo a decir, Spark
  No he vuelto a mirar Iceberg desde entonces, pero pienso hacerlo pronto, y realmente espero que esta área avance
  Ahora ya tenemos herramientas y capacidad de cómputo para manejar datos sin tecnologías legacy, y no todos los datos son big data
  Por suerte, la ingeniería de datos se parece cada vez más al desarrollo backend común, y las prácticas de desarrollo normales también se están asentando
  Espero que en un futuro muy cercano aparezca una librería Iceberg pura en Python

  • Trino ya no depende de Hadoop/Hive en ningún conector de data lake
    Eliminar esa dependencia requirió un esfuerzo enorme
  • A mí me pasó algo parecido. Pasé como un mes de mi tiempo libre intentando ajustar el stack viejo hasta el punto de poder simplemente insertar datos, pero terminé insatisfecho
    Levanté Databend en una hora, y pensé que, si aparece una implementación en Rust, con mejor portabilidad frente a Java/Hive, será mucho más fácil usarlo bien en adelante

• No entiendo por qué no pueden explicar todo esto de forma más concreta
  Me gustaría que dijeran cosas como cómo se almacenan los datos, cómo se conectan y se consultan, y qué tan rápidas son las consultas. Por ejemplo, la diferencia entre velocidad transaccional y velocidad de consultas analíticas

• Actualmente manejamos unos 100 TB de datos en GCP, usamos BigQuery como motor de consultas y empleamos particionado Hive simple como /key3=000/key2=002/
  Podemos ejecutar todas las consultas que queremos y el costo es increíblemente bajo, así que estamos satisfechos.
  Sin embargo, la latencia está aumentando bastante, aunque no es algo muy crítico para nosotros. Aun así, me pregunto si adoptar Iceberg mejoraría esto.
  Me gustaría saber si alguien tiene experiencia con esto y, en general, esta arquitectura es realmente excelente.

  • Hay un buen resumen sobre este tema en la sección “Optimizing read performance” de https://aws.amazon.com/blogs/big-data/choosing-an-open-table...
    El objetivo principal de estas tecnologías es la gestión de datos a gran escala, pero también amplían las capacidades que ofrecen los formatos de almacenamiento sin procesar como Parquet. Así que podría ayudar, aunque habría que evaluar si realmente lo necesitan.
    No he usado BigQuery, pero podría tener funciones similares
    Primero habría que definir qué significa “latencia” aquí y qué nivel es “bastante alto”.
    Los almacenes de datos analíticos están diseñados para procesamiento por lotes eficiente, y buscar un solo registro no es el objetivo principal de esta arquitectura. Para búsquedas rápidas se necesita caché o indexación.
    En algunos casos, puede bastar con agregar limit 1 a la búsqueda de un solo registro.
    Hay que verificar que se esté usando un formato de almacenamiento eficiente como Parquet, y revisar los tamaños de archivo para asegurarse de que no exista el "problema de archivos pequeños"
    Después, también hay que comprobar si se están usando las funciones relevantes de BigQuery. Ejecuten explain sobre las consultas antes y después de estas revisiones; si no se usan claves de partición ni columnas indexadas, ningún sistema de big data devolverá resultados de búsqueda al instante.
  • Nuestra escala es aproximadamente 1/10 de esa, pero en visualización de datos los clientes, como es de esperarse, no tienen paciencia, así que la velocidad de las consultas es un tema importante.
    Si no están usando tablas de BigQuery como entrada para cómputo de alto rendimiento, yo me enfocaría en optimizar la herramienta de BI o en crear tablas analíticas que eviten latencia para el usuario final.
    Por ejemplo, recientemente materializamos joins de tablas de hechos/dimensiones y operaciones COALESCE para crear una tabla grande dedicada al análisis.
    Conceptualmente está “fuera” de la configuración normal de un data warehouse, pero como existe dentro de dbt, pudimos mantener la calidad de datos y el linaje.
    Gracias a eso eliminamos cálculos fijos de Tableau y redujimos alrededor de 95% el tiempo de carga/agrupación para los usuarios finales.
  • Si estás usando almacenamiento nativo de BigQuery, Iceberg no va a acelerar las consultas.
    Si son consultas federadas contra GCS/S3, sí podría acelerarlas.
  • Si no les molesta moverse a AWS, esto se ve bastante bien: https://www.boilingdata.com/

• Me encanta la actitud de “este artículo no pretende ser 100% exhaustivo ni probablemente sea el mejor punto de partida para la mayoría; lo escribo para mí. Siento que la mejor forma de aprender algo nuevo es obligarme a explicárselo de nuevo a otra persona”.
  Yo también empecé a adoptar este método en papel y en las notas de mi sitio web.

• Tenía muchas expectativas de profundizar en la era Iceberg de almacenes Parquet más gestionados.
  Pero el soporte para E/S rápida con GPU (GPUDirect/cuFile) todavía está varios años atrasado.
  Por eso, cada vez que intento llevarlo a clientes para cargas de trabajo de IA, me topo con esa pared.
  Al final parece algo que va a suceder, y es más una cuestión de “cuándo” que de “si es posible”. Sería genial poder tener lo mejor de ambos mundos.

  • Me da curiosidad cuál es el caso de uso. ¿Almacenamiento de datos de imágenes?
    Para almacenar texto, Parquet hoy es suficiente.
    PyTorch Data Loader y TF Data ofrecen clientes multihilo que leen por adelantado en paralelo, llenan búferes de memoria y luego intercambian datos con la GPU.
    Estoy de acuerdo en que S3 puede ser el cuello de botella aquí. Por eso usamos HopsFS sobre S3 como una caché NVMe coherente, distribuida globalmente.
    Anyscale también ha hecho algo parecido con una caché NVMe local para S3.
    Otro formato de archivo interesante es Lance, que es parecido a Parquet pero para datos de imágenes. Tiene además un índice rápido de E/S aleatoria para encontrar imágenes dentro del archivo.