A data scientist created a BigQuery ML model. You must serve per-user predictions via a REST API with <100 ms latency. The prediction query is: SELECT predicted_label, user_id FROM ML.PREDICT(MODEL 'dataset.model', TABLE user_features). How should you build the serving pipeline?

The correct answer is to use a Dataflow pipeline to pre-calculate and store predictions in Bigtable. BigQuery ML is optimized for batch predictions, and directly querying it for individual, low-latency requests (like a per-user API) would be inefficient and unlikely to meet the <100ms latency requirement due to BigQuery's query processing overhead. Bigtable is a low-latency NoSQL database ideal for serving individual records quickly. Dataflow can efficiently process the batch predictions from BigQuery ML and populate Bigtable. The application can then query Bigtable directly for fast, per-user predictions. Adding a WHERE clause to ML.PREDICT and granting BigQuery Data Viewer would still incur BigQuery's query latency for each API call, failing the latency requirement. Creating an authorized view would not change the underlying BigQuery query latency. A Dataflow job running the query and returning results directly would still involve BigQuery as the serving layer, which is not designed for low-latency point lookups.