Información sobre las ranuras
Una ranura de BigQuery es una CPU virtual que usa BigQuery para ejecutar consultas de SQL. Durante la ejecución de la consulta, BigQuery calcula automáticamente cuántas ranuras requiere una consulta según su tamaño y complejidad.
Tienes la opción de usar un modelo de precios según demanda o un modelo de precios basado en la capacidad. Ambos modelos usan ranuras para el procesamiento de datos. Con un modelo basado en la capacidad, puedes pagar por la capacidad de procesamiento de consultas específica o con ajuste de escala automático. El modelo basado en la capacidad te brinda un control explícito sobre las ranuras y la capacidad de estadísticas, mientras que el modelo según demanda no lo hace.
Los clientes que usan el modelo de precios basado en la capacidad eligen de forma explícita cuántas ranuras reservar. Tus consultas se ejecutan dentro de esa capacidad y pagas por esa capacidad de forma continua cada segundo que se implementa. Por ejemplo, si compras 2,000 ranuras de BigQuery, tus consultas en conjunto se limitan al uso de 2,000 CPU virtuales en cualquier momento. Tendrás esta capacidad hasta que la borres y pagarás por 2,000 ranuras hasta que las borres.
Los proyectos del modelo de precios según demanda de BigQuery están sujetos a la cuota de ranuras por proyecto con capacidad de aumento de actividad transitorio. Para la mayoría de los usuarios del modelo según demanda, la capacidad de ranuras predeterminada es más que suficiente. Según la carga de trabajo, el acceso a más ranuras mejora el rendimiento de las consultas. Para verificar cuántas ranuras usa tu cuenta, consulta Supervisión de BigQuery.
Estima cuántas ranuras comprar
BigQuery está diseñado para escalar de forma eficiente con más recursos. Según la carga de trabajo, es probable que la capacidad incremental te brinde beneficios adicionales. Por lo tanto, elegir la cantidad óptima de ranuras que debes comprar depende de los requisitos de rendimiento, de capacidad de procesamiento y de utilidad.
Puedes experimentar con ranuras del modelo de referencia y de ajuste de escala automático para determinar la mejor configuración de ranuras. Por ejemplo, puedes probar la carga de trabajo con 500 ranuras del modelo de referencia, luego con 1,000 y, más adelante, con 1,500 y 2,000, y observar el impacto en el rendimiento.
También puedes examinar el uso de ranuras actual de los proyectos, junto con el precio mensual que deseas pagar. Por el momento, las cargas de trabajo según demanda tienen un límite mínimo de 2,000 ranuras, pero es importante verificar cuántas ranuras realmente usan los proyectos con vistas INFORMATION_SCHEMA.JOBS*, Cloud Logging, la API de Jobs o los registros de auditoría de BigQuery. Para obtener más información, consulta Visualiza las ranuras disponibles y las ranuras asignadas.
Después de comprar ranuras y ejecutar tus cargas de trabajo durante al menos siete días, puedes usar el estimador de ranuras para analizar el rendimiento y modelar el efecto de agregar o reducir ranuras. Para obtener más información, consulta Estima los requisitos de capacidad de ranuras.
Ejecución de consultas mediante ranuras
Cuando BigQuery ejecuta un trabajo de consulta, convierte la instrucción declarativa de SQL en un grafo de ejecución dividido en una serie de etapas de consulta que, a su vez, están compuestas por conjuntos de pasos de ejecución más detallados. BigQuery usa una arquitectura en paralelo muy distribuida para ejecutar estas consultas, y las etapas modelan las unidades de trabajo que varios trabajadores potenciales pueden ejecutar en paralelo. Las etapas se comunican entre sí a través de una arquitectura aleatoria de distribución rápida, que se analiza con más detalle en Blog de Google Cloud.
La ejecución de consultas de BigQuery es dinámica, lo que significa que el plan de consultas se puede modificar mientras una de ellas está en tránsito. Las etapas que se ingresan mientras se ejecuta una consulta se suelen usar para mejorar la distribución de datos en todos los trabajadores de consultas.
BigQuery puede ejecutar varias etapas de forma simultánea. BigQuery puede usar la ejecución especulativa para acelerar una consulta y puede particionar de forma dinámica una etapa para lograr una paralelización óptima.
Las ranuras de BigQuery ejecutan unidades de trabajo individuales en cada etapa de la consulta. Por ejemplo, si BigQuery determina que el factor de paralelización óptima de una etapa es 10, solicitará 10 ranuras para procesar esa etapa.
Ejecución de consultas en ahorro de recursos de ranura
Si una consulta solicita más ranuras que las disponibles actualmente, BigQuery pone en cola las unidades de trabajo individuales y espera a que las ranuras estén disponibles. A medida que se avanza en la ejecución de la consulta y se liberan las ranuras, estas unidades de trabajo en cola se seleccionan de forma dinámica para su ejecución.
BigQuery puede solicitar cualquier cantidad de ranuras para una etapa en particular de una consulta. La cantidad de ranuras solicitadas no está relacionada con la cantidad de capacidad que adquieres, sino que es una indicación del factor de mejor paralelización que elige BigQuery para esa etapa. Las unidades de trabajo se ponen en cola y se ejecutan a medida que van quedando ranuras disponibles.
Cuando la demanda de consultas supere la cantidad de ranuras a las que te comprometiste, no se te cobrará por las ranuras adicionales ni por las tarifas adicionales a pedido. Las unidades de trabajo individuales se ponen en cola.
Por ejemplo,
- Una etapa de consulta solicita 2,000 ranuras, pero solo 1,000 están disponibles.
- BigQuery consume las 1,000 ranuras y pone en cola el resto.
- A partir de esto, si 100 ranuras terminan su trabajo, seleccionan de forma dinámica 100 unidades de trabajo de las 1,000 unidades de trabajo en cola. Quedan 900 unidades de trabajo en cola.
- Si 500 ranuras terminan su trabajo, seleccionan de forma dinámica 500 unidades de trabajo de las 900 unidades de trabajo en cola. Quedan 400 unidades de trabajo en cola.
Ranuras inactivas
En un momento determinado, es posible que algunas ranuras estén inactivas. Esto puede incluir lo siguiente:
- Compromisos de ranuras que no están asignados a ninguna referencia de reserva.
- Las ranuras que se asignaron a un modelo de referencia de reserva, pero no se encuentran en uso.
De forma predeterminada, las consultas que se ejecutan en una reserva usan ranuras inactivas de otras reservas dentro del mismo proyecto de administración de forma automática. BigQuery asigna ranuras de inmediato a una reserva asignada cuando se necesitan. Las ranuras inactivas que usa otra reserva se interrumpen con rapidez. Es posible que, durante un período breve, veas que el consumo total de ranuras supera la cantidad máxima que especificaste en todas las reservas, pero no se te cobrará por este uso adicional de ranuras.
Por ejemplo, supongamos que tienes la siguiente configuración de reservas:
project_ase asigna areservation_a, que tiene 500 ranuras de modelo de referencia sin ajuste de escala automático.project_bse asigna areservation_b, que tiene 100 ranuras de modelo de referencia sin ajuste de escala automático.- Ambas reservas están en el mismo proyecto administrativo y no hay otros proyectos asignados a ellas.
Ejecutas query_b en project_b. Si no se ejecuta ninguna consulta en project_a, query_b tiene acceso a las 500 ranuras inactivas de reservation_a. Mientras query_b aún se está ejecutando, puede usar hasta 600 ranuras: 100 ranuras de modelo de referencia 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 modelo de referencia reservadas para
project_a,query_ase inicia de inmediato y se le asignan 500 ranuras. - La cantidad de ranuras asignadas a
query_bdisminuye rápidamente a 100 ranuras de referencia. - Las consultas adicionales que se ejecutan en
project_bcomparten esas 100 ranuras. Si las consultas posteriores no tienen suficientes ranuras para comenzar, se ponen en cola hasta que se completen las consultas que se están ejecutando y las ranuras estén disponibles.
En este ejemplo, si project_b se asignó a una reserva sin ranuras de referencia ni ajuste de escala automático, entonces query_b no tendría ranuras después de que query_a comience a ejecutarse. BigQuery detendría query_b hasta que haya ranuras inactivas disponibles o se agote el tiempo de espera de la consulta. Las consultas adicionales en project_b se pondrán en cola hasta que haya ranuras inactivas disponibles.
Para asegurarte de que una reserva solo use sus ranuras aprovisionadas, configura ignore_idle_slots como true. Sin embargo, las reservas que tienen ignore_idle_slots
configurado como true pueden compartir sus ranuras inactivas con otras reservas.
No puedes compartir ranuras inactivas entre reservas de ediciones diferentes. Solo puedes compartir las ranuras del modelo de referencia o las ranuras confirmadas. Las ranuras con ajuste de escala automático pueden estar disponibles temporalmente, pero no se pueden compartir como ranuras inactivas para otras reservas, ya que pueden reducir la escala verticalmente.
Siempre que ignore_idle_slots sea falso, una reserva puede tener un recuento de ranuras de 0 y aun así tener acceso a las ranuras sin usar. Si solo usas la reserva default,
desactiva ignore_idle_slots como práctica recomendada. Luego, puedes
asignar un proyecto o
una carpeta
a esa reserva y solo usará las ranuras inactivas.
Las asignaciones de tipo ML_EXTERNAL son una excepción en cuanto a que las ranuras que usan
los trabajos de creación de modelos externos de BigQuery ML que no son interrumpibles. Las
ranuras en una reserva con tipos de asignación ML_EXTERNAL y QUERY
solo están disponibles para otros trabajos de consulta cuando las tareas ML_EXTERNAL no ocupan
las ranuras. Además, estos trabajos no pueden usar ranuras inactivas de otras
reservas.
Asignación de ranuras dentro de las reservas
BigQuery asigna la capacidad de ranuras dentro de una sola reserva mediante un algoritmo llamado programación equilibrada.
El programador de BigQuery aplica el uso compartido equitativo de ranuras entre proyectos con consultas en ejecución dentro de una reserva y, luego, dentro de los trabajos de un proyecto determinado. El programador proporciona equidad eventual. Durante períodos breves, algunos trabajos pueden obtener un porcentaje desproporcionado de ranuras, pero el programador lo corregirá con el tiempo. El objetivo del programador es encontrar un equilibrio entre expulsar de forma agresiva las tareas en ejecución (lo que da como resultado una pérdida de tiempo de ranura) y ser demasiado tolerante (lo que da como resultado que los trabajos con tareas de larga duración obtengan un porcentaje desproporcionado de el tiempo de la ranura).
Si un trabajo importante necesita más ranuras de las que recibe del programador con regularidad, considera crear una reserva adicional con una cantidad garantizada de ranuras y asignar el trabajo a esa reserva.
Uso excesivo de ranuras
Cuando un trabajo se retiene en las ranuras por demasiado tiempo, puede recibir un porcentaje injusto de ranuras, como se describió aquí. Para evitar demoras, otros trabajos pueden tomar prestadas ranuras adicionales, lo que da como resultado períodos de uso total de las ranuras por encima de la capacidad de ranura especificada. Cualquier uso excesivo de ranuras se atribuye solo a los trabajos que reciben más del uso legítimo.
No se te facturan directamente los espacios adicionales. En cambio, los trabajos continúan ejecutándose y acumulando uso de ranuras en su porcentaje justo hasta que tu capacidad regular cubra todo el uso excesivo. Los espacios adicionales se excluyen del uso de espacios informados, a excepción de ciertas estadísticas de ejecución detalladas.
Ten en cuenta que cierto préstamo interrumpible de ranuras puede ocurrir para reducir los retrasos futuros y proporcionar otros beneficios, como una variabilidad de los costos de ranuras y una latencia final reducidas. El préstamo de ranuras se limita a una pequeña fracción de la capacidad total de las ranuras.
Programación equilibrada en BigQuery
Las ranuras se distribuyen de manera equitativa entre los proyectos y, luego, en los trabajos del proyecto. Esto significa que cada consulta tiene acceso a todas las ranuras disponibles en cualquier momento, y la capacidad se vuelve a asignar de forma dinámica y automática entre las consultas activas a medida que la capacidad de cada consulta exige un cambio. Las consultas completas y nuevas se envían para su ejecución en función de las siguientes condiciones:
- Cada vez que se envía una consulta nueva, la capacidad se vuelve a asignar de forma automática entre las consultas que se ejecutan. Las unidades de trabajo individuales se pueden detener, reanudar y poner en cola con facilidad a medida que va quedando disponible una mayor capacidad para cada consulta.
- Cada vez que se completa una consulta, la capacidad que utiliza esa consulta va quedando disponible de forma automática e inmediata para las demás consultas.
- Cada vez que la capacidad de una consulta exige una modificación debido a los cambios en el DAG dinámico de la consulta, BigQuery vuelve a evaluar de forma automática la capacidad disponible para esta y todas las demás consultas, y vuelve a asignar o detiene las ranuras según sea necesario.
Según la complejidad y el tamaño, es posible que una consulta no necesite todas las ranuras a las que tiene derecho o que pueda necesitar más. BigQuery garantiza de forma dinámica que, con una programación equilibrada, todas las ranuras se pueden usar en cualquier momento.