Comprendre la fiabilité

Ce document présente les fonctionnalités de fiabilité de BigQuery telles que la disponibilité, la durabilité, la cohérence des données, la cohérence des performances et la récupération des données, ainsi que des considérations relatives à la gestion des erreurs.

Cette présentation vous aide à répondre à trois considérations principales :

Déterminer si BigQuery est l'outil approprié pour votre tâche.
Comprendre les dimensions de fiabilité de BigQuery.
Identifier des exigences de fiabilité spécifiques pour des cas d'utilisation spécifiques.

Choisir BigQuery

BigQuery est un entrepôt de données d'entreprise entièrement géré, conçu pour stocker et analyser de grands ensembles de données. Il permet d'ingérer, de stocker, de lire et d'interroger des quantités de données allant du mégaoctet au pétaoctet, avec des performances constantes et sans avoir à gérer l'infrastructure sous-jacente. En raison de sa puissance et de ses performances, BigQuery convient parfaitement à un large éventail de solutions. Certaines de ces solutions sont décrites en détail en tant que modèles de référence.

En général, BigQuery convient parfaitement aux charges de travail dans lesquelles de grandes quantités de données sont ingérées et analysées. Plus précisément, il peut être déployé efficacement pour des cas d'utilisation tels que l'analyse de données prédictive en temps réel (avec ingestion par flux et BigQuery ML), la détection d'anomalies et d'autres cas d'utilisation nécessitant d'analyser de grands volumes de données avec des performances prévisibles. Toutefois, si vous recherchez une base de données pour prendre en charge les applications de type traitement transactionnel en ligne (OLTP), envisagez d'utiliser d'autres services Google Cloud tels que Spanner, Cloud SQL ou Bigtable qui pourraient être mieux adaptés à ces cas d'utilisation.

Dimensions de fiabilité dans BigQuery

Disponibilité

La disponibilité définit la capacité de l'utilisateur à lire des données depuis BigQuery ou à y écrire des données. BigQuery est conçu pour rendre ces deux services hautement disponibles avec un contrat de niveau de service garantissant une disponibilité de 99,99 %. Deux composants sont impliquées dans les deux opérations :

Le service BigQuery
Les ressources de calcul nécessaires pour exécuter la requête spécifique

La fiabilité du service est une fonction de l'API BigQuery spécifique utilisée pour récupérer les données. La disponibilité des ressources de calcul dépend de la capacité disponible pour l'utilisateur au moment de l'exécution de la requête. Consultez la page Comprendre les emplacements pour en savoir plus sur l'unité de calcul fondamentale de BigQuery et sur l'économie des ressources d'emplacements qui en résulte.

Durabilité

La durabilité est décrite dans le chapitre Mise en œuvre des SLO du Classeur d'ingénierie SRE et est décrite comme "la proportion de données pouvant être lues avec succès".

Cohérence des données

La cohérence définit les attentes des utilisateurs concernant la manière dont les données peuvent être interrogées une fois écrites ou modifiées. Un aspect de la cohérence des données consiste à garantir une sémantique de type "exactement une fois" pour l'ingestion des données. Pour en savoir plus, consultez les sections "Fiabilité de la solution" dans Exemples de cas d'utilisation lors du chargement de données et Réessayer les insertions de tâches en échec.

Cohérence des performances

En général, les performances peuvent être exprimées en deux dimensions. La latence est une mesure du temps d'exécution des longues opérations de récupération de données, telles que les requêtes. Le débit est une mesure de la quantité de données que BigQuery peut traiter au cours d'une période spécifique. Grâce à la conception mutualisée et évolutive horizontalement de BigQuery, le débit peut s'adapter à des tailles de données arbitraires. L'importance relative de la latence et du débit est déterminée par le cas d'utilisation spécifique.

Récupération de données

Il existe deux façons de mesurer la capacité à récupérer des données après une panne :

Objectif de temps de récupération (RTO). Durée pendant laquelle les données restent indisponibles après un incident.
Objectif de point de récupération (RPO). Quantité de données collectées avant l'incident qu'il est acceptable de perdre.

Ces considérations sont particulièrement pertinentes dans le cas peu probable où une zone ou une région subit une panne durant plusieurs jours ou une panne destructive.

Planification de reprise après sinistre

Bien que le terme "sinistre" puisse faire penser à des visions de catastrophes naturelles, le champ d'application de cette section traite des défaillances spécifiques, de la perte d'une machine individuelle à la perte catastrophique d'une région. Les premières sont des occurrences quotidiennes gérées automatiquement par BigQuery, tandis que les secondes peuvent être nécessaires aux clients pour concevoir leur architecture si nécessaire. Il est important de comprendre en quoi la planification des sinistres passe par la responsabilité du client.

BigQuery offre un contrat de niveau de service garantissant une disponibilité de 99,99 %. Ceci est rendu possible par l'architecture régionale de BigQuery qui écrit les données dans deux zones différentes et provisionne une capacité de calcul redondante. Il est important de garder à l'esprit que le contrat de niveau de service BigQuery est identique pour les régions, par exemple us-central1, et les emplacements multirégionaux, par exemple, US.

Gestion automatique des scénarios

Comme BigQuery est un service régional, il est de la responsabilité de BigQuery de gérer automatiquement la perte d'une machine, voire d'une zone entière. Le fait que BigQuery soit construit sur des zones n'est pas perçu par les utilisateurs.

Perte d'une machine

Les défaillances des machines sont une occurrence quotidienne à l'échelle de laquelle Google opère. BigQuery est conçu pour gérer automatiquement les défaillances de machine sans aucun impact sur la zone conteneur.
En arrière-plan, l'exécution d'une requête est divisée en petites tâches pouvant être distribuées en parallèle sur de nombreuses machines. La perte soudaine ou la dégradation des performances de la machine est gérée automatiquement par la répartition des tâches vers une autre machine. Une telle approche est essentielle pour réduire la latence de queue.

BigQuery utilise l'encodage Reed–Solomon pour stocker efficacement et de manière durable une copie zonale de vos données. Dans le cas très peu probable où plusieurs défaillances de machine entraînent la perte d'une copie zonale, les données sont également stockées de la même manière dans au moins une autre zone. Dans ce cas, BigQuery détecte le problème et crée une copie zonale des données pour restaurer la redondance.

Perte d'une zone

La disponibilité sous-jacente des ressources de calcul dans une zone donnée n'est pas suffisante pour répondre au contrat de niveau de service garantissant une disponibilité de 99,99 % dans BigQuery. Par conséquent, BigQuery fournit une redondance zonale automatique pour les emplacements de données et de calcul. Bien qu'il ne s'agisse pas de perturbations zonales de courte durée, elles se produisent. Cependant, l'automatisation BigQuery basculera les requêtes vers une autre zone dans la minute ou deux suivant une panne majeure. Les requêtes déjà en cours peuvent ne pas être récupérées immédiatement, mais les requêtes nouvellement émises le seront. Cela se traduit par le fait que l'exécution de requêtes en cours prend beaucoup de temps, tandis que les nouvelles requêtes se terminent rapidement.

Même si une zone doit rester indisponible pendant une période plus longue, aucune perte de données ne sera due au fait que BigQuery écrit des données de manière synchrone sur deux zones. Ainsi, même en cas de perte de zone, les clients ne subiront pas d'interruption de service.

Types de défaillances

Il existe deux types de défaillances : les défaillances temporaires et les défaillances permanentes.

Les défaillances temporaires sont des anomalies opérationnelles où le matériel n'est pas détruit. Il s'agit par exemple d'une panne de courant, d'une partition réseau ou du plantage d'une machine. En général, BigQuery ne doit jamais perdre de données en cas de défaillance temporaire.

Les défaillances permanentes sont des anomalies opérationnelles où le matériel est détruit. Ces défaillances sont plus graves que les défaillances temporaires. Il s'agit par exemple de dégâts occasionnés par des inondations, des attaques terroristes, des séismes et des ouragans.

Disponibilité et durabilité

Lorsque vous créez un ensemble de données BigQuery, vous sélectionnez un emplacement pour stocker vos données. Cet emplacement est choisi parmi les éléments suivants :

Une région : emplacement géographique spécifique, par exemple l'Iowa (us-central1) ou Montréal (northamerica-northeast1).
Un emplacement multirégional : secteur géographique de grande étendue contenant au moins deux lieux géographiques, tel que les États-Unis (US) ou l'Europe (EU).

Dans les deux cas, BigQuery stocke automatiquement des copies de vos données dans deux zones Google Cloud distinctes au sein d'une même région, dans l'emplacement sélectionné.

En plus de la redondance de stockage, BigQuery conserve également une capacité de calcul redondante sur plusieurs zones. En combinant le stockage redondant et le calcul sur plusieurs zones de disponibilité, BigQuery offre à la fois une disponibilité et une durabilité élevées.

En cas de défaillance au niveau des machines, BigQuery continue de s'exécuter avec un décalage de quelques millisecondes maximum. Toutes les requêtes en cours continuent d'être traitées. En cas de défaillance zonale temporaire ou permanente, aucune perte de données n'est attendue. Toutefois, les requêtes en cours d'exécution peuvent échouer et doivent être de nouveau envoyées. Une défaillance zonale temporaire, telle qu'une panne de courant, la destruction d'un transformateur ou une partition réseau, est un processus éprouvé et est automatiquement atténué en quelques minutes.

Une défaillance régionale temporaire, telle qu'une perte de connectivité réseau à l'échelle de la région, entraîne la perte de disponibilité tant que la région n'est pas de nouveau en ligne, mais elle n'entraîne pas de perte de données. Une défaillance régionale permanente, par exemple, si un sinistre détruit la région, peut entraîner une perte des données stockées dans cette région. BigQuery ne fournit pas automatiquement de sauvegarde ni d'instance dupliquée de vos données dans une autre région géographique. Vous pouvez créer des copies d'ensembles de données interrégionales pour améliorer votre stratégie de reprise après sinistre.

Pour en savoir plus sur les emplacements des ensembles de données BigQuery, consultez la section Considérations relatives aux emplacements.

Scénario : perte de région

BigQuery n'offre pas de durabilité ou de disponibilité dans l'événement incroyablement peu probable et sans précédent de perte de région physique. Cela est valable pour les configurations "régionales et multirégionales". Par conséquent, maintenir la durabilité et la disponibilité dans ce scénario nécessite une planification client. En cas de perte temporaire, telle qu'une panne du réseau, la disponibilité redondante doit être prise en compte si le contrat de niveau de service de 99,99 % de BigQuery n'est pas considéré comme suffisant.

Pour éviter toute perte de données en cas de perte régionale destructive, vous devez sauvegarder les données dans un autre emplacement géographique. Par exemple, vous pouvez exporter régulièrement un instantané de vos données vers Google Cloud Storage dans une autre région géographique. Pour ce faire, procédez comme décrit dans le cas d'utilisation du traitement par lot des données.
Dans le cas d'emplacements multirégionaux BigQuery, vous devez éviter de sauvegarder les régions dans le champ d'application de l'emplacement multirégional. Par exemple, ne sauvegardez pas vos données aux États-Unis dans la région us-central1. La région et l'emplacement multirégional risquent de partager des domaines de défaillance et de subir le même sort en cas de sinistre. Sauvegardez plutôt vos données dans une région autre que US, telle que northamerica-northeast1. Si les exigences de résidence des données nécessitent que les sauvegardes soient stockées aux États-Unis, il est préférable d'associer deux régions telles que us-central1 et us-east1.

Pour éviter une indisponibilité étendue, vous devez provisionner les données et les emplacements dans deux emplacements BigQuery géographiquement distincts. Comme pour l'exemple ci-dessus, évitez de mélanger des régions et des emplacements multirégionaux, car ils peuvent subir le même sort en cas de sinistre.

L'architecture la plus fiable pour une configuration régionale redondante consiste à exécuter un mode chaud (hot-hot), également appelé actif-actif. Cela signifie que votre charge de travail s'exécute en parallèle dans votre région principale et dans votre région secondaire. Bien que plus coûteux, cela garantit que la région secondaire obtient une validation continue et fonctionnera si vous devez basculer vers elle. Si la disponibilité en cas de panne régionale est moins préoccupante, la sauvegarde des données dans une autre région garantit la durabilité.

Scénario : suppression accidentelle ou corruption de données

Grâce à l'architecture de contrôle de simultanéité multiversion de BigQuery, BigQuery est compatible avec les fonctionnalités temporelles. Avec cette fonctionnalité, vous pouvez interroger les données à tout moment au cours des sept derniers jours. Cela permet la restauration en libre-service de toutes les données supprimées par erreur, modifiées ou corrompues au cours d'une période de sept jours. Les fonctionnalités temporelles sont disponibles sur les tables supprimées.

BigQuery accepte également les instantanés des tables. Grâce à cette fonctionnalité, vous pouvez explicitement sauvegarder les données dans la même région pendant une période de plus de sept jours. Un instantané est simplement une opération de métadonnées, qui n'entraîne aucun octet de stockage supplémentaire. Bien que cela puisse augmenter la protection contre la suppression accidentelle, cela n'augmente pas la durabilité des données.

Cas d'utilisation : analyse en temps réel

Dans ce cas d'utilisation, les données en streaming sont ingérées à partir de journaux de points de terminaison vers BigQuery de manière continue. Pour vous protéger contre l'indisponibilité étendue de BigQuery pour l'ensemble de la région, vous devez répliquer en continu les données et provisionner les emplacements dans une autre région. Étant donné que l'architecture est résiliente à l'indisponibilité de BigQuery en raison de l'utilisation de Pub/Sub et de Dataflow dans le chemin d'ingestion, ce niveau élevé de redondance ne vaut probablement pas le coût.

En supposant que l'utilisateur a configuré les données BigQuery dans us-east4 pour qu'elles soient exportées la nuit en utilisant des tâches d'exportation vers Cloud Storage sous la classe de stockage Archive dans la région us-central1. Cela fournit une sauvegarde durable en cas de perte de données catastrophique dans la région us-east4. Dans ce cas, l'objectif de point de récupération (RPO) est de 24 heures, car la dernière sauvegarde exportée peut remonter jusqu'à 24 heures dans le pire des cas. L'objectif de temps de récupération (RTO) peut atteindre plusieurs jours, car les données doivent être restaurées de la sauvegarde Cloud Storage vers BigQuery dans la région us-central1. Si BigQuery doit être provisionné dans une région différente de celle dans laquelle les sauvegardes sont placées, les données doivent d'abord être transférées vers cette région. Sachez également que si vous avez acheté à l'avance des emplacements redondants dans la région de récupération, le provisionnement de la capacité BigQuery requise en fonction de la quantité demandée peut prendre un certain temps.

Cas d'utilisation : traitement de données par lot

Dans ce cas d'utilisation, il est essentiel pour les entreprises de soumettre un rapport quotidien dans un délai fixe à une entité de réglementation. La mise en œuvre de la redondance en exécutant deux instances distinctes de l'ensemble du pipeline de traitement en vaut probablement le coût. L'utilisation de deux régions distinctes, par exemple us-west1 et us-east4, fournit une séparation géographique et deux domaines de défaillance indépendants en cas d'indisponibilité étendue d'une région, voire dans le cas improbable de perte de région permanente.

En supposant que le rapport doive être livré une seule fois, nous devons rapprocher le cas attendu des deux pipelines ayant abouti. Une stratégie raisonnable consiste à choisir le résultat du pipeline qui se termine en premier, par exemple en notifiant un sujet Pub/Sub lors de la réussite de l'opération. Vous pouvez également écraser le résultat et reversionner l'objet Cloud Storage. Si le pipeline se terminant plus tard écrit des données corrompues, vous pouvez récupérer en restaurant la version écrite par le pipeline qui se termine en premier à partir de Cloud Storage.

Gestion des exceptions

Voici les bonnes pratiques à suivre pour résoudre les erreurs qui affectent la fiabilité.

Réessayer les requêtes d'API en échec

Les clients BigQuery, y compris les bibliothèques clientes et les outils partenaires, doivent utiliser un intervalle exponentiel tronqué entre les tentatives lors de l'envoi de requêtes API. Cela signifie que si un client reçoit une erreur système ou une erreur de quota, il doit relancer la requête jusqu'à un certain nombre de fois, mais avec un intervalle aléatoire et exponentiel entre les tentatives.

L'utilisation de cette méthode permet de rendre votre application beaucoup plus robuste en cas d'erreurs. Même dans des conditions de fonctionnement normales, vous pouvez vous attendre à un taux d'échec d'environ une requête pour 10 000, conformément au contrat de niveau de service garantissant une disponibilité à 99,99% pour BigQuery. Bien que ce taux d'erreur puisse augmenter en cas de conditions anormales, la stratégie d'intervalle exponentiel entre les tentatives peut mitiger tous les cas sauf les plus graves tant que les erreurs sont distribuées de manière aléatoire.

Si vous rencontrez un scénario entraînant l'échec persistant d'une requête avec une erreur 5XX, vous devez transmettre votre demande à l'assistance Google Cloud. Veillez à indiquer clairement l'impact de cet échec sur votre activité afin que le problème puisse être trié correctement. En revanche, si une requête échoue de manière permanente avec une erreur 4XX, le problème doit être résolu par des modifications apportées à votre application. Lisez le message d'erreur pour en savoir plus.

Exemple de logique d'intervalle exponentiel entre les tentatives

La logique d'intervalle exponentiel entre les tentatives relance une demande ou une requête en augmentant le temps d'attente entre les tentatives jusqu'à ce que la durée maximale de l'intervalle exponentiel soit atteinte. Exemple :

Envoyez une requête à BigQuery.
Si la requête échoue, attendez 1 + random_number_milliseconds secondes, puis effectuez une nouvelle tentative.
Si la requête échoue, attendez 2 + random_number_milliseconds secondes, puis effectuez une nouvelle tentative.
Si la requête échoue, attendez 4 + random_number_milliseconds secondes, puis effectuez une nouvelle tentative.
Poursuivez ainsi jusqu'à atteindre l'intervalle maximal entre les tentatives maximum_backoff.
Continuez d'attendre et de relancer la requête jusqu'à atteindre le nombre maximal de tentatives, mais n'augmentez pas le temps d'attente entre les tentatives.

Veuillez noter les points suivants :

Le temps d'attente est défini sur min(((2^n)+random_number_milliseconds), maximum_backoff), avec n incrémenté de 1 pour chaque itération (requête).
random_number_milliseconds correspond à un nombre aléatoire de millisecondes inférieur ou égal à 1 000. Cette randomisation permet d'éviter les situations où de nombreux clients sont synchronisés et effectuent tous une nouvelle tentative simultanément, en envoyant des requêtes par vagues synchronisées. La valeur de random_number_milliseconds est recalculée après chaque nouvelle tentative de la requête.
L'intervalle maximal entre les tentatives (maximum_backoff) est généralement de 32 ou 64 secondes. La valeur appropriée pour maximum_backoff dépend du cas d'utilisation.

Le client peut continuer à effectuer des nouvelles tentatives après avoir atteint le délai maximal entre les tentatives. Au-delà de ce point, il n'est pas nécessaire de continuer à augmenter la durée de l'intervalle exponentiel entre les tentatives. Par exemple, si le client utilise un intervalle maximal entre les tentatives de 64 secondes, une fois celui-ci atteint, il peut continuer à effectuer des nouvelles tentatives toutes les 64 secondes. À un certain moment, vous devez empêcher les clients d'effectuer des tentatives à l'infini.

Le temps d'attente entre les nouvelles tentatives et le nombre de tentatives dépendent de votre cas d'utilisation et des conditions du réseau.

Réessayer les insertions de tâches en échec

Si la sémantique d'insertion de type "exactement une fois" est importante pour votre application, d'autres considérations doivent être prises en compte lors de l'insertion de tâches. Pour la sémantique d'insertion "pas plus d'une fois", la procédure du paramétrage de la propriété WriteDisposition (disposition d'écriture). La disposition d'écriture indique à BigQuery comment procéder lorsqu'il rencontre des données existantes dans une table : échec, écrasement ou ajout.

Avec une disposition WRITE_EMPTY ou WRITE_TRUNCATE, il suffit simplement de retenter l'insertion ou l'exécution des tâches ayant échoué. En effet, toutes les lignes ingérées par une tâche sont écrites de manière atomique dans la table.

Avec une disposition WRITE_APPEND, le client doit spécifier l'ID de tâche pour empêcher les nouvelles tentatives d'ajouter plusieurs fois des données identiques. Cette méthode fonctionne car BigQuery refuse les requêtes de création de job qui tentent d'utiliser un ID provenant d'un job. Cela permet d'obtenir une sémantique de type "pas plus d'une fois" pour chaque ID de tâche. Vous pouvez ensuite obtenir une sémantique de type "exactement une fois" en réessayant avec un nouvel ID de tâche prévisible une fois que vous avez confirmé avec BigQuery que toutes les tentatives précédentes ont bien échoué.

Dans certains cas, le client API ou le client HTTP peuvent ne pas recevoir la confirmation que la tâche a été insérée, en raison de problèmes temporaires ou d'interruptions de réseau. Lorsque l'insertion est relancée, cette requête échoue en renvoyant status=ALREADY_EXISTS (code=409 et reason="duplicate"). Vous pouvez récupérer l'état de la tâche existante en appelant jobs.get. Lorsque l'état de la tâche existante est retrieved, l'appelant peut déterminer si une nouvelle tâche avec un nouvel ID de tâche doit être créée.

Cas d'utilisation et exigences de fiabilité

BigQuery peut être un composant essentiel de diverses architectures. En fonction du cas d'utilisation et de l'architecture déployée, il est possible que vous deviez répondre à diverses exigences de disponibilité, de performances ou de fiabilité. Pour les besoins de ce guide, nous allons sélectionner deux cas d'utilisation principaux et leurs architectures afin de les présenter en détail.

Analyse en temps réel

Le premier exemple est un pipeline de traitement de données d'événement. Dans cet exemple, les événements de journal des points de terminaison sont ingérés à l'aide de Pub/Sub. Ensuite, un pipeline Dataflow de traitement par flux effectue certaines opérations sur les données avant de les écrire dans BigQuery en utilisant l'API Storage Write. Les données sont ensuite utilisées à la fois pour des requêtes ad hoc, par exemple pour recréer des séquences d'événements susceptibles d'avoir entraîné des résultats de points de terminaison spécifiques, et pour alimenter des tableaux de bord en temps réel afin de permettre la détection de tendances et de modèles dans les données grâce à la visualisation.

Cet exemple nécessite de prendre en compte plusieurs aspects de la fiabilité. Les exigences de fraîcheur des données de bout en bout étant relativement élevées, la latence du processus d'ingestion est essentielle. Une fois les données écrites dans BigQuery, la fiabilité est perçue comme la capacité des utilisateurs à émettre des requêtes ad hoc avec une latence cohérente et prévisible, et la capacité à s'assurer que les tableaux de bord utilisent des données qui reflètent bien les informations les plus récentes disponibles.

Traitement de données par lot

Le deuxième exemple est une architecture de traitement par lots basée sur les exigences de conformité réglementaire du secteur des services financiers. L'une des principales exigences est de soumettre aux autorités de régulation des rapports quotidiens et à heure fixe. Tant que le processus quotidien de traitement par lots génère ses rapports dans le délai imparti, il est considéré comme suffisamment rapide.

Les données doivent être disponibles dans BigQuery et associées à d'autres sources de données à des fins de création de tableaux de bord, d'analyse et de génération de rapports au format PDF. Il est essentiel que ces rapports soient fournis dans le délai imparti et sans erreur. Par conséquent, il est essentiel de garantir la fiabilité de l'ingestion des données et de la génération du rapport dans un délai cohérent pour respecter les délais requis.