Swapping Partitions in BigQuery

Senior Data Engineer • Contractor / Freelancer • GCP & AWS Certified
Search for a command to run...

Senior Data Engineer • Contractor / Freelancer • GCP & AWS Certified
No comments yet. Be the first to comment.
Practical guides to making BigQuery queries faster and cheaper — partitioning, clustering, search indexes, time travel, cost optimization, and query tuning strategies.
It should be no surprise that understanding your data is very important when working with it. The initial step in my approach to a new dataset always involves examining the data closely. Although the Schema Tab reveals the data schema, to grasp the c...
Here's a useful Dataform concept: pre_operations and post_operations. As the name implies, these represent a set of actions that run before and after the main operation (table, view, or SQL operations

BigQuery has always been a SQL engine for tabular data. Object tables add an interesting twist to that. Instead of rows containing values, an object table gives you one row per file — pointing at da

Query your data lake with warehouse-grade security and performance — without moving a single file.

Ever run a heavy BigQuery SQL query, processed gigabytes of data — and then accidentally closed the tab or forgot to save the results? 😬 Don't re-run it. Your results are still there. BigQuery automa

You can use query parameters in BigQuery hashtag#SQL (now in the console as well!) — but how are they different from variables, and when should you use each? Both parameters and variables act as place

A few years back, when working on SQL Server projects, I often utilized the ALTER TABLE SWITCH partition between staging and target tables. This left me pondering—could a similar functionality be achieved in BigQuery? 🤔
BigQuery facilitates copying a partition to another table using the bq cp command:
bq cp -f 'project:dataset.source_table$your_partition' 'project:dataset.target_table$your_partition'
🧪 Example Scenario 🧪
Imagine a staging table, where we extract the delta from a source table (based on the last entry seen in the target table), and MERGE it into the target table.


Instead, we can craft a short script to copy delta partitions (new + changed, if any) into the target table, bypassing the need for MERGE altogether! This generates COPY jobs as opposed to QUERY jobs.
#!/bin/bash
# Check if the correct number of arguments is provided
if [[ "$#" -ne 2 ]]; then
echo "Usage: $0 <start_date> <end_date>"
exit 1
fi
# Define the project and dataset names
PROJECT="***********"
DATASET_SOURCE="learning.data_source_staging"
DATASET_DEST="learning.data_source"
# Assign start date and end date from input arguments
START_DATE=$1
END_DATE=$2
# Loop through the dates from START_DATE to END_DATE
for date in $(seq -w $START_DATE $END_DATE); do
# Echo a message indicating the partition being swapped
echo "Swapping partition $date"
# Run the bq cp statement
bq cp -f "${PROJECT}:${DATASET_SOURCE}\$$date" "${PROJECT}:${DATASET_DEST}\$$date"
done
Once this executes, we will have copied the partitions from the staging table to the target table using the bq cp command.

We can confirm that all the partitions have been loaded properly and see the list of COPY jobs in the job history tab.

Also, don’t forget—leveraging the INFORMATION_SCHEMA PARTITIONS view can assist in constructing even more advanced functionalities.
Found it useful? Subscribe to my Analytics newsletter at notjustsql.com.