BigQuery es un data warehouse versátil que te permite convertir big data en insights valiosos, pero los costos se pueden disparar rápido. En la primera entrega de una serie de guías detalladas, te mostramos cómo sacarle provecho de forma eficiente.
Nueva guía para optimizar costos y rendimiento en BigQuery
Que los costos se disparen de un día para otro no es algo raro cuando manejas varios datasets de BigQuery con distintos equipos de analistas consultándolos a la vez. Pero tampoco es inevitable.
En nuestro nuevo ebook, The BigQuery Optimization Handbook: Preparing to Save, Sayle Matthews, Senior Cloud Architect y especialista en datos de DoiT, abre una serie en la que comparte su experiencia para gastar menos y lograr más con BigQuery, además de hacer más predecibles tus facturas de Google Cloud.
El ebook cubre:
- Dominar lo básico
- Evitar errores comunes al escribir consultas
- Identificar tus consultas más costosas
Dominar lo básico
El data warehouse BigQuery es totalmente administrado e incluye funciones como machine learning, análisis geoespacial y business intelligence para ayudarte a gestionar y analizar big data. Sin embargo, es fácil acumular costos inesperados si no haces un trabajo previo. Antes de atacar tus costos en BigQuery, conviene tener claros algunos conceptos. Empecemos por los slots y los modelos de Precios:
Slots
El cómputo de BigQuery se apoya en una unidad llamada slot, que es una vCPU con algo de memoria asignada. En teoría, mientras más slots tengas asignados y disponibles, más rápido se ejecutan las consultas. Los slots estándar siempre se compran en bloques de 100 dentro de un commitment con plazos de uno o doce meses.
Los slots cumplen una tarea no documentada: hacer shuffling de los datos. Dicho de forma simple, el shuffling consiste en redistribuir los datos procesados a una nueva ubicación para que el paso actual o el siguiente del plan de consulta se ejecute más rápido. Hasta el 60% de los slots asignados a tu proyecto pueden actuar como shuffle slots en cualquier momento. El shuffling mejora la eficiencia de las consultas, pero ocupa slots valiosos en operaciones que no hacen avanzar la ejecución de manera directa.
Modelos de Precios
Los modelos de Precios son on-demand o flat-rate. El predeterminado es on-demand, que cobra USD 5 por TB de datos escaneados por las consultas. Para la mayoría de las empresas, este es el principal generador de costos en BigQuery.
El modelo flat-rate o por slots fija un precio plano para el escaneo en BigQuery, con un posible costo en términos de rendimiento. Funciona limitando la cantidad de slots disponibles a los que compras por adelantado y elimina el cobro de USD 5 por TB escaneado.
Con el modelo flat-rate, puedes ajustar el diseño de tu arquitectura para sumar un pool de slots llamados Flex slots, que te permiten ampliar o reemplazar los slots existentes. Los Flex slots ofrecen commitments más cortos y flexibles, con un mínimo de 60 segundos, y la opción de eliminarlos cancelándolos en cualquier momento.
Para igualar el rendimiento del on-demand, tendrías que comprar 20 bloques de 100 slots, a un costo de USD 40,000 al mes o USD 34,000 al año. No es rentable comprar 2,000 slots a menos que ya estés gastando al menos esa cantidad en costos de escaneo de BigQuery.
Determinar los costos
Antes de optimizar tus costos, hay que analizar el uso de datos de tus proyectos. Para eso necesitas acceso a los datos de las consultas en tus proyectos/datasets.
Existen dos métodos: los audit log sinks y las tablas INFORMATION_SCHEMA. El audit log sink es la opción preferida porque entrega información mucho más completa . Los clientes de DoiT que usan la función BigQuery Lens en DoiT Cloud Intelligence™ ya tienen configurado el audit log sink en sus entornos. Encontrarás más información aquí.
Evitar errores comunes al escribir consultas
Antes de entrar en las consultas que te darán los datos que realmente buscas, repasemos algunos errores frecuentes que se cometen al escribir consultas en BigQuery. Estos errores pueden hacer que las consultas tarden más y cuesten más de lo necesario.
1. SELECT *
Probablemente sea la mayor fuente de costos adicionales innecesarios en consultas de BigQuery. Casi nunca hace falta seleccionar todas las columnas de una tabla o vista. Recuerda que las facturas de BigQuery se calculan en función de la cantidad de datos que escaneas, así que reduce al mínimo lo que seleccionas para bajar el costo.
2. Joins innecesarios o demasiado grandes
En data warehouses orientados a una estrategia OLAP (como BigQuery), la mejor práctica es desnormalizar los esquemas de la base de datos. Esto aplana las estructuras de datos y reduce la cantidad de joins requeridos frente a una base de datos relacional tradicional.
3. Cross joins
Los cross joins son necesarios en varios casos de uso de BigQuery, pero los problemas aparecen cuando se aplican como la operación más interna de la consulta, lo que hace que se traigan muchos más datos de los que finalmente llegan al resultado.
4. Uso incorrecto de Common Table Expressions (CTEs)
Las Common Table Expressions (CTEs) son un recurso muy útil que simplifica enormemente el código SQL. Sin embargo, si usas una CTE en una consulta y la referencias varias veces, la consulta de la CTE se ejecutará varias veces y se te cobrará por leer los datos cada una de esas veces.
5. No usar particiones en cláusulas WHERE
Las particiones son una de las funciones más importantes de BigQuery para reducir costos y optimizar el rendimiento de lectura. Aun así, suelen omitirse, sumando costos innecesarios a las consultas.
6. Usar vistas demasiado complicadas
Crear vistas complejas puede degradar el rendimiento. Si la lógica de una vista es demasiado enredada, quizá convenga precalcularla en otra tabla o llevarla a una vista materializada para mejorar el rendimiento.
7. Inserciones pequeñas
Si necesitas insertar una cantidad pequeña de registros en una tabla, hazlo en lote en lugar de ejecutar muchas inserciones pequeñas.
8. Abuso de sentencias DML
Es común abusar de las sentencias DML cuando se trata a BigQuery como un RDBMS tradicional y se recrean datos a discreción. Una mejor alternativa es usar un "modelo aditivo": insertar nuevas filas con un timestamp que indique la versión más reciente y eliminar periódicamente las filas antiguas si no necesitas el historial.
Identificar tus consultas más costosas
El ebook enlaza a un repositorio de GitHub con los archivos SQL que necesitarás para encontrar tus consultas más costosas. Estas son las tres consultas principales que vas a usar:
- Las consultas más costosas en total
- Las consultas individuales más costosas
- Los usuarios más costosos
Otras consultas en el repositorio
El repo de GitHub también incluye consultas adicionales para fines más específicos, como detectar consultas originadas en Looker, la cantidad de veces que se ejecuta una consulta, el costo de consultas con etiquetas determinadas, etc.
Detectar consultas con problemas de rendimiento
Una vez que hayas identificado las consultas más costosas, el siguiente paso es detectar aquellas que consumen más recursos de los necesarios y no rinden como se espera. Suelen coincidir con las más costosas, así que puede haber cierto solapamiento.
El ajuste de rendimiento se aborda con mayor profundidad en una entrega futura de esta serie, enfocada en algunos de los problemas menos conocidos del rendimiento de BigQuery y en cómo resolverlos.
El último tema de esta entrega es un conjunto de consultas del repositorio de GitHub que muestran información más general o metadatos:
- Consultas por tipo de job
- Consultas concurrentes
- Conteo de consultas
Qué hacer a continuación
Descarga The BigQuery Optimization Handbook: Preparing to Save. Como esta entrega y las siguientes de la serie incluyen una buena cantidad de material detallado, te recomendamos configurar desde ya un audit log sink para tus proyectos de BigQuery, de modo que puedas recopilar datos a lo largo del tiempo y aprovechar al máximo estas consultas y el resto de la serie. Recuerda que los clientes actuales de DoiT que usan la función BigQuery Lens en DoiT Cloud Intelligence ya lo tienen configurado en sus entornos.