A shipping company has live package-tracking data that is sent to an Apache Kafka stream in real time. This is then loaded into BigQuery. Analysts in your company want to query the tracking data in…

Question

Options

• ARe-create the table using data partitioning on the package delivery date.
• BImplement clustering in BigQuery on the package-tracking ID column.
• CImplement clustering in BigQuery on the ingest date column.
• DTier older data onto Cloud Storage files and create a BigQuery table using Cloud Storage as an external data source.

• A
  14% (4)
• B
  75% (21)
• C
  7% (2)
• D
  4% (1)

Explanation

Clustering on the package-tracking ID (option B) is correct because analysts query the lifecycle of individual packages, meaning their queries filter and aggregate by package ID. Clustering physically co-locates rows with the same tracking ID on disk, so BigQuery scans far less data per query - directly addressing the growing processing time.

Option A is wrong because switching the partition column to delivery date is a re-partitioning strategy, not a clustering strategy, and the question explicitly asks for a clustered table; changing the partition key also wouldn't help analysts who query across a package's full geospatial journey.

Option C is wrong because clustering on ingest date essentially mirrors the existing partition scheme - it doesn't help analysts who filter by package ID or location, and clustering a column already used for partitioning provides little additional benefit.

Option D is wrong because offloading data to Cloud Storage as an external table increases query latency and loses BigQuery's native performance optimizations - the opposite of what's needed.

Memory tip: Think "partition = coarse time-based pruning; cluster = fine-grained column-based sorting within partitions." When the query workload targets a specific entity (a package, a user, a device), cluster on that entity's ID.

No community discussion yet for this question.