A 10 TB initial load into Bigtable for ML features shows suboptimal read/write performance. You want to improve throughput while minimizing cost. What should you do?

The correct answer is to redefine the schema for even distribution across the row key space. Bigtable is designed for high throughput when reads and writes are spread across many tablets. A well-designed row key prevents hotspots and ensures parallel processing, which is crucial for performance with large datasets. Increasing cluster size (option 2) might help but is a costlier solution and doesn't address fundamental schema issues that cause hotspots. Redesigning to use a single hot row key (option 3) is detrimental, as it creates a severe hotspot, bottlenecking performance. Using sequential numeric row keys (option 4) also leads to hotspots, as all new writes would target the same tablet at the end of the key range, negating Bigtable's distributed nature.