Free PMLE flashcards

What model and Google Cloud product fit nightly univariate forecasts for thousands of series owned by a SQL-only team?

ARIMA models univariate temporal autocorrelation directly, and BigQuery ML lets a SQL-fluent team train and forecast many per-entity series in-place at low cost. Results stay in BigQuery, so dashboards read them without any Python serving pipeline or data movement.

For nightly univariate forecasts, why not train one deep neural network across all series and serve batch predictions via a managed endpoint?

A DNN adds Python and serving overhead a SQL-only team cannot maintain, and a single shared network ignores the per-series univariate structure that ARIMA captures directly. BigQuery ML ARIMA keeps the work in SQL and the results in the warehouse instead.

How do you tune Vertex AI endpoint autoscaling to absorb a sharp morning spike without paying for idle replicas overnight?

Keep a small minReplicaCount above zero so a few warm replicas answer the first burst with no cold-start delay, raise maxReplicaCount well above peak so the endpoint can scale out for the spike, and lower the target utilisation so the autoscaler adds replicas before the request queue saturates. Together these cover the spike economically without holding peak capacity through the quiet hours.

To remove cold-start timeouts on a spiky endpoint, just set minReplicaCount equal to peak so replicas are always provisioned.

Pinning the floor to peak does eliminate cold starts, but it keeps every peak replica running through idle periods, so you pay full peak cost overnight. A small warm floor plus a high ceiling and an earlier scale-out trigger absorbs the spike without holding peak capacity when traffic is near zero.

When model decay arrives unpredictably rather than on a calendar, what should trigger retraining?

Tie retraining to a monitored signal: fire it when prediction performance or input drift crosses a defined threshold. Because unpredictable concept drift cannot be anticipated by a clock, a threshold trigger fires exactly when the model genuinely degrades, conserving compute while keeping the model fresh only when accuracy actually falls.

Retraining every night guarantees the model is always fresh, so nightly scheduling is the safest policy.

Nightly scheduling sounds safer because data is fresh, but it retrains even when performance is stable, wasting compute on needless runs. When degradation is unpredictable, a performance or drift threshold fires only on genuine decay, which conserves compute without sacrificing freshness.

What engine fits a one-off, multi-terabyte join and window-aggregation backfill over Parquet in Cloud Storage when the team wants standard SQL and no clusters?

BigQuery. It is a serverless analytics engine that scales terabyte joins and window functions automatically, reads Parquet through external tables, and needs no provisioned cluster. Loading the Parquet as an external table lets a single SQL query join it against an existing dimension table, satisfying scale, SQL, and no-infrastructure constraints together.

For a one-off terabyte-scale Parquet backfill, I should provision a Dataproc Spark cluster and write the joins in Spark SQL.

Spark on Dataproc can express the same logic, but it forces you to size, run, and tear down a cluster. That contradicts a stated wish to avoid maintaining infrastructure for a one-off job. A serverless SQL engine like BigQuery handles the same scale with no cluster lifecycle to manage.