Estimar y controlar los costes
En esta página se describen las prácticas recomendadas para estimar y controlar los costes en BigQuery.
Los costes principales de BigQuery son los de computación, que se usan para el procesamiento de consultas, y los de almacenamiento, que se aplican a los datos almacenados en BigQuery. BigQuery ofrece dos tipos de modelos de precios para el procesamiento de consultas: bajo demanda y basado en la capacidad. Cada modelo ofrece diferentes prácticas recomendadas para controlar los costes. En el caso de los datos almacenados en BigQuery, los costes dependen del modelo de facturación del almacenamiento configurado para cada conjunto de datos.
Información sobre los precios de computación de BigQuery
Hay pequeñas diferencias en los precios de los recursos de computación de BigQuery que afectan a la planificación de la capacidad y al control de costes.
Modelos de precios
En el caso de la computación bajo demanda en BigQuery, se te cobrará por TiB de consultas de BigQuery.
Por otro lado, en el caso de la capacidad de computación de BigQuery, se te cobrarán los recursos de computación (ranuras) que se utilicen para procesar la consulta. Para usar este modelo, debes configurar reservas para los espacios.
Las reservas tienen las siguientes características:
- Se asignan en grupos de ranuras y te permiten gestionar la capacidad y aislar las cargas de trabajo de forma que se adapten a tu organización.
- Deben residir en un proyecto de administración y están sujetas a cuotas y límites.
El modelo de precios por capacidad ofrece varias ediciones, todas ellas con una opción de pago por uso que se cobra en horas de ranura. Las ediciones Enterprise y Enterprise Plus también ofrecen compromisos de uno o tres años opcionales que pueden ahorrar dinero en comparación con la tarifa de pago por uso.
También puedes configurar reservas de autoescalado con la opción de pago por uso. Para obtener más información, consulta lo siguiente:
- Para comparar los modelos de precios, consulta el artículo Elegir un modelo.
- Para obtener información sobre los precios, consulta los precios de los recursos de computación bajo demanda y los precios de los recursos de computación de capacidad.
Restringir los costes de cada modelo
Si usas el modelo de precios bajo demanda, la única forma de restringir los costes es configurar cuotas diarias a nivel de proyecto o de usuario. Sin embargo, estas cuotas imponen un límite estricto que impide que los usuarios ejecuten consultas que superen el límite de la cuota. Para definir cuotas, consulta Crear cuotas de consulta personalizadas.
Cuando usas el modelo de precios por capacidad con reservas de espacios publicitarios, especificas el número máximo de espacios publicitarios que están disponibles para una reserva. También puedes comprar compromisos de espacio publicitario que te ofrecen precios rebajados durante un periodo determinado.
Puedes usar las ediciones completamente bajo demanda configurando la base de la reserva en 0 y el máximo en un valor que se ajuste a las necesidades de tu carga de trabajo. BigQuery se adapta automáticamente al número de ranuras que necesita tu carga de trabajo, sin superar nunca el máximo que hayas definido. Para obtener más información, consulta Gestión de cargas de trabajo mediante reservas.
Controlar los costes de las consultas
Para controlar los costes de las consultas individuales, te recomendamos que sigas las prácticas recomendadas para optimizar el cálculo de las consultas y optimizar el almacenamiento.
En las siguientes secciones se describen otras prácticas recomendadas que puede usar para controlar aún más los costes de las consultas.
Crear cuotas de consulta personalizadas
Práctica recomendada: Usa cuotas de consulta diarias personalizadas para limitar la cantidad de datos que se procesan al día.
Para gestionar los costes, puedes definir una cuota personalizada que especifique un límite en la cantidad de datos procesados al día por proyecto o por usuario. Los usuarios no pueden ejecutar consultas una vez que se alcanza la cuota.
Para definir una cuota personalizada, necesitas roles o permisos específicos. Para ver las cuotas que se pueden definir, consulta Cuotas y límites.
Para obtener más información, consulta Restringir los costes de cada modelo de precios.
Consultar el coste estimado antes de ejecutar una consulta
Práctica recomendada: Antes de ejecutar consultas, previsualízalas para estimar los costes.
Si usas el modelo de precios bajo demanda, las consultas se facturan según el número de bytes leídos. Para estimar los costes antes de ejecutar una consulta, sigue estos pasos:
- Usa el validador de consultas en la Google Cloud consola.
- Realiza una prueba de funcionamiento de las consultas.
Usar el validador de consultas
Cuando introduces una consulta en la Google Cloud consola, el validador de consultas verifica la sintaxis de la consulta y proporciona una estimación del número de bytes leídos. Puedes usar esta estimación para calcular el coste de las consultas en la calculadora de precios.
Si la consulta no es válida, el validador de consultas muestra un mensaje de error. Por ejemplo:
Not found: Table myProject:myDataset.myTable was not found in location US
Si la consulta es válida, el validador de consultas proporciona una estimación del número de bytes necesarios para procesarla. Por ejemplo:
This query will process 623.1 KiB when run.
Realizar una prueba de funcionamiento
Para hacer una prueba de funcionamiento, sigue estos pasos:
Consola
Ve a la página de BigQuery.
Escribe tu consulta en el editor de consultas.
Si la consulta es válida, aparecerá automáticamente una marca de verificación junto con la cantidad de datos que procesará la consulta. Si la consulta no es válida, aparecerá un signo de exclamación junto con un mensaje de error.
bq
Introduce una consulta como la siguiente con la marca --dry_run
.
bq query \ --use_legacy_sql=false \ --dry_run \ 'SELECT COUNTRY, AIRPORT, IATA FROM `project_id`.dataset.airports LIMIT 1000'
Si la consulta es válida, el comando genera la siguiente respuesta:
Query successfully validated. Assuming the tables are not modified, running this query will process 10918 bytes of data.
API
Para hacer una prueba con la API, envía una tarea de consulta con el valor true
en el campo dryRun
del tipo JobConfiguration.
Go
Antes de probar este ejemplo, sigue las Goinstrucciones de configuración de la guía de inicio rápido de BigQuery con bibliotecas de cliente. Para obtener más información, consulta la documentación de referencia de la API Go de BigQuery.
Para autenticarte en BigQuery, configura las credenciales predeterminadas de la aplicación. Para obtener más información, consulta el artículo Configurar la autenticación para bibliotecas de cliente.
Java
Antes de probar este ejemplo, sigue las Javainstrucciones de configuración de la guía de inicio rápido de BigQuery con bibliotecas de cliente. Para obtener más información, consulta la documentación de referencia de la API Java de BigQuery.
Para autenticarte en BigQuery, configura las credenciales predeterminadas de la aplicación. Para obtener más información, consulta el artículo Configurar la autenticación para bibliotecas de cliente.
Node.js
Antes de probar este ejemplo, sigue las Node.jsinstrucciones de configuración de la guía de inicio rápido de BigQuery con bibliotecas de cliente. Para obtener más información, consulta la documentación de referencia de la API Node.js de BigQuery.
Para autenticarte en BigQuery, configura las credenciales predeterminadas de la aplicación. Para obtener más información, consulta el artículo Configurar la autenticación para bibliotecas de cliente.
PHP
Antes de probar este ejemplo, sigue las PHPinstrucciones de configuración de la guía de inicio rápido de BigQuery con bibliotecas de cliente. Para obtener más información, consulta la documentación de referencia de la API PHP de BigQuery.
Para autenticarte en BigQuery, configura las credenciales predeterminadas de la aplicación. Para obtener más información, consulta el artículo Configurar la autenticación para bibliotecas de cliente.
Python
Asigna el valor True
a la propiedad QueryJobConfig.dry_run.
Client.query()
siempre devuelve un QueryJob
completado cuando se proporciona una configuración de consulta de prueba.
Antes de probar este ejemplo, sigue las Pythoninstrucciones de configuración de la guía de inicio rápido de BigQuery con bibliotecas de cliente. Para obtener más información, consulta la documentación de referencia de la API Python de BigQuery.
Para autenticarte en BigQuery, configura las credenciales predeterminadas de la aplicación. Para obtener más información, consulta el artículo Configurar la autenticación para bibliotecas de cliente.
Estimar los costes de las consultas
Si usas el modelo de precios bajo demanda, puedes estimar el coste de ejecutar una consulta calculando el número de bytes procesados.
Cálculo del tamaño de las consultas bajo demanda
Para calcular el número de bytes procesados por los distintos tipos de consultas, consulta las siguientes secciones:
Evitar ejecutar consultas para explorar los datos de las tablas
Práctica recomendada: No ejecutes consultas para explorar o previsualizar datos de tablas.
Si estás experimentando con tus datos o explorándolos, puedes usar las opciones de vista previa de la tabla para ver los datos sin coste económico y sin que esto afecte a las cuotas.
BigQuery admite las siguientes opciones de vista previa de datos:
- En la Google Cloud consola, en la página de detalles de la tabla, haga clic en la pestaña Vista previa para obtener una muestra de los datos.
- En la herramienta de línea de comandos bq, usa el comando
bq head
y especifica el número de filas que quieres previsualizar. - En la API, usa
tabledata.list
para recuperar los datos de tabla de un conjunto de filas especificado. - No uses
LIMIT
en tablas no agrupadas. En las tablas no agrupadas, una cláusulaLIMIT
no reducirá los costes de computación.
Restringir el número de bytes facturados por consulta
Práctica recomendada: Usa el ajuste de número máximo de bytes facturados para limitar los costes de las consultas cuando utilices el modelo de precios bajo demanda.
Puedes limitar el número de bytes facturados de una consulta mediante el ajuste de bytes máximos facturados. Cuando fijas el número máximo de bytes facturados, el número de bytes que lee la consulta se estima antes de ejecutarla. Si el número de bytes estimados supera el límite, la consulta fallará sin suponer ningún cargo.
En las tablas agrupadas en clústeres, la estimación del número de bytes facturados de una consulta es un límite superior y puede ser mayor que el número real de bytes facturados después de ejecutar la consulta. Por lo tanto, en algunos casos, si se define el número máximo de bytes facturados, una consulta en una tabla agrupada puede fallar, aunque el número de bytes facturados no supere el valor máximo definido.
Si una consulta falla debido a la configuración del número máximo de bytes facturados, se devuelve un error similar al siguiente:
Error: Query exceeded limit for bytes billed: 1000000. 10485760 or higher
required.
Para definir el número máximo de bytes facturados, sigue estos pasos:
Consola
- En el editor de consultas, haz clic en Más > Configuración de consultas > Opciones avanzadas.
- En el campo Número máximo de bytes que se facturan, introduce un número entero.
- Haz clic en Guardar.
bq
Usa el comando bq query
con la marca --maximum_bytes_billed
.
bq query --maximum_bytes_billed=1000000 \ --use_legacy_sql=false \ 'SELECT word FROM `bigquery-public-data`.samples.shakespeare'
API
Define la propiedad maximumBytesBilled
en JobConfigurationQuery
o QueryRequest
.
Evita usar LIMIT
en tablas no agrupadas en clústeres
Práctica recomendada: En las tablas no agrupadas en clústeres, no uses una cláusula LIMIT
como método de control de costes.
En las tablas no agrupadas, aplicar una cláusula LIMIT
a una consulta no afecta a la cantidad de datos que se leen. Se te cobra por leer todos los bytes de la tabla completa, tal como indica la consulta, aunque esta solo devuelva un subconjunto. En una tabla agrupada en clústeres, una cláusula LIMIT
puede reducir el número de bytes analizados, ya que el análisis se detiene cuando se han analizado suficientes bloques para obtener el resultado. Solo se te cobra por los bytes que se analizan.
Materializar los resultados de las consultas por fases
Práctica recomendada: Si es posible, materializa los resultados de las consultas por fases.
Si creas una consulta grande de varias fases, cada vez que la ejecutes, BigQuery leerá todos los datos que necesite la consulta. Se te cobrará por todos los datos que se lean cada vez que se ejecute la consulta.
En su lugar, divide la consulta en fases en las que cada fase materialice los resultados de la consulta escribiéndolos en una tabla de destino. Al consultar la tabla de destino más pequeña, se reduce la cantidad de datos que se leen y, por lo tanto, los costes. El coste de almacenar los resultados materializados es mucho menor que el coste de procesar grandes cantidades de datos.
Controlar los costes de las cargas de trabajo
En esta sección se describen las prácticas recomendadas para controlar los costes de una carga de trabajo. Una carga de trabajo es un conjunto de consultas relacionadas. Por ejemplo, una carga de trabajo puede ser una canalización de transformación de datos que se ejecuta a diario, un conjunto de paneles de control que utiliza un grupo de analistas de negocio o varias consultas ad hoc que ejecuta un conjunto de científicos de datos.
Usa la Google Cloud calculadora de precios
Práctica recomendada: usa la Google Cloud calculadora de precios para crear una estimación del coste mensual total de BigQuery en función del uso previsto. Después, puedes comparar esta estimación con tus costes reales para identificar áreas de optimización.
bajo demanda
Para estimar los costes en la Google Cloud calculadora de precios cuando se usa el modelo de precios bajo demanda, sigue estos pasos:
- Abre la Google Cloud calculadora de precios.
- Haz clic en Añadir a la estimación.
- Selecciona BigQuery.
- Seleccione "Bajo demanda" en Tipo de servicio.
- Elige la ubicación en la que se ejecutarán tus consultas.
- En Cantidad de datos consultados, introduce los bytes estimados que se han leído en la ejecución de prueba o en el validador de consultas.
- Introduce tus estimaciones de uso del almacenamiento activo, a largo plazo, de inserciones de transmisión y de lecturas de transmisión. Solo tienes que estimar el almacenamiento físico o el lógico, en función del modelo de facturación del almacenamiento de conjuntos de datos.
- La estimación aparece en el panel Detalles del coste. Para obtener más información sobre el coste estimado, haga clic en Abrir vista detallada. También puedes descargar y compartir la estimación de costes.
Para obtener más información, consulta los precios bajo demanda.
Ediciones
Para estimar los costes en la Google Cloud calculadora de precios al usar el modelo de precios basado en la capacidad con las ediciones de BigQuery, sigue estos pasos:
- Abre la Google Cloud calculadora de precios.
- Haz clic en Añadir a la estimación.
- Selecciona BigQuery.
- Seleccione "Ediciones" en Tipo de servicio.
- Elige la ubicación en la que se usan los espacios.
- Elige tu edición.
- Elige Número máximo de ranuras, Número de ranuras de referencia, Compromiso (opcional) y Utilización estimada del autoescalado.
- Elige la ubicación en la que se almacenarán los datos.
- Introduce tus estimaciones de uso del almacenamiento activo, a largo plazo, de inserciones de transmisión y de lecturas de transmisión. Solo tienes que estimar el almacenamiento físico o el lógico, en función del modelo de facturación del almacenamiento de conjuntos de datos.
- La estimación aparece en el panel Detalles del coste. Para obtener más información sobre el coste estimado, haga clic en Abrir vista detallada. También puedes descargar y compartir la estimación de costes.
Para obtener más información, consulta los precios basados en la capacidad.
Usar reservas y compromisos
Práctica recomendada: usa reservas y compromisos de BigQuery para controlar los costes.
Para obtener más información, consulta Restringir los costes de cada modelo de precios.
Usar el estimador de espacios
Práctica recomendada: Usa la herramienta de estimación de slots para calcular el número de slots que necesitan tus cargas de trabajo.
El estimador de slots de BigQuery te ayuda a gestionar la capacidad de los slots en función de las métricas del historial de rendimiento.
Además, los clientes que usen el modelo de precios bajo demanda pueden ver recomendaciones de tamaño para los compromisos y las reservas con escalado automático con un rendimiento similar al cambiar a los precios basados en la capacidad.
Cancelar tareas de larga duración innecesarias
Para liberar capacidad, comprueba los trabajos de larga duración y asegúrate de que deben seguir ejecutándose. Si no es así, cancélalos.
Ver los costes mediante un panel de control
Práctica recomendada: crea un panel de control para analizar tus datos de Facturación de Cloud y así poder monitorizar y ajustar tu uso de BigQuery.
Puedes exportar tus datos de facturación a BigQuery y visualizarlos en una herramienta como Looker Studio. Para ver un tutorial sobre cómo crear un panel de facturación, consulta Visualizar la facturación con BigQuery y Looker Studio. Google Cloud
Usar presupuestos y alertas de facturación
Práctica recomendada: Usa los presupuestos de Facturación de Cloud para monitorizar tus cargos de BigQuery en un mismo lugar.
Los presupuestos de facturación de Cloud te permiten monitorizar tus costes reales y compararlos con los costes planificados. Una vez que hayas definido el importe de tu presupuesto, deberás configurar reglas de umbrales de alertas de presupuesto que se usarán para enviar notificaciones por correo electrónico. Los correos de alerta de presupuesto te ayudan a estar al tanto de cómo se compara tu gasto en BigQuery con tu presupuesto.
Controlar los costes de almacenamiento
Sigue estas prácticas recomendadas para optimizar el coste del almacenamiento de BigQuery. También puedes optimizar el almacenamiento para mejorar el rendimiento de las consultas.
Usar el almacenamiento a largo plazo
Práctica recomendada: usa los precios de almacenamiento a largo plazo para reducir el coste de los datos antiguos.
Cuando cargas datos en el almacenamiento de BigQuery, estos están sujetos a los precios de almacenamiento de BigQuery. En el caso de los datos antiguos, puedes aprovechar automáticamente los precios de almacenamiento a largo plazo de BigQuery.
Si tienes una tabla que no se modifica durante 90 días consecutivos, el precio de almacenamiento de esa tabla se reduce automáticamente en un 50 %. Si tiene una tabla con particiones, cada partición se considera por separado para determinar si cumple los requisitos de los precios a largo plazo, de acuerdo con las mismas reglas que las tablas sin particiones.
Configurar el modelo de facturación del almacenamiento
Práctica recomendada: Optimiza el modelo de facturación del almacenamiento en función de tus patrones de uso.
BigQuery admite la facturación del almacenamiento mediante bytes lógicos (sin comprimir) o físicos (comprimidos), o una combinación de ambos. El modelo de facturación del almacenamiento configurado para cada conjunto de datos determina los precios del almacenamiento, pero no afecta al rendimiento de las consultas.
Puedes usar las INFORMATION_SCHEMA
vistas para determinar el modelo de facturación del almacenamiento que mejor se adapte a tus patrones de uso.
Evitar sobrescribir tablas
Práctica recomendada: Si usas el modelo de facturación de almacenamiento físico, evita sobrescribir tablas repetidamente.
Cuando sobrescribes una tabla, por ejemplo, usando el parámetro --replace
en tareas de carga por lotes o la instrucción SQL TRUNCATE TABLE
, los datos sustituidos se conservan durante los periodos de tiempo de viaje y de seguridad.
Si sobrescribes una tabla con frecuencia, se te aplicarán cargos adicionales por almacenamiento.
En su lugar, puede cargar datos de forma incremental en una tabla mediante el parámetro WRITE_APPEND
en las tareas de carga, la instrucción SQL MERGE
o la API de escritura de almacenamiento.
Reducir la ventana de viaje en el tiempo
Práctica recomendada: En función de tus requisitos, puedes reducir el periodo de retroceso en el tiempo.
Si reduces el periodo de viaje en el tiempo, que tiene un valor predeterminado de siete días, se reduce el periodo de conservación de los datos eliminados o modificados en una tabla. Solo se te cobra por el almacenamiento de viajes en el tiempo cuando usas el modelo de facturación de almacenamiento físico (comprimido).
El periodo de retroceso se define a nivel del conjunto de datos. También puedes definir el periodo predeterminado de la ventana de viaje en el tiempo para los nuevos conjuntos de datos mediante los ajustes de configuración.
Usar la caducidad de la tabla en las tablas de destino
Práctica recomendada: Si vas a escribir resultados de consultas de gran tamaño en una tabla de destino, usa el tiempo de vencimiento predeterminado de la tabla para eliminar los datos cuando ya no los necesites.
Mantener grandes conjuntos de resultados en el almacenamiento de BigQuery tiene un coste. Si no necesitas acceso permanente a los resultados, usa la fecha de vencimiento predeterminada de la tabla para que los datos se eliminen automáticamente.
Archivar datos en Cloud Storage
Práctica recomendada: considera la posibilidad de archivar datos en Cloud Storage.
Puedes mover datos de BigQuery a Cloud Storage en función de las necesidades de archivo de tu empresa. Como práctica recomendada, ten en cuenta los precios del almacenamiento a largo plazo y el modelo de facturación del almacenamiento físico antes de exportar datos de BigQuery.
Solucionar problemas de discrepancias en los costes y cargos inesperados de BigQuery
Sigue estos pasos para solucionar problemas relacionados con cargos inesperados de BigQuery o discrepancias en los costes:
Para saber de dónde proceden los cargos de BigQuery al consultar el informe de Facturación de Cloud, le recomendamos que agrupe los cargos por SKU para que le resulte más fácil observar el uso y los cargos de los servicios de BigQuery correspondientes.
Después, consulta los precios de los SKUs correspondientes en la página de documentación de SKUs o en la página
Pricing
de la interfaz de Facturación de Cloud para saber qué función es (por ejemplo, la API Storage Read de BigQuery, el almacenamiento a largo plazo, los precios bajo demanda o la edición Standard).Una vez que haya identificado los SKUs correspondientes, utilice las vistas
INFORMATION_SCHEMA
para identificar los recursos específicos asociados a estos cargos. Por ejemplo:- Si se te cobra por el análisis bajo demanda, consulta los ejemplos de la vista
INFORMATION_SCHEMA.JOBS
para determinar qué tareas generan costes y qué usuarios las han iniciado. - Si se te cobra por SKUs de reserva o compromiso, consulta las vistas
INFORMATION_SCHEMA.RESERVATIONS
yINFORMATION_SCHEMA.CAPACITY_COMMITMENTS
correspondientes para identificar las reservas y los compromisos por los que se te cobra. - Si los cargos proceden de SKUs de almacenamiento, consulta los
INFORMATION_SCHEMA.TABLE_STORAGE
ejemplos de vistas para saber qué conjuntos de datos y tablas están generando más costes.
- Si se te cobra por el análisis bajo demanda, consulta los ejemplos de la vista
Consideraciones importantes para solucionar problemas:
Ten en cuenta que el periodo Diario del informe de Facturación de Cloud empieza a medianoche (hora del Pacífico de EE. UU. y Canadá, UTC-8) y tiene en cuenta los cambios de horario de verano en Estados Unidos. Ajusta tus cálculos y agregaciones de datos para que coincidan con los mismos periodos.
Filtra por proyecto si hay varios proyectos asociados a la cuenta de facturación y quieres revisar los cargos de un proyecto concreto.
Asegúrate de seleccionar la región correcta al realizar investigaciones.
Cargos inesperados relacionados con consultas, reservas y confirmaciones
Para solucionar los problemas relacionados con los cargos inesperados por la ejecución de tareas, debes determinar el origen de estos cargos:
- Si observas un aumento en los costes de análisis bajo demanda, puede deberse a un incremento en el número de tareas que se han iniciado o a un cambio en la cantidad de datos que deben procesar las tareas. Investiga este problema con la vista
INFORMATION_SCHEMA.JOBS
. - Si se produce un aumento en los cargos de las ranuras comprometidas, investiga la situación consultando
INFORMATION_SCHEMA.CAPACITY_COMMITMENT_CHANGES
para ver si se han comprado o modificado nuevos compromisos. - Para ver los aumentos de los cargos derivados del uso de reservas, consulta los cambios en las reservas que se registran en
INFORMATION_SCHEMA.RESERVATION_CHANGES
. Para que el uso de la reserva de autoescalado coincida con los datos de facturación, sigue el ejemplo de autoescalado.
Las horas de ranura facturadas son superiores a las horas de ranura calculadas en la vista INFORMATION_SCHEMA.JOBS
Cuando se usa una reserva con escalado automático, la facturación se calcula en función del número de espacios escalados, no del número de espacios utilizados. BigQuery se escala automáticamente en múltiplos de 50 ranuras, lo que conlleva que se facture el múltiplo más cercano aunque se use una cantidad inferior a la que se ha escalado automáticamente. El autoescalador tiene un periodo mínimo de 1 minuto antes de reducir la escala, lo que significa que se cobrará al menos 1 minuto aunque la consulta haya usado las ranuras durante menos tiempo (por ejemplo, solo 10 segundos de ese minuto). La forma correcta de estimar los cargos de una reserva de autoescalado se describe en la página Autoescalado de slots. Para obtener más información sobre cómo usar el autoescalado de forma eficiente, consulta las prácticas recomendadas de autoescalado.
En el caso de las reservas sin escalado automático, la facturación se calcula en función del número de ranuras aprovisionadas, no del número de ranuras utilizadas. Si quieres estimar los cargos de una reserva que no se ajusta automáticamente, puedes consultar directamente la vista RESERVATIONS_TIMELINE
.
La facturación es inferior al total de bytes facturados calculado mediante INFORMATION_SCHEMA.JOBS para el proyecto que ejecuta consultas bajo demanda
Puede haber varios motivos por los que la facturación real sea inferior a los bytes procesados calculados:
- Cada proyecto dispone de 1 TB de consultas de nivel gratuito al mes sin coste adicional.
- Los trabajos de tipo
SCRIPT
no se excluyeron del cálculo, lo que podría provocar que algunos valores se contabilizaran dos veces. - Diferentes tipos de ahorros aplicados a tu cuenta de facturación de Cloud, como descuentos negociados, créditos promocionales y otros. Consulta la sección Ahorros del informe de facturación de Cloud. También se incluye el nivel gratuito de 1 TB de consultas al mes.
La facturación es superior a los bytes procesados calculados mediante INFORMATION_SCHEMA.JOBS para el proyecto que ejecuta consultas bajo demanda
Si el importe de la factura es superior al valor que has calculado consultando la vista INFORMATION_SCHEMA.JOBS
, puede deberse a alguna de estas causas:
Consultas en tablas con seguridad a nivel de fila
- Las consultas sobre tablas con seguridad a nivel de fila no producen un valor para
total_bytes_billed
en la vistaINFORMATION_SCHEMA.JOBS
. Por lo tanto, la facturación calculada mediantetotal_bytes_billed
de la vistaINFORMATION_SCHEMA.JOBS
será inferior al valor facturado. Consulta la página Prácticas recomendadas para la seguridad a nivel de fila para obtener más información sobre por qué no se muestra esta información.
- Las consultas sobre tablas con seguridad a nivel de fila no producen un valor para
Realizar operaciones de aprendizaje automático en BigQuery
- El precio de BigQuery ML para las consultas bajo demanda depende del tipo de modelo que se cree. Algunas de estas operaciones con modelos se cobran a un precio más alto que las consultas que no son de aprendizaje automático. Por lo tanto, si solo sumas todos los
total_billed_bytes
del proyecto y usas la tarifa estándar bajo demanda por TB, no obtendrás una agregación de precios correcta. Debes tener en cuenta la diferencia de precios por TB.
- El precio de BigQuery ML para las consultas bajo demanda depende del tipo de modelo que se cree. Algunas de estas operaciones con modelos se cobran a un precio más alto que las consultas que no son de aprendizaje automático. Por lo tanto, si solo sumas todos los
Importes de precios incorrectos
- Confirme que se utilizan los valores de precios por TB correctos en los cálculos. Asegúrese de elegir la región correcta, ya que los precios dependen de la ubicación. Consulta la documentación sobre los precios.
La recomendación general es seguir el método recomendado para calcular el uso de trabajos a petición para la facturación que se indica en nuestra documentación pública.
Se me cobra por el uso de la API Reservations de BigQuery aunque la API esté inhabilitada y no se usen reservas ni compromisos
Inspecciona la SKU para saber qué servicios se cobran. Si el SKU facturado es BigQuery Governance SKU
, se trata de cargos procedentes de Dataplex Universal Catalog.
Algunas funciones de Dataplex Universal Catalog activan la ejecución de tareas a través de BigQuery. Ahora, estos cargos se procesan con el SKU de la API Reservations de BigQuery correspondiente. Consulta más información en la documentación sobre los precios de Dataplex Universal Catalog.
El proyecto se ha asignado a una reserva, pero siguen apareciendo costes bajo demanda de análisis de BigQuery
Lee la sección Solucionar problemas con las reservas para identificar de dónde pueden proceder los cargos de Analysis
.
Cargos inesperados por las ranuras de pago por uso de la edición Estándar de BigQuery
En el informe de facturación de Cloud, aplica un filtro con la etiqueta goog-bq-feature-type
y el valor BQ_STUDIO_NOTEBOOK
. El uso que verás se mide como slots de pago por uso en la edición estándar de BigQuery. Se trata de cargos por usar el cuaderno de BigQuery Studio. Consulta más información sobre los precios de los cuadernos de BigQuery Studio.
Cargos de la API Reservations de BigQuery que aparecen después de inhabilitar la API Reservations
Si inhabilitas BigQuery, no se detendrán los cargos por el compromiso. Para dejar de recibir cargos por compromisos, debes eliminar uno. Define el plan de renovación como NONE
y la confirmación se eliminará automáticamente cuando caduque.
Cargos de almacenamiento inesperados
Situaciones que pueden provocar un aumento de las tarifas de almacenamiento:
- Aumentos en la cantidad de datos almacenados en tus tablas: usa la vista
INFORMATION_SCHEMA.TABLE_STORAGE_USAGE_TIMELINE
para monitorizar el cambio en bytes de tus tablas. - Cambiar los modelos de facturación de conjuntos de datos
- Aumentar el periodo de retroacción de los conjuntos de datos del modelo de facturación física
- Modificación de tablas que tienen datos en almacenamiento a largo plazo, lo que hace que se conviertan en almacenamiento activo
La eliminación de tablas o conjuntos de datos ha provocado un aumento de los costes de almacenamiento de BigQuery
La función de viaje en el tiempo de BigQuery conserva los datos eliminados durante el periodo de tiempo configurado y 7 días más para poder recuperarlos en caso de fallo. Durante este periodo de conservación, los datos eliminados de los conjuntos de datos del modelo de facturación de almacenamiento físico contribuyen al coste del almacenamiento físico activo, aunque las tablas ya no aparezcan en INFORMATION_SCHEMA.TABLE_STORAGE
ni en la consola. Si los datos de la tabla estaban en almacenamiento a largo plazo, la eliminación hará que se muevan al almacenamiento físico activo. Esto provoca que el coste correspondiente aumente, ya que los bytes físicos activos se cobran aproximadamente el doble que los bytes físicos a largo plazo, según la página de precios de almacenamiento de BigQuery. La práctica recomendada para minimizar los costes derivados de la eliminación de datos en los conjuntos de datos del modelo de facturación de almacenamiento físico es reducir la ventana de viaje en el tiempo a 2 días.
Reducción de los costes de almacenamiento sin modificar los datos
En BigQuery, los usuarios pagan por el almacenamiento activo y a largo plazo. Los costes de almacenamiento activo incluyen cualquier tabla o partición de tabla que no se haya modificado durante 90 días consecutivos, mientras que los costes de almacenamiento a largo plazo incluyen tablas y particiones que no se hayan modificado durante 90 días consecutivos. El coste total de almacenamiento se puede reducir cuando los datos pasan al almacenamiento a largo plazo, que es aproximadamente un 50% más barato que el almacenamiento activo. Consulta más información sobre los precios del almacenamiento.
Los cálculos de almacenamiento de INFORMATION_SCHEMA no coinciden con la facturación
- Usa la vista
INFORMATION_SCHEMA.TABLE_STORAGE_USAGE_TIMELINE
en lugar deINFORMATION_SCHEMA.TABLE_STORAGE
.TABLE_STORAGE_USAGE_TIMELINE
proporciona datos más precisos y detallados para calcular correctamente los costes de almacenamiento. - Las consultas que se ejecutan en las vistas de
INFORMATION_SCHEMA
no incluyen impuestos, ajustes ni errores de redondeo, por lo que debes tenerlos en cuenta al comparar los datos. Consulta más información sobre los informes de Facturación de Cloud en esta página. - Los datos que se muestran en las vistas de
INFORMATION_SCHEMA
están en UTC, mientras que los datos de los informes de facturación se indican en la hora del Pacífico de EE. UU. y Canadá (UTC-8).
Siguientes pasos
- Obtén más información sobre los precios de BigQuery.
- Consulta cómo optimizar las consultas.
- Consulta cómo optimizar el almacenamiento.
Para obtener información sobre la facturación, las alertas y la visualización de datos, consulte los siguientes temas: