Formato de tabla Iceberg, una buena idea - una especificación mal definida - Parte 2 de 2

Problemas con la especificación de Iceberg

• Problema grave de la especificación de Iceberg: la especificación de Iceberg no es un intento serio de resolver los problemas de metadatos de los data lakes a gran escala.
• Lecciones históricas: en la primera parte se volvió a la historia para aprender de las lecciones del pasado, y se presentó el “problema de administración del espacio” que las bases de datos deben resolver.
  • Elementos del problema:
    1. Fragmentación del espacio
    2. Control de concurrencia de grano fino
    3. Atomicidad sobre múltiples objetos
    4. Desajuste de impedancia entre filas y archivos
    5. Acceso a metadatos de baja latencia y alto rendimiento
• Importancia de los formatos abiertos: está 100% a favor de usar formatos abiertos en todo el stack, y especialmente entusiasmado con usar Parquet como formato de almacenamiento común para datos tabulares.
• Diferencia entre archivos Parquet y tablas de base de datos: el hecho de tener un conjunto de archivos Parquet no los convierte en una tabla de base de datos. Una tabla de base de datos es más que un simple conjunto de filas.

Resumen del problema de los metadatos

• Problema de administración del espacio: se vuelve a enfatizar que las bases de datos deben resolver varios problemas.
• Necesidad de metadatos: para hacer que varios archivos Parquet parezcan una tabla de base de datos, se necesitan los siguientes metadatos:
  1. Una lista de ubicaciones de todos los archivos que componen la tabla
  2. Metadatos aproximados para cada archivo
  3. Un mecanismo de control transaccional para agregar o eliminar archivos
  4. Una forma de evolucionar el esquema de la tabla
• Búsqueda de ubicaciones de archivos: para tratar un conjunto de archivos Parquet como una sola tabla, se necesita un mecanismo para encontrar los archivos.
• Importancia de los metadatos: cada archivo necesita metadatos adicionales para encontrar rápidamente las filas de interés.

Archivos Parquet y tablas de base de datos

• Definición de archivo Parquet: Parquet ofrece un formato de datos tabular y autodescriptivo.
• Definición de tabla de base de datos: una tabla de base de datos no es simplemente un conjunto de filas, sino que requiere varios metadatos y control transaccional.
• Condiciones para usar archivos Parquet como si fueran tablas:
  1. Lista de ubicaciones de archivos
  2. Metadatos de cada archivo
  3. Mecanismo de control transaccional para agregar y eliminar archivos
  4. Método para evolucionar el esquema de la tabla
• Diferencia entre archivos y tablas: aunque los archivos Parquet tengan el mismo diseño de columnas, eso no hace que se vean como una tabla de base de datos.

Archivos manifest y listas

• Proceso de agregar datos: para que un cliente de Iceberg agregue datos a una tabla, debe pasar por los siguientes pasos:
  1. Escribir uno o más archivos Parquet en una ubicación específica (por ejemplo, S3).
  2. Escribir un archivo manifest que apunte a los archivos escritos en el paso 1.
  3. Escribir una nueva lista de manifests.
• Formato de los archivos manifest: los archivos manifest y las listas están en formato AVRO, que es comprimido y autodescriptivo.
• Contenido de los archivos manifest: los archivos manifest incluyen punteros a archivos Parquet y metadatos de cada columna.
• Problema del tamaño de los metadatos: almacenar los metadatos de esta forma hace que sean más grandes de lo necesario, y no permite comprimir reconociendo valores de cadenas comunes entre archivos.

Aumento de la carga sobre el cliente

• Responsabilidad del cliente: a lo largo de toda la especificación de Iceberg, el cliente tiene que hacer una enorme cantidad de trabajo de mantenimiento de registros para cambios simples.
• Problema de exactitud de los metadatos: si el cliente escribe mal alguna parte, el commit del nuevo snapshot debe verificarse a fondo y hay que comprobar que los datos del manifest se hayan escrito correctamente.
• Problema de seguridad: como el cliente debe escribir una lista de manifests que apunte a todos los archivos manifest, se exponen las ubicaciones de todos los archivos en S3.
• Importancia de la seguridad de los datos: dado el alto valor de los datos, hay que cuestionar por qué la especificación no trata la seguridad como máxima prioridad.

Defectos en la seguridad a nivel de fila

• Necesidad de seguridad a nivel de fila: incluso en países con regulación más laxa como Estados Unidos, se necesita seguridad a nivel de fila para proteger datos sensibles.
• GDPR en la UE: en Europa, leyes como el GDPR obligan a ser aún más cuidadosos con el acceso a los datos.
• Problema de acceso a los datos por parte del cliente: un cliente puede agregar datos a una tabla, pero no se puede restringir su acceso a los datos ya existentes.
• Gravedad del problema de seguridad: el hecho de que la especificación no priorice la seguridad debe hacer cuestionar cuánto valor se le da a la información de los data lakes.

El papel de los archivos de metadatos

• Creación de archivos de metadatos: después de escribir archivos Parquet, el cliente debe generar el archivo manifest correspondiente, leer la lista de manifests existente, crear una nueva lista de manifests y luego hacer commit de los datos.
• Proceso de commit: el commit se realiza escribiendo un archivo de metadatos (<prefix>.metadata.json).
• Elección del formato JSON: no está claro por qué el archivo de metadatos está en formato JSON, y eso da la impresión de una “diseñada por comité”.
• Repetición en los metadatos: el archivo de metadatos enumera todos los snapshots, lo que desperdicia espacio debido a la repetición de información.

Complejidad del proceso de commit

• Problema de atomicidad: el nuevo archivo de metadatos debe convertirse en el archivo más reciente y reemplazar atómicamente al archivo de metadatos anterior.
• Complejidad del procedimiento de commit: para hacer commit de una nueva versión de metadatos V+1, se deben seguir estos pasos:
  1. Generar un nuevo archivo de metadatos de la tabla con base en los metadatos actuales.
  2. Escribir los nuevos metadatos de la tabla en un archivo único.
  3. Solicitar al metastore que reemplace el puntero de metadatos de la tabla de V a V+1.
• Qué pasa si falla el swap: si el swap falla, significa que otro escritor ya generó V+1, por lo que el cliente debe volver al paso 1.
• Problema de condiciones de carrera: cuando varios clientes compiten, deben volver a leer el archivo de metadatos escrito por el cliente anterior y regenerar la lista de manifests y el archivo de metadatos.

Problemas del control de concurrencia optimista

• Realidad de la concurrencia: si no se espera contención sobre un recurso, da igual qué tipo de concurrencia se use.
• Cuando se espera contención: si dos clientes intentan cambiar el mismo valor, se debe usar un mecanismo de bloqueo.
• Límites del control de concurrencia optimista: en Iceberg, dos escrituras concurrentes siempre van a entrar en conflicto, y eso se debe a cómo está diseñada la especificación.
• La peor semántica de bloqueo: se está usando la peor semántica de bloqueo posible para los metadatos, aunque si solo se quiere agregar datos no debería hacer falta coordinación entre clientes.

Límites del swap de metadatos

• Centralización de metadatos: al centralizar los metadatos de la tabla en un solo archivo, se creó un único punto de contención para todas las escrituras.
• Carga sobre el cliente al reintentar: si un cliente falla, debe leer los datos escritos por el cliente anterior y volver a generar la lista de manifests y el archivo de metadatos.
• Velocidad del swap de metadatos: el servicio que realiza el swap de metadatos tiene que manejar reintentos, lo que provoca degradación del rendimiento.
• Número limitado de commits: debido a esta implementación simple de concurrencia, la cantidad de commits está limitada por el tiempo que tarda el reemplazo atómico del archivo de metadatos.

La necesidad de una base de datos

• Encontrar la ubicación del archivo de metadatos: un snapshot de una tabla Iceberg queda completamente descrito por el archivo metadata.json.
• Contradicción de la idea: Iceberg intenta definir un formato de metadatos basado solo en archivos, pero al final igual necesita una base de datos.
• Ventajas de las bases de datos: las bases de datos modernas pueden manejar cientos de miles de escrituras y escalar de forma distribuida.
• Comparación entre sistema de archivos y base de datos: guardar metadatos en una base de datos es más eficiente que guardarlos en archivos.

Fragmentación e inflado de metadatos

• Crecimiento del archivo metadata.json: el archivo metadata.json apunta al snapshot más reciente, y cada archivo de metadatos incluye un puntero inverso al snapshot anterior.
• Aumento continuo de los metadatos: los metadatos siguen creciendo, y eso afecta negativamente el rendimiento del data lake.
• Necesidad de limpieza periódica de metadatos: si se agregan datos continuamente al data lake, hay que limpiar los metadatos.
• Costo de las solicitudes HTTP: durante el proceso de borrar archivos de metadatos se generan solicitudes HTTP, lo que puede implicar costos.

Lectura de datos y planificación de consultas

• Papel de los archivos manifest: los archivos manifest contienen metadatos sobre los archivos Parquet.
• Complejidad de la planificación de consultas: para ejecutar una consulta, hay que leer secuencialmente la lista de manifests y los archivos manifest.
• Problema de costos: leer desde S3 tiene costo, y eso afecta la velocidad de ejecución de las consultas.
• Problema de fragmentación de metadatos: si los metadatos están fragmentados, la planificación de consultas se vuelve más compleja y el acceso a los datos más difícil.

Caching y dificultades en la planificación de consultas

• Cacheo de manifests: se pueden cachear los manifests, pero eso es ineficiente porque el tamaño de los metadatos sigue creciendo.
• Mantener válida la caché: hay que comprobar que la caché siga actualizada, lo que añade costo y complejidad.
• Carga sobre el cliente: todos los clientes tienen que cachear metadatos, y eso genera millones de solicitudes HTTP.
• Aumento de la complejidad: el uso del data lake se vuelve más complejo, y se necesitan soluciones adicionales para resolverlo.

Conclusión de la idea

• Crítica de la idea: la especificación de Iceberg no es una especificación seria para los metadatos de data lakes, y arrastra varios problemas.
• Resumen de los problemas: Iceberg agrega metadatos usando trabajo O(n), no puede manejar commits entre tablas y no resuelve el problema del inflado de metadatos.
• Límites de escalamiento: Iceberg no es adecuado para escalar y traslada demasiada complejidad al cliente.
• Pregunta para la industria: se plantea la pregunta de por qué ocurren estos problemas en la industria de TI.