Introducción a la optimización de costos y rendimiento en BigQuery
Planteamiento del problema
Imagina que en tu empresa se ejecutan varios datasets de BigQuery y que hace un mes sumaste un nuevo equipo de analistas que los consulta a diario. Una mañana, mientras tomas tu café (o tu té, no queremos discriminar), llega la factura de GCP y descubres que tus costos de análisis y almacenamiento en BQ subieron un 5,000%. Lo más probable es que escupas la bebida al instante y termines con un buen desastre sobre el teclado y el monitor. Este artículo te ayudará a corregir, o incluso a prevenir, esta lamentable situación, mostrándote cómo optimizar tus costos de BigQuery con varios métodos.
Empezar por lo básico
Antes de meterle mano a tus costos de BigQuery, hay que hacer algunos preparativos y manejar ciertos requisitos básicos.
En esta primera parte de la serie cubriré justamente eso. Una vez que domines los fundamentos y dejes los preparativos listos, podrás avanzar directo a la Parte 2 y siguientes para ejecutar las optimizaciones.
Esto es lo que necesitas saber sobre los slots de BigQuery, los modelos de precios y los factores que determinan los costos:
Slots
En el corazón del cómputo de BigQuery hay un concepto llamado slot. Un slot es simplemente una vCPU con algo de memoria asociada, como una mini-VM dedicada al procesamiento de BigQuery. Cuando ejecutas una consulta en BigQuery, esta se procesa a través de un conjunto de slots asignados. En teoría, mientras más slots tengas asignados y disponibles, más rápido se ejecutarán tus consultas.
Un slot se encarga de prácticamente cualquier acción que aparezca durante el procesamiento de un job de BigQuery.
Shuffle Slots
Dentro de BigQuery, una tarea no documentada que realizan los slots es el shuffling de los datos. Hasta el 60% de los slots asignados a tu proyecto puede actuar como shuffle slot en un momento dado.
En términos muy simples, hacer shuffling consiste en redistribuir los datos procesados a una nueva ubicación para que el paso actual o el siguiente del plan de la consulta se ejecute más rápido. El white paper de Google sobre la arquitectura de BigQuery te dará una mejor comprensión de cómo funciona el shuffling. El shuffling ayuda a que la consulta corra con mayor eficiencia, pero consume slots muy valiosos en operaciones que no hacen avanzar de forma directa la ejecución de la consulta.
Modelos de precios
Actualmente BigQuery cuenta con dos modelos de precios distintos: on-demand y flat-rate.
Precios on-demand
El modelo predeterminado es el de precios on-demand, que asigna 2,000 slots para tus consultas y otro pool, de cantidad no publicada, para cargas, copias de tablas y jobs de extracción. A medida que se liberan slots en BigQuery en general, el pool de 2,000 slots puede crecer, pero no está garantizado, así que no debes asumir que ocurrirá. Como referencia, lo máximo que he visto son alrededor de 3,500 slots en ráfagas cortas.
En este modelo se factura un precio fijo de USD $5 por TB de datos escaneados por las consultas.
Para muchas organizaciones, este es el principal motor de los costos de BigQuery.
Precios flat-rate
Los precios flat-rate (o por slot) fijan un precio plano para el escaneo de BigQuery, a costa potencial del rendimiento. Lo logran al limitar la cantidad de slots disponibles a los que pre-compras y al eliminar el cargo de USD $5 por TB escaneado.
Los slots (incluyendo los Flex Slots, que cubro más adelante) siempre se compran en bloques de 100. Los slots estándar (es decir, los que no son Flex Slots) se compran dentro de un commitment con plazo de un mes o un año. Ten en cuenta que, una vez comprada una reservación, no se puede cancelar fácilmente. Un commitment de un mes puede convertirse en uno de un año, pero no al revés.
Hay un detalle delicado sobre lo que pasa cuando termina un commitment, que difiere entre ambos casos y ha cambiado varias veces. Por eso prefiero enlazar la documentación de Google sobre commitments mensuales y commitments anuales, por si vuelve a cambiar. Recomiendo mucho configurar eventos de calendario que te avisen con suficiente anticipación antes de que terminen, para que puedas reaccionar a tiempo.
Dicho esto, en el modelo flat-rate tus slots pueden complementarse, o reemplazarse por completo, con un pool adicional llamado Flex Slots. Los Flex Slots son idénticos en capacidad y función a los slots normales, pero ofrecen la opción de un commitment más corto y flexible, con un mínimo de 60 segundos. Una vez alcanzado ese mínimo puedes cancelar la reservación en cualquier momento y los slots desaparecen. Esto te permite escalar slots hacia arriba o hacia abajo según haga falta. Suelen usarse cuando se necesitan más slots por períodos cortos, como picos de uso o cuando se ejecuta un job especialmente intensivo en recursos que podría consumir todos los slots de una reservación. Un ejemplo claro es el de las empresas de retail durante el Black Friday o el Cyber Monday, los días de compras más grandes en Estados Unidos.
Al momento de escribir este artículo, 100 slots cuestan USD $2,000 con un commitment de 1 mes y USD $1,700 al mes con un commitment de 1 año. Así que para igualar el rendimiento del modelo on-demand necesitarías comprar veinte bloques de 100 slots, lo que equivale a USD $40,000 al mes con commitment de 1 mes o USD $34,000 al mes con commitment de 1 año. Por eso, en general, no resulta rentable comprar 2,000 slots a menos que estés gastando al menos esa cantidad en costos de escaneo en BigQuery.
El plan para determinar los costos
Antes de optimizar costos hay que analizar los datos de uso de tu(s) proyecto(s). Para ello necesitas tener acceso a los datos de las consultas en tus proyectos/datasets.
Una nota rápida para alinear expectativas: cubro esto ahora, en la primera parte de la serie, para que puedas dejarlo configurado y empezar a registrar datos de uso por si no lees varias partes de un tirón (o de pie). A partir de la parte 3 es donde realmente se aprovechan los frutos de este trabajo.
Hay dos métodos para hacerlo: los audit log sinks y las tablas INFORMATION_SCHEMA.
El audit log sink es el método preferido, ya que los datos son mucho más ricos y abarcan múltiples proyectos, datasets y regiones; pero si aún no está habilitado, tomará algo de tiempo poblarse a medida que se ejecuten jobs en BigQuery. Ten en cuenta que el audit log sink tiene un pequeño costo asociado, en forma de costos de almacenamiento de BigQuery por los datos.
En cambio, las vistas INFORMATION_SCHEMA ya existen en cada dataset, proyecto y región, pero a diferencia del audit log sink, cada combinación de dataset y región tiene su propio set de estas tablas, por lo que puede ser necesario ejecutar las consultas varias veces. Ten presente que falta cierta información en las tablas INFORMATION_SCHEMA que sí existe en las tablas de audit log; algunos ejemplos están documentados como comentarios en las consultas SQL más adelante en el artículo, donde no coinciden 1 a 1 con las consultas del audit log sink.
Si vas a usar el método INFORMATION_SCHEMA, puedes saltarte la siguiente sección sobre cómo configurar el audit log sink, porque tus datos ya existen. Hay un detalle: los datos recopilados en el audit log sink son más ricos que los que ofrecen las vistas INFORMATION_SCHEMA. La contrapartida es que, una vez configurado, empieza a registrar datos desde ese momento, así que tendrán que correr workloads regulares durante un tiempo antes de que los datos estén listos para usarse. Ese plazo depende mucho de los workloads que se ejecuten y de lo que se considere "normal" en cuanto a la frecuencia con que corren.
Nota: si ya eres cliente de DoiT y usas el dashboard BigQuery Lens dentro de nuestra Cloud Management Platform (CMP), entonces ya tienes el Audit Log Sink configurado en tu entorno. Recomiendo usarlo para las operaciones descritas en estos artículos. Puedes encontrar más información al respecto aquí.
El nombre completamente calificado del dataset será
Si es tu caso, puedes saltarte la siguiente sección.
Cómo configurar el Audit Log Sink
Si decides usar las vistas INFORMATION_SCHEMA en lugar del Audit Log sink, salta esta sección.
A continuación van las instrucciones para configurar un Audit Log Sink. Lo mejor es ejecutar estos comandos en tu localhost o en la Cloud Shell con el gcloud CLI configurado para usar el proyecto donde quieres almacenar el dataset.
Primero ejecuta el siguiente comando, actualizando el nombre del sink, el ID del proyecto y el nombre del dataset:
gcloud logging sinks create <Sink Name> bigquery.googleapis.com/projects/<Project ID>/datasets/<Dataset Name> \ — use-partitioned-tables \
— log-filter=’protoPayload.metadata."@type"="type.googleapis.com/google.cloud.audit.BigQueryAuditMetadata"’
Tras ejecutar este comando, se mostrará una service account creada para este propósito; copia la dirección de correo completa de esa service account en una nota.
Después tendrás que otorgar a la service account recién creada el rol BigQuery Editor en cada proyecto que use BigQuery. Como siempre en la nube, hay varias formas de hacerlo, así que incluyo las 3 más comunes: por proyecto, sobre toda una organización y sobre una carpeta dentro de una organización.
Para obtener el ID de proyecto, carpeta u organización, puedes entrar al "project picker" en la parte superior de tu consola de GCP; ahí hay una columna de ID que te dará el identificador necesario del recurso.
Por proyecto:
gcloud projects add-iam-policy-binding <Project ID> \
— member=<Service Account> — role=roles/bigquery.dataEditor
A nivel de organización:
gcloud organizations add-iam-policy-binding <Organization ID> \
— -member=<Service Account> — role=roles/bigquery.dataEditor
A nivel de carpeta:
gcloud resource-manager folders add-iam-policy-binding <Folder ID> \
— -member=<Service Account> — role=roles/bigquery.dataEditor
A partir de este momento, los datos de las consultas empezarán a almacenarse en el dataset indicado arriba. Para generar una buena cantidad de datos, lo recomendable es esperar al menos unos días, y mejor aún unas semanas. Cuanto más tiempo se recopilen datos de tu uso normal, mejor, ya que así podrás detectar picos o patrones de uso.
Vistas INFORMATION_SCHEMA
Las vistas INFORMATION_SCHEMA ya existen en cada dataset, proyecto y región, pero, a diferencia del audit log sink, cada combinación de dataset y región tiene su propio set de tablas, así que puede ser necesario ejecutar las consultas varias veces. Las vistas INFORMATION_SCHEMA omiten cierta información presente en las tablas de audit log. Hay ejemplos documentados como comentarios en las consultas SQL más adelante en la serie, donde no se alinean exactamente con las consultas del audit log sink.
La ventaja de las vistas INFORMATION_SCHEMA es que los datos ya existen aunque no hayas configurado el sink.
Próximamente
Aquí concluye la primera parte de esta serie, que sirve como base para los métodos descritos en el resto de los artículos.