Presentado recientemente por AWS, S3 Tables proporciona tablas Apache Iceberg totalmente administradas directamente en S3.

En este post, explicamos brevemente qué significa esto y su importancia, además de explorar algunas de sus principales características y limitaciones. A continuación, ofreceremos algunas pautas útiles para analizar si esta herramienta es adecuada para su pila de datos y cómo interactuar con los datos guardados en ella.

Presentamos las tablas Amazon S3

Las tablas de Amazon S3 proporcionan almacenamiento de S3 para datos tabulares, representados en columnas y filas, como en una tabla de base de datos SQL. Estos datos se almacenan en un nuevo tipo de bucket: a cubo de mesa, donde las tablas son subrecursos.

Los cubos de mesa permiten almacenar mesas en Iceberg Apache formato, que permite el uso de SQL estándar para consultar sus tablas con cualquiera de los motores compatibles con Iceberg, como Amazon Athena, Amazon Redshift y Apache Spark.

Antes de profundizar en las propias tablas S3, repasemos algunos conceptos clave relacionados con ellas: Apache Iceberg y Data Lakehouses.

¿Qué es Apache Iceberg?

Apache Iceberg es un formato de tabla de código abierto para grandes conjuntos de datos analíticos. Es añade una capa de abstracción a Object Storage, como S3, lo que permite que muchos motores diferentes puedan consultar los datos de forma fiable y eficaz.

Esta capa de abstracción habilita las características de un lago de datos que son típicas de los almacenes de datos y las bases de datos relacionales, lo que a menudo se denomina Datos Lakehouse:

• Lagos de datos permiten a los usuarios almacenar grandes volúmenes de datos a un bajo costo, a la vez que proporcionan escalabilidad y flexibilidad. Sin embargo, carecen de algunas capacidades cruciales para administrar estos datos, y a menudo se convierten en pantanos de datos. Dificultan la gobernanza de los datos y la aplicación de la calidad de los datos, y no están optimizados para el rendimiento de las consultas.
  
• Data Lakehouses añada la capa de abstracción para proporcionar, entre otras funciones, soporte para transacciones ACID y evolución de esquemas, sin dejar de admitir el almacenamiento en sistemas rentables como Amazon S3.

Si bien hay algunos competidores propietarios, como Delta Lake de Databricks, Iceberg se ha convertido en la standard for Data Lakehouse tablakehouse formats. Ofrece una verdadera interoperabilidad, no depende de ningún proveedor y es ampliamente adoptado por plataformas líderes como Snowflake, Databricks y Dremio.

Además de permitir el uso de sentencias SQL en los datos subyacentes y en la evolución del esquema, Apache Iceberg admite la partición de datos y administra el control de versiones de los datos, lo que permite viajar en el tiempo y retroceder a estados anteriores. También está diseñado para ser escalable, por lo que es ideal para administrar tablas de más de cientos de gigabytes.

Opciones de implementación de Data Lakehouse

Al diseñar e implementar un Data Lakehouse, tradicionalmente había dos opciones principales:

• Lagos de datos autogestionados: Que incluyen una capa de almacenamiento de datos, a menudo en S3 estándar o Google Cloud Storage, y un formato de tabla abierta, normalmente Apache Iceberg. Esta opción ofrece flexibilidad y bajos costos de almacenamiento. Sin embargo, se requiere un alto grado de madurez operativa para administrar el catálogo, optimizar el tamaño de los archivos y gestionar las escrituras simultáneas.

• Plataformas propietarias externas: Reducen el mantenimiento y ofrecen un rendimiento increíble, pero a menudo conllevan tarifas de licencia, altos costos de procesamiento y cierto grado de dependencia de un proveedor. Algunos ejemplos de estas plataformas son Databricks y Snowflake.

Características principales de las mesas S3

Lo que diferencia a estos nuevos buckets de Amazon S3 no es solo que admiten datos tabulares, sino que los administradores de forma activa. Tradicionalmente, mantener un lago de datos implicaba administrar cuidadosamente los metadatos y los tamaños de los archivos, y las tablas de S3 cambian esa dinámica.

Esa administración es un factor clave en las casas lacustres modernas, ya que su obstáculo más importante es la degradación del diseño de los datos, a menudo denominado problema de archivos pequeños. Cuando se transmiten datos de forma continua o se ejecutan procesos frecuentes de ingesta por microlotes, se escriben miles de archivos fragmentados por hora. Esta hiperfragmentación provoca errores en cascada en toda la arquitectura: aumenta el tamaño de las listas de manifiestos de Iceberg, desborda el catálogo de metadatos e impone una enorme sobrecarga al motor de consultas al abrir archivos. Precisamente por eso, AWS presentó S3 Tables, que integra el mantenimiento automatizado de las tablas de forma nativa en la capa de almacenamiento.

Así que, básicamente, Amazon S3 Tables ofrece un punto óptimo entre la implementación de Iceberg autogestionado y el aprovechamiento de las plataformas externas, que utilizan formatos y complementos propietarios.

Algunas de sus principales características son las siguientes:

• Integrated support for Apache Iceberg
  Las tablas de estos cubos se almacenan de forma nativa en formato Iceberg, lo que elimina la necesidad de añadir manualmente la capa de abstracción sobre los archivos sin formato en S3. Como mencionamos anteriormente, Iceberg incluye una variedad de funciones para optimizar el rendimiento de las consultas y es el formato de tabla abierta estándar, que utilizan la mayoría de los proveedores.
  
  
• Mantenimiento y optimización gestionados de tablas
  S3 realiza de forma continua y automática las siguientes operaciones de mantenimiento:  
  
  • Compactacion: combinación de archivos pequeños en archivos más grandes para reducir la sobrecarga de metadatos y hacer que el escaneo de consultas sea más eficiente.
  • Instantáneas administration: hacen caducar las instantáneas antiguas en función de períodos de retención configurables, lo que convierte los archivos de datos correspondientes en no actualizados y los limpia.
  • Eliminación de archivos sin referencia: elimina los archivos de datos y metadatos a los que ninguna instantánea ya no hace referencia.
  • Caducidad del registro: eliminación de registros caducados en función de una columna de marca de tiempo, disponible con S3 Tables Intelligent-Tiering.

Estas operaciones aumentan el rendimiento de las tablas (mantienen los metadatos ajustados para que los motores de consulta puedan consumirlos fácilmente) y, al mismo tiempo, reducen los costos de almacenamiento. La automatización agiliza el funcionamiento de los lagos de datos a escala al reducir la necesidad de administración y optimización manuales.

• Disacoplamiento entre almacenamiento y computación
  S3 Tables expone un punto final del catálogo REST de Iceberg, que es el estándar emergente para la interoperabilidad del catálogo de Iceberg. Todos los motores de consulta compatibles con Iceberg pueden leer y escribir directamente en sus tablas. Esto permite separar por completo la capa de almacenamiento de los motores de procesamiento.
  
  
• High performance
  S3 Tables está optimizado para las altas exigencias de simultaneidad de los análisis modernos, ya que proporciona mayores transacciones por segundo (TPS) y un mejor rendimiento de consultas en comparación con las tablas autogestionadas de los cubos de uso general de S3. También ofrece la misma durabilidad, disponibilidad y escalabilidad que los cubos S3 normales.‍

• Access and security administration
  El acceso y los permisos a los grupos de tablas, los espacios de nombres de tablas y las tablas individuales se pueden administrar con AWS Identity and Access Management (IAM), lo que facilita la gobernanza de los datos y lo integra en el sistema de administración de seguridad existente para otros recursos en la nube de AWS.

Limitaciones de las mesas S3

Si bien Amazon S3 Tables ofrece una variedad de funciones sólidas, también ofrece ventajas y desventajas en cuanto al control, el costo y la flexibilidad, en comparación con los catálogos Iceberg autogestionados o las plataformas patentadas de Lakehouse (como Databricks o Snowflake). Algunas de sus principales limitaciones son las siguientes:

• La disponibilidad regional no está garantizada
  No todas las regiones de AWS admiten este servicio todavía, por lo que debe comprobar la disponibilidad actual para las regiones de destino.
  
  
• Flexibilidad limitada de clases de almacenamiento
  Uno de los puntos fuertes de S3 es su variedad de niveles de almacenamiento, pero las tablas S3 son más restrictivas y solo admiten S3 Standard e Intelligent-Tiering. No se admiten los niveles fríos de forma individual.
  
  
• Formato de archivo único
  En los cubos de tablas, Iceberg es el único formato habilitado; no puede almacenar registros, CSV o imágenes sin procesar en ellos.
  
  
• Se admiten menos métodos de accesoA diferencia del S3 estándar, no puede generar un URL prefirmada para dar a un tercero acceso temporal a un archivo de datos específico. El acceso debe realizarse a través del catálogo REST de Iceberg. Además, los cubos de mesa no son compatibles políticas de acceso público, se debe acceder a todos los datos mediante la API de AWS autenticadas o motores integrados.‍

• Aplicación de mayúsculas y minúsculasPara garantizar la compatibilidad con todos los servicios de AWS Analytics, los nombres y las definiciones de las tablas deben utilizar letras minúsculas.

Use casos en los que las mesas S3 brillan

Hemos descrito las características de Data Lakehouses, Iceberg y S3 Tables, pero en la práctica: ¿cómo identificar si una solución de datos específica se beneficiará de la implementación de un Data Lakehouse y, más específicamente, del uso de S3 Tables? Estas son algunas pautas que le ayudarán a responder estas preguntas.

When need a Data Lakehouse?

Necesita una capa de abstracción cuando su lago de datos comience a sentirse como un pantano de datos: encuentra datos corruptos debido a escrituras parciales y hay datos redundantes o no validados en sus archivos. Además, si necesita administrar los archivos fila por fila en lugar de hacerlo como una unidad completa y sus esquemas evolucionan con frecuencia, es esencial contar con una capa de abstracción con un formato de tabla.

Un Data Lakehouse es ideal para implementar el almacenamiento Bronze o Raw Data en su plataforma de datos, ya que simplifica la gobernanza de los datos y reduce la duplicación de datos y los costos de infraestructura. Permite a las organizaciones realizar análisis de SQL de alto rendimiento junto con el aprendizaje automático y la transmisión en tiempo real.

¿Cuándo S3 Tables es la elección correcta?

Tras identificar la necesidad de un Data Lakehouse, ¿qué hace que S3 Tables sea especialmente adecuado? Estas son algunas características que pueden hacer que un caso específico sea un buen candidato para la implementación de S3 Tables:

• AWS como principal proveedor de servicios en la nube
  Si la infraestructura de nube de su organización se basa principalmente en AWS, S3 Tables es un recurso de AWS de primera clase que se integra perfectamente en su infraestructura principal. Puede crear puntos de enlace de interfaz de VPC específicos, aplicar políticas de IAM, implementar canalizaciones de ingestión sin código con herramientas como Amazon Data Firehose, etc.
  
  
• Necesidades de cumplimiento normativo y auditoría
  Industrias como la tecnología financiera o la atención médica a menudo requieren informes puntuales o la posibilidad de viajar en el tiempo y ver el estado de ciertas tablas en una fecha específica. Al aprovechar la administración de versiones nativas de Iceberg en un entorno S3 administrado, se obtiene un control de versiones y una auditoría integrados. Puede consultar los estados de los datos históricos sin complejos procesos de archivado manual.

• Ingestión de streaming a alta velocidad
  S3 Tables ofrece un rendimiento considerablemente mejor para las cargas de trabajo de análisis y streaming.
  
  • Soporta hasta 10 veces más transacciones por segundo que un Iceberg Lakehouse autogestionado en buckets S3 estándar, lo cual es fundamental para las cargas de trabajo con escrituras simultáneas frecuentes desde múltiples canalizaciones.
  • Como el rendimiento de las consultas depende en gran medida del mantenimiento de las tablas, las empresas con canales de ingesta de datos a alta velocidad (como el streaming o las actualizaciones frecuentes de ETL) se beneficiarán enormemente de la optimización automática de S3 Tables.
    
    
• Ecosistemas con múltiples proveedores
  En las organizaciones en las que se utilizan muchos motores de consulta y lenguajes de programación diferentes, la interoperabilidad que ofrece el punto final del catálogo REST de Iceberg garantiza el acceso a los datos a todos los usuarios y, al mismo tiempo, mantiene una única versión de los datos. Por ejemplo: el equipo de ingeniería de datos usa Spark, el equipo de inteligencia empresarial usa Athena o Snowflake, y el equipo de ciencia de datos usa Python, y todos se conectan al mismo Data Lakehouse.

¿Cuándo S3 Tables puede no ser la mejor opción?

También hay algunas situaciones en las que las Lakehouses autogestionadas o las herramientas propietarias pueden ser la mejor opción, por ejemplo:

• Necesidades de control de mantenimiento y flexibilidad
  Si necesita un control total sobre el diseño de los archivos, las clases de almacenamiento, las políticas del ciclo de vida y las propiedades de las tablas Iceberg, sin las restricciones que imponen los servicios gestionados. En una configuración autogestionada, puedes decidir exactamente cuándo ejecutar la compactación, por ejemplo.
  
  
• Cargas de trabajo de archivado sensibles a los costos
  Si tiene una gran cantidad de datos inactivos, a los que rara vez se accede pero que deben conservarse durante años, los depósitos de uso general ofrecen más opciones de clases de almacenamiento, como Glacier Instant Retrieval o Standard-IA. El costo de guardarlos en un contenedor S3 Table será considerablemente mayor.

• Iceberg data different requirements
  Si necesita almacenar tablas Iceberg junto con datos no tabulares (imágenes, registros, artefactos de aprendizaje automático) en el mismo depósito, se requieren depósitos de uso general.

Comprensión de los costos

Al evaluar las tablas S3 como un componente de su plataforma de datos, es importante tener en cuenta el costo total de propiedad (TCO) y no solo el costo de almacenamiento. Si bien los precios de almacenamiento de S3 Tables están estructurados de manera diferente a los del S3 estándar (y son ligeramente más altos por GB), la verdadera diferencia radica en el tiempo de procesamiento e ingeniería.

Con S3 Tables, paga una tarifa nominal por la optimización de tablas sin servidor ejecutada por AWS. Sin embargo, esto elimina la necesidad de crear y pagar sus propios clústeres de EMR o Glue únicamente para ejecutar trabajos de OPTIMIZE, VACUUM o compactación. Esto es especialmente importante en los casos en los que se escriben con alta frecuencia y hay varias tablas, ya que se necesita una mayor compactación y el coste operativo del mantenimiento aumenta.

Si se tienen en cuenta los costes informáticos ahorrados y las horas de ingeniería que se recuperan al no tener que crear y supervisar sus propios procesos de mantenimiento, S3 Tables suele reducir el coste total de propiedad.

Comentarios sobre el rendimiento de las consultas

Otra consideración importante a la hora de decidir la infraestructura de su Data Lakehouse es el rendimiento resultante de las consultas de sus datos. Si bien este tema es complejo y requeriría una publicación extensa por sí solo, hemos recopilado algunos comentarios importantes al respecto.

Lo primero que hay que saber es que el rendimiento de las consultas y los costos de procesamiento en Apache Iceberg dependen de una combinación de factores como: la arquitectura del motor de ejecución, la eficiencia de las estructuras de archivos subyacentes, la implementación del catálogo de metadatos y las rutinas de mantenimiento aplicadas a Lakehouse.

Para seleccionar el motor de consultas que consumirá su Data Lakehouse, hay dos opciones principales:

• Plataformas o almacenes de datos propietarios externos
  Como vimos, estas plataformas, como Databricks y Snowflake, pueden alojar todo su Data Lakehouse, pero también proporcionan la tecnología para consultarlo. Cada motor tiene sus principales modelos de ejecución y asignación de recursos, así como sus mecanismos de gestión de la simultaneidad y sus filosofías de optimización. En consecuencia, cada uno tiene las cargas de trabajo objetivo para las que es más adecuado.
  También pueden consumir datos que residen en Lakehouses externos, como las tablas S3 y las opciones autogestionadas. Sin embargo, en algunos casos, no pueden ofrecer el mismo rendimiento en estas fuentes que en las internas.

• Motores de consulta federados
  Estas herramientas permiten una arquitectura de datos totalmente descentralizada en la que los datos permanecen exclusivamente en Lakehouses o tablas S3 autogestionadas, y proporcionan acceso directo a SQL. Los motores más destacados de esta categoría son Amazon Athena y Trino. Si bien ambos motores están diseñados para la ejecución distribuida de SQL sobre el almacenamiento de objetos, sus modelos operativos son muy diferentes.
  
  Estos motores son muy rentables para la exploración ad hoc poco frecuente. Para los escenarios de BI, si desea crear informes empresariales sofisticados a partir de datos históricos, una herramienta de almacenamiento de datos, como Amazon Redshift, es la opción más adecuada.

Independientemente de la herramienta seleccionada, el rendimiento final del motor de consultas depende en gran medida del estado físico de los datos que se encuentran en el lago. Como mencionamos anteriormente, las Lakehouses modernas tienden a sufrir de problema de archivos pequeños. Una solución gestionada minimiza los esfuerzos para prevenir este problema, mientras que, para las organizaciones que utilizan tablas Iceberg autogestionadas en almacenamiento de uso general, la implementación de una rutina de mantenimiento rigurosa y automatizada no es negociable.

Cómo interactuar con las tablas de Amazon S3

Para acceder a las tablas almacenadas en un bucket de tablas, es necesario integrarlo con aplicaciones de análisis compatibles con Apache Iceberg. Hay dos formas principales de hacerlo:

• Usos AWS Glue data catalog, para integrarse principalmente con los servicios de análisis de AWS y conectarse con otros clientes de Iceberg de terceros.
• Aprovechando el Punto final REST Iceberg of Amazon S3 Tables para conectarse directamente a motores de consulta de código abierto y otros servicios.

AWS Glue data catalog

Puede integrar los cubos de tablas con los servicios de análisis de Data Catalog y AWS mediante los controles de acceso de IAM de forma predeterminada u, de forma opcional, utilizar los controles de acceso de Lake Formation.

Para realizar esta integración, debe habilitar la «Integración con los servicios de análisis de AWS» para sus cubos de tabla y Amazon S3 agrega el catálogo denominado catalog of tablas s3 como federado catalog in AWS Glue, in the current region. A continuación, todos los grupos de tablas, espacios de nombres y tablas actuales y futuros se rellenan en el catálogo de datos de AWS Glue de esa región, siguiendo esta equivalencia: los grupos de tablas se asignan como catálogos, los espacios de nombres como bases de datos y las tablas siguen siendo tablas.

• Puede crear tablas de Apache Iceberg en grupos de tablas y acceder a ellas mediante los siguientes motores de análisis de AWS: Amazon Athena, Amazon Redshift, Amazon EMR, Amazon Data Firehose, AWS Glue ETL, Quick y Querying S3 Tables con SageMaker Unified Studio.

• Además, puede utilizar motores de análisis de terceros que también sean compatibles con Iceberg, a través del REST point of AWS Glue Iceberg, utilizando cualquier cliente de Iceberg, incluidos Spark, PyIceberg y más.

Punto final REST Iceberg of Amazon S3 Tables

Puede usar el punto de enlace REST Iceberg de Amazon S3 Tables para acceder a sus tablas directamente desde cualquier cliente compatible con Iceberg REST a través de puntos de enlace HTTP, para crear, actualizar o consultar tablas en cubos de tablas de S3.

El punto final implementa un conjunto de API REST de Iceberg estandarizadas especificadas en la especificación de API abierta del catálogo REST de Apache Iceberg. El punto final funciona traduciendo las operaciones de la API REST de Iceberg en las operaciones correspondientes de S3 Tables.

Los siguientes motores de consulta y servicios de análisis de AWS pueden acceder a las tablas de esta manera: cualquier cliente de Iceberg, incluidos Spark, PyIceberg y más, así como Amazon EMR y AWS Glue ETL.

Example

Para usar el Punto final REST Iceberg of Amazon S3 Tables con PyIceberg, especifique las siguientes propiedades de configuración de la aplicación:

rest_catalog = load_catalog(
  catalog_name, 
  **{
    "type": "rest",    
    "warehouse":"arn:aws:s3tables:<Region>:<accountID>:bucket/<bucketname>",
    "uri": "https://s3tables.<Region>.amazonaws.com/iceberg",
    "rest.sigv4-enabled": "true",
    "rest.signing-name": "s3tables",
    "rest.signing-region": "<Region>"
  }
) 
      

Luego, puede usar la función de escaneo PyIceberg para leer los datos de sus tablas de Iceberg, por ejemplo. Puedes filtrar filas, seleccionar columnas específicas y limitar la cantidad de registros devueltos:

table = rest_catalog.load_table(f"{database_name}.{table_name}")
scan_df = table.scan(
    row_filter=(
        f"city = 'Amsterdam'"
    ),
    selected_fields=("city", "lat"),
    limit=100,
).to_pandas()

print(scan_df)

Conclusión

Para los Data Stacks modernos, la implementación de Data Lakehouses suele ser un requisito, principalmente para implementar la capa de datos sin procesar, y Apache Iceberg se ha convertido en el formato estándar para ello.

Al convertir Apache Iceberg en una capa de almacenamiento sin servidor y totalmente gestionada, AWS permite a los equipos recuperar las horas dedicadas a la administración de bases de datos y centrarse en obtener el valor real de sus datos. Si su equipo tiene problemas con el mantenimiento de Iceberg, o si está buscando construir desde cero un Lakehouse rentable y de alto rendimiento, S3 Tables debería estar en lo más alto de su lista de evaluación.

¿Quieres modernizar tu pila de datos? En Marvik.ai, ayudamos a los equipos a diseñar e implementar soluciones de datos escalables y preparadas para el futuro. Ponte en contacto con nosotros para ver cómo podemos ayudarte a aprovechar S3 Tables y Apache Iceberg para tus casos de uso específicos.

Fuentes

• Cómo trabajar con tablas y cubos de mesa de Amazon S3 - Amazon Simple Storage Service  
• Iceberg Apache 
• Lagos de datos modernos: orientación prescriptiva de AWS 
• Amazon S3 Tables and Apache Iceberg autogestionado in S3: análisis técnico detallado para empresas emergentes | AWS Builder Center 
• Cubos de mesa - Amazon Simple Storage Service 
• Acceso a los datos de la tabla - Amazon Simple Storage Service
• Descripción general de la integración de Amazon S3 Tables con los servicios de análisis de AWS 
• Integración de Amazon S3 Tables con los servicios de análisis de AWS
• Acceso a las tablas mediante el punto de enlace REST Iceberg de Amazon S3 Tables - Amazon Simple Storage Service 
• Cómo trabajar con tablas Iceberg mediante PyIceberg - Guía prescriptiva de AWS ‍
• ¿Cuándo debo usar Athena? - Amazon Atenea