Comprender slots

Las ranuras de BigQuery son unidades de computación virtuales que usa BigQuery para ejecutar consultas de SQL u otros tipos de trabajos. Durante la ejecución de una consulta, BigQuery determina automáticamente cuántas ranuras utiliza la consulta. El número de slots utilizados depende de la cantidad de datos que se procesen, la complejidad de la consulta y el número de slots disponibles. Por lo general, si tienes acceso a más ranuras, puedes ejecutar más consultas simultáneas y tus consultas complejas se pueden ejecutar más rápido.

Aunque todas las consultas usan ranuras, tienes dos opciones para que se te cobre por el uso: el modelo de precios bajo demanda o el modelo de precios basado en la capacidad.

De forma predeterminada, se te cobra según el modelo bajo demanda. En este modelo, se te cobra por la cantidad de datos procesados (medida en TiB) por cada consulta. Los proyectos que usan el modelo bajo demanda están sujetos a límites de slots por proyecto y por organización con capacidad de ráfaga transitoria. La mayoría de los usuarios del modelo bajo demanda consideran que los límites de capacidad de los espacios publicitarios son más que suficientes. Sin embargo, en función de tu carga de trabajo, el acceso a más ranuras puede mejorar el rendimiento de las consultas. Para comprobar cuántas ranuras usa tu cuenta, consulta la página sobre la monitorización de BigQuery.

Con el modelo basado en la capacidad, pagas por la capacidad de ranura asignada a tus consultas a lo largo del tiempo. Este modelo te permite controlar explícitamente la capacidad total de los espacios, mientras que el modelo bajo demanda no. Elige explícitamente la cantidad de ranuras que quieres usar mediante una reserva. Puedes especificar la cantidad de espacios de una reserva como una cantidad de referencia que siempre se asigna o como una cantidad escalada automáticamente, que se asigna cuando es necesario.

Ejecución de consultas mediante ranuras

Cuando BigQuery ejecuta una tarea de consulta, convierte la instrucción SQL en un plan de ejecución, que se divide en una serie de fases de la consulta, que a su vez se componen de conjuntos más granulares de pasos de ejecución. BigQuery usa una arquitectura paralela muy distribuida para ejecutar estas consultas, y las fases modelan las unidades de trabajo que muchos trabajadores potenciales pueden ejecutar en paralelo. Los datos se transfieren entre fases mediante una arquitectura de aleatorización distribuida rápida, que se explica con más detalle en la Google Cloud entrada de blog.

La ejecución de consultas de BigQuery es dinámica, lo que significa que el plan de consulta se puede modificar mientras se está ejecutando una consulta. Las fases que se introducen mientras se ejecuta una consulta se suelen usar para mejorar la distribución de los datos entre los trabajadores de la consulta. Además, la ejecución de las consultas puede verse afectada por la cantidad de capacidad disponible, que cambia a medida que se completan o se inician otras consultas, o bien cuando el escalador automático añade ranuras a la reserva.

BigQuery puede ejecutar varias fases simultáneamente, usar la ejecución especulativa para acelerar una consulta y reparticionar dinámicamente una fase para conseguir una paralelización óptima.

Las ranuras de BigQuery ejecutan unidades de trabajo individuales en cada fase de la consulta. Por ejemplo, si BigQuery determina que el factor de paralelización óptimo de una fase es 10, solicita 10 slots para procesar esa fase.

Gráfico de ejecución de consultas de fases y pasos

Economía de recursos de ranuras

Si una consulta solicita más ranuras de las que hay disponibles, BigQuery pone en cola unidades de trabajo individuales y espera a que haya ranuras disponibles. A medida que se procesa la ejecución de la consulta y van quedando slots libres, estas unidades de trabajo puestas en cola se van recogiendo de forma dinámica para ejecutarse.

BigQuery puede solicitar cualquier número de ranuras para una fase concreta de una consulta. El número de ranuras solicitadas no está relacionado con la cantidad de capacidad que compras, sino que indica el factor de paralelización óptimo que BigQuery ha elegido para esa fase. Las unidades de trabajo se ponen en cola y se ejecutan a medida que hay ranuras disponibles.

Cuando la demanda de consultas supera las ranuras que has confirmado, no se te cobra por las ranuras adicionales ni por las tarifas adicionales bajo demanda. Tus unidades de trabajo individuales se ponen en cola.

Por ejemplo,

1. Una fase de consulta solicita 2000 ranuras, pero solo hay 1000 disponibles.
2. BigQuery consume las 1000 ranuras y pone en cola las otras 1000.
3. Después, si 100 ranuras terminan su trabajo, se asignan dinámicamente 100 unidades de trabajo de las 1000 unidades de trabajo en cola. Quedan 900 unidades de trabajo en cola.
4. Después, si 500 ranuras terminan su trabajo, se asignan dinámicamente 500 unidades de trabajo de las 900 unidades de trabajo en cola. Quedan 400 unidades de trabajo en cola.

Ranuras de BigQuery en cola si la demanda supera la disponibilidad

Programación equitativa en BigQuery

BigQuery asigna capacidad de ranuras en una sola reserva mediante un algoritmo llamado programación equitativa.

El programador de BigQuery aplica el reparto equitativo de ranuras entre los proyectos con consultas en ejecución dentro de una reserva y, a continuación, entre las tareas de un proyecto concreto. El programador proporciona equidad eventual. Durante periodos breves, algunos trabajos pueden obtener una proporción desmesurada de ranuras, pero el programador acaba corrigiéndolo. El objetivo del programador es encontrar un equilibrio entre desalojar de forma agresiva las tareas en ejecución (lo que provoca que se pierda tiempo de ranura) y ser demasiado permisivo (lo que provoca que los trabajos con tareas de larga duración obtengan una parte desproporcionada del tiempo de ranura).

La programación equitativa asegura que todas las consultas tengan acceso a todos los espacios disponibles en cualquier momento, y la capacidad se reasigna de forma dinámica y automática entre las consultas activas a medida que cambian las demandas de capacidad de cada consulta. Las consultas se completan y se envían nuevas consultas para ejecutarse en las siguientes condiciones:

• Cada vez que se envía una consulta nueva, la capacidad se reasigna automáticamente entre las consultas en ejecución. Las unidades de trabajo individuales se pueden pausar, reanudar y poner en cola de forma correcta a medida que haya más capacidad disponible para cada consulta.
• Cada vez que se completa una consulta, la capacidad que ha consumido se pone a disposición de todas las demás consultas de forma inmediata.
• Cuando las demandas de capacidad de una consulta cambian debido a modificaciones en su DAG dinámico, BigQuery vuelve a evaluar automáticamente la disponibilidad de capacidad de esta y de todas las demás consultas, y reasigna y pausa las ranuras según sea necesario.

Programación equitativa en BigQuery

En función de su complejidad y tamaño, es posible que una consulta no necesite todas las ranuras que tiene derecho a usar o que necesite más. BigQuery se asegura de forma dinámica de que, con una programación justa, todos los slots se puedan usar por completo en cualquier momento.

Si una tarea importante necesita constantemente más ranuras de las que recibe del programador, considera la posibilidad de crear una reserva adicional con el número de ranuras necesario y asignar la tarea a esa reserva.

Por ejemplo, supongamos que tiene la siguiente configuración de reserva:

• Reserva A, que tiene 1000 espacios de referencia sin autoescalado
• Los proyectos A y B, que están asignados a tu reserva

Situación 1: En el proyecto A, ejecutas la consulta A (una consulta simultánea) que requiere un uso elevado de ranuras y, en el proyecto B, ejecutas 20 consultas simultáneas. Aunque hay un total de 21 consultas que usan la reserva A, la distribución de las ranuras es la siguiente:

• El proyecto A recibe 500 ranuras y la consulta A se ejecuta con 500 ranuras.
• El proyecto B recibe 500 ranuras que se comparten entre sus 20 consultas.

Situación 2: En el proyecto A, ejecutas la consulta A (una consulta simultánea) que requiere 100 slots para ejecutarse. En el proyecto B, ejecutas 20 consultas simultáneas. Como la consulta A no requiere el 50% de la reserva, la distribución de los espacios es la siguiente:

• El proyecto A recibe 100 ranuras y la consulta A se ejecuta con 100 ranuras.
• El proyecto B recibe 900 ranuras que se comparten entre sus 20 consultas.

Por el contrario, considera la siguiente configuración de reserva:

• Reserva B, que tiene 1000 espacios base sin autoescalado.
• 10 proyectos, todos ellos asignados a la reserva B.

Supongamos que los 10 proyectos están ejecutando consultas que tienen suficiente demanda de ranuras. En ese caso, cada proyecto recibirá 1/10 del total de ranuras de la reserva (es decir, 100 ranuras), independientemente del número de consultas que se estén ejecutando en cada proyecto.

Cuotas y límites de los espacios publicitarios

Las cuotas y los límites de las ranuras protegen BigQuery. Los distintos modelos de precios usan diferentes tipos de cuota de espacio publicitario, como se indica a continuación:

• Modelo de precios bajo demanda: estás sujeto a un límite de ranuras por proyecto y organización con capacidad de picos transitorios. En función de tus cargas de trabajo, acceder a más ranuras puede mejorar el rendimiento de las consultas.

• Modelo de precios basado en la capacidad: las cuotas y los límites de las reservas definen el número máximo de espacios que puedes asignar a todas las reservas de una ubicación. Solo se te cobrará por las reservas y los compromisos, no por las cuotas. Para obtener información sobre cómo aumentar tu cuota de espacios publicitarios, consulta Solicitar un aumento de cuota.

Para comprobar cuántas ranuras estás utilizando, consulta Monitorización de BigQuery.

Espacios inactivos

En un momento dado, puede que algunas ranuras estén inactivas. Esto puede incluir:

• Compromisos de ranuras que no se han asignado a ninguna base de reserva.
• Ranuras asignadas a una base de referencia de reserva, pero que no se están usando.

Las ranuras inactivas no se aplican cuando se usa el modelo de precios bajo demanda.

De forma predeterminada, las consultas que se ejecutan en una reserva usan automáticamente las ranuras inactivas de otras reservas del mismo proyecto de administración. BigQuery asigna inmediatamente los slots a una reserva asignada cuando se necesitan. Las ranuras inactivas que usaba otra reserva se expropian rápidamente. Puede que durante un breve periodo de tiempo veas que el consumo total de espacios publicitarios supera el máximo que has especificado en todas las reservas, pero no se te cobrará por este uso adicional de espacios publicitarios.

Por ejemplo, supongamos que tiene la siguiente configuración de reserva:

• project_a se asigna a reservation_a, que tiene 500 ranuras de referencia sin autoescalado.
• project_b se asigna a reservation_b, que tiene 100 ranuras de referencia sin autoescalado.
• Ambas reservas están en el mismo proyecto administrativo y no hay otros proyectos asignados a estas reservas.

Corres query_b en project_b. Si no se está ejecutando ninguna consulta en project_a, entonces query_b tiene acceso a las 500 ranuras inactivas de reservation_a. Mientras query_b siga ejecutándose, puede usar hasta 600 ranuras: 100 ranuras de base más 500 ranuras inactivas.

Mientras se ejecuta query_b, supongamos que ejecutas query_a en project_a, que puede usar 500 ranuras.

• Como tienes 500 ranuras de base reservadas para project_a, query_a empieza inmediatamente y se le asignan 500 ranuras.
• El número de slots asignados a query_b disminuye rápidamente hasta los 100 slots de referencia.
• Las consultas adicionales que se ejecuten en project_b compartirán esas 100 ranuras. Si las consultas posteriores no tienen suficientes ranuras para iniciarse, se pondrán en cola hasta que se completen las consultas en ejecución y haya ranuras disponibles.

En este ejemplo, si se asignara project_b a una reserva sin ranuras de referencia ni escalado automático, query_b no tendría ranuras después de que query_a empezara a ejecutarse. BigQuery pausaría query_b hasta que haya ranuras inactivas disponibles o hasta que se agote el tiempo de espera de la consulta. Las consultas adicionales de project_b se pondrían en cola hasta que hubiera ranuras disponibles.

Para asegurarse de que una reserva solo use los espacios aprovisionados, asigne el valor true a ignore_idle_slots. Sin embargo, las reservas con ignore_idle_slots definido como true pueden compartir sus ranuras inactivas con otras reservas.

No puedes compartir ranuras inactivas entre reservas de diferentes ediciones. Solo puedes compartir las ranuras de referencia o las ranuras comprometidas. Las ranuras con escalado automático pueden estar disponibles temporalmente, pero no se pueden compartir como ranuras inactivas para otras reservas porque pueden reducirse.

Mientras ignore_idle_slots sea false, una reserva puede tener un número de espacios de 0 y seguir teniendo acceso a los espacios no utilizados. Si solo usas la default reserva, desactiva ignore_idle_slots como práctica recomendada. Después, puedes asignar un proyecto o una carpeta a esa reserva, que solo usará las ranuras inactivas.

Las asignaciones de tipo ML_EXTERNAL son una excepción, ya que las ranuras que usan las tareas de creación de modelos externos de BigQuery ML no son interrumpibles. Las ranuras de una reserva con los tipos de asignación ML_EXTERNAL y QUERY solo están disponibles para otras tareas de consulta cuando las tareas ML_EXTERNAL no las ocupan. Además, estas tareas no pueden usar las ranuras inactivas de otras reservas.

Equidad basada en reservas

Con la equidad basada en reservas, BigQuery prioriza y asigna las ranuras inactivas de forma equitativa entre todas las reservas del mismo proyecto de administrador, independientemente del número de proyectos que ejecuten tareas en cada reserva. Cada reserva recibe una parte similar de la capacidad disponible en el grupo de ranuras inactivas y, a continuación, sus ranuras se distribuyen de forma equitativa entre sus proyectos. Esta función solo está disponible en las ediciones Enterprise y Enterprise Plus.

En el siguiente gráfico se muestra cómo se distribuyen las franjas inactivas sin la función de equidad basada en reservas habilitada:

En este gráfico, las ranuras inactivas se comparten a partes iguales entre los proyectos.

Si la equidad basada en reservas no está habilitada, las ranuras inactivas disponibles se distribuyen de forma equitativa entre los proyectos de las reservas.

En el siguiente gráfico se muestra cómo se distribuyen las franjas inactivas con la opción de equidad basada en reservas habilitada:

En este gráfico, las ranuras inactivas se comparten a partes iguales entre las reservas, no entre los proyectos.

Si la equidad basada en reservas está habilitada, las ranuras inactivas disponibles se distribuyen equitativamente entre las reservas.

Cuando habilites la equidad basada en reservas, revisa el consumo de recursos para gestionar la disponibilidad de las ranuras y el rendimiento de las consultas.

No confíes únicamente en las ranuras inactivas para las cargas de trabajo de producción con requisitos de tiempo estrictos. Estos trabajos deben usar ranuras de referencia o autoescaladas. Recomendamos usar ranuras inactivas para los trabajos de menor prioridad, ya que las ranuras se pueden interrumpir en cualquier momento.

Uso excesivo de ranuras

Si una tarea retiene las ranuras durante demasiado tiempo, puede recibir una parte injusta de las ranuras. Para evitar retrasos, BigQuery permite que otras tareas tomen prestadas ranuras adicionales, lo que provoca que, en algunos periodos, el uso total de ranuras supere la capacidad especificada. El uso excesivo de ranuras solo se atribuye a los trabajos que reciben más de lo que les corresponde.

Los espacios publicitarios adicionales no se te facturan directamente. En su lugar, las tareas siguen ejecutándose y acumulando uso de ranuras en la parte que les corresponde hasta que todo el uso excesivo se cubra con la capacidad asignada. Las ranuras en exceso se excluyen del uso de ranuras registrado, a excepción de determinadas estadísticas de ejecución detalladas.

Ten en cuenta que se pueden pedir prestados algunos espacios de forma preventiva para reducir los retrasos futuros y ofrecer otras ventajas, como una menor variabilidad del coste de los espacios y una menor latencia de cola. El préstamo de espacios está limitado a una pequeña parte de tu capacidad total de espacios.