Reduce los costos de BigQuery y Looker con ClickHouse (Parte 1)

Esta es una serie de varias partes sobre el tema, dividida en bloques lógicos para configurar todo el proceso. Como hay muchas condiciones del tipo "if-then-else" por la complejidad del ecosistema y la tecnología, decidí dividir el artículo para tratar cada una por separado y no enredar la lectura. La primera parte cubre la mayor parte de la teoría y la segunda se enfoca en una implementación básica.

De entrada, si todavía no lo conoces, ClickHouse es un data warehouse que compite con BigQuery. Su carta de presentación es ser un datastore de altísimo rendimiento, capaz de ejecutar operaciones mucho más rápido que otros data warehouses del mercado. Esto lo vuelve ideal para almacenar y servir datos a workloads que lo consultan constantemente, como herramientas de BI tipo Looker.

Este artículo se escribió con la asistencia técnica de nuestro partner Aiven, proveedor líder de soluciones DBaaS, que además ofrece un servicio gestionado de ClickHouse. Para que el panorama quede completo, también incluyo detalles de ClickHouse, que cuenta con su propio servicio gestionado.

BigQuery es una excelente plataforma para análisis a gran escala o workloads de ML, y suele integrarse con herramientas de BI como Looker para tareas de visualización o reportes. Lamentablemente, al ejecutar consultas de este tipo, suelen aparecer problemas de rendimiento por restricciones de recursos o de costos. Y luego está el enorme gorila (a veces enojado) en la sala: el costo por consulta que cobra BigQuery.

A esto se suma que, tras los recientes aumentos de precio por consulta, BigQuery se ha encarecido, sobre todo cuando se conecta a una herramienta que consulta datos sin parar. Por eso muchos clientes están buscando formas de reducir los costos de sus workloads y descubren algo que los Customer Reliability Engineers de DoiT International venimos repitiendo desde hace años: sus herramientas de BI son uno de los mayores responsables (si no el mayor) de los costos de BigQuery, y uno de los mejores objetivos para optimizar costos.

En Google Next 2023, durante mi presentación (la grabación se eliminó, pero las diapositivas siguen disponibles), propuse un tema sobre optimización de costos que muchos de nuestros clientes han aplicado con gran éxito: migrar ciertos workloads costosos fuera de BigQuery, en particular los que demandan mucho cómputo, hacia otras herramientas más económicas y mejor adaptadas al propósito.

En línea con esa idea, en este artículo propongo un método alternativo de presentación de datos: usar el data warehouse ClickHouse como capa de "caché y entrega" entre BigQuery y herramientas de BI como Looker. Así, los workloads de reportes y visualización se pueden mover de BigQuery a una plataforma más barata y con mejor rendimiento.

Nota importante: aquí utilizo ClickHouse, pero esto se podría hacer fácilmente con otras herramientas y bases de datos según convenga. Lo uso porque funciona increíble para servir datos muy rápido a herramientas de visualización y lo veo con suficiente frecuencia como para justificar este artículo.

Últimamente quizá hayas visto bastante publicidad en LinkedIn u otros sitios anunciando que ClickHouse es más barato o más rápido que BigQuery. Las mentes brillantes detrás de esa campaña están capitalizando los pilares del concepto que propongo en este artículo. Nuestros arquitectos de datos en DoiT International han visto a escala cómo los cambios de precios afectan a una porción enorme de clientes de GCP, mientras idean formas creativas de ayudarlos a ahorrar dinero.

ClickHouse es un data warehouse "similar" a BigQuery, pero con cambios arquitectónicos importantes que los diferencian. ClickHouse se construye en torno a una arquitectura más monolítica, centrada en "módulos" definidos por el usuario que se utilizan dentro del sistema para incrementar el rendimiento de forma masiva. Gracias a esa infraestructura modular, puede ser bastante más performante para muchas tareas que BigQuery u otras soluciones de data warehousing del mercado.

Esta cita de PostHog lo resume muy bien:

"La diferencia de rendimiento entre BigQuery y ClickHouse puede ser inmensa. BigQuery puede tardar decenas de segundos en ejecutar una consulta. ClickHouse, si se ajusta correctamente, puede ejecutar la misma consulta sobre terabytes de datos con un rendimiento por debajo del segundo."

"Elemental, mi querido Watson, por el ahorro de costos" –Sherlock Holmes (con un giro moderno para la nube)

¡La respuesta es ahorro de costos! Bueno, para ser más realistas: ahorro potencial de costos.

Esto ocurre porque consultas un data warehouse que no factura por uso de consultas, sino que tiene un precio fijo, así que puedes consultar tanto como los recursos lo permitan sin que te cobren por uso.

En este artículo voy a usar la oferta de servicio gestionado de ClickHouse de Aiven para los precios. Es el servicio con el que probé este artículo y han facilitado mucho conectar ClickHouse, y sus otras ofertas, a tu entorno de GCP.

Los planes business de Aiven arrancan en ~$500/mes para el nivel startup y ~$2.000/mes para el nivel business, lo que nos da los puntos de Precios que vamos a analizar para evaluar si esto es viable o no para tu entorno.

Existen varios puntos de equilibrio para que esta solución sea viable desde el punto de vista de costos.

Ten en cuenta que si gastas menos de $500/mes en BigQuery o en tu herramienta de visualización, es muy probable que esto no te genere ninguna reducción de costos; pero, por otro lado, hay muchísimas probabilidades de que te dé mejoras enormes de rendimiento.

Tomando como referencia los Precios de $500 y $2.000 de Aiven, esto equivale a 1 TiB y 321 TiB (320 TiB + 1 TiB del tier gratuito) de datos procesados al mes en el modelo de precios on-demand de BigQuery. También puedes ejecutar esta consulta [1] contra el proyecto donde se ejecutan los jobs de tu herramienta de BI.

Como referencia comparativa, ClickHouse ofrece planes con un componente de autoescalado e instancias un poco más grandes a precios muy comparables. Según el dimensionamiento y las necesidades de desarrollo/producción, podrían ser una alternativa más económica.

Para BigQuery Editions no hay un valor directo que indique dónde está el punto de equilibrio, porque Editions usa un autoescalador que es básicamente una escala móvil de precios. Lo más sencillo es ejecutar la consulta enlazada arriba [1] en el proyecto al que apunta Looker, y así se calcularán los costos aproximados de Looker.

Nota sobre esta consulta:

Quizá necesites ajustar el regex o reemplazarlo por completo con el nombre de tu service account de Looker para obtener costos precisos, sobre todo si usas una service account de Looker no estándar o varias.

Una vez calculado ese valor, podrás determinar si ese precio queda por encima o por debajo de los umbrales de $500 y $2.000 mencionados arriba. Además, si el rendimiento es una preocupación, podría valer la pena el costo extra con tal de no esperar 20 segundos a que un dashboard de Looker muestre datos en tiempo real.

El plan es "replicar" datos entre BigQuery y ClickHouse, y luego conectar a ClickHouse cualquier herramienta de BI con consultas pesadas, o cualquier otra herramienta con consultas exigentes. Así, en teoría, se eliminan los costos por consulta asociados a BigQuery y se reducen los costos de forma significativa, ya que pasas a usar un activo de precio fijo para tus consultas.

Esto también sirve si necesitas capacidad de consulta en tiempo real o mucho más rápida, ya que ClickHouse puede ser un motor de consultas MUCHO más performante cuando se ajusta correctamente.

Siempre hay primeros pasos cuando vas a hacer algo que potencialmente te ahorrará mucho dinero, y este proceso no es la excepción.

Lo primero es determinar cuántos datos y qué tablas usa tu herramienta de BI desde BigQuery. Esta es una afirmación muy genérica y no es un problema trivial de resolver en BigQuery, pero, como ya he mostrado antes, te dejo aquí una consulta para ayudarte[2]. Nota: esta consulta podría costar bastante dinero, así que asegúrate de revisar la estimación en la UI de BQ antes de ejecutarla.

El segundo punto de la lista es el más detallado de los dos: hacer un descubrimiento sobre tu proceso de ingesta. Tendrás que entender qué "hace que funcione" y revisar cómo se ingieren los datos hoy en BigQuery. La razón es que vamos a modificarlo para "dividir" los datos entre BigQuery y la nueva instancia de ClickHouse, de modo que se propaguen a ambos.

Para cerrar esta primera parte, quiero dar algo de orientación sobre cómo dimensionar y crear la instancia de ClickHouse que usaremos a lo largo del resto de la serie.

Después de haber realizado múltiples migraciones de BigQuery -> * (algún otro sistema de base de datos), me preguntan a menudo cómo elegir el tamaño correcto del sistema de base de datos destino. La respuesta lamentable que he descubierto es que en realidad no existe un método infalible para hacerlo.

He hecho ejercicios analizando los datos extraídos de BigQuery en consultas, mirando el volumen de aciertos de caché y el uso de slots, pero la verdad es que BigQuery es un tipo de sistema tan distinto a la mayoría de las bases de datos que no se puede armar una comparación uno a uno. Al hacer estos ejercicios, descubrí que sí se podría lograr, pero BigQuery no emite algunas métricas necesarias para esto, como datos únicos consultados o CPU/memoria utilizados por los slots.

Dicho eso, hacer estos ejercicios me ha enseñado una cosa: arranca siempre con al menos 8 GB de RAM para una base de datos sobre la que harás consultas básicas de forma regular; y, si vas a tener una base de datos de visualización en producción real con >10 usuarios que ejecutan consultas computacionalmente pesadas a lo largo del día, entonces 16 GB es el mínimo. A medida que aumenta la complejidad de las consultas, agregar más CPUs es beneficioso, pero una máquina con dos CPUs es un buen punto de partida sin importar el workload, ya que la memoria es mucho más importante que la CPU en la mayoría de las capacidades de consulta.

Con esa orientación, yo arrancaría una prueba de concepto con una instancia muy pequeña, como el tier hobbyist de Aiven o la instancia de development de ClickHouse, para echar a andar las cosas y luego escalar desde ahí según haga falta hacer right-sizing.

En lugar de hacer un recorrido completo aquí (que inevitablemente quedará desactualizado cuando cambie la UI), voy a enlazar directamente a la documentación de Aiven sobre cómo hacerlo.

El primer paso es crear una cuenta en Aiven, según se indica aquí.

El segundo paso es crear una VPC de Aiven, según esto, y luego hacer peering con tu VPC de GCP según esto.

El siguiente paso es crear el servicio de ClickHouse según esto. Esto puede tardar unos minutos, así que aprovecha para tomarte un café o un té mientras esperas.

Verifica que funcione usando el contenedor de Docker o la herramienta CLI dentro de tu VPC con peering, y deberías estar listo para empezar a usarlo.

Igual que arriba, voy a enlazar directamente a la documentación del proveedor, ya que cualquier cosa que escriba aquí inevitablemente quedará desactualizada cuando algo cambie en el futuro.

Aquí está la guía de inicio rápido del proveedor sobre cómo crear una instancia.

Recomendaría configurar GCP Private Service Connect hacia tu instancia de ClickHouse según esto. Esto garantiza el mayor nivel de seguridad y la menor cantidad de configuración para utilizar tu instancia.

Esta parte fue solo una introducción básica a lo que vamos a hacer con este plan. En la siguiente sección cubriré cómo llevar tus datos a ClickHouse y configurar la replicación entre este y BigQuery.