Any downside to multiple data sources based on same BQ view?

[lauratilton]

Is there any compelling reason why one Looker Studio solution is better than another, besides the fact that B might seem inefficient?

• Looker Studio Report A: Contains 5 charts, all using the same embedded Looker Studio data source, which is based on a BigQuery view. (In other words, when I go to Manage Added Data Sources I have one data source.)
• Looker Studio Report B: Contains 5 charts, each using a different embedded Looker Studio data source, all of which are based on the same BigQuery view. (In other words, when I go to Manage Added Data Sources I have five data sources.)

[dylantrose]

Hey Lauratilton,

I think it better generally to have one source assuming they are all the same source. I believe this, because:

• Bigquery is a serverless solution, so I don't believe there is a queue time for hitting the table. (unneeded extra work or inefficient as you put it.)
• Bigquery Engine will cache similar queries, so I would assume having multiple datasets doesn't have many upsides for loading times. (unneeded extra work or inefficient as you put it.)
• Datasets in looker studio that are separate will not share fields and parameters, meaning they have to be reproduced between datasets. (Creates extra work)
• Without setting custom field ids, it can be difficult and janky to make filters work cross charts. (Causes platform issues and inconsistency, but could be turned into a pro if grouping isn't enough for your use case.)
• The more data sources being accessed, the more lag it feels the page gets. (Especially for computers with resource and network constraints)

I noticed you specified embedded datasets, which can be its own debate and I'm curious as to why you specified this. I understand why someone may use them especially for privacy, however usually I prefer having one reusable dataset, as then we are able to keep those fields and parameters consistent across reports, which can be a serious pain point when you get report sprawl.

However, I think in general its highly use case dependent in the end and I could see one or the other.

Re-reading this, it seems you may be referencing 5 datasets that query the same bigquery dataset, which unless for the purposes of aggregation, I would prefer to use a service like DBT to do rather than the somewhat laggy in-built looker studio custom queries.

Just my opinions, would love to hear what you think.

Sincerely,

Dylan

[lauratilton]

Thanks for the insights. Essentially the reason for embedded data sources is that the elements using them are being copied and pasted between reports; and they need to bring the data and calculated fields with them when they travel. You mention custom field IDs, and yes, those are in place in all the data sources so cross filtering is not an issue. The 5 Looker Studio data sources in my theoretical example would all pull data from the same view that we built in BQ (there aren't any Looker Studio custom queries) but may have different source-level calculated fields (done in the Looker Studio data source).

In my use case, it's just a lot simpler to manage and implement if there are separate embedded data sources that use the same BQ view, so I'm just trying to figure out if there's any huge downside.

[dylantrose]

Ohh for organization? Thats really cool. Right now I usually just put A_ or B_ in front of my fields so I can click them quicker on bigger datasets, but for complicated charts with lots of source level calculated fields that would definitely be a nice QOL. I wish they would add datasource field folders, feel like that would solve so many organization issues with big datasources.