1000 sensors emit one metric per sensor per second with timestamps. You already have 1 TB and will grow ~1 GB/day. You need millisecond reads for a single sensor+timestamp and daily complex analytic queries with joins. How should you store this data?

The correct option leverages Bigtable for its low-latency, millisecond-level reads for specific sensor data, which is ideal for time-series data when the row key is designed correctly (sensor ID + timestamp). Bigtable's high throughput also handles the incoming 1000 metrics/second. The daily export to BigQuery enables complex analytical queries and joins on the aggregated data, as BigQuery is optimized for large-scale analytics. Storing all data directly in BigQuery with a concatenated primary key would be less efficient for single-row lookups due to BigQuery's columnar storage optimized for analytical queries, not transactional point reads. Using metric as a primary key is incorrect because metrics are not unique identifiers. Concatenating sensor ID and metric for a Bigtable row key is also incorrect as it doesn't provide a unique, time-ordered key for individual sensor readings.