Almacenamiento Apache Iceberg y análisis de Pandas: Parte I

Generalmente me gusta probar cosas nuevas, y la tecnología no es la excepción. Así que decidí investigar más a fondo la mecánica subyacente de Apache Iceberg, y en concreto, la implementación de Python, PyIceberg.

Apache Iceberg with Industrial Piping

Estaba analizando específicamente algunos elementos clave que suelen formar parte de las prácticas de gestión de datos, independientemente de la tecnología:

• Controles de calidad de datos: ¿Puedo validar esquemas como mínimo con tipificación de datos, pero preferiblemente con inspección de valores?

  
  

• Integridad de los datos: ¿se pueden evitar duplicados, aplicar claves y mantener cierto nivel de integridad referencial cuando los datos están vinculados entre estructuras de datos?

  
  

  
  

  
  

• Acceso a datos: ¿puede administrar la seguridad con acceso a nivel de fila? ¿El tiempo de acceso es robusto para que las recuperaciones y cargas sean razonables, es decir, las expectativas promedio para los usuarios, los servicios y las aplicaciones?

  
  

• Gestión de metadatos: ¿puedo tener esquemas que puedan evolucionar a través de múltiples versiones y tal vez brindarme la capacidad de revertir/deshacer cambios?

Si eres nuevo en PyIceberg, es una implementación en Python de Apache Iceberg sin necesidad de una JVM. Es de código abierto, así que el repositorio de GitHub de PyIceberg está aquí y puedes encontrar soporte de la comunidad aquí . El proyecto comenzó como una extensión para Apache Spark, luego para Flink y Hive.

Fundación Apache Arrow

Su mecánica de E/S de datos se basa en Apache Arrow , un proyecto lanzado para definir una especificación para datos tabulares y su intercambio entre sistemas, específicamente en el área de análisis en memoria. Arrow se escribió inicialmente en C y posteriormente se adaptó a varios otros lenguajes (véase el enlace "Implementaciones desde la página principal" más arriba).

En la parte inferior de la página de inicio, encontrará enlaces adicionales a libros de recetas para C++ , Java , Python y R , para que pueda empezar a implementarlos rápidamente. También está disponible la migración a lenguajes y kits de herramientas populares como C#, Rust, Ruby y MATLAB.

Si actualmente utiliza o planea utilizar los formatos Apache Parquet u ORC, probablemente encontrará que las bibliotecas de proveedores de la nube o motores de consulta obtienen y encapsulan las bibliotecas Arrow como una base inicial para las extensiones específicas de cada proveedor.

Extensiones de IA/ML

Hay extensiones CUDA para la comunidad AI/ML, pero con suerte evitará realizar transformaciones y manipulaciones de datos en recursos de GPU costosos; así obtendrá una mayor rentabilidad y eficiencia de procesamiento.

Creo que la falta de separación de preocupaciones para estas tareas centradas en datos es uno de los factores que impulsan la demanda de GPU y el bajo consumo de CPU para el entrenamiento y la ejecución de modelos de IA/ML. No se trata tanto de la falta de reconocimiento de que la separación es necesaria, sino del tiempo que lleva diseñarla y entregarla; es decir, no se realiza.

Las GPU no son procesadores de propósito general, como las CPU, y son más adecuadas (al menos hasta ahora) para cálculos de algoritmos y visualización. Se inventaron para calcular puntos de un triángulo en paralelo para su visualización gráfica. NVIDIA ofrece una introducción al tema del rendimiento de las GPU . A continuación, se presenta una descripción general básica de los procesadores basados en celdas (de los cuales las GPU son una variante) del Laboratorio de Supercomputación de Ohio (2007):

2007_tech_notes_jun_jul.pdf

Descargar PDF • 196KB

La clave reside en los casos de uso específicos para el uso de procesadores basados en celdas, ya que, en términos de desarrollo, la mayoría de los ingenieros se centran en un solo procesador y no en varios. Es necesario desarrollar y perfeccionar las habilidades de separación de cargas de trabajo para recursos computacionales específicos (fin del tema del interludio).

Apache Iceberg bajo las sábanas

El enfoque general para los metadatos y el almacenamiento de datos es garantizar la inmutabilidad, lo cual es sin duda una ventaja. ¿Por qué? En resumen, la concurrencia y el rendimiento del acceso a los datos escalan mejor con implementaciones de inmutabilidad (si se implementan correctamente), además de proporcionar trazabilidad a medida que el esquema y los datos evolucionan. Si utiliza productos RDBMS, el problema habitual de la fragmentación de datos (metadatos) e índices puede requerir ciclos de vigilancia y mantenimiento. Es especialmente importante en casos de análisis (ROLAP) o híbridos (OLTP + largo historial), pero desaparece con las implementaciones de inmutabilidad.

Como indiqué o insinué anteriormente, Iceberg encapsula y utiliza varias bibliotecas de proyectos Apache de Arrow, Parquet, ORC y AVRO. Estas se centran principalmente en operaciones de E/S, ya sean en memoria o de persistencia basada en archivos. Iceberg también utiliza considerablemente Pydantic para la implementación de metadatos en Python.

Los "modelos" para las estructuras de esquema se construyen y validan con Pydantic, y los objetos de metadatos se almacenan en un catálogo mediante un almacén persistente. Se puede acceder al almacén persistente mediante REST, un SGBD SQL, un almacén en memoria, Apache Hive, AWS Glue oun archivo personalizado . A continuación, se muestra una descripción general, obtenida de https://iceberg.apache.org/spec/, para mostrar su organización. La figura a continuación muestra algunos detalles adicionales: el archivo de metadatos es un archivo Apache AVRO y las listas de manifiestos están en formato JSON. Las propiedades de validación del esquema, junto con Pydantic, probablemente explican la elección de esta combinación.

Metadatos y calidad de los datos

La organización de metadatos comienza a nivel de espacio de nombres y consiste en una separación lógica o contextual de los datos. Si es necesario, puede realizar referencias entre espacios de nombres al acceder a los datos. Los objetos de tabla se crean bajo un espacio de nombres y proporcionan los tipos de implementación para los esquemas que puede encontrar aquí . Si necesita almacenar datos geoespaciales, Iceberg admite tipos geométricos y geográficos, además de ofrecer compatibilidad con CRS (sistema de referencia de coordenadas) e interpolación de bordes en la capa de metadatos. También está disponible la partición de datos y el linaje de filas, y el número de registros que se conservan para el linaje detallado se puede configurar al crear el catálogo.

Para ilustrar mejor el diagrama anterior, he incluido la salida del archivo de consola de las tablas Iceberg que creé para la implementación de ejemplo en la Parte II. Creé una carpeta "warehouse" en mi dispositivo, y el listado comienza en el espacio de nombres "docs". Analiza en detalle los datos y metadatos de "previsión".

Namespace and Table Organization

Data and Metadata for Forecasts Object

La implementación de Pydantic, especialmente al usar el modo "estricto" (metadatos y datos), cubre los puntos "Metadatos" y "Calidad de los datos" mencionados al principio del artículo. También ofrece controles de versiones de esquema en los metadatos, hasta el nivel de columna, y cuenta con excelentes mecanismos para facilitar la evolución del esquema. Los metadatos Iceberg ofrecen muchas variaciones implementadas mediante el equivalente de "restricciones" en RDBMS (no el DDL de tabla literal). Ofrece validación de tipos, designación de campos obligatorios e inspección de tamaño y precisión; sin embargo, carece de la aplicación de una lista de valores personalizada a campos específicos.

En mi experiencia, el uso de listas de valores suele ser más común en patrones de diseño OLTP que en casos de OLAP (analítica) para un RDBMS. Apache Iceberg está claramente diseñado para casos de uso analíticos, no para el procesamiento de transacciones. En general, es un buen punto de partida para la calidad de datos y los metadatos. Los atributos de valores predeterminados permiten implementar una clave sustituta equivalente o usar identificadores de campo .

No ofrece un equivalente a una clave principal o única, que es un tipo de restricción de base de datos que garantiza la unicidad independientemente de tener un índice asociado. Tampoco existe indexación administrada por el usuario, pero si ya es usuario de alguno de los formatos de archivo mencionados, no es nuevo y no se espera que exista. Garantizar la unicidad depende del usuario. Puede imponer la unicidad dentro de una estructura, por ejemplo, pero la entrega depende de usted; Iceberg no lo hará por usted.

Seguridad a nivel de fila

Las áreas desafiantes para Apache Iceberg son la RWA (seguridad de acceso a nivel de fila) y la integridad de los datos. Estoy evaluando lo que está integrado en las bibliotecas, no cómo se puede construir una solución para resolver esos problemas utilizando herramientas adicionales.

La seguridad de RWA no está integrada en las bibliotecas. Existen excelentes capacidades de filas y metadatos que pueden ayudar a diagnosticar problemas de calidad de los datos y proporcionar capacidades de cambio a lo largo del tiempo. Esto último podría ser muy útil en un caso de uso de series temporales. Sin embargo, la seguridad de RWA suele ser un requisito de seguridad corporativa; es de esperar que la integración con LDAP se implemente en algún momento para facilitar esto.

Integridad de los datos

Las capacidades de integridad de datos no se priorizan en Iceberg, quizás porque la tendencia en el acceso a datos de IA/ML ha sido desnormalizar las tablas de datos para que no se requieran claves foráneas, es decir, una sola tabla grande. Sin embargo, sí se presenta en casos de uso de análisis más tradicionales, donde existen múltiples tablas que requieren vínculos de relaciones (físicos o virtuales), por lo que sería una adición útil en esos casos. Incluso si solo se trata de información para rastrear en metadatos, esto mejora la validación. Es un área que se pasa por alto en Iceberg.

Acceso a datos

Los usuarios que actualmente utilizan cualquiera de los formatos de Apache Arrow mencionados anteriormente saben lo que obtienen con cada uno. Para grandes cantidades de almacenamiento de datos, Parquet suele usarse con frecuencia para conjuntos de datos grandes o muy grandes, especialmente si se requiere particionamiento para garantizar tiempos de respuesta razonables a las consultas. Realicé una pequeña implementación, que detallaré en la Parte II del artículo, donde se registran tiempos de respuesta simples. Pero como muchos saben, Parquet, especialmente si está bien particionado, responde muy bien a las solicitudes de consulta. Su formato en columnas está especialmente bien diseñado para adaptarse a los casos de uso de análisis de servicios.

En la siguiente parte del artículo, analizaré una implementación sencilla utilizando Apache Iceberg y datos financieros con algunas agregaciones de Python.