A connected vehicle platform ingests real-time telemetry from over 500,000 vehicles streaming diagnostic metrics at 1-second intervals. The data engineering team needs to design a high-throughput storage tier in Cloud Bigtable that satisfies the following requirements: Eliminate write hotspots across cluster tablets during peak driving hours. Support low-latency row range scans to retrieve historical telemetry for a specific vehicle over a designated time window. Maintain an instance configuration optimized specifically for query latency under high write volumes. Which row key pattern and cluster target should you implement?

Construct row keys formatted as `vehicle_id#timestamp` and configure cluster autoscaling to maintain a maximum CPU utilization target of 60%.: ### What This Solution Is This architecture uses a **composite row key** design (`vehicle_id#timestamp`) paired with latency-optimized cluster capacity targets to handle high-velocity time-series ingestion and range reads in **Cloud Bigtable**. ### How It Meets the Requirements - **Eliminate write hotspots**: Bigtable indexes data lexicographically by row key. Because vehicle identifiers are naturally distributed across the keyspace (e.g., pseudo-random strings or evenly distributed alphanumeric hashes), incoming writes from 500,000 distinct vehicles land simultaneously across different **tablets** and **nodes** rather than concentrating on a single tablet. - **Support efficient range scans**: Placing the timestamp after the `vehicle_id` ensures all chronological events for an individual vehicle are stored sequentially in contiguous rows. Client applications can perform high-speed **row-range scans** using a specific `vehicle_id` prefix and start/end timestamps. - **Optimize for query latency**: Setting the cluster's CPU utilization target to **60%** provides sufficient processing headroom to prevent queueing delays and keep request latencies predictably low under high write throughput. ### Key Advantages and Capabilities - **Even load distribution**: Distributes simultaneous write traffic evenly across all Bigtable cluster nodes. - **Optimized read performance**: Enables single-prefix contiguous row scans, which is the most performant read pattern in Bigtable. - **Built-in latency headroom**: Adheres to Google Cloud recommended operational ceilings (60% CPU and 60% storage utilization) when prioritizing low response latency over absolute throughput efficiency. - **Linear scalability**: Allows the cluster to dynamically scale out tablets and nodes seamlessly as vehicle fleet size expands. ### Why This Is Optimal Placing `vehicle_id` as the primary prefix avoids monotonically increasing key hot spots, while appending the timestamp enables fast sequential row-range retrieval. Sizing the cluster for 60% CPU utilization guarantees predictable sub-10ms response times for real-time diagnostic queries.

StudyCerts

Bigtable Time Series Rowkey Latency Optimization | professional-cloud-data-engineer | StudyCerts

Professional Cloud Data Engineer

professional-cloud-data-engineer

Advanced

Prepare and test your skills

Track Readiness

Set Exam Goal

Advanced

Prepare and test your skills

Track Readiness

Set Exam Goal

Bigtable Time Series Rowkey Latency Optimization

Section: Choosing managed services (e.g., BigQuery, BigLake, AlloyDB, Bigtable, Spanner, Cloud SQL, Cloud Storage, Firestore, Memorystore)

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.

A connected vehicle platform ingests real-time telemetry from over 500,000 vehicles streaming diagnostic metrics at 1-second intervals. The data engineering team needs to design a high-throughput storage tier in Cloud Bigtable that satisfies the following requirements:

Eliminate write hotspots across cluster tablets during peak driving hours.
Support low-latency row range scans to retrieve historical telemetry for a specific vehicle over a designated time window.
Maintain an instance configuration optimized specifically for query latency under high write volumes.

Which row key pattern and cluster target should you implement?

Construct row keys formatted as md5(vehicle_id#timestamp) and configure cluster autoscaling to maintain a maximum storage utilization target of 85%.

Construct row keys formatted as timestamp#vehicle_id and configure cluster autoscaling to maintain a maximum CPU utilization target of 90%.

Construct row keys formatted as vehicle_id with each metric stored in separate timestamped cells within a single row, and maintain a maximum CPU utilization target of 90%.

Construct row keys formatted as vehicle_id#timestamp and configure cluster autoscaling to maintain a maximum CPU utilization target of 60%.

Professional Cloud Data Engineer

Bigtable Time Series Rowkey Latency Optimization

Related questions