Tablas delta en un arquitectura de medallón generalmente se utilizan para crear productos de datos. Estos productos de datos se utilizan para ciencia de datos, análisis de datos e informes. Sin embargo, una pregunta común es exponer también productos de datos a través de API REST. La idea es integrar estas API en aplicaciones web con requisitos de rendimiento más estrictos. Las preguntas importantes son las siguientes:
- ¿La lectura de datos de tablas delta es lo suficientemente rápida para servir aplicaciones web?
- ¿Se necesita una capa informática para que la solución sea más escalable?
- ¿Se necesita una capa de almacenamiento para lograr requisitos de rendimiento estrictos?
Para profundizar en estas preguntas, se evalúan tres arquitecturas de la siguiente manera: arquitectura A (bibliotecas en API), arquitectura B (capa informática) y arquitectura C (capa de almacenamiento). Vea también la imagen a continuación.
En el resto de la publicación del blog, se describen, implementan y prueban las tres arquitecturas. Luego se llega a una conclusión.
2.1 Arquitectura A: Bibliotecas en API usando DuckDB y PyArrow
En esta arquitectura, las API se conectan directamente a tablas delta y no hay ninguna capa informática intermedia. Esto implica que los datos se analizan utilizando la memoria y el cálculo de la propia API. Para mejorar el rendimiento, las bibliotecas Python de base de datos integrada DuckDB y PyArrow son usados. Estas bibliotecas garantizan que solo se carguen datos relevantes (por ejemplo, solo las columnas que necesita la API).
La ventaja de esta arquitectura es que no es necesario duplicar los datos y no se necesita ninguna capa entre la API y las tablas delta. Esto significa menos piezas móviles.
La desventaja de esta arquitectura es que es más difícil de escalar y todo el trabajo debe realizarse en la computación y la memoria de la propia API. Esto es especialmente desafiante si es necesario analizar una gran cantidad de datos. Esto puede provenir de muchos registros, columnas grandes y/o muchas solicitudes simultáneas.
2.2 Arquitectura B: capa informática utilizando Synapse, Databricks o Fabric
En esta arquitectura, las API se conectan a una capa informática y no directamente a las tablas delta. Esta capa informática obtiene datos de tablas delta y luego los analiza. La capa de computación puede ser Sinapsis azul, Ladrillos de datos de Azureo Tela de Microsoft y normalmente escala bien. Los datos no se duplican en la capa informática, aunque se puede aplicar el almacenamiento en caché en la capa informática. En lo que resta de este blog se prueba con Sinapsis sin servidor.
La ventaja de esta arquitectura es que no es necesario duplicar los datos y la arquitectura se escala bien. Además, se puede utilizar para procesar grandes conjuntos de datos.
La desventaja de esta arquitectura es que se necesita una capa adicional entre la API y las tablas delta. Esto significa que es necesario mantener y asegurar más piezas móviles.
2.3 Arquitectura C: Capa de almacenamiento optimizada usando Azure SQL o Cosmos DB
En esta arquitectura, las API no se conectan a tablas delta, sino a una capa de almacenamiento diferente en la que las tablas delta están duplicadas. La capa de almacenamiento diferente puede ser Azure SQL o Cosmos DB. La capa de almacenamiento se puede optimizar para una rápida recuperación de datos. En el resto de este blog se realizan pruebas con Azure SQL.
La ventaja de esta arquitectura es que la capa de almacenamiento se puede optimizar para leer datos rápidamente mediante índices, particiones y vistas materializadas. Este suele ser un requisito en escenarios de aplicaciones web de solicitud-respuesta.
La desventaja de esta arquitectura es que los datos deben duplicarse y se necesita una capa adicional entre la API y las tablas delta. Esto significa que es necesario mantener y asegurar más piezas móviles.
En el resto del blog se implementan y prueban las arquitecturas.
3.1 Implementación de arquitecturas
Para implementar las arquitecturas, se crea un proyecto GitHub que implementa las tres soluciones como se analizó en el capítulo anterior. El proyecto se puede encontrar en el siguiente enlace:
https://github.com/rebremer/expose-deltatable-via-restapi
Se implementará lo siguiente cuando se ejecute el proyecto GitHub:
- Una tabla delta que se origina a partir de un conjunto de datos de prueba estándar WideWorldImportedDW completo. El conjunto de datos de prueba consta de 50 millones de registros y 22 columnas con 1 columna de descripción grande.
- Todas las arquitecturas: Función de Azure actuando como API.
- Arquitectura B: Synapse Serverless actuando como capa informática.
- Arquitectura C: Azure SQL actuando como capa de almacenamiento optimizada.
Una vez implementadas, las pruebas se pueden ejecutar. Las pruebas se describen en el siguiente párrafo.
3.2 Pruebas de arquitecturas
Para probar la arquitectura, se aplicarán diferentes tipos de consultas y diferentes escalamientos. Los diferentes tipos de consultas se pueden describir de la siguiente manera:
- Busque 20 registros con 11 columnas pequeñas (char, entero, fecha y hora).
- Busque 20 registros con 2 columnas, incluida una columna de descripción grande que contiene más de 500 caracteres por campo.
- Agregación de datos usando agrupar por, tener, máximo, promedio.
Las consultas se describen a continuación.
-- Query 1: Point look up 11 columns without large texts
SELECT SaleKey, TaxAmount, CityKey, CustomerKey, BillToCustomerKey, SalespersonKey, DeliveryDateKey, Package
FROM silver_fact_sale
WHERE CityKey=41749 and SalespersonKey=40 and CustomerKey=397 and TaxAmount > 20
-- Query 2: Description column with more than 500 characters
SELECT SaleKey, Description
FROM silver_fact_sale
WHERE CityKey=41749 and SalespersonKey=40 and CustomerKey=397 and TaxAmount > 20
-- Query 3: Aggregation
SELECT MAX(DeliveryDateKey), CityKey, AVG(TaxAmount)
FROM silver_fact_sale
GROUP BY CityKey
HAVING COUNT(CityKey) > 10
La escala se puede describir de la siguiente manera:
- Para la arquitectura A, el procesamiento de datos se realizará en la propia API. Esto significa que el cálculo y la memoria de la API se utilizan a través de su plan de servicio de aplicaciones. Estos serán probados con ambos SKU Básico (1 núcleo y 1,75 GB de memoria) y SKU P1V3 SKU (2 núcleos, 8 GB de memoria). Para las arquitecturas B y C, esto no es relevante, ya que el procesamiento se realiza en otro lugar.
- Para la arquitectura B, se utiliza Synapse Serverless. El escalado se realizará automáticamente.
- Para la arquitectura C, una base de datos Azure SQL de nivel estándar Se toma con 125 DTU. Se probará sin índice y con índice en CityKey.
En el siguiente párrafo se describen los resultados.
3.3 Resultados
Después del despliegue y prueba de las arquitecturas, se pueden obtener los resultados. Este es un resumen de los resultados:
La arquitectura A no se puede implementar con SKU B1. En caso de que se utilice SKU P1V3, los resultados se pueden calcular en 15 segundos en caso de que el tamaño de la columna no sea demasiado grande. Tenga en cuenta que todos los datos se analizan en el plan de servicio de la aplicación API. Si se cargan demasiados datos (ya sea a través de muchas filas, columnas grandes y/o muchas solicitudes simultáneas), esta arquitectura es difícil de escalar.
La arquitectura B que utiliza Synapse Serverless funciona en 10 a 15 segundos. El cálculo se realiza en Synapse Serverless, que se escala automáticamente para recuperar y analizar los datos. El rendimiento es consistente para los tres tipos de consultas.
La arquitectura C que utiliza Azure SQL funciona mejor cuando se crean índices. Para las consultas de búsqueda 1 y 2, la API responde en aproximadamente 1 segundo. La consulta 3 requiere un escaneo completo de la tabla y su rendimiento es más o menos igual al de otras soluciones.
Tablas delta en un arquitectura de medallón generalmente se utilizan para crear productos de datos. Estos productos de datos se utilizan para ciencia de datos, análisis de datos e informes. Sin embargo, una pregunta común es exponer también tablas delta a través de API REST. En esta publicación de blog, se describen tres arquitecturas con sus pros y sus contras.
Arquitectura A: Bibliotecas en API usando DuckDB y PyArrow.
En esta arquitectura, las API se conectan directamente a tablas delta y no hay ninguna capa intermedia. Esto implica que todos los datos se analizan en la memoria y el cálculo de la función de Azure.
- La ventaja de esta arquitectura es que no se necesitan recursos adicionales. Esto significa menos piezas móviles que necesitan mantenimiento y seguridad.
- La desventaja de esta arquitectura es que no se escala bien, ya que todos los datos deben analizarse en la propia API. Por lo tanto, sólo se utilizará para pequeñas cantidades de datos.
Arquitectura B: capa informática utilizando Synapse, Databricks o Fabric.
En esta arquitectura, las API se conectan a una capa informática. Esta capa informática recupera y analiza datos de tablas delta.
- La ventaja de esta arquitectura es que se escala bien y los datos no se duplican. Funciona bien para consultas que realizan agregaciones y analizan grandes conjuntos de datos.
- La desventaja de esta arquitectura es que no es posible obtener respuestas. en 5 segundos para consultas de búsqueda consistentes. Además, es necesario asegurar y mantener recursos adicionales.
Arquitectura C: capa de almacenamiento optimizada mediante Azure SQL o Cosmos DB.
En esta arquitectura, las API se conectan a una capa de almacenamiento optimizada. Las tablas delta se duplican de antemano en esta capa de almacenamiento y la capa de almacenamiento se utiliza para recuperar y analizar los datos.
- La ventaja de esta arquitectura es que se puede optimizar para consultas rápidas mediante índices, particiones y vistas materializadas. Este suele ser un requisito para las aplicaciones web de solicitud y respuesta.
- La desventaja de esta arquitectura es que los datos se duplican en una capa de almacenamiento diferente, que debe mantenerse sincronizada. Además, es necesario asegurar y mantener recursos adicionales.
Desafortunadamente, no existe una solución mágica. Este artículo tuvo como objetivo brindar orientación para elegir la mejor arquitectura para exponer tablas delta a través de API REST.