# Google BigQuery vs Amazon Redshift en 2026 : Comparatif et Questions d'Entretien Data Analyst

> Comparatif détaillé entre BigQuery et Redshift en 2026 : architecture, tarification, performances et questions fréquentes en entretien pour les analystes de données.

- Published: 2026-07-31
- Updated: 2026-07-31
- Author: SharpSkill
- Tags: bigquery, redshift, data warehouse, cloud analytics, entretien data analyst
- Reading time: 10 min

---

Google BigQuery et Amazon Redshift dominent le marché des entrepôts de données cloud en 2026, chacun offrant des avantages distincts pour les charges de travail d'[analyse de données](/technologies/data-analytics). Cette comparaison couvre les différences architecturales, les modèles tarifaires, les caractéristiques de performance et les questions fréquemment posées aux candidats analystes de données lors des entretiens.

> **Guide de décision rapide**
>
> Privilégier BigQuery pour la simplicité serverless, la tarification à la requête et l'intégration native à GCP. Opter pour Redshift pour des coûts prévisibles à grande échelle, des pipelines ETL complexes et une intégration profonde dans l'écosystème AWS.

## Différences architecturales entre BigQuery et Redshift

BigQuery repose sur une architecture serverless multi-tenant où le stockage et le calcul sont entièrement séparés. Les requêtes s'exécutent sur des ressources allouées dynamiquement sans aucune gestion de cluster. Google gère automatiquement toute la mise à l'échelle, les correctifs et les optimisations de l'infrastructure.

Redshift fonctionne selon un modèle de cluster provisionné avec des nœuds dédiés. Le stockage et le calcul sont étroitement couplés au sein des nœuds, bien que [Redshift Serverless](https://docs.aws.amazon.com/redshift/latest/mgmt/serverless-whatis.html) propose désormais une alternative basée sur la consommation. Le type de nœud RA3 introduit une séparation du stockage géré, permettant une mise à l'échelle indépendante du calcul et du stockage.

| Aspect | BigQuery | Redshift |
|--------|----------|----------|
| Déploiement | Entièrement serverless | Clusters provisionnés ou Serverless |
| Stockage-Calcul | Entièrement séparé | Couplé (RA3 sépare le stockage géré) |
| Mise à l'échelle | Automatique | Redimensionnement manuel ou Concurrency Scaling |
| Maintenance | Zéro | Fenêtres de maintenance requises |
| Démarrage à froid | Aucun | Temps de reprise du cluster si en pause |

Cette différence architecturale impacte significativement la charge opérationnelle. BigQuery ne nécessite aucune planification de capacité, tandis que Redshift exige des décisions continues sur le dimensionnement des clusters et la planification des maintenances.

## Modèles tarifaires : paiement à la requête vs capacité provisionnée

BigQuery facture 6,25 $ par To analysé en mode à la demande en 2026. La tarification à capacité réservée (forfait) offre des coûts mensuels prévisibles pour les charges de travail régulières. Le stockage coûte 0,02 $/Go/mois pour les données actives et 0,01 $/Go/mois pour le stockage à long terme après 90 jours.

```sql
-- BigQuery : Vérifier le coût d'une requête après exécution
SELECT
  total_bytes_billed / POW(10, 12) AS tb_factures,
  (total_bytes_billed / POW(10, 12)) * 6.25 AS cout_estime_usd
FROM `region-us`.INFORMATION_SCHEMA.JOBS_BY_PROJECT
WHERE job_id = 'votre-job-id';
```

La tarification Redshift dépend du type et du nombre de nœuds. Les nœuds DC2 (calcul dense) démarrent à 0,25 $/heure, tandis que les nœuds RA3 avec stockage géré commencent à 1,086 $/heure. Redshift Serverless facture en fonction des Redshift Processing Units (RPU) consommées.

Les stratégies d'optimisation des coûts diffèrent considérablement. BigQuery récompense l'optimisation des requêtes par le partitionnement et le clustering, car analyser moins de données réduit directement les coûts. L'optimisation Redshift se concentre sur le dimensionnement approprié des clusters et l'utilisation d'instances réservées pour les charges prévisibles.

## Différences de syntaxe SQL et de fonctions

Les deux plateformes supportent SQL ANSI, mais des variations syntaxiques existent pour les fonctionnalités avancées. Comprendre ces différences est essentiel pour les [questions d'entretien SQL](/technologies/data-analytics/interview-questions/sql-subqueries-ctes) et les projets de migration.

```sql
-- BigQuery : Fonctions de date avec EXTRACT et DATE_TRUNC
SELECT
  DATE_TRUNC(order_date, MONTH) AS mois_commande,
  EXTRACT(DAYOFWEEK FROM order_date) AS jour_semaine,
  COUNT(*) AS nombre_commandes
FROM `project.dataset.orders`
WHERE order_date >= DATE_SUB(CURRENT_DATE(), INTERVAL 1 YEAR)
GROUP BY 1, 2;

-- Redshift : Similaire mais DATE_TRUNC avec argument chaîne
SELECT
  DATE_TRUNC('month', order_date) AS mois_commande,
  EXTRACT(DOW FROM order_date) AS jour_semaine,
  COUNT(*) AS nombre_commandes
FROM orders
WHERE order_date >= DATEADD(year, -1, CURRENT_DATE)
GROUP BY 1, 2;
```

La gestion des tableaux et structures montre une divergence significative. BigQuery supporte nativement les champs imbriqués et répétés avec les opérations UNNEST. Redshift gère les données semi-structurées via le type SUPER et la syntaxe PartiQL introduite récemment.

```sql
-- BigQuery : Travail avec des tableaux imbriqués
SELECT
  user_id,
  event.name AS nom_evenement,
  event.timestamp AS heure_evenement
FROM `analytics.events`,
UNNEST(events) AS event
WHERE DATE(event.timestamp) = CURRENT_DATE();

-- Redshift : Type SUPER avec PartiQL
SELECT
  user_id,
  e.name AS nom_evenement,
  e.timestamp AS heure_evenement
FROM events_table AS t, t.events AS e
WHERE DATE(e.timestamp) = CURRENT_DATE;
```

## Caractéristiques de performance et optimisation des requêtes

BigQuery excelle pour les requêtes analytiques ad-hoc sur des ensembles de données massifs sans ajustement. Le modèle d'exécution basé sur les slots distribue automatiquement le travail. Les performances restent constantes indépendamment du nombre d'utilisateurs simultanés, chaque requête recevant des ressources dédiées du pool de slots.

Redshift offre des performances supérieures pour les requêtes prévisibles et répétitives lorsqu'il est correctement configuré. Les clés de distribution, les clés de tri et les vues matérialisées impactent significativement la vitesse des requêtes. Le planificateur génère des plans d'exécution optimisés basés sur les statistiques des tables.

```sql
-- Redshift : Définition des clés de distribution et de tri
CREATE TABLE ventes_fait (
  vente_id BIGINT,
  client_id BIGINT,
  produit_id BIGINT,
  date_vente DATE,
  montant DECIMAL(10, 2)
)
DISTKEY(client_id)
SORTKEY(date_vente);

-- Redshift : Vue matérialisée pour les requêtes de tableau de bord
CREATE MATERIALIZED VIEW resume_ventes_quotidien AS
SELECT
  date_vente,
  COUNT(*) AS nombre_transactions,
  SUM(montant) AS chiffre_affaires_total
FROM ventes_fait
GROUP BY date_vente;
```

L'optimisation BigQuery repose sur le partitionnement et le clustering. Le partitionnement réduit les données analysées par plage de dates ou d'entiers. Le clustering trie les données au sein des partitions pour accélérer les requêtes filtrées.

```sql
-- BigQuery : Table partitionnée et clusterisée
CREATE TABLE `project.dataset.ventes_fait`
PARTITION BY DATE(date_vente)
CLUSTER BY client_id, produit_id
AS SELECT * FROM `project.dataset.ventes_brutes`;
```

Pour les stratégies d'optimisation des performances sur des sujets connexes, le [guide sur les fonctions de fenêtrage et CTE](/blog/data-analytics/sql-window-functions-ctes-advanced-queries) couvre les techniques avancées d'optimisation des requêtes.

## Chargement des données et intégration ETL

BigQuery supporte l'insertion en streaming pour les données temps réel à 0,05 $ par Go, le chargement par lots depuis Cloud Storage gratuitement, et des connecteurs natifs pour Dataflow et Pub/Sub. Le BigQuery Data Transfer Service automatise les imports planifiés depuis les applications SaaS.

```sql
-- BigQuery : Chargement de données depuis Cloud Storage
LOAD DATA INTO `project.dataset.events`
FROM FILES (
  format = 'PARQUET',
  uris = ['gs://bucket/events/*.parquet']
);
```

Redshift s'intègre étroitement avec S3 via la commande COPY, qui parallélise le chargement des données sur les nœuds du cluster. AWS Glue fournit un ETL géré, tandis que Redshift Spectrum interroge directement les données S3 sans chargement.

```sql
-- Redshift : Commande COPY avec paramètres optimaux
COPY events
FROM 's3://bucket/events/'
IAM_ROLE 'arn:aws:iam::123456789:role/RedshiftS3Access'
FORMAT AS PARQUET
COMPUPDATE ON
STATUPDATE ON;
```

Les deux plateformes supportent désormais le format de table [Apache Iceberg](https://iceberg.apache.org/) pour les lacs de données externes. BigQuery BigLake et Redshift Spectrum permettent une analytique unifiée entre l'entrepôt de données et le stockage du lac de données.

## Questions d'entretien : comparaison BigQuery vs Redshift

Les entretiens pour analystes de données testent fréquemment la compréhension des compromis entre entrepôts de données cloud. Ces questions apparaissent dans les postes nécessitant une expertise des plateformes cloud.

**Question 1 : Quand recommander BigQuery plutôt que Redshift ?**

Recommander BigQuery lorsque l'organisation a besoin d'une opération serverless sans gestion d'infrastructure, que la tarification à la requête convient aux charges de travail imprévisibles ou en pics, que la plateforme de données fonctionne déjà sur GCP, ou que les équipes ont besoin de résultats de requêtes immédiats sur des données à l'échelle du pétaoctet sans délais de provisionnement de cluster.

**Question 2 : Comment fonctionne l'allocation des slots dans BigQuery ?**

BigQuery alloue dynamiquement des slots (unités de capacité de calcul) aux requêtes. Les requêtes à la demande partagent un pool de 2 000 slots par projet. Chaque slot représente approximativement un CPU virtuel avec accès streaming à Colossus (stockage distribué). Les requêtes complexes nécessitant plus de parallélisme reçoivent proportionnellement plus de slots jusqu'à épuisement de la capacité disponible.

**Question 3 : Expliquer les styles de distribution Redshift et quand utiliser chacun.**

Redshift propose quatre styles de distribution :
- **KEY** : Distribue les lignes par hachage de la colonne spécifiée. Utiliser pour les grandes tables de faits jointes fréquemment sur cette colonne.
- **EVEN** : Distribue les lignes en round-robin sur les nœuds. Utiliser pour les tables sans schéma de jointure évident.
- **ALL** : Copie la table entière sur chaque nœud. Utiliser pour les petites tables de dimension jointes avec de grandes tables de faits.
- **AUTO** : Laisse Redshift choisir selon la taille de la table et les patterns de requêtes.

**Question 4 : Comment optimiser les coûts des requêtes dans BigQuery ?**

Optimiser les coûts BigQuery en partitionnant les tables sur les colonnes de dates fréquemment filtrées, en clusterisant sur les colonnes de filtrage à haute cardinalité, en évitant les requêtes SELECT *, en utilisant les fonctions d'agrégation approximatives (APPROX_COUNT_DISTINCT) pour l'analyse exploratoire, en matérialisant les résultats intermédiaires pour les calculs répétés, et en configurant des contrôles de coûts avec des quotas personnalisés.

**Question 5 : Quels outils de monitoring existent pour les performances Redshift ?**

Redshift fournit des tables et vues système pour le monitoring des performances : STL_QUERY journalise les détails d'exécution des requêtes, STL_WLM_QUERY affiche les statistiques de gestion de la charge de travail, SVL_QUERY_REPORT présente les métriques par étape, et les métriques CloudWatch suivent la santé au niveau du cluster. Les performances des requêtes peuvent se dégrader lorsque les opérations de vacuum sont en retard ou que les statistiques des tables deviennent obsolètes.

## Capacités de sécurité et conformité

Les deux plateformes supportent le chiffrement au niveau des colonnes, l'isolation VPC et la journalisation des audits. BigQuery applique un contrôle d'accès granulaire via [IAM et les politiques de sécurité au niveau des colonnes](https://cloud.google.com/bigquery/docs/column-level-security). Le masquage des données et la sécurité au niveau des lignes permettent les architectures multi-tenant.

Redshift offre des contrôles similaires via l'intégration IAM, le contrôle d'accès au niveau des colonnes et le masquage dynamique des données. La réplication des snapshots cross-région supporte les exigences de reprise après sinistre.

Les deux plateformes maintiennent les certifications de conformité SOC 1/2/3, ISO 27001, HIPAA et PCI DSS. La parité fonctionnelle existe pour la plupart des exigences de sécurité d'entreprise, ce qui fait que le choix dépend des relations existantes avec les fournisseurs cloud plutôt que des capacités de sécurité.

## Considérations de migration et approches hybrides

Migrer entre plateformes nécessite d'adresser les différences de dialecte SQL, les mappages de types de données et la réécriture des workflows ETL. Le service de migration BigQuery évalue les charges de travail Redshift et automatise la traduction SQL. AWS Database Migration Service gère la direction inverse.

De nombreuses organisations adoptent des stratégies hybrides, interrogeant les deux plateformes via des capacités de requêtes fédérées. BigQuery Omni s'exécute sur l'infrastructure AWS, permettant des requêtes BigQuery SQL contre des données S3. Le partage de données Redshift supporte la fédération de requêtes cross-account au sein d'AWS.

Les équipes d'analyse de données choisissent de plus en plus en fonction des investissements cloud existants plutôt que de la supériorité technique. Les deux plateformes continuent d'ajouter des fonctionnalités qui comblent les limitations historiques, réduisant l'écart fonctionnel.

## Conclusion

- BigQuery convient aux équipes privilégiant la simplicité serverless et les charges de travail variables avec facturation à la requête
- Redshift correspond aux organisations avec des requêtes prévisibles et volumineuses où la capacité provisionnée offre des avantages de coûts
- Les différences de syntaxe SQL nécessitent une attention particulière lors de la planification de migration et de la formation des équipes
- Les approches d'optimisation des performances diffèrent fondamentalement : BigQuery met l'accent sur le partitionnement et le clustering, Redshift requiert des clés de distribution et de tri
- Les questions d'entretien portent sur les compromis architecturaux, les stratégies d'optimisation des coûts et les techniques de réglage spécifiques à chaque plateforme
- Les capacités de sécurité et conformité sont comparables ; l'intégration à l'écosystème cloud guide souvent la sélection de la plateforme

---

Source: SharpSkill (https://sharpskill.dev), tech interview preparation for your real stack.
HTML version of this page: https://sharpskill.dev/fr/blog/data-analytics/bigquery-vs-redshift-comparison-interview-2026