Comprende la confiabilidad

BigQuery te permite ejecutar cargas de trabajo de análisis con una interrupción mínima, ya que controla automáticamente las fallas de máquinas y zonas dentro de una región. Para obtener una mayor resiliencia, puedes configurar la recuperación ante desastres entre regiones, restablecer los datos borrados o dañados, y, además, implementar reintentos de errores del cliente para cumplir con tus requisitos de confiabilidad.

Estas funciones admiten cargas de trabajo que transfieren y analizan grandes volúmenes de datos con un rendimiento constante, incluida la detección de anomalías, el análisis en tiempo real con transferencia de transmisión y el análisis predictivo con BigQuery ML. Para ver ejemplos detallados de estas soluciones, consulta Patrones de referencia de BigQuery.

Dimensiones de confiabilidad en BigQuery

Para determinar si BigQuery cumple con los requisitos de tu carga de trabajo, puedes evaluar su confiabilidad en cinco dimensiones clave: disponibilidad, durabilidad, coherencia de los datos, coherencia del rendimiento y recuperación de datos.

Disponibilidad

La disponibilidad define tu capacidad de leer datos de BigQuery o escribir datos en él. BigQuery está diseñado para que las operaciones de lectura y escritura tengan alta disponibilidad con un ANS de tiempo de actividad 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 usas para recuperar los datos. La disponibilidad de los recursos de procesamiento depende de la capacidad disponible para ti cuando ejecutas la consulta. Para obtener más información sobre la unidad fundamental de procesamiento para BigQuery y la economía de recursos de ranuras, consulta Información sobre las ranuras.

Durabilidad

La durabilidad mide la proporción de datos que puedes leer correctamente, como se define en el capítulo Implementa SLO del Cuaderno de ejercicios de confiabilidad de sitios. Para proporcionar una alta durabilidad, BigQuery almacena automáticamente copias redundantes de tus datos en dos zonas dentro de la ubicación seleccionada.

Coherencia de los datos

La coherencia de los datos define cómo y cuándo puedes consultar los datos después de 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. Tu caso de uso específico determina la importancia relativa de la latencia y la capacidad de procesamiento.

Recuperación de datos

Puedes medir la capacidad de recuperar datos después de una interrupción con las siguientes métricas:

• Objetivo de tiempo de recuperación (RTO): Es el período máximo durante el cual los datos pueden no estar disponibles después de un incidente.
• Objetivo de punto de recuperación (RPO): Es la cantidad máxima de datos recopilados antes del incidente que tu organización puede tolerar perder.

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

En esta sección, la planificación ante desastres abarca fallas que van desde la pérdida de una sola máquina hasta la pérdida catastrófica de una región completa. BigQuery controla las fallas de una sola máquina y de zona de forma automática, mientras que las fallas regionales requieren que diseñes tu arquitectura para la recuperación si tu carga de trabajo lo requiere. Comprender dónde termina la recuperación automática y comienza tu responsabilidad es esencial para la planificación ante desastres.

BigQuery ofrece un ANS de tiempo de actividad del 99.99%. Esta disponibilidad se respalda en la arquitectura regional de BigQuery, que escribe datos en dos zonas diferentes y aprovisiona una capacidad de procesamiento redundante. El ANS de BigQuery es el mismo para las regiones (como us-central1) y las multirregiones (como US).

Manejo automático de fallas

Debido a que BigQuery es un servicio regional, controla de forma automática la pérdida de una máquina individual o de una zona completa. BigQuery abstrae la infraestructura zonal subyacente.

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.

BigQuery divide cada consulta en tareas pequeñas y las envía en paralelo a muchas máquinas. Si una máquina falla o se degrada, BigQuery reenvía automáticamente las tareas afectadas a otra máquina. Este enfoque es fundamental para reducir la latencia final.

BigQuery usa la codificación Reed-Solomon para almacenar de forma duradera una copia zonal de tus datos y almacena al menos una copia zonal adicional en otra zona. Si varias fallas de máquinas causan la pérdida de una copia zonal, BigQuery detecta la pérdida y crea una nueva copia zonal para restablecer la redundancia.

Pérdida de una zona

Para cumplir con su ANS de tiempo de actividad del 99.99%, BigQuery proporciona redundancia zonal automática para datos y ranuras de procesamiento. Debido a que la disponibilidad de procesamiento en una sola zona no puede cumplir con este ANS por sí sola, BigQuery enruta automáticamente las consultas nuevas a otra zona en un minuto desde que ocurre una interrupción zonal grave. Las consultas en tránsito pueden tardar más en finalizar, mientras que las consultas recién emitidas se completan con normalidad en otra zona.

Incluso si una zona no está disponible durante un período prolongado, no se pierden datos, ya que BigQuery escribe datos en dos zonas de forma síncrona. Como resultado, una interrupción zonal no interrumpe tu 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. BigQuery está diseñado para evitar la pérdida de datos durante una falla leve.

Una falla grave es una falla operativa en la que el hardware se destruye, como daños por inundaciones, terremotos o huracanes. Si BigQuery puede evitar la pérdida de datos durante una falla grave, depende de si la falla afecta a una sola zona o a una región completa.

Redundancia de ubicación y comportamiento ante fallas

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 Google Cloud 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. BigQuery almacena tus datos en una sola región dentro de la ubicación multirregional.

En el caso de una falla a nivel de máquina, BigQuery continúa ejecutándose con apenas unos milisegundos de retraso, y todas las consultas actualmente en ejecución continúan procesándose. Durante una falla zonal leve o grave, no se produce una pérdida de datos, aunque es posible que debas volver a enviar las consultas que se están ejecutando. BigQuery mitiga automáticamente las fallas zonales leves, como cortes de energía, fallas de transformadores o particiones de red, 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, como un desastre que destruye una región completa, puede 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 usar la replicación de conjuntos de datos entre regiones o la recuperación ante desastres administrada para mejorar tu resiliencia ante fallas regionales graves.

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 si se destruye una región física. Esta limitación se aplica tanto a las regiones como a las multirregiones, por lo que mantener la durabilidad y la disponibilidad durante una interrupción regional requiere que planifiques con anticipación. Si el ANS del 99.99% de BigQuery no cumple con tus requisitos de disponibilidad durante una interrupción regional temporal, considera configurar la disponibilidad redundante en todas las regiones.

Para evitar la pérdida de datos si se destruye una región, crea una copia de seguridad de tus datos en otra ubicación geográfica. Por ejemplo, puedes usar la replicación de conjuntos de datos entre regiones para replicar tus datos de forma continua en una región geográficamente distinta.

Si usas una multirregión de BigQuery, no crees copias de seguridad de los datos en una sola región dentro del alcance geográfico de esa multirregión. Por ejemplo, si creas una copia de seguridad de los datos de la multirregión US, evita elegir una región superpuesta, como us-central1, debido al riesgo de falla correlacionada durante un desastre. Para obtener más información sobre el alcance geográfico de las multirregiones, consulta Multirregiones.

Para evitar una falta de disponibilidad extendida, replica tus datos y aprovisiona ranuras en dos ubicaciones de BigQuery separadas a nivel geográfico. Puedes usar la recuperación ante desastres administrada para aprovisionar ranuras automáticamente en una región secundaria y controlar la conmutación por error de tus cargas de trabajo de una región a otra.

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 el viaje en el tiempo, puedes consultar datos de cualquier momento de los últimos 7 días. Esta función te permite restablecer los datos que se borraron, modificaron o dañaron por error dentro del período de 7 días. El viaje en el tiempo también funciona con tablas que se borraron.

BigQuery también te permite crear instantáneas de tablas para crear copias de seguridad de los datos en la misma región durante más de los 7 días del período de viaje en el tiempo. Crear una instantánea es una operación de solo metadatos que no genera cargos de almacenamiento adicionales. Aunque las instantáneas de tablas ayudan a proteger contra la eliminación accidental, no aumentan la durabilidad de los datos.

Recuperación ante desastres para estadísticas en tiempo real

Para una canalización de estadísticas en tiempo real que transfiere de forma continua los registros de extremos de transmisión a BigQuery, la protección contra la falta de disponibilidad regional extendida requiere la replicación continua de los datos y el aprovisionamiento de ranuras en una región secundaria. Sin embargo, debido a que la arquitectura de transferencia ya es resistente a la falta de disponibilidad temporal de BigQuery cuando usa Pub/Sub y Dataflow como uno de sus métodos de carga de datos, es posible que este alto nivel de redundancia no valga la pena.

Por ejemplo, supongamos que configuras trabajos de extracción nocturnos para exportar datos de BigQuery de us-east4 a Archive Storage de Cloud Storage en us-central1. Esta exportación proporciona una copia de seguridad duradera en caso de que se produzca una pérdida catastrófica de datos en us-east4. En esta configuración, el objetivo de punto de recuperación (RPO) es de 24 horas, ya que la copia de seguridad más reciente puede tener hasta 24 horas de antigüedad. El objetivo de tiempo de recuperación (RTO) puede ser de varios días, ya que debes restablecer los datos de la copia de seguridad de Cloud Storage a BigQuery en us-central1. Si aprovisionas BigQuery en una región diferente de la de tus copias de seguridad, primero debes transferir los datos a esa región. A menos que compres ranuras redundantes en la región de recuperación por adelantado, el aprovisionamiento de la capacidad requerida de BigQuery puede tardar más tiempo, según la cantidad que solicites.

Recuperación ante desastres para el procesamiento de datos por lotes

Para una carga de trabajo de procesamiento de datos por lotes en la que debes entregar un informe diario fundamental para la empresa a un regulador en un plazo fijo, implementar la redundancia ejecutando dos instancias independientes de toda la canalización de procesamiento suele valer la pena. El uso de dos regiones separadas, como us-west1 y us-east4, proporciona separación geográfica y dos dominios con fallas independientes en caso de una falta de disponibilidad regional extendida o una pérdida permanente de la región.

Si debes entregar el informe exactamente una vez, debes conciliar el resultado cuando ambas canalizaciones finalicen de forma correcta. Un enfoque consiste en seleccionar el resultado de la canalización que finaliza primero, por ejemplo, publicando una notificación en un tema de Pub/Sub cuando se completa. Como alternativa, puedes permitir que la segunda canalización reemplace el resultado y use el control de versiones de objetos en Cloud Storage. Si la canalización que termina después escribe datos dañados, puedes restablecer la versión que escribió la primera canalización desde Cloud Storage.

Manejo de errores

En las siguientes secciones, se describen las prácticas recomendadas para controlar los errores que afectan la confiabilidad.

Reintenta las solicitudes a la API fallidas

Cuando tus aplicaciones cliente, bibliotecas cliente o herramientas de socios emitan solicitudes a la API de BigQuery, usa la retirada exponencial truncada. Con esta estrategia de reintento, si un cliente recibe un error del sistema o un error de cuota, reintenta la solicitud hasta una cantidad máxima de veces con un intervalo de espera aleatorio y creciente.

El uso de la retirada exponencial truncada hace que tu aplicación sea más resiliente a los errores transitorios. Incluso en condiciones operativas normales, puedes esperar que alrededor de una en 10,000 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 retirada exponencial puede mitigar la mayoría de las fallas.

Si una solicitud falla de forma persistente con un error 5xx, comunícate con Atención al cliente de Cloud y comunica con claridad el impacto en el negocio cuando establezcas la prioridad del caso de asistencia para que el equipo de asistencia pueda clasificar el problema con precisión. Por el contrario, si una solicitud falla de forma persistente con un error 4xx, puedes resolver el problema modificando tu aplicación. Consulta el mensaje de error para obtener detalles.

Ejemplo de lógica de retirada exponencial

La lógica de retirada exponencial vuelve a intentar una consulta o solicitud aumentando el tiempo de espera entre los reintentos hasta un tiempo de retirada máximo. En los siguientes pasos, se ilustra cómo un cliente implementa la retirada exponencial truncada:

1. Haz una solicitud a BigQuery.

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

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

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

5. Repite este patrón y duplica el tiempo de espera base en cada reintento hasta el tiempo maximum_backoff.

6. Continúa con la espera y vuelve a intentar una cantidad máxima de reintentos, sin aumentar el período de espera más allá de maximum_backoff.

Ten en cuenta los siguientes detalles para este cálculo de retirada:

• 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 por casualidad y vuelven a intentarlo de forma simultánea, lo que envía solicitudes en oleadas sincronizadas. Vuelve a calcular random_number_milliseconds 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 de tu 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 que el cliente alcance este valor, puede volver a intentarlo cada 64 segundos. Para evitar bucles de reintentos infinitos, configura una cantidad máxima de reintentos para que el cliente deje de reintentar después de un límite establecido.

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 tu aplicación requiere una semántica de inserción de tipo exactamente una vez, considera cómo el WriteDisposition de tu trabajo controla los datos existentes en una tabla (falla, reemplazo o adición).

Con una disposición WRITE_EMPTY o WRITE_TRUNCATE, puedes lograr la semántica de como máximo una vez reintentando cualquier inserción o ejecución de trabajo fallida, ya que BigQuery escribe de forma atómica todas las filas que un trabajo transfiere a la tabla.

Con una disposición WRITE_APPEND, especifica un ID de trabajo personalizado para que un reintento no agregue datos duplicados. Debido a que BigQuery rechaza cualquier solicitud de creación de trabajo que reutilice un ID de trabajo anterior, especificar un ID de trabajo proporciona una semántica de como máximo una vez para ese ID. Luego, puedes lograr la semántica de exactamente una vez confirmando que todos los intentos anteriores fallaron antes de volver a intentarlo con un nuevo ID de trabajo predecible.

Si un problema de red transitorio impide que tu cliente reciba la confirmación de una inserción de trabajo, un reintento con el mismo ID de trabajo fallará con status=ALREADY_EXISTS (code=409 y reason="duplicate"). Llama a jobs.get para recuperar el estado del trabajo existente y 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 que implementes, es posible que debas cumplir con diferentes requisitos de disponibilidad, rendimiento y confiabilidad. En las siguientes secciones, se examinan dos arquitecturas comunes y sus requisitos de confiabilidad.

Analítica en tiempo real

El primer ejemplo es una canalización de procesamiento de datos de eventos. En esta arquitectura, Pub/Sub transfiere eventos de registro desde los extremos, y una canalización de transmisión de Dataflow procesa y escribe los datos en BigQuery con la API de BigQuery Storage Write. Luego, los analistas ejecutan consultas ad hoc en los datos para recrear secuencias de eventos, y los paneles casi en tiempo real visualizan los datos para detectar tendencias y patrones.

Debido a que esta carga de trabajo requiere una alta actualidad de los datos de extremo a extremo, la latencia de transferencia baja es fundamental. Después de que los datos se escriben en BigQuery, la confiabilidad depende de dos factores: si los usuarios pueden ejecutar consultas ad hoc con una latencia coherente y predecible, y si los paneles que usan los datos reflejan la información más reciente.

Procesamiento de datos por lotes

El segundo ejemplo es una arquitectura de procesamiento por lotes para el cumplimiento de reglamentaciones en el sector 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 cumple con el requisito de rendimiento.

La canalización carga datos en BigQuery y los une a otras fuentes de datos para su uso en paneles, en análisis y en la generación de informes en PDF. Enviar estos informes a tiempo y sin errores es un requisito empresarial fundamental. Por lo tanto, debes garantizar la confiabilidad durante la transferencia de datos y generar informes precisos en un plazo coherente para cumplir con los plazos regulatorios.