Confiabilidad: Consulta datos

En este documento, se explica cómo compilar soluciones confiables con BigQuery y cómo consultar datos en tu entorno de BigQuery de manera confiable.

Información sobre las ranuras

Cuando BigQuery ejecuta un trabajo de consulta, convierte la instrucción de SQL enviada en un grafo de ejecución dividido en una serie de etapas de consulta, que a su vez están compuestos 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. Los recursos de estos trabajadores se llaman ranuras.

Dicho de manera más sencilla, una ranura de BigQuery es una CPU virtual que BigQuery utiliza para ejecutar consultas de SQL. Para obtener más información sobre las ranuras y su funcionamiento, consulta Información sobre las ranuras.

BigQuery puede lograr un ANS de un 99.99% para las consultas, ya que proporciona capacidad de ranuras redundante en dos zonas distintas. Esta distribución protege a los clientes de fallas zonales.

Los recursos de procesamiento que se usan para ejecutar consultas se compran de acuerdo con un modelo de precios según demanda o de tasa fija. En el modelo según demanda, los recursos de procesamiento se cobran según la cantidad de bytes que las consultas enviadas procesen. En el modelo de tasa fija, compras una cantidad dedicada de capacidad de procesamiento de consultas, lo que proporciona un modelo de costos estable.

Modelo de análisis a pedido

Con el modelo de precios según demanda de BigQuery, se te cobra solo por el uso en función de la cantidad de bytes, también denominados “bytes leídos”, que las consultas enviadas procesan. Los proyectos que usan el modelo de precios según demanda de BigQuery tienen acceso a una capacidad predeterminada de ranuras, que, por lo general, es más que suficiente, y estas están sujetas a cuotas de ranuras por proyecto.

Modelo de ranura de tasa fija

Los clientes que prefieren un costo estable para las consultas en lugar de pagar con el modelo de precios según demanda deben considerar el modelo de precios de tasa fija. Cuando estás inscrito en el precio de tasa fija, adquieres una capacidad de procesamiento dedicada de consultas que se mide en ranuras de BigQuery. Tus consultas consumen esta capacidad, y no se facturan los bytes procesados.

La estructura de tasa fija permite a los clientes comprar ranuras en diferentes momentos de compromiso (anual, mensual o sin compromiso), priorizar ranuras para proyectos o carpetas específicos con reservas de ranuras y compartir ranuras inactivas entre varias reservas. Para obtener más información, consulta Introducción a las reservas.

El modelo de tasa fija establece de forma explícita una cantidad máxima de recursos de ranuras disponibles para las carpetas o los proyectos, por lo que comprar muy pocas ranuras puede afectar el rendimiento de las consultas, mientras que comprar demasiadas ranuras puede generar inactividad en el procesamiento, lo que da como resultado recursos poco usados y costos innecesarios.

Consideraciones para los modelos de ranuras de tasa fija

Si bien las consideraciones de costos suelen ser el factor más importante para elegir entre el modelo según demanda y el de tasa fija, esta decisión también puede afectar la confiabilidad. Por ejemplo, la escalabilidad puede diferir entre el modelo de precios según demanda, que proporciona un modelo de referencia de 2,000 ranuras disponibles por proyecto durante la carga máxima, y el modelo de tasa fija, que se puede configurar con hasta cientos de miles de ranuras. La cantidad de ranuras que consume tu proyecto depende de la complejidad de la consulta, la cantidad de datos analizados, el uso de funciones especiale,s como las funciones definidas por el usuario (UDF), y la cantidad de consultas simultáneas enviadas. Sin embargo, las 2,000 ranuras disponibles para los clientes del modelo según demanda suelen ser más que suficientes para los usuarios que comienzan con BigQuery. Si deseas obtener más información para elegir el modelo según demanda o el de tasa fija de BigQuery, consulta Elige entre los precios según demanda y los de tasa fija.

El ANS de disponibilidad del 99.99% de BigQuery se aplica al modelo según demanda y al de tasa fija, pero la cantidad de recursos de ranuras solo está garantizada en el modelo de tasa fija, ya que el modelo según demanda usa un grupo de recursos de ranuras compartidos. Ten en cuenta que BigQuery no proporciona ninguna garantía sobre la disponibilidad de las ranuras reservadas hasta que se hayan comprado y aprovisionado. Por este motivo, Google no recomienda que dependas de la adquisición de ranuras reservadas en el momento para las cargas de trabajo fundamentales de la empresa. Cuanto mayor sea la solicitud de la ranura, mayor será la probabilidad de que se requiera un plazo de entrega para aprovisionar los recursos de la ranura.

También es posible combinar el modelo según demanda y el de tasa fija dentro de tu organización o proyecto para que se adapte mejor a tus necesidades. Esto es posible por el concepto de reservas de BigQuery. Un buen ejemplo de esto podría ser usar una reserva de tasa fija para un conjunto de datos de producción de varias regiones de EE.UU. y usar una capacidad según demanda para un conjunto de datos de desarrollo más pequeño basado en una región alternativa.

Reservas

Las reservas de BigQuery te permiten personalizar las asignaciones de capacidad de ranuras en toda la organización y, cuando lo haces, priorizar los recursos según las cargas de trabajo. Por ejemplo, puedes crear una reserva llamada prod para las cargas de trabajo de producción y otra llamada test para las pruebas. De esta manera, los trabajos de prueba no competirán por los recursos que necesitan las cargas de trabajo de producción. Una reserva especifica la priorización de los recursos de ranuras para el proyecto, la carpeta o la organización asignados. Cada nivel de la jerarquía de recursos hereda la asignación del nivel superior, a menos que se anule. En otras palabras, un proyecto hereda la asignación de su carpeta superior y una carpeta hereda la asignación de su organización.

Para reservar los recursos, BigQuery comparte los recursos de ranuras inactivas con otras reservas de forma predeterminada. Esto permite que las cargas de trabajo no priorizadas, como los entornos de desarrollo y prueba, se beneficien de un mejor rendimiento de las consultas durante los momentos en que las reservas de producción pueden no usarse por completo. En el caso de que una carga de trabajo de desarrollo y prueba consuma ranuras sin usar de una reserva de producción, y esa reserva de producción ahora se usa por completo, el programador de ranuras de BigQuery extraerá de forma inteligente los recursos de las ranuras de las consultas de desarrollo/pruebas en ejecución y las pondrá a disposición de la reserva de producción. Las consultas de desarrollo y prueba continuarán ejecutándose, aunque de forma más lenta, ya que tienen menos recursos de procesamiento para usar.

Según la naturaleza de tus necesidades de estadísticas, a menudo tiene sentido crear varias reservas de BigQuery dentro de tu entorno, mediante la separación de las cargas de trabajo según la unidad de negocios, la función (producción o desarrollo/prueba) o el tipo de aplicación (panel de inteligencia empresarial frente a consultas/trabajos programados y consultas ad hoc de los usuarios).

Ten en cuenta que las ranuras inactivas solo se comparten dentro de las reservas creadas dentro de un solo proyecto de administración de BigQuery.

Ajusta el tamaño de una reserva

La mejor forma de redimensionar con precisión una reserva suele ser mediante la supervisión del uso histórico y actual de las ranuras de BigQuery con una de las siguientes opciones: Gráficos de recursos del administrador de BigQuery o Panel de Cloud Monitoring. Los gráficos de recursos de administrador proporcionan datos históricos y en tiempo real de los últimos 14 días con detalles sobre el uso de ranuras, la simultaneidad de trabajos y el rendimiento del trabajo a nivel de la organización, la carpeta, el proyecto, la reserva, el usuario o el trabajo.

Optimiza la confiabilidad de los trabajos

Se pueden enviar dos tipos de consultas para analizar datos:

Consultas interactivas: Se remite una consulta interactiva enviada para su ejecución de inmediato.
Consultas por lotes: Una consulta por lotes enviada se pone en cola y se inicia en cuanto haya suficientes recursos de ranuras disponibles. Si BigQuery no inicia la consulta en 24 horas, cambia la prioridad del trabajo a interactivo y despacha la consulta de inmediato.

Las consultas interactivas y por lotes usan los mismos recursos de ranuras. De hecho, después de que el programador de BigQuery inicia una consulta por lotes, no hay diferencias entre la prioridad de una consulta interactiva o por lotes. Sin embargo, las consultas interactivas y por lotes afectan a los límites y cuotas de las consultas de manera diferente. Las consultas por lotes no cuentan para tu límite de frecuencia simultánea, lo que puede facilitar el inicio de muchas consultas a la vez. Sin embargo, tu proyecto puede ejecutar hasta 10 consultas por lotes simultáneas.

Si se alcanza el límite de consultas simultáneas, las consultas interactivas adicionales fallarán con un error quotaExceeded. Esta cuota existe para tu protección, por lo que, siempre que no se consuman las ranuras disponibles, por lo general puedes aumentar esta cuota si te comunicas con Atención al cliente oVentas. Sin embargo, los grados altos de consultas simultáneas reducen la disponibilidad general de los recursos de procesamiento para cada consulta y, por lo tanto, pueden generar la contención de los recursos y degradar la capacidad de procesamiento por consulta. Por lo tanto, no debes aumentar la cuota de consultas simultáneas más allá del punto en que los recursos de ranuras se saturan. Si se encuentran errores de consultas simultáneas, puedes volver a realizar la consulta con una lógica de retirada exponencial para evitar que la latencia del trabajo de consulta se vea afectada.

Entre las posibles opciones para reducir la cantidad de consultas simultáneas en tu entorno, se incluyen las siguientes:

Ejecuta consultas en modo de ejecución de prueba, con lo que se calcula la cantidad de bytes leídos, pero que no se procesa la consulta.
Cuando experimentes o explores datos, en lugar de ejecutar consultas, obtén una vista previa de los datos de tablas con la función de vista previa de tablas de BigQuery.
Usa los resultados de las consultas en caché. Todos los resultados de consultas, incluidas las consultas interactivas y por lotes, se almacenan en caché en tablas temporales durante unas 24 horas, con algunas excepciones. Si bien la ejecución de una consulta almacenada en caché aún se considera para el límite de consultas simultáneas, las consultas que usan los resultados en caché son mucho más rápidas porque BigQuery no necesita procesar el conjunto de resultados.
Usa BI Engine, el servicio de análisis en memoria rápido y de BigQuery. BI Engine te permite compilar informes y paneles interactivos con herramientas como Looker Studio y la interfaz de SQL, y ofrece una simultaneidad mejorada para los datos almacenados en BigQuery. Esto es especialmente útil para grandes cantidades de consultas pequeñas.

Otras consideraciones relacionadas con la simultaneidad de las consultas y el rendimiento de los trabajos son el aislamiento de trabajos y el trabajo escalonado. Aislar los trabajos de consulta por caso de uso en cada proyecto o reserva puede hacer desaparecer el “problema del vecino ruidoso” en el que una consulta consume una gran cantidad de recursos, lo que puede afectar de forma negativa el rendimiento de otras consultas. Esto también reduce la probabilidad de alcanzar los límites de consultas simultáneas por proyecto.

El trabajo escalonado, o la acción de enviar varios trabajos en secuencia en lugar de remitirlos de forma simultánea, también puede beneficiar el rendimiento general y reducir las tasas de error. Como ejemplo, considera un conjunto de cinco trabajos complejos. Supongamos que la ejecución de estas cinco consultas consume una cantidad grande de ranuras y necesita una hora para completarse. Si se envían esos cinco trabajos en secuencia puede aún tarden una hora en completarse, pero esto liberará recursos de ranuras para que los usen otras consultas y reducirá la posibilidad de alcanzar límites de consultas simultáneas.

BigQuery usa la programación equilibrada para asignar recursos entre las consultas que compiten dentro de un proyecto o una reserva. Esto significa que cada consulta tiene igual 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. Por este motivo, es posible que ejecutar consultas de desarrollo y prueba fundamentales para la empresa dentro del mismo proyecto o reserva no sea lo ideal, ya que cada consulta tiene el mismo acceso a las ranuras, por lo que las consultas no fundamentales pueden afectar el rendimiento de consultas fundamentales en curso. Se recomienda priorizar las consultas antes de ejecutarlas.

Consideraciones de DML para la optimización de la confiabilidad

Las declaraciones de lenguaje de manipulación de datos (DML) de BigQuery te permiten actualizar, insertar y borrar datos de tus tablas de BigQuery y tener sus propios lineamientos sobre la confiabilidad.

BigQuery es completamente atómico, por lo que cada declaración DML inicia una transacción implícita, lo que significa que los cambios realizados por la declaración se confirman de forma automática al final de cada declaración DML exitosa.
Las declaraciones UPDATE , DELETE o MERGE de DML no se pueden usar en una tabla, que tiene datos en el almacenamiento optimizado para escritura. Si lo intentas, se producirá un error en la consulta.
Las declaraciones DML INSERT, UPDATE, DELETE y MERGE no tienen límites de cuotas simultáneas. Sin embargo, una vez que se alcanza un cierto umbral de trabajos simultáneos, los trabajos nuevos estarán en cola con un estado pendiente.
Si se ejecutan declaraciones DML de forma simultánea en la misma tabla, BigQuery determina si estas pueden mutar los mismos archivos de backend y solo permite que una declaración DML continúe, mientras se reintentan las otras hasta tres veces. Si los tres reintentos posteriores de DML fallan, las declaraciones DML fallarán debido a conflictos en los cambios que intentaron realizar.
Si bien BigQuery es compatible por completo con las operaciones UPDATE , DELETE y MERGE, no está diseñado para ser una base de datos transaccional con estilo OLTP.

Como práctica recomendada, evita enviar grandes cantidades de actualizaciones o inserciones de filas DML individuales. Agrupa las operaciones DML cuando sea posible.

Consideraciones sobre las UDF para la optimización de la confiabilidad

Las funciones definidas por el usuario (UDF) de BigQuery son funciones persistentes o temporales creadas a partir de una expresión SQL o código JavaScript que muestran resultados basados en la ejecución del código proporcionado. Las UDF tienen sus propios lineamientos sobre la confiabilidad.

Por lo general, las UDF consumen más recursos de ranuras en comparación con las consultas de SQL estándar y pueden afectar el rendimiento del trabajo. Si la función se puede expresar en SQL, suele ser más óptimo ejecutar el código como un trabajo de consulta de SQL estándar.
Una UDF de JavaScript puede agotar el tiempo de espera y evitar que se completen las consultas. Los tiempos de espera pueden ser de tan solo 5 minutos, pero pueden variar según distintos factores, incluidos el tiempo de CPU del usuario que consume tu función y el tamaño de las entradas y salidas en la función de JavaScript.
Las UDF están sujetas a sus propias cuotas y límites de consultas simultáneas. Para obtener más información, consulta Límites de UDF.

Administra cuotas y límites

Como se mencionó antes, los trabajos de consulta están sujetos a una serie de límites y cuotas. Estos límites varían según el tipo de consulta y otros factores, pero el límite máximo de tiempo de consulta o secuencia de comandos es de 6 horas. Este límite no puede cambiarse. En algunos casos es posible reintentar las consultas. Cuando esto ocurre, la consulta en cuestión puede ejecutarse por seis horas más y puede volver a intentarse hasta tres veces.

Supervisa los trabajos de consulta

Supervisar los trabajos de BigQuery es fundamental para ejecutar aplicaciones confiables. La supervisión se puede realizar mediante gráficos de recursos del administrador de BigQuery, paneles de Cloud Monitoring o las vistas INFORMATION_SCHEMA.JOBS*.
Los gráficos de recursos del administrador de BigQuery y los paneles de Cloud Monitoring permiten la supervisión nativa de los bytes consultados, la cantidad de consultas simultáneas ejecutadas, el consumo de ranuras, la latencia de las consultas, etc. Las tablas INFORMATION_SCHEMA proporcionan metadatos adicionales sobre tipos de trabajo, mensajes de error específicos, tasas de caché, complejidad de trabajos, etc. Si aprovechas las tablas de INFORMATION_SCHEMA, se proporcionan capas adicionales de personalización como en la siguiente consulta, que proporciona una lista de las consultas actuales pendientes o en ejecución ordenadas según hace cuánto se crearon:

SELECT
    creation_time,
    project_id,
    user_email,
    job_id,
    job_type,
    priority,
    state,
    TIMESTAMP_DIFF(CURRENT_TIMESTAMP(), start_time,second) as running_time_sec
 FROM
   region-us.INFORMATION_SCHEMA.JOBS_BY_PROJECT
 WHERE
    creation_time BETWEEN TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 1 DAY) AND CURRENT_TIMESTAMP()
    AND state != "DONE"
ORDER BY
    running_time_sec DESC

Casos de uso para consultar datos

Analítica en tiempo real

En este caso práctico, los datos de transmisión se usan para alimentar un panel de IE en tiempo real, que es usado por una gran cantidad de usuarios que ejecutan consultas interactivas.

En este caso práctico, debes mantener las consultas del panel de IE aisladas de otras consultas de uso general mediante proyectos o reservas independientes para evitar que el panel de IE se convierta en un “vecino ruidoso” y afecte el rendimiento de otros trabajos de consulta de uso general. Además, se deben supervisar las consultas en ejecución, las consultas costosas y las consultas de SQL que presentan antipatrones de BigQuery mediante la revisión de las tablas INFORMATION_SCHEMA, y se deben corregir para evitar gastos innecesarios y una mayor latencia de las consultas.

Considera aprovechar BI Engine si se envían una gran cantidad de trabajos de consultas simultáneas al panel de IE o si la latencia de una consulta es una preocupación.

Considera crear límites personalizados de control de costos para limitar la cantidad de datos que se pueden procesar por día, por usuario o por tabla.

Procesamiento de datos por lotes

En este caso de uso, los trabajos por lotes nocturnos complejos se procesan para realizar un análisis detallado de los datos de todo el día y se unen con otras fuentes de datos para enriquecer los datos.

Al igual que con la orientación para casos prácticos en tiempo real, se recomienda mantener estas consultas complejas por lotes aisladas de otras consultas de uso general mediante proyectos o reservas independientes a fin de evitar problemas con estos trabajos o convertirse en un “vecino ruidoso” y afectar el rendimiento de otros trabajos de consulta. Además, las consultas largas en ejecución, las consultas costosas y las consultas de SQL que presentan antipatrones de BigQuery deben supervisarse con tablas INFORMATION_SCHEMA y corregirse para evitar gastos innecesarios y una mayor latencia de consulta.

Considera crear alertas en Cloud Monitoring a fin de alertar sobre factores como la disponibilidad baja de ranuras, los tiempos de consulta altos y el análisis de grandes cantidades de bytes para alertar sobre trabajos con bajo rendimiento.