Si trabajas con datos, sabes que la forma en la que los almacenamos y procesamos evoluciona a un ritmo vertiginoso. En ixpantia nos encanta ayudar a nuestros clientes a construir arquitecturas modernas, pero como reza el dicho: el buen juez por su casa empieza.
Recientemente, decidimos someter a nuestro propio Data Warehouse interno (al que llamamos de cariño ix_dw) a una cirugía mayor: migrar de una base de datos tradicional en Cloud SQL a una arquitectura serverless basada en Cloud Storage y BigQuery.
En este artículo, te contamos un poco sobre los conceptos detrás de esta decisión, los dolores que nos llevaron a dar el salto y por qué elegimos este camino.
Un Data Warehouse (DW) o repositorio centralizado de datos, es una arquitectura de datos diseñada específicamente para procesar, almacenar y disponibilizar datos en una organización, casi siempre para satisfacer necesidades de analítica. A diferencia de las bases de datos transaccionales, este tipo de arquitectura está optimizada para la consulta, el análisis de datos y la creación de productos de datos que soportan la toma de decisiones.
Tradicionalmente, las arquitecturas de DW se construyen utilizando un Sistema de Gestión de Bases de Datos (DBMS) como PostgreSQL o Microsoft SQL Server, alojado en un servidor que está encendido 24/7.Una arquitectura Serverless, es decir, sin servidor, cambia las reglas del juego. En lugar de tener un motor de base de datos encendido todo el tiempo procesando y almacenando, separamos el almacenamiento del cómputo. Los datos se guardan en su forma cruda y/o curada en servicios de almacenamiento en la nube (como S3 en AWS, Blob Storages en Azure o Cloud Storage en Google Cloud Platform) y solo utilizamos motores de consulta elásticos cuando realmente necesitamos procesar o leer esos datos.
El ix_dw 1.0 tenía, a muy alto nivel, esta arquitectura:
Nuestro ix_dw 1.0 estaba montado sobre una instancia de PostgreSQL en Cloud SQL, con ETLs (procesos de Extract, Transform, Load o Extracción, Transformación y Carga de datos) corriendo como contenedores en máquinas virtuales en GCP y aplicaciones internas que consumían los datos que corrían también como contenedores en otras máquinas virtuales así como tableros en Looker.
Esta arquitectura nos sirvió muy bien durante un tiempo, pero conforme fuimos creciendo y añadiendo más fuentes de datos y procesos, empezamos a sentir varias fricciones:
En resumen teníamos muchos cambios de estructura grandes por hacer.
Para resolver estos problemas, diseñamos una arquitectura congruente de un solo camino. Si bien varios de los dolores se podían resolver de otras formas, queríamos aprovechar el cambio para resolver los dolores y modernizar la arquitectura de un solo. Nos decidimos por almacenar los datos en Cloud Storage en formato Parquet (creando una capa cruda y una curada), y llevar a BigQuery únicamente aquellas tablas que necesitan ser consumidas por herramientas de BI como Looker (que no pueden leer parquets directamente).
El diagrama de arquitectura a alto nivel se ve así ahora:
Tomamos esta decisión por los siguientes beneficios:
La teoría suena excelente, pero sabemos que el verdadero reto está en la implementación técnica. En un próximo blogpost te mostraremos exactamente cómo hicimos esta migración. Compartiremos detalles de cómo estructuramos los buckets, cómo escribimos los ETLs, y te enseñaremos ejemplos de código reales utilizando polars en R para interactuar con esos archivos Parquet a velocidades increíbles.
Notas
[1] Cómputo: Capacidad de procesamiento de un sistema para organizar, calcular y analizar hechos o valores aislados, convirtiéndolos en información con significado.
[2] Whitelisting: Mecanismo de control que permite el acceso o ejecución solo a direcciones IP previamente aprobadas, denegando automáticamente todo lo demás como medida de prevención.