You need to look at BigQuery data from a specific table multiple times a day. The underlying table you are querying is several petabytes in size, but you want to filter your data and provide simple aggregations to downstream users. You want to run queries faster and get up-to-date insights quicker. What should you do?

A is not correct because running a scheduled query that is identical to the existing query won’t really improve anything. You could try to make sure that the scheduled queries are run before the downstream consumer needs it, but this is very rigid and inflexible because from the scenario above we don’t know the exact times the data will be needed. Additionally, running a scheduled query on PBs of data is not very performant, and updates would only occur when queries are run. B is not correct because since query caching is, in theory, already enabled, this would not speed up the query. C is not correct because while this is a way to optimize your queries, from the problem statement we have no indication that there are excess columns being brought in by the query. Taking a route that would eliminate data that may be necessary to end consumers is not the best option in this scenario. D is the correct option in this scenario. Materialized views are optimal for improving query performance if you frequently need to pre-aggregate, pre-filter, pre-join, and recluster data. Since we want to pre-filter PBs of data and take advantage of the performance and incremental refresh of materialized views, this is the best option. Additionally, materialized views will be updated whenever there are changes to the source table, providing fresh data.