professional-cloud-data-engineer
Prepare and test your skills
Prepare and test your skills
Worked example. The correct answer is already marked and every option is explained below, so there is nothing to select here. To answer questions yourself, start the free trial.
Keep the momentum going with these hand-picked practice scenarios
Want more questions like this?
Get a free certification question every week.
Last updated
An analytics team is troubleshooting severe latency regressions in analytical aggregation queries running on a Cloud Spanner Enterprise instance. Operational transactions continue to write updates, while reporting queries scan millions of rows.
The team investigates the performance diagnostics and observes the following:
SPANNER_SYS.QUERY_STATS_TOP_* shows that the AVG_COLUMNAR_READ_SHARE metric for these queries is near 0%.SELECT *.Which actions should the team take to diagnose and mitigate this retrieval bottleneck?
Rewrite queries to select only the essential columns required for aggregation, and allow Spanner's background compaction to build and populate the columnar representation.
Configure an aggressive LIMIT clause on all aggregation queries and disable background compaction to conserve CPU utilization.
Add a non-storing secondary index on the aggregation columns and force an index scan using query hints to trigger the Cross Apply operator.
Export the data to Cloud Storage and use a manual Bigtable instance with HDD nodes to perform sequential row-key range scans.
Rewrite queries to select only the essential columns required for aggregation, and allow Spanner's background compaction to build and populate the columnar representation.
Cloud Spanner's columnar engine provides accelerated scan performance for analytical workloads on operational data by storing single-column runs across blocks instead of colocating full rows. When diagnosing queries using SPANNER_SYS.QUERY_STATS_TOP_* and the query execution plan, an AVG_COLUMNAR_READ_SHARE near 0% indicates that Spanner is falling back to scanning row-oriented PAX (Ressi) storage rather than columnar storage. Furthermore, a high-latency Table scan node confirms that the query is scan-bound.
SELECT * forces Spanner to retrieve every column in the schema. In columnar layouts, reading all columns diminishes columnar scan advantages because multiple individual column files must be scanned and reconstructed. Restricting projections to specific columns (e.g., SELECT customer_id, SUM(order_total)) allows Spanner to read strictly the necessary contiguous column blocks.AVG_COLUMNAR_READ_SHARE indicates the newly loaded or heavily churned data has not yet completed compaction into columnar runs. Allowing automatic compaction to complete will naturally raise the columnar read share and improve scan speed by up to 200x.Because the diagnostic metrics clearly show a scan-bound profile with unpopulated columnar blocks, pruning projection lists and letting background compaction finalize columnar structures aligns precisely with the database engine's architecture without introducing operational overhead.
Configure an aggressive LIMIT clause on all aggregation queries and disable background compaction to conserve CPU utilization.
Add a non-storing secondary index on the aggregation columns and force an index scan using query hints to trigger the Cross Apply operator.
Export the data to Cloud Storage and use a manual Bigtable instance with HDD nodes to perform sequential row-key range scans.