GCP operators (BigQuery, GCS, Dataflow) in Apache Airflow - Time & Space Complexity

Time Complexity: GCP operators (BigQuery, GCS, Dataflow)

O(n)

Understanding Time Complexity

When using GCP operators in Airflow, it's important to understand how the number of tasks and API calls grows as you handle more data or jobs.

We want to know how the work done by these operators changes when the input size changes.

Scenario Under Consideration

Analyze the time complexity of the following operation sequence.

from airflow import DAG
from airflow.utils.dates import days_ago
from airflow.providers.google.cloud.operators.bigquery import BigQueryInsertJobOperator
from airflow.providers.google.cloud.operators.gcs import GCSListObjectsOperator
from airflow.providers.google.cloud.operators.dataflow import DataflowStartFlexTemplateOperator

with DAG('gcp_data_pipeline', start_date=days_ago(1)) as dag:
    list_files = GCSListObjectsOperator(bucket='my-bucket')
    for file in list_files.output:
        start_dataflow = DataflowStartFlexTemplateOperator(
            job_name=f'dataflow-job-{file}',
            template_path='gs://dataflow-templates/latest/flex',
            parameters={'inputFile': f'gs://my-bucket/{file}'}
        )
        run_bigquery = BigQueryInsertJobOperator(
            configuration={...}
        )

This sequence lists files in a GCS bucket, then for each file starts a Dataflow job and runs a BigQuery job.

Identify Repeating Operations

Identify the API calls, resource provisioning, data transfers that repeat.

• Primary operation: Starting a Dataflow job and running a BigQuery job for each file.
• How many times: Once per file found in the GCS bucket.

How Execution Grows With Input

As the number of files in the bucket increases, the number of Dataflow and BigQuery jobs started grows the same way.

Input Size (n)	Approx. Api Calls/Operations
10	About 10 Dataflow + 10 BigQuery jobs
100	About 100 Dataflow + 100 BigQuery jobs
1000	About 1000 Dataflow + 1000 BigQuery jobs

Pattern observation: The number of operations grows directly with the number of files.

Final Time Complexity

Time Complexity: O(n)

This means the work grows linearly with the number of files processed.

Common Mistake

[X] Wrong: "Starting one Dataflow job can handle all files at once, so the number of files doesn't affect the number of jobs."

[OK] Correct: In this setup, each file triggers its own Dataflow and BigQuery job, so more files mean more jobs and API calls.

Interview Connect

Understanding how cloud operator tasks scale with input size helps you design efficient pipelines and explain your reasoning clearly in discussions.

Self-Check

"What if we changed the pipeline to batch all files into a single Dataflow job? How would the time complexity change?"

Practice

1. What is the main purpose of GCP operators in Airflow when working with BigQuery, GCS, and Dataflow?

easy

A. To create virtual machines in Google Cloud

B. To manually write SQL queries for BigQuery

C. To replace Google Cloud Console for all cloud services

D. To automate and manage cloud tasks like queries, storage, and data processing

Solution

1. Step 1: Understand the role of GCP operators in Airflow

   GCP operators are designed to automate cloud tasks such as running queries in BigQuery, managing files in GCS, and launching Dataflow jobs.

2. Step 2: Identify the correct purpose among options

   Only To automate and manage cloud tasks like queries, storage, and data processing correctly describes automation and management of cloud tasks, while others describe unrelated or manual tasks.

3. Final Answer:

   To automate and manage cloud tasks like queries, storage, and data processing -> Option D

4. Quick Check:

   GCP operators automate cloud tasks = A [OK]

Hint: GCP operators automate cloud tasks, not manual or unrelated actions [OK]

Common Mistakes:

• Thinking GCP operators replace all Google Cloud Console functions
• Confusing manual SQL writing with automation
• Assuming GCP operators create virtual machines

2. Which of the following is the correct way to import the BigQuery operator in an Airflow DAG?

easy

A. from airflow.providers.google.cloud.operators.bigquery import BigQueryInsertJobOperator

B. import airflow.gcp.bigquery as bq

C. from airflow.operators.bigquery import BigQueryOperator

D. from google.cloud import bigquery

Solution

1. Step 1: Recall the correct import path for BigQuery operators in Airflow

   Airflow uses provider packages; the BigQuery operator is imported from airflow.providers.google.cloud.operators.bigquery.

2. Step 2: Match the correct operator class and import syntax

   from airflow.providers.google.cloud.operators.bigquery import BigQueryInsertJobOperator uses the correct module and operator class name. Options B and C use incorrect paths or outdated names. from google.cloud import bigquery imports the Google Cloud client library, not Airflow operator.

3. Final Answer:

   from airflow.providers.google.cloud.operators.bigquery import BigQueryInsertJobOperator -> Option A

4. Quick Check:

   Correct Airflow BigQuery import = D [OK]

Hint: Airflow GCP operators import from airflow.providers.google.cloud.operators [OK]

Common Mistakes:

• Using outdated or incorrect import paths
• Confusing Google Cloud client libraries with Airflow operators
• Importing non-existent modules

3. Given this Airflow task using BigQueryInsertJobOperator:

bigquery_task = BigQueryInsertJobOperator(
    task_id='run_query',
    configuration={
        'query': {
            'query': 'SELECT COUNT(*) FROM `my_dataset.my_table`',
            'useLegacySql': False
        }
    }
)

What will this task do when executed?

medium

A. Upload data from GCS to BigQuery

B. Create a new BigQuery table named my_table

C. Run a BigQuery SQL query that counts rows in my_dataset.my_table

D. Delete the table my_dataset.my_table

Solution

1. Step 1: Analyze the BigQueryInsertJobOperator configuration

   The configuration specifies a SQL query: 'SELECT COUNT(*) FROM `my_dataset.my_table`' with standard SQL enabled (useLegacySql: False).

2. Step 2: Determine the task action from the query

   The query counts rows in the specified table. The operator runs this query as a job in BigQuery.

3. Final Answer:

   Run a BigQuery SQL query that counts rows in my_dataset.my_table -> Option C

4. Quick Check:

   BigQueryInsertJobOperator runs SQL queries = A [OK]

Hint: Look at the 'query' field to see what SQL runs [OK]

Common Mistakes:

• Assuming it creates or deletes tables
• Confusing query execution with data upload
• Ignoring useLegacySql flag

4. You wrote this Airflow task to upload a file to GCS:

upload_task = GCSToBigQueryOperator(
    task_id='upload_to_gcs',
    bucket='my_bucket',
    source_objects=['data.csv'],
    destination_project_dataset_table='my_dataset.my_table'
)

What is wrong with this task?

medium

A. GCSToBigQueryOperator is used incorrectly to upload to GCS; it loads data from GCS to BigQuery

B. The bucket name must be omitted for this operator

C. source_objects should be a string, not a list

D. destination_project_dataset_table should be a GCS path

Solution

1. Step 1: Understand GCSToBigQueryOperator purpose

   This operator loads data from Google Cloud Storage (GCS) into BigQuery tables; it does not upload files to GCS.

2. Step 2: Identify the misuse in the task

   The task tries to upload a file to GCS using GCSToBigQueryOperator, which is incorrect. Uploading to GCS requires a different operator like GCSUploadOperator.

3. Final Answer:

   GCSToBigQueryOperator is used incorrectly to upload to GCS; it loads data from GCS to BigQuery -> Option A

4. Quick Check:

   GCSToBigQueryOperator loads data from GCS, not upload to GCS [OK]

Hint: Check operator purpose: GCSToBigQuery loads data, doesn't upload files [OK]

Common Mistakes:

• Using GCSToBigQueryOperator to upload files to GCS
• Confusing source_objects type
• Misunderstanding destination table format

5. You want to run a Dataflow job in Airflow that reads data from GCS, processes it, and writes results back to BigQuery. Which combination of operators is best to build this workflow?

hard

A. Use DataflowCreatePythonJobOperator to run the Dataflow job, and BigQueryInsertJobOperator to run SQL queries

B. Use DataflowCreatePythonJobOperator to run Dataflow job that reads/writes data, no separate BigQuery operator needed

C. Use DataflowCreateJavaJobOperator to run Dataflow, and GCSToBigQueryOperator to load data from GCS to BigQuery

D. Use GCSCreateBucketOperator to create buckets, then DataflowTemplatedJobStartOperator to run Dataflow

Solution

1. Step 1: Understand Dataflow job capabilities

   Dataflow jobs can read from GCS, process data, and write directly to BigQuery within the same job.

2. Step 2: Choose the operator that runs the Dataflow job end-to-end

   DataflowCreatePythonJobOperator runs Python Dataflow jobs that handle reading and writing data, so no separate BigQuery operator is needed for writing results.

3. Step 3: Evaluate other options

   Use DataflowCreatePythonJobOperator to run the Dataflow job, and BigQueryInsertJobOperator to run SQL queries runs Dataflow and BigQuery separately, which is unnecessary if Dataflow handles both. Use GCSCreateBucketOperator to create buckets, then DataflowTemplatedJobStartOperator to run Dataflow involves bucket creation, not relevant here. Use DataflowCreateJavaJobOperator to run Dataflow, and GCSToBigQueryOperator to load data from GCS to BigQuery uses Java job and GCSToBigQueryOperator, which is redundant.

4. Final Answer:

   Use DataflowCreatePythonJobOperator to run Dataflow job that reads/writes data, no separate BigQuery operator needed -> Option B

5. Quick Check:

   Dataflow job can read/write data itself = B [OK]

Hint: Dataflow jobs can handle GCS to BigQuery in one step [OK]

Common Mistakes:

• Running separate BigQuery operators unnecessarily
• Confusing Dataflow Java and Python operators
• Adding unrelated bucket creation tasks