You currently use a SQL-based tool to visualize your data stored in BigQuery. The data visualizations require the use of outer joins and analytic functions. Visualizations must be based on data that…

Question

Options

• ACreate materialized views with the allow_non_incremental_definition option set to true for the visualization queries. Specify the max_staleness parameter to 4
• BCreate views for the visualization queries. Reference the views in the data visualization tool.
• CCreate a Cloud Function instance to export the visualization query results as parquet files to a Cloud Storage bucket. Use Cloud Scheduler to trigger the Cloud
• DCreate materialized views for the visualization queries. Use the incremental updates capability of BigQuery materialized views to handle changed data

• A
  82% (18)
• B
  5% (1)
• C
  9% (2)
• D
  5% (1)

Explanation

Option A is correct because BigQuery materialized views pre-compute and cache query results, directly addressing the slow query performance. Setting allow_non_incremental_definition=true is required when the query uses outer joins or analytic functions - features incompatible with incremental refresh - and the max_staleness parameter (set to 4 hours) tells BigQuery to serve cached results as long as they aren't older than the business-required threshold, satisfying both the freshness and performance constraints with minimal pipeline maintenance.

Option B fails because regular views are just saved SQL - they execute fully at runtime and provide zero performance improvement over running the query directly.

Option D fails because standard BigQuery incremental materialized views do not support outer joins or analytic functions; using them here would either error or require rewriting the queries, making this option incompatible with the stated requirements.

Option C fails because exporting to Parquet via Cloud Functions + Cloud Scheduler introduces a multi-service pipeline that maximizes maintenance overhead - the opposite of what the question asks for.

Memory tip: Think of allow_non_incremental_definition as the "unlock switch" for complex SQL in materialized views, and max_staleness as your "freshness budget" - whenever a question mentions a tolerated data age and complex joins/analytics, these two parameters working together is the answer.

No community discussion yet for this question.