Ein Data Scientist hat ein BigQuery ML-Modell erstellt. Sie müssen Vorhersagen pro Benutzer über eine REST-API mit einer Latenz von <100 ms bereitstellen. Die Vorhersageabfrage lautet: SELECT predicted_label, user_id FROM ML.PREDICT(MODEL 'dataset.model', TABLE user_features). Wie sollten Sie die Bereitstellungspipeline aufbauen?

Die korrekte Option beschreibt eine Architektur, die die Leistungsanforderungen erfüllt. BigQuery ML.PREDICT ist für Batch-Vorhersagen optimiert und nicht für Einzelabfragen mit geringer Latenz. Durch das Ausführen der Vorhersageabfrage einmalig als Batch-Job mit Dataflow, das Speichern der Ergebnisse in Bigtable (einer NoSQL-Datenbank mit geringer Latenz) und das Abrufen der Vorhersagen pro Benutzer aus Bigtable kann die Anwendung die Latenzanforderung von <100 ms erfüllen. Die Option, eine WHERE-Klausel hinzuzufügen, ist ineffizient, da BigQuery für jede Anfrage eine vollständige Tabellenscan-ähnliche Operation durchführen müsste. Eine autorisierte Ansicht würde die Leistung nicht verbessern, da die zugrunde liegende Abfrage immer noch BigQuery ML.PREDICT ist. Ein Dataflow-Job, der BigQueryIO verwendet, um die Abfrage auszuführen und Ergebnisse direkt zurückzugeben, würde immer noch die Latenz von BigQuery ML.PREDICT erben und die Anforderung nicht erfüllen.