Comprendre les emplacements
Un emplacement BigQuery est un processeur virtuel utilisé par BigQuery pour exécuter des requêtes SQL. Pendant l'exécution d'une requête, BigQuery calcule automatiquement le nombre d'emplacements requis par une requête en fonction de la taille et de la complexité de cette requête.
Vous pouvez décider d'utiliser un modèle de tarification à la demande ou un modèle de tarification basé sur la capacité. Les deux modèles utilisent des emplacements pour le traitement des données. Avec un modèle basé sur la capacité, vous pouvez payer pour une capacité de traitement de requêtes dédiée ou avec autoscaling. Le modèle basé sur la capacité vous confère un contrôle explicite sur les emplacements et la capacité d'analyse, contrairement au modèle à la demande.
Les clients optant pour le modèle de tarification basé sur la capacité choisissent explicitement le nombre d'emplacements à réserver. Vos requêtes sont traitées dans les limites de cette capacité, et vous payez pour celle-ci en permanence à chaque seconde où elle est déployée. Par exemple, si vous achetez 2 000 emplacements BigQuery, vos requêtes sont limitées à une utilisation totale de 2 000 processeurs virtuels à un moment donné. Vous disposez de cette capacité jusqu'à ce que vous la supprimiez, et vous payez pour 2 000 emplacements jusqu'à leur suppression.
Les projets déployés selon le modèle de tarification à la demande sont soumis à un quota d'emplacements par projet avec une capacité d'utilisation intensive temporaire. La plupart des utilisateurs du modèle à la demande trouvent que la capacité par défaut des emplacements est amplement suffisante. En fonction de la charge de travail, l'accès à un plus grand nombre d'emplacements améliore les performances des requêtes. Pour vérifier le nombre d'emplacements utilisés par votre compte, consultez la page Surveiller BigQuery.
Estimer le nombre d'emplacements à acheter
BigQuery est conçu pour évoluer efficacement avec des ressources accrues. En fonction de la charge de travail, la capacité incrémentielle peut vous apporter des avantages supplémentaires. Par conséquent, le choix du nombre optimal d'emplacements à acheter dépend de vos exigences en termes de performances, de débit et d'utilisation.
Vous pouvez tester les emplacements de référence et d'autoscaling pour déterminer la meilleure configuration d'emplacements. Par exemple, vous pouvez tester votre charge de travail avec 500 emplacements de référence, puis 1 000, puis 1 500 et 2 000, et observer l'impact sur les performances.
Cela vous permet également d'examiner les emplacements qu'utilisent actuellement vos projets, ainsi que le prix mensuel que vous souhaitez payer. Les charges de travail à la demande ont actuellement une limite approximative de 2 000 emplacements. Cependant, nous vous conseillons de vérifier le nombre d'emplacements réellement utilisés par vos projets à l'aide de vues INFORMATION_SCHEMA.JOBS*, de Cloud Logging, de l'API Jobs ou des journaux d'audit BigQuery. Pour en savoir plus, consultez la section Visualiser les emplacements disponibles et alloués.
Après avoir acheté des emplacements et exécuté vos charges de travail pendant au moins sept jours, vous pouvez utiliser l'estimateur d'emplacement pour analyser les performances, et modéliser l'effet de l'ajout ou de la réduction d'emplacements. Pour en savoir plus, consultez la section Estimer les exigences relatives à la capacité d'emplacements.
Exécuter des requêtes à l'aide d'emplacements
Lorsque BigQuery exécute une tâche de requête, il convertit l'instruction SQL déclarative en un graphe d'exécution divisé en une série de phases de requête. Ces dernières sont composées d'ensembles d'étapes d'exécution plus précis. BigQuery exploite une architecture parallèle fortement distribuée pour exécuter ces requêtes, et les phases modélisent les unités de travail que de nombreux nœuds de calcul potentiels peuvent exécuter en parallèle. Les étapes communiquent entre elles à l'aide d'une architecture de brassage distribuée rapide qui est présentée en détail sur le blog Google Cloud.
L'exécution d'une requête BigQuery est dynamique, ce qui signifie que le plan de requête peut être modifié lorsqu'une requête est en cours d'exécution. Les phases introduites lors de l'exécution d'une requête permettent souvent d'améliorer la distribution des données entre les nœuds de calcul qui traitent la requête.
BigQuery peut exécuter plusieurs phases simultanément. BigQuery peut exploiter l'exécution spéculative pour accélérer une requête, et repartitionner dynamiquement une phase pour obtenir une parallélisation optimale.
Les emplacements BigQuery exécutent des unités de travail individuelles à chaque phase de la requête. Par exemple, si BigQuery détermine que le facteur de parallélisation optimal d'une phase est de 10, il demande 10 emplacements pour traiter cette phase.
Exécuter des requêtes en économisant les ressources d'emplacements
Si une requête demande un plus grand nombre d'emplacements que ce qui est actuellement disponible, BigQuery place en file d'attente des unités de travail individuelles et attend que des emplacements soient disponibles Au fur et à mesure de l'exécution de la requête et de la libération des emplacements, ces unités de travail mises en file d'attente sont sélectionnées de manière dynamique.
BigQuery peut demander autant d'emplacements qu'il le souhaite pour une phase donnée d'une requête. Le nombre d'emplacements demandés n'est pas lié au volume de capacité achetée, mais indique plutôt le facteur de parallélisation optimal choisi par BigQuery pour cette phase. Les unités de travail sont placées en file d'attente et sont exécutées dès que des emplacements sont disponibles.
Lorsque vos besoins en requêtes dépassent le nombre d'emplacements que vous avez souscrit, aucun emplacement ni aucuns frais supplémentaires ne vous sont facturés. Vos unités de travail individuelles sont placées en file d'attente.
Par exemple,
- Une phase de requête nécessite 2 000 emplacements, mais seulement 1 000 emplacements sont disponibles.
- BigQuery utilise ces 1 000 emplacements et place les 1 000 autres en file d'attente.
- Par la suite, si 100 emplacements se libèrent, ils récupèrent de façon dynamique 100 unités de travail parmi les 1 000 unités de travail en attente. Il reste donc 900 unités de travail en attente.
- Par la suite, si 500 emplacements se libèrent, ils récupèrent de façon dynamique 500 unités de travail parmi les 900 unités de travail en attente. Il reste donc 400 unités de travail en attente.
Emplacements inactifs
Certains emplacements peuvent être inactifs à n'importe quel moment. Par exemple :
- Les engagements d'emplacements qui ne sont alloués à aucune réservation.
- Les emplacements qui sont alloués à une référence de réservation, mais qui ne sont pas utilisés.
Par défaut, les requêtes exécutées dans une réservation utilisent automatiquement les emplacements inactifs des autres réservations du même projet d'administration. Cela signifie qu'une tâche peut toujours s'exécuter tant qu'elle dispose d'une capacité suffisante. Si nécessaire, la capacité inactive est immédiatement préemptée au profit de la réservation attribuée initialement, quelle que soit la priorité de la requête nécessitant les ressources. Cela se produit automatiquement et en temps réel.
Pour éviter ce problème et vous assurer qu'une réservation n'utilise que ses emplacements provisionnés, définissez ignore_idle_slots sur true. Les réservations où ignore_idle_slots est défini sur true peuvent toutefois partager leurs emplacements inactifs avec d'autres réservations.
Vous ne pouvez pas partager des emplacements inactifs entre des réservations d'éditions différentes. Vous ne pouvez partager que les emplacements de référence ou les emplacements validés. Les emplacements avec autoscaling peuvent être temporairement disponibles, mais ne peuvent pas être partagés, car ils peuvent être réduits.
Tant que ignore_idle_slots est défini sur "false", une réservation peut avoir un nombre d'emplacements de 0 et avoir toujours accès aux emplacements inutilisés. Si vous utilisez uniquement la réservation default, il est recommandé de désactiver ignore_idle_slots. Vous pouvez ensuite attribuer un projet ou un dossier à cette réservation, qui n'utilisera que des emplacements inactifs.
Les attributions de type ML_EXTERNAL font exception à la règle, car les emplacements utilisés par les tâches de création de modèles externes BigQuery ML ne sont pas préemptifs. Les emplacements d'une réservation avec les types d'attribution ML_EXTERNAL et QUERY ne sont disponibles que pour les autres tâches de requête lorsque ceux-ci ne sont pas occupés par les tâches ML_EXTERNAL. De plus, ces tâches ne peuvent pas utiliser les emplacements inactifs associés à d'autres réservations.
Allocation d'emplacements dans les réservations
BigQuery alloue la capacité d'emplacements dans une seule réservation à l'aide d'un algorithme appelé planification équitable.
Le programmeur BigQuery applique un partage équitable des emplacements entre les projets avec des requêtes en cours d'exécution au sein d'une réservation, puis entre les tâches d'un projet donné. Le programmeur assure une équité à terme. Pendant de courtes périodes, certaines tâches peuvent obtenir une part disproportionnée des emplacements, mais le planificateur finit par corriger cette inégalité. L'objectif du programmeur est de trouver un équilibre entre l'éviction agressive des tâches en cours (ce qui entraîne un gaspillage du temps d'utilisation des emplacements) et une attitude trop indulgente (où les tâches de longue durée obtiennent une part disproportionnée de la durée de l'utilisation de l'emplacement).
Si une tâche importante a toujours besoin d'un nombre d'emplacements supérieur à celui qu'elle reçoit du programmeur, envisagez de créer une réservation supplémentaire avec un nombre garanti d'emplacements et d'attribuer la tâche à cette réservation.
Planification équitable dans BigQuery
Les emplacements sont répartis équitablement entre les projets, puis entre les tâches des projets. Cela signifie que chaque requête dispose d'un accès à tous les emplacements disponibles à tout moment, et que la capacité est réaffectée de manière dynamique et automatique aux requêtes actives, au fil de l'évolution de leurs besoins. Les requêtes s'exécutent, et les nouvelles requêtes sont soumises pour exécution dans les conditions suivantes :
- Lorsqu'une nouvelle requête est soumise, la capacité est automatiquement réaffectée aux requêtes en cours d'exécution. Les unités de travail individuelles peuvent être mises en pause, réactivées et placées en file d'attente de manière optimale en fonction des capacités disponibles pour chaque requête.
- Lorsqu'une requête se termine, la capacité consommée par cette requête peut immédiatement être utilisée par toutes les autres.
- Chaque fois que les besoins d'une requête changent en raison des modifications apportées au DAG dynamique de celle-ci, BigQuery réévalue automatiquement la disponibilité en capacité pour cette requête et pour toutes les autres, et réaffecte ou met en pause les emplacements si nécessaire
En fonction de sa complexité et de sa taille, une requête peut ne pas utiliser tous les emplacements auxquels elle a droit. Elle peut aussi devoir en utiliser plus. Grâce à un fonctionnement dynamique et à la planification équitable, BigQuery permet une utilisation complète de tous les emplacements à tout moment.