Comprende la confiabilidad

En este documento, se proporciona información sobre las características de confiabilidad de BigQuery, como la disponibilidad, la durabilidad, la coherencia de los datos y del rendimiento, la recuperación de datos y una revisión de las consideraciones de manejo de errores.

Esta introducción te ayuda a abordar tres consideraciones principales:

• Determina si BigQuery es la herramienta adecuada para tu trabajo.
• Comprende las dimensiones de confiabilidad de BigQuery
• Identifica requisitos de confiabilidad específicos para casos de uso específicos.

Selecciona BigQuery

BigQuery es un almacén de datos empresarial completamente administrado, diseñado para almacenar y analizar conjuntos de datos de gran tamaño. Proporciona una forma de transferir, almacenar, leer y consultar de megabytes a petabytes de datos con un rendimiento coherente sin tener que administrar ninguna infraestructura subyacente. Debido a su potencia y rendimiento, BigQuery es ideal para usarse en una variedad de soluciones. Algunos de ellos se documentan en detalle como patrones de referencia.

En general, BigQuery es muy adecuado para cargas de trabajo en las que se transfieren y analizan grandes cantidades de datos. En particular, se puede implementar de manera eficaz para casos prácticos como análisis de datos predictivos y en tiempo real (con transferencia de transmisión y BigQuery ML), detección de anomalías y otros casos prácticos en los que es clave analizar grandes volúmenes de datos con un rendimiento predecible. Sin embargo, si buscas una base de datos que admita aplicaciones de estilo de procesamiento de transacciones en línea (OLTP), debes considerar otros servicios de Google Cloud, como Spanner, Cloud SQL o Cloud Bigtable, que pueden ser más adecuados para estos casos prácticos.

Dimensiones de confiabilidad en BigQuery

Disponibilidad

La disponibilidad define la capacidad del usuario de leer datos de BigQuery o escribir datos en él. BigQuery está diseñado para que ambas tengan alta disponibilidad con un ANS del 99.99%. Hay dos componentes involucrados en ambas operaciones:

• El servicio de BigQuery
• Los recursos de procesamiento necesarios para ejecutar la consulta específica

La confiabilidad del servicio es una función de la API de BigQuery específica que se usa para recuperar los datos. La disponibilidad de los recursos de procesamiento depende de la capacidad disponible para el usuario en el momento en que se ejecuta la consulta. Consulta Comprende las ranuras a fin de obtener más información sobre la unidad fundamental de procesamiento para BigQuery y la económica de recursos de ranuras resultante.

Durabilidad

La durabilidad se analiza en el capítulo sobre la implementación de SLO del cuaderno de ejercicios de SRE y se describe como la “proporción de datos que se puede leer correctamente”.

Coherencia de los datos

La coherencia define las expectativas que tienen los usuarios sobre cómo se pueden consultar los datos una vez que se escriben o modifican. Un aspecto de la coherencia de los datos es garantizar una semántica de “exactamente una vez” para la transferencia de datos. Para obtener más información, consulta Reintenta las inserciones de trabajos fallidas.

Coherencia del rendimiento

En general, el rendimiento se puede expresar en dos dimensiones. La latencia es una medida del tiempo de ejecución de las operaciones de recuperación de datos largas, como las consultas. La capacidad de procesamiento es una medida de la cantidad de datos que BigQuery puede procesar durante un período específico. Debido al diseño multiusuario con escalamiento horizontal de BigQuery, su capacidad de procesamiento se puede escalar verticalmente a tamaños de datos arbitrarios. La importancia relativa de la latencia y la capacidad de procesamiento se determina según el caso de uso específico.

Recuperación de datos

Hay dos formas de medir la capacidad de recuperar datos después de una interrupción:

• Objetivo de tiempo de recuperación (RTO). La cantidad de tiempo que los datos pueden no estar disponibles después de un incidente.
• Objetivo de punto de recuperación (RPO). La cantidad de datos recopilados antes del incidente que se puede perder de manera aceptable.

Estas consideraciones son específicamente relevantes para el caso improbable de que una zona o región experimente una interrupción destructiva o de varios días.

Planificación ante desastres

Si bien el término “desastre” puede evocar imágenes de desastres naturales, el alcance de esta sección aborda fallas específicas desde la pérdida de una máquina individual hasta la pérdida catastrófica de una región. Las primeras corresponden a casos cotidianos que BigQuery maneja de forma automática. mientras que lo segundo podría exigir que los clientes diseñen su arquitectura para solucionarlo si es necesario. Comprender en qué medida la planificación de desastres involucra la responsabilidad del cliente es importante.

BigQuery ofrece un ANS de tiempo de actividad del 99.99% líder en el sector. Esto es posible gracias a la arquitectura regional de BigQuery que escribe datos en dos zonas diferentes y aprovisiona una capacidad de procesamiento redundante. Es importante tener en cuenta que el ANS de BigQuery es el mismo en las regiones, por ejemplo, us-central1, y en las multirregiones, por ejemplo, US.

Manejo automático de situaciones

Debido a que BigQuery es un servicio regional, es responsabilidad de BigQuery manejar de forma automática la pérdida de una máquina o incluso una zona completa. El hecho de que BigQuery se compila sobre las zonas se abstrae de los usuarios.

Pérdida de una máquina

Las fallas de las máquinas son casos comunes en la escala a la que opera Google. BigQuery está diseñado para manejar las fallas de máquinas de forma automática sin afectar la zona que las contiene.
De forma interna, la ejecución de una consulta se divide en tareas pequeñas que se pueden enviar en paralelo a muchas máquinas. La pérdida repentina o degradación del rendimiento de una máquina se controla automáticamente mediante el reenvío de trabajo a una máquina diferente. Este enfoque es fundamental para reducir la latencia final.

BigQuery usa la codificación Reed–Solomon para almacenar de manera eficiente y duradera una copia zonal de tus datos. En el caso muy poco probable de que varias fallas de máquina causen la pérdida de una copia zonal, los datos también se almacenan de la misma manera en al menos una zona diferente. En ese caso, BigQuery detectará el problema y hará una nueva copia zonal de los datos para restablecer la redundancia.

Pérdida de una zona

La disponibilidad subyacente de los recursos de procesamiento en una zona determinada no es suficiente para cumplir con el ANS de tiempo de actividad del 99.99% de BigQuery. Por lo tanto, BigQuery proporciona redundancia zonal automática para datos y ranuras de procesamiento. Si bien las interrupciones zonales de corta duración no son comunes, ocurren. Sin embargo, la automatización de BigQuery realizará una conmutación por error de las consultas a otra zona en un minuto o dos desde que ocurra cualquier interrupción grave. Es posible que las consultas ya en tránsito no se recuperen de inmediato, pero sí las consultas nuevas. Esto se manifiesta en que las consultas en tránsito tardan mucho tiempo en completarse mientras las consultas recién enviadas se completan con rapidez.

Incluso si una zona no estuviera disponible durante un período más largo, no se perderán datos debido a que BigQuery escribe los datos en dos zonas de forma síncrona. Por lo tanto, incluso ante una pérdida zonal, los clientes no experimentarán una interrupción del servicio.

Tipos de fallas

Existen dos tipos de fallas: leves y graves.

Una falla leve es una deficiencia operativa en la que el hardware no se destruye. Algunos ejemplos incluyen fallas de alimentación, particiones de red o fallas en las máquinas. En general, BigQuery no pierde datos en caso de una falla leve.

Una falla grave es una deficiencia operativa en la que el hardware se destruye. Las fallas graves son más severas que las fallas leves. Algunos ejemplos de fallas graves incluyen daños por inundación, ataques terroristas, terremotos y huracanes.

Disponibilidad y durabilidad

Cuando creas un conjunto de datos de BigQuery, debes seleccionar una ubicación en la que puedas almacenar tus datos. Esta ubicación es una de las siguientes:

• Una región: una ubicación geográfica específica, como Iowa (us-central1) o Montreal (northamerica-northeast1).
• Una multirregión: un área geográfica grande que contiene dos o más lugares geográficos, como los Estados Unidos (US) o Europa (EU).

En cualquier caso, BigQuery almacena de forma automática las copias de tus datos en dos zonas diferentes de Google Cloud dentro de una sola región en la ubicación seleccionada.

Además de la redundancia de almacenamiento, BigQuery también mantiene una capacidad de procesamiento redundante en varias zonas. BigQuery combina el almacenamiento y el procesamiento redundantes en varias zonas de disponibilidad para proporcionar alta disponibilidad y durabilidad.

Nota: Seleccionar una ubicación multirregional no proporciona replicación entre regiones ni redundancia regional. Los datos se almacenarán en una sola región dentro de la ubicación geográfica.

En el caso de una falla a nivel de máquina, BigQuery continúa ejecutándose con apenas unos milisegundos de retraso. Todas las consultas actualmente en ejecución continúan procesándose. En el caso de una falla zonal leve o grave, no se espera una pérdida de datos. Sin embargo, es posible que las consultas actualmente en ejecución fallen y deban volver a enviarse. Una falla zonal leve, como la que resulta de un corte de energía, la destrucción de un transformador o una partición de red, es una ruta bien probada y se mitiga de forma automática en unos minutos.

Una falla regional leve, como una pérdida de conectividad de red en toda la región, provoca una pérdida de disponibilidad hasta que la región vuelva a estar en línea, pero no genera una pérdida de datos. Una falla regional grave, por ejemplo, si un desastre destruye la región completa, podría provocar la pérdida de datos almacenados en esa región. BigQuery no proporciona de forma automática una copia de seguridad o una réplica de los datos en otra región geográfica. Puedes crear copias de conjuntos de datos entre regiones para mejorar tu estrategia de recuperación ante desastres.

Para obtener más información sobre las ubicaciones de los conjuntos de datos de BigQuery, consulta Consideraciones de ubicaciones.

Situación: Pérdida de región

BigQuery no ofrece durabilidad ni disponibilidad en el caso excepcionalmente improbable y sin precedentes de pérdida de una región física. Esto se aplica a las configuraciones de “regiones y multirregiones”. Por lo tanto, mantener la durabilidad y la disponibilidad en este caso requiere una planificación por parte del cliente. En el caso de una pérdida temporal, como una interrupción de la red, se debe considerar la disponibilidad redundante si el ANS del 99.99% de BigQuery no se considera suficiente.

Para evitar la pérdida de datos ante una pérdida regional destructiva, debes crear una copia de seguridad de los datos en otra ubicación geográfica. Por ejemplo, podrías exportar de forma periódica una instantánea de los datos a Google Cloud Storage en otra región distinta a nivel geográfico. Esto se puede hacer como se describe en el caso de uso del procesamiento de datos por lotes.
En el caso de las multirregiones de BigQuery, debes evitar crear copias de seguridad en regiones que se encuentran dentro del alcance de la multirregión. Por ejemplo, no crees una copia de seguridad de tus datos en US en la región us-central1. La región y la multirregión pueden compartir dominios con fallas y tener el mismo destino en caso de desastre. En su lugar, crea una copia de seguridad de los datos en una región que no pertenezca a EE.UU., como northamerica-northeast1. Si los requisitos de residencia de los datos requieren que las copias de seguridad se almacenen en la región US, es mejor sincronizar dos regiones como us-central1 y us-east1.

Para evitar una falta de disponibilidad extendida, debes tener los datos replicados y las ranuras aprovisionadas en dos ubicaciones de BigQuery separadas a nivel geográfico. De manera similar a lo que se mencionó antes, evita mezclar regiones y multirregiones, ya que pueden tener el mismo destino en caso de un desastre.

La arquitectura más confiable para una configuración regional redundante es ejecutar “hot-hot”, también conocido como activo-activo. Esto significa que la carga de trabajo se ejecuta en paralelo en la región principal y la secundaria. Si bien es más costoso, esto garantiza que la región secundaria obtenga una verificación continua y funcionará si necesitas realizar una conmutación por error a ella. Si la disponibilidad durante una interrupción regional no es un problema, crear una copia de seguridad de los datos en otra región garantiza la durabilidad.

Situación: Eliminación accidental o corrupción de datos

En virtud de la arquitectura de control de simultaneidad de varias versiones de BigQuery, BigQuery es compatible con el viaje en el tiempo. Con esta función, puedes consultar datos de cualquier momento de los últimos siete días. Esto permite el restablecimiento automático de todos los datos que se hayan borrado, modificado o por error dentro de un período de 7 días. El viaje en el tiempo incluso funciona con tablas que se borraron.

BigQuery también admite la función de tablas de instantáneas. Con esta función, puedes crear copias de seguridad de los datos de forma explícita en la misma región, con una duración superior a los 7 días del viaje en el tiempo. Una instantánea solo es una operación de metadatos y no genera bytes de almacenamiento adicionales. Si bien esto puede agregar protección contra la eliminación accidental, no aumenta la durabilidad de los datos.

Caso de uso: Analítica en tiempo real

En este caso práctico, los datos de transmisión se transfieren desde los registros de extremos a BigQuery de forma continua. La protección contra la falta de disponibilidad extendida de BigQuery para toda la región requiere la replicación continua de los datos y el aprovisionamiento de ranuras en una región diferente. Debido a que la arquitectura es resistente a la falta de disponibilidad de BigQuery gracias al uso de Pub/Sub y Dataflow en la ruta de transferencia, es probable que este alto nivel de redundancia no valga la pena.

Supongamos que el usuario configuró datos de BigQuery en us-east4 para que se exporten cada noche mediante trabajos de exportación a Cloud Storage bajo la clase Archive Storage en us-central1. Esto proporciona una copia de seguridad duradera en caso de pérdida catastrófica de datos en us-east4. En este caso, el objetivo de punto de recuperación (RPO) es de 24 horas, ya que la última copia de seguridad exportada puede tener hasta 24 horas de antigüedad en el peor de los casos. El objetivo de tiempo de recuperación (RTO) puede ser de días, ya que los datos deben restablecerse de la copia de seguridad de Cloud Storage a BigQuery en us-central1. Si BigQuery debe aprovisionarse en una región diferente de donde se ubican las copias de seguridad, los datos primero deben transferirse a esta región. Además, ten en cuenta que, a menos que hayas comprado ranuras redundantes en la región de recuperación por adelantado, puede haber un retraso adicional en el aprovisionamiento de la capacidad requerida de BigQuery, dependiendo de la cantidad solicitada.

Caso de uso: Procesamiento de datos por lotes

Para este caso de uso, es fundamental para la empresa que se complete un informe diario en un plazo fijo a fin de enviarlo a un regulador. Es probable que valga la pena implementar la redundancia mediante la ejecución de dos instancias distintas de toda la canalización de procesamiento. El uso de dos regiones separadas, p. ej., us-west1 y us-east4, proporciona separación geográfica y dos dominios con fallas independientes en caso de una falta de disponibilidad extendida de una región o incluso en el caso improbable de una pérdida permanente de la región.

Si suponemos que necesitamos que el informe se entregue exactamente una vez, debemos conciliar el caso esperado de que ambas canalizaciones finalicen de forma correcta. Una estrategia razonable es simplemente seleccionar el resultado de la canalización que finaliza primero, p. ej., mediante la notificación a un tema de Pub/Sub cuando se completa de forma correcta. También puedes reemplazar el resultado y volver a crear la versión del objeto de Cloud Storage. Si la canalización que termina después escribe datos dañados, puedes recuperarte si restableces la versión que escribió la canalización que finalizó primero desde Cloud Storage.

Manejo de errores

Las siguientes son prácticas recomendadas para abordar los errores que afectan la confiabilidad.

Reintenta las solicitudes a la API fallidas

Los clientes de BigQuery, incluidas las bibliotecas cliente y las herramientas de socios, deben usar la retirada exponencial truncada cuando emiten solicitudes a la API. Esto significa que, si un cliente recibe un error del sistema o un error de cuota, debe reintentar la solicitud hasta una cierta cantidad de veces, pero con un intervalo de retirada aleatorio y creciente.

El uso de este método de reintentos hace que tu aplicación sea mucho más sólida ante errores. Incluso en condiciones operativas normales, puedes esperar que alrededor de una en diez mil solicitudes falle, como se describe en el ANS de disponibilidad del 99.99% de BigQuery. En condiciones anormales, esta tasa de error puede aumentar, pero si los errores se distribuyen de forma aleatoria, la estrategia de retirada exponencial puede mitigar todos los casos, excepto los más graves.

Si encuentras una situación en la que una solicitud falla de forma persistente con un error 5XX, debes derivarla a la asistencia de Google Cloud. Asegúrate de comunicar con claridad el impacto que la falla tiene en tu negocio para que el problema se pueda clasificar de forma correcta. Por otro lado, si una solicitud falla de forma persistente con un error 4XX, el problema debería poder abordarse mediante cambios en la aplicación. Lee el mensaje de error para obtener más información.

Ejemplo de lógica de retirada exponencial

La lógica de retirada exponencial vuelve a intentar una consulta o solicitud mediante el aumento del tiempo de espera entre los reintentos hasta un tiempo de retirada máximo. Por ejemplo:

1. Haz una solicitud a BigQuery.

2. Si la solicitud falla, espera 1 + random_number_milliseconds segundos y vuelve a intentar la solicitud.

3. Si la solicitud falla, espera 2 + random_number_milliseconds segundos y vuelve a intentar la solicitud.

4. Si la solicitud falla, espera 4 + random_number_milliseconds segundos y vuelve a intentar la solicitud.

5. Y así sucesivamente, hasta un tiempo de (maximum_backoff).

6. Continúa con la espera y vuelve a intentar hasta una cantidad máxima de reintentos, pero no aumentes el período de espera entre los reintentos.

Ten en cuenta lo siguiente:

• El tiempo de espera es min(((2^n)+random_number_milliseconds), maximum_backoff), n se incrementa en 1 para cada iteración (solicitud).

• random_number_milliseconds es un número al azar de milisegundos menor o igual que 1,000. Esta aleatorización ayuda a evitar situaciones en las que muchos clientes se sincronizan y todos vuelven a intentarlo en simultáneamente, lo que envía solicitudes en oleadas sincronizadas. El valor de random_number_milliseconds se vuelve a calcular después de cada reintento de solicitud.

• El intervalo de retirada máximo (maximum_backoff) suele ser de 32 o 64 segundos. El valor apropiado de maximum_backoff depende del caso de uso.

El cliente puede seguir reintentando después de que alcanza el tiempo de retirada máximo. Después de este punto, los reintentos no necesitan continuar con el aumento del tiempo de retirada. Por ejemplo, si el cliente usa un tiempo de retirada máximo de 64 segundos, después de alcanzar este valor, el cliente puede volver a intentarlo cada 64 segundos. En algún momento, se debe evitar que los clientes vuelvan a intentarlo de forma ilimitada.

El tiempo de espera entre los reintentos y la cantidad de reintentos depende del caso práctico y las condiciones de la red.

Reintenta las inserciones de trabajos fallidas

Si la semántica de inserción del tipo “exactamente una vez” es importante para tu aplicación, hay consideraciones adicionales cuando se trata de insertar trabajos. La forma de lograr las semánticas de "como máximo una vez" depende de la WriteDisposition que especifiques. La disposición de escritura le indica a BigQuery qué debe hacer cuando se encuentra con datos existentes en una tabla: falla, reemplaza o agrega.

Con una disposición WRITE_EMPTY o WRITE_TRUNCATE, esto se logra fácilmente si solo reintentas cualquier inserción o ejecución de trabajo fallida. Esto se debe a que todas las filas transferidas por un trabajo se escriben de forma atómica en la tabla.

Con una disposición WRITE_APPEND, el cliente debe especificar el ID de trabajo para proteger contra un reintento que agregue los mismos datos por segunda vez. Esto funciona porque BigQuery rechaza las solicitudes de creación de trabajos que intentan usar el ID de un trabajo anterior. Esto logra una semántica de "como máximo una vez" para cualquier ID de trabajo determinado. Luego, puedes lograr "exactamente una vez" si vuelves a intentar con un nuevo ID de trabajo predecible una vez que confirmes con BigQuery que fallaron todos los intentos anteriores.

En algunos casos, el cliente de la API o el cliente HTTP pueden no recibir la confirmación de que el trabajo se inserta debido a problemas transitorios o interrupciones de la red. Cuando se vuelva a intentar la inserción, esa solicitud fallará con status=ALREADY_EXISTS (code=409 y reason="duplicate"). El estado del trabajo existente se puede recuperar con una llamada a jobs.get. Cuando el estado del trabajo existente es retrieved, el emisor puede determinar si se debe crear un trabajo nuevo con un ID de trabajo nuevo.

Casos de uso y requisitos de confiabilidad

BigQuery puede ser un componente fundamental de una variedad de arquitecturas. Según el caso de uso y la arquitectura implementada, es posible que se deba cumplir con una variedad de requisitos de disponibilidad, rendimiento u otros relacionados con la confiabilidad. Para los fines de esta guía, seleccionemos dos casos de uso y arquitecturas principales para analizarlos en detalle.

Analítica en tiempo real

El primer ejemplo es una canalización de procesamiento de datos de eventos. En este ejemplo, los eventos de registro de los extremos se transfieren mediante Pub/Sub. Desde allí, una canalización de transmisión de Dataflow realiza algunas operaciones en los datos antes de escribirlos en BigQuery mediante la API de Storage Write. Luego, los datos se usan para las consultas ad hoc a fin de, por ejemplo, volver a crear secuencias de eventos que podrían haber generado resultados de extremos específicos y para proporcionar paneles casi en tiempo real con el objetivo de permitir la detección de tendencias y patrones en los datos a través de la visualización.

En este ejemplo, se requiere que consideremos varios aspectos de la confiabilidad. Debido a que los requisitos de actualidad de datos de extremo a extremo son bastante altos, la latencia del proceso de transferencia es fundamental. Una vez que los datos se escriben en BigQuery, la confiabilidad se percibe como la capacidad de los usuarios para emitir consultas ad hoc con una latencia coherente y predecible, y garantizar que los paneles que usan los datos reflejen la información más reciente disponible.

Procesamiento de datos por lotes

El segundo ejemplo es una arquitectura de procesamiento por lotes basada en el cumplimiento normativo en la industria de servicios financieros. Un requisito clave es entregar informes diarios a los reguladores antes de un plazo fijo todas las noches. Siempre que el proceso por lotes de cada noche que genera los informes se complete antes de este plazo, se considera que es lo suficientemente rápido.

Los datos deben estar disponibles en BigQuery y unirse a otras fuentes de datos para su uso en paneles, en análisis y, por último, en la generación de un informe en PDF. Enviar estos informes a tiempo y sin errores es un requisito empresarial fundamental. Por lo tanto, es fundamental garantizar la confiabilidad de la transferencia de datos y la generación del informe correctamente y en un período coherente para cumplir con los plazos requeridos.