Copier des données entre vos propres tables dans BigQuery est devenu bien plus simple ces dernières années. Les méthodes restent toutefois nombreuses, chacune avec ses limites, ce qui peut semer la confusion. Je vais les passer en revue, avantages et inconvénients à l'appui.
Copier des données d'une région à l'autre était autrefois une opération complexe.
Copie via Storage
Il était possible de copier depuis BigQuery vers Cloud Storage, puis de revenir vers BigQuery dans l'autre région. Cette approche ajoute une étape supplémentaire et peut vite devenir coûteuse. Il fallait aussi tout orchestrer soi-même, par exemple avec Composer pour la planification, la mise en mémoire tampon et la parallélisation.
Copie de datasets
La fonctionnalité Dataset Copying a récemment beaucoup simplifié l'opération. Elle fonctionne entre régions et reste gratuite, hors coûts réseau. La planification et les fonctionnalités associées sont intégrées.
Copie intra-région avec `bq` _, l'API Job ou Copy Tables_
La copie au sein d'une même région a toujours été plus simple, et surtout gratuite. À l'intérieur d'une région, vous pouvez exécuter bq cp en ligne de commande, passer par l'API Job, ou utiliser Copy Tables dans la Cloud Console.
Requêtes planifiées
Scheduled Queries est une autre façon de copier des données au sein d'une région. Cette méthode n'est pas gratuite, mais elle est très souple : vous pouvez écrire n'importe quelle instruction SELECT pour insérer le résultat dans une table cible. Et comme son nom l'indique, la planification est intégrée.
Parmi les approches évoquées, seules bq cp et Scheduled Queries couvrent un cas d'usage courant : la sauvegarde incrémentielle quotidienne d'une table partitionnée par date d'ingestion. Elles sont les seules à pouvoir copier uniquement la partition de la veille et à la préserver en tant que partition dans la table cible.
Voici vos options résumées dans un tableau :