Forum Discussion
Report Server data refresh options
PBIRS runs SSAS behind the scenes with a built in mechanism for scheduling data refreshes. Unless you need control over your tabular models or have other constraints (see below), then I'd drop your plan to host SSAS tabular and just use what PBIRS gives you with your reports running in "Import" mode.
Contrary to my advice, we have actually implemented our own SSAS Tabular instance in a similar architecture to what you've described. Because our finances are limited and we can only afford PBIRS under an SQL EE with SA licence for 4 cores only, we came to the conclusion that the server running PBIRS/SQLEE would not be fast enough to handle our usage requirements, so we implemented SSAS under our SQL Standard licence on an extremely fast server.
If money were no object, I would not have done this. I would of used PBIRS out of the box.
Thank you, that's useful.
What are the advantages of not using a dedicated Tabular SSAS?
We planned multiple reporst to share a data model.
Not sure if incremental/partitioned data refresh is possible in PBIRS hosted SSAS?
I also got an impression that SSAS tabular is easier to automatically manage and deploy for multiple environments.
Simplicity is a big advantage to not using dedicated SSAS.
There are also limitations within PBI when connecting directly to a dedicated SSAS - e.g. you're forced to create calculated columns and hierarchies within the SSAS model. The analysts on my team (fresh from their PBI training courses) can't stand this! They have to add columns to the SSAS model within SSDT, build the asdatabase, send it to infrastructure for deployment, then head back into PBI and refresh their data source. They find this cumbersome and want to work directly in PBI at all times.
Another reason for having a dedicated SSAS server (which I haven't mentioned before) could be if you need to scale SSAS/PBIRS differently.
Thanks again, this makes sense.