Información sobre la fiabilidad

En este documento se describen las funciones de fiabilidad de BigQuery, como la disponibilidad, la durabilidad, la coherencia de los datos, la coherencia del rendimiento y la recuperación de datos, así como una revisión de las consideraciones sobre la gestión de errores.

Esta introducción te ayudará a abordar tres aspectos principales:

• Determina si BigQuery es la herramienta adecuada para tu trabajo.
• Conocer las dimensiones de la fiabilidad de BigQuery.
• Identifica requisitos de fiabilidad específicos para casos prácticos concretos.

Selecciona BigQuery.

BigQuery es un almacén de datos empresarial totalmente gestionado diseñado para almacenar y analizar conjuntos de datos masivos. Proporciona una forma de ingerir, almacenar, leer y consultar datos de megabytes a petabytes con un rendimiento constante sin tener que gestionar la infraestructura subyacente. Gracias a su potencia y rendimiento, BigQuery es una herramienta adecuada para usar en una amplia gama de soluciones. Algunos de ellos se documentan en detalle como patrones de referencia.

Por lo general, BigQuery es muy adecuado para cargas de trabajo en las que se ingieren y analizan grandes cantidades de datos. En concreto, se puede implementar de forma eficaz en casos prácticos como las analíticas de datos predictivas y en tiempo real (con ingestión de streaming y BigQuery ML), la detección de anomalías y otros casos prácticos en los que es fundamental analizar grandes volúmenes de datos con un rendimiento predecible. Sin embargo, si buscas una base de datos que admita aplicaciones de procesamiento de transacciones online (OLTP), deberías tener en cuenta otros servicios, como Spanner, Cloud SQL o Bigtable, que pueden ser más adecuados para estos casos prácticos. Google Cloud

Dimensiones de la fiabilidad en BigQuery

Disponibilidad

La disponibilidad define la capacidad del usuario para leer datos de BigQuery o escribir datos en él. BigQuery se ha diseñado para que ambos elementos tengan una alta disponibilidad con un acuerdo de nivel de servicio del 99,99 %. En ambas operaciones intervienen dos componentes:

• El servicio BigQuery
• Recursos de computación necesarios para ejecutar la consulta específica

La fiabilidad del servicio depende de la API de BigQuery específica que se utilice para recuperar los datos. La disponibilidad de los recursos de computación depende de la capacidad disponible para el usuario en el momento en que se ejecuta la consulta. Consulta el artículo Información sobre las ranuras para obtener más información sobre la unidad de computación fundamental de BigQuery y la economía de recursos de ranuras resultante.

Durabilidad

La durabilidad se trata en el capítulo sobre la implementación de los SLOs del SRE Workbook y se describe como la "proporción de datos que se pueden leer correctamente".

Coherencia de datos

La coherencia define las expectativas de los usuarios sobre cómo se pueden consultar los datos una vez que se han escrito o modificado. Un aspecto de la coherencia de los datos es asegurar la semántica "exactamente una vez" para la ingestión de datos. Para obtener más información, consulta Reintentar 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 prolongadas, como las consultas. El rendimiento es una medida de la cantidad de datos que BigQuery puede procesar durante un periodo específico. Gracias al diseño de BigQuery, que es multitenant y se puede escalar horizontalmente, su rendimiento puede aumentar hasta tamaños de datos arbitrarios. La importancia relativa de la latencia y el rendimiento se determina en función del caso práctico 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). Cuánto tiempo pueden dejar de estar disponibles los datos después de un incidente.
• Objetivo de punto de recuperación (RPO). Cuántos datos recogidos antes del incidente se pueden perder de forma aceptable.

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

Planificación ante desastres

Aunque el término "desastre" puede evocar imágenes de desastres naturales, el ámbito de esta sección abarca fallos específicos, desde la pérdida de una máquina hasta la pérdida catastrófica de una región. Los primeros son sucesos cotidianos que BigQuery gestiona automáticamente, mientras que los segundos son algo para lo que los clientes pueden tener que diseñar su arquitectura si es necesario. Es importante saber en qué medida la planificación ante desastres se solapa con la responsabilidad del cliente.

BigQuery ofrece un acuerdo de nivel de servicio con un tiempo de actividad del 99,99%, uno de los más altos del sector. Esto es posible gracias a la arquitectura regional de BigQuery, que escribe datos en dos zonas diferentes y proporciona capacidad de computación redundante. Es importante tener en cuenta que el SLA de BigQuery es el mismo para las regiones (por ejemplo, us-central1) y las multirregiones (por ejemplo, EE. UU.).

Gestión automática de situaciones

Como BigQuery es un servicio regional, es responsabilidad de BigQuery gestionar automáticamente la pérdida de una máquina o incluso de una zona completa. El hecho de que BigQuery se base en zonas se oculta a los usuarios.

Pérdida de una máquina

Los fallos de las máquinas son algo habitual a la escala en la que opera Google. BigQuery se ha diseñado para gestionar los fallos de las máquinas automáticamente sin que afecten a la zona que los contiene.
En segundo plano, la ejecución de una consulta se divide en pequeñas tareas que se pueden enviar en paralelo a muchas máquinas. La pérdida o degradación repentina del rendimiento de la máquina se gestiona automáticamente redirigiendo el trabajo a otra máquina. Este enfoque es fundamental para reducir la latencia final.

BigQuery utiliza la codificación Reed-Solomon para almacenar de forma eficiente y duradera una copia zonal de tus datos. En el caso muy improbable de que se produzcan varios fallos en las máquinas que provoquen la pérdida de una copia zonal, los datos también se almacenan de la misma forma en al menos otra zona. En ese caso, BigQuery detectará el problema y hará una nueva copia zonal de los datos para restaurar la redundancia.

Pérdida de una zona

La disponibilidad subyacente de los recursos de computación en una zona determinada no es suficiente para cumplir el acuerdo de nivel de servicio de BigQuery, que es del 99,99% del tiempo de actividad. Por lo tanto, BigQuery proporciona redundancia zonal automática tanto para los datos como para las ranuras de computación. Aunque las interrupciones zonales de corta duración no son habituales, sí se producen. Sin embargo, la automatización de BigQuery conmutará por error las consultas a otra zona en un plazo de uno o dos minutos tras cualquier interrupción grave. Es posible que las consultas que ya estén en curso no se recuperen inmediatamente, pero sí las que se emitan a partir de ese momento. Esto se manifestaría en consultas en curso que tardan mucho en completarse, mientras que las consultas recién emitidas se completan rápidamente.

Aunque una zona no esté disponible durante un periodo prolongado, no se perderán datos, ya que BigQuery escribe datos de forma síncrona en dos zonas. Por lo tanto, aunque se produzca una pérdida zonal, los clientes no experimentarán una interrupción del servicio.

Tipos de errores

Hay dos tipos de errores: errores leves y errores graves.

Un fallo leve es una deficiencia operativa en la que el hardware no se destruye. Por ejemplo, un fallo de alimentación, una partición de red o un fallo de la máquina. Por lo general, BigQuery nunca debería perder datos en caso de que se produzca un error leve.

Un fallo grave es una deficiencia operativa en la que se destruye el hardware. Los errores graves son más graves que los errores leves. Entre los ejemplos de fallos graves se incluyen los daños causados por inundaciones, ataques terroristas, terremotos y huracanes.

Disponibilidad y durabilidad

Cuando creas un conjunto de datos de BigQuery, seleccionas una ubicación en la que 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: una zona geográfica grande que contiene dos o más lugares geográficos, como Estados Unidos (US) o Europa (EU).

En ambos casos, BigQuery almacena automáticamente copias de tus datos en dos Google Cloud zonas diferentes de una misma región en la ubicación seleccionada.

Además de la redundancia del almacenamiento, BigQuery también mantiene una capacidad de computación redundante en varias zonas. Al combinar el almacenamiento y la computación redundantes en varias zonas de disponibilidad, BigQuery ofrece alta disponibilidad y durabilidad.

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

En caso de fallo a nivel de máquina, BigQuery sigue funcionando con un retraso de unos pocos milisegundos como máximo. Todas las consultas que se estén ejecutando en ese momento seguirán procesándose. En caso de que se produzca un error de zona, ya sea leve o grave, no se espera que se pierdan datos. Sin embargo, es posible que las consultas que se estén ejecutando fallen y deban volver a enviarse. Un fallo zonal leve, como el que se produce por un corte de luz, un transformador destruido o una partición de red, es una ruta bien probada y se mitiga automáticamente en unos minutos.

Si se produce un fallo regional leve, como la pérdida de conectividad de red en toda una región, se pierde la disponibilidad hasta que la región vuelve a estar online, pero no se pierden datos. Por ejemplo, si se produce un fallo grave en una región, como un desastre que destruya toda la región, se podrían perder los datos almacenados en ella. BigQuery no proporciona automáticamente una copia de seguridad ni una réplica de sus datos en otra región geográfica. Puede crear copias de conjuntos de datos entre regiones para mejorar su estrategia de recuperación ante desastres.

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

Situación: pérdida de una región

BigQuery no ofrece durabilidad ni disponibilidad en el caso extraordinariamente improbable y sin precedentes de que se pierda una región física. Esto se aplica tanto a las configuraciones de regiones como a las multirregionales. Por lo tanto, para mantener la durabilidad y la disponibilidad en este caso, el cliente debe planificarlo. En caso de pérdida temporal, como una interrupción de la red, se debe tener en cuenta la disponibilidad redundante si el acuerdo de nivel de servicio del 99,99% de BigQuery no se considera suficiente.

Para evitar que se pierdan datos en caso de que se produzca una pérdida regional destructiva, debes crear una copia de seguridad de los datos en otra ubicación geográfica. Por ejemplo, puedes exportar periódicamente una instantánea de tus datos a Google Cloud Storage en otra región geográficamente distinta. Para ello, siga las instrucciones que se indican en el caso práctico de procesamiento de datos por lotes.
En el caso de las multirregiones de BigQuery, debes evitar crear copias de seguridad en regiones que estén dentro del ámbito de la multirregión. Por ejemplo, no haga copias de seguridad de sus datos de EE. UU. en la región us-central1. La región y la multirregión pueden compartir dominios de errores y tener un destino común en caso de desastre. En su lugar, crea una copia de seguridad de tus datos en una región que no sea de EE. UU., como northamerica-northeast1. Si los requisitos de residencia de datos exigen que las copias de seguridad se almacenen en EE. UU., es mejor que emparejes dos regiones, como us-central1 y us-east1.

Para evitar que el servicio no esté disponible durante un periodo prolongado, debes replicar los datos y aprovisionar ranuras en dos ubicaciones de BigQuery geográficamente separadas. Al igual que en el caso anterior, no mezcles regiones y multirregiones, ya que pueden compartir el mismo destino en caso de desastre.

La arquitectura más fiable para una configuración con redundancia de región es la de tipo activo-activo. Esto significa que tu carga de trabajo se ejecuta en paralelo en tu región principal y en la secundaria. Aunque es más caro, esto asegura que la región secundaria se verifique continuamente y funcione si necesitas conmutar por error a ella. Si la disponibilidad durante una interrupción regional no es un problema, hacer una copia de seguridad de los datos en otra región garantiza la durabilidad.

Situación: eliminación accidental o daño de datos

Gracias a la arquitectura de control de concurrencia multiversión de BigQuery, este servicio admite la función de viaje en el tiempo. Con esta función, puede consultar datos de cualquier momento de los últimos siete días. De esta forma, los usuarios pueden restaurar por sí mismos los datos que hayan eliminado, modificado o dañado por error en un plazo de 7 días. Los viajes en el tiempo también funcionan en tablas que se han eliminado.

BigQuery también permite crear instantáneas de tablas. Con esta función, puedes crear copias de seguridad de los datos de una misma región durante más tiempo que el periodo de 7 días de la función de recuperación de versiones anteriores. Una captura es una operación de metadatos pura y no ocupa bytes de almacenamiento adicionales. Aunque esto puede añadir protección contra la eliminación accidental, no aumenta la durabilidad de los datos.

Caso práctico: analíticas en tiempo real

En este caso práctico, se están ingiriendo datos de streaming de los registros de endpoints en BigQuery de forma continua. Para protegerse frente a la falta de disponibilidad prolongada de BigQuery en toda la región, es necesario replicar los datos continuamente y aprovisionar ranuras en otra región. Dado que la arquitectura es resistente a la falta de disponibilidad de BigQuery debido al uso de Pub/Sub y Dataflow en la ruta de ingestión, es probable que este alto nivel de redundancia no merezca la pena.

Supongamos que el usuario ha configurado los datos de BigQuery en us-east4 para que se exporten cada noche mediante tareas de exportación a Cloud Storage con la clase de almacenamiento Archive en us-central1. De esta forma, se crea una copia de seguridad duradera en caso de que se produzca una pérdida de datos catastrófica 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 en el peor de los casos. El objetivo de tiempo de recuperación (RTO) puede ser de varios días, ya que los datos deben restaurarse desde la copia de seguridad de Cloud Storage a BigQuery en us-central1. Si BigQuery se va a aprovisionar en una región diferente a la de las copias de seguridad, los datos deben transferirse primero a esa región. Ten en cuenta también que, a menos que hayas comprado ranuras redundantes en la región de recuperación con antelación, puede haber un retraso adicional en el aprovisionamiento de la capacidad de BigQuery necesaria en función de la cantidad solicitada.

Caso práctico: procesamiento de datos por lotes

En este caso práctico, es fundamental que se complete un informe diario antes de una fecha límite fija para enviarlo a un organismo regulador. Implementar la redundancia ejecutando dos instancias independientes de toda la canalización de procesamiento probablemente merezca la pena. Si usas dos regiones independientes, como us-west1 y us-east4, se proporciona separación geográfica y dos dominios de errores independientes en caso de que una región no esté disponible durante un periodo prolongado o incluso en el improbable caso de que se pierda una región de forma permanente.

Si necesitamos que el informe se entregue exactamente una vez, debemos conciliar el caso esperado de ambas canalizaciones que finalizan correctamente. Una estrategia razonable consiste en elegir el resultado de la canalización que termine primero, por ejemplo, notificando un tema de Pub/Sub cuando se complete correctamente. También puedes sobrescribir el resultado y volver a crear una versión del objeto de Cloud Storage. Si la canalización que termina más tarde escribe datos dañados, puedes restaurar la versión escrita por la canalización que termina primero desde Cloud Storage.

Gestión de errores

A continuación, se indican las prácticas recomendadas para solucionar los errores que afectan a la fiabilidad.

Reintentar solicitudes a la API fallidas

Los clientes de BigQuery, incluidas las bibliotecas de cliente y las herramientas de partners, deben usar el tiempo de espera exponencial truncado al enviar solicitudes a la API. Esto significa que, si un cliente recibe un error del sistema o un error de cuota, debe volver a intentar enviar la solicitud un número determinado de veces, pero con un intervalo de interrupción aleatorio y creciente.

Si utilizas este método de reintentos, tu aplicación será mucho más robusta frente a los errores. Incluso en condiciones de funcionamiento normales, puedes esperar que falle una de cada diez mil solicitudes, tal como se describe en el SLA de disponibilidad del 99,99% de BigQuery. En condiciones normales, esta tasa de errores puede aumentar, pero si los errores se distribuyen de forma aleatoria, la estrategia de espera exponencial puede mitigar todos los casos, excepto los más graves.

Si se da el caso de que una solicitud falla de forma persistente con un error 5XX, debes derivar el problema al Google Cloud equipo de Asistencia. Asegúrate de comunicar claramente el impacto que está teniendo el fallo en tu empresa para que el problema se pueda clasificar correctamente. Por otro lado, si una solicitud falla de forma persistente con un error 4XX, el problema se puede solucionar haciendo cambios en la aplicación. Consulta el mensaje de error para obtener más información.

Ejemplo de lógica de tiempo de espera exponencial

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

1. Hacer 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. Y así sucesivamente, hasta (maximum_backoff) veces.

6. Sigue esperando y reintentando hasta alcanzar el número máximo de reintentos, pero no aumentes el periodo de espera entre reintentos.

Ten en cuenta lo siguiente:

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

• random_number_milliseconds es un número aleatorio de milisegundos inferior o igual a 1000. Esta aleatorización ayuda a evitar situaciones en las que muchos clientes se sincronizan y todos vuelven a intentar la operación simultáneamente, enviando solicitudes en oleadas sincronizadas. El valor de random_number_milliseconds se vuelve a calcular después de cada solicitud de reintento.

• El intervalo de tiempo de espera máximo (maximum_backoff) suele ser de 32 o 64 segundos. El valor adecuado de maximum_backoff depende del caso práctico.

El cliente puede seguir intentándolo después de alcanzar el tiempo de espera máximo. Los reintentos posteriores a este punto no tienen que seguir aumentando el tiempo de espera. Por ejemplo, si el cliente usa un tiempo de espera máximo de 64 segundos, después de alcanzar este valor, el cliente puede seguir reintentando cada 64 segundos. En algún momento, se debe impedir que los clientes vuelvan a intentar la operación indefinidamente.

El tiempo de espera entre reintentos y el número de reintentos dependen de tu caso de uso y de las condiciones de la red.

Reintentar inserciones de trabajos fallidas

Si la semántica de inserción exactamente una vez es importante para tu aplicación, hay otras consideraciones que debes tener en cuenta a la hora de insertar trabajos. La forma de conseguir la semántica de al menos una vez depende del WriteDisposition que especifiques. La disposición de escritura indica a BigQuery qué debe hacer cuando encuentra datos en una tabla: fallar, sobrescribir o añadir.

Si el estado es WRITE_EMPTY o WRITE_TRUNCATE, esto se consigue volviendo a intentar insertar o ejecutar cualquier trabajo fallido. Esto se debe a que todas las filas insertadas por una tarea se escriben en la tabla de forma atómica.

Con una disposición WRITE_APPEND, el cliente debe especificar el ID de la tarea para evitar que se vuelva a intentar añadir los mismos datos una segunda vez. Esto funciona porque BigQuery rechaza las solicitudes de creación de trabajos que intentan usar un ID de un trabajo anterior. De esta forma, se consigue una semántica de al menos una vez para cualquier ID de trabajo. Para conseguir que se ejecute exactamente una vez, puedes volver a intentarlo con un nuevo ID de trabajo predecible una vez que hayas confirmado con BigQuery que todos los intentos anteriores han fallado.

En algunos casos, es posible que el cliente de la API o el cliente HTTP no reciban la confirmación de que se ha insertado el trabajo debido a problemas transitorios o interrupciones de la red. Cuando se vuelve a intentar la inserción, esa solicitud falla con status=ALREADY_EXISTS (code=409 y reason="duplicate"). El estado del trabajo se puede recuperar con una llamada a jobs.get. Una vez que el estado del trabajo sea retrieved, la persona que ha llamado puede determinar si se debe crear un nuevo trabajo con un nuevo ID de trabajo.

Casos prácticos y requisitos de fiabilidad

BigQuery puede ser un componente fundamental de varias arquitecturas. En función del caso práctico y de la arquitectura implementada, es posible que se deban cumplir diversos requisitos de disponibilidad, rendimiento u otra fiabilidad. En esta guía, vamos a seleccionar dos casos prácticos y arquitecturas principales para analizarlos en detalle.

Analíticas en tiempo real

El primer ejemplo es un flujo de procesamiento de datos de eventos. En este ejemplo, los eventos de registro de los endpoints se ingieren mediante Pub/Sub. Desde ahí, una canalización de Dataflow de streaming realiza algunas operaciones en los datos antes de escribirlos en BigQuery mediante la API Storage Write. Después, los datos se usan tanto para hacer consultas ad hoc (por ejemplo, para recrear secuencias de eventos que pueden haber dado lugar a resultados de endpoints específicos) como para proporcionar información a paneles de control casi en tiempo real, lo que permite detectar tendencias y patrones en los datos mediante la visualización.

En este ejemplo, debes tener en cuenta varios aspectos de la fiabilidad. Como los requisitos de actualización de los datos de extremo a extremo son bastante altos, la latencia del proceso de ingestión es fundamental. Una vez que se han escrito los datos en BigQuery, la fiabilidad se percibe como la capacidad de los usuarios de enviar consultas ad hoc con una latencia constante y predecible, así como de asegurarse de que los paneles de control que utilizan 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 de las normativas del sector de los servicios financieros. Un requisito fundamental es enviar informes diarios a las autoridades competentes antes de una hora límite fija cada noche. Siempre que el proceso por lotes nocturno que genera los informes se complete antes de esta fecha límite, se considerará lo suficientemente rápido.

Los datos deben estar disponibles en BigQuery y combinarse con otras fuentes de datos para crear paneles de control, realizar análisis y, en última instancia, generar un informe en PDF. Es fundamental que estos informes se envíen a tiempo y sin errores. Por lo tanto, es fundamental asegurar la fiabilidad de la ingesta de datos y generar el informe correctamente y en un plazo coherente para cumplir los plazos requeridos.