Forum Discussion
Power BI and Data Warehousing strategy
Thanks smoupre, that's helpful.
My thinking has been similar so far - ETL data from business applications into a SQL Server/Warehouse and plug both SSRS/Power BI into this new data store/warehouse.
However, I started to wonder how redundant this step is if Power BI itself can just ETL data from multiple data sources too and then these Power BI files can be made available as sources for other users/Power BI reports?
Preferably I'd prefer to centralise OLAP/tabular-based reporting models in SSAS (making these models available to many people) but (it looks like) I'd need to invest in an Azure virtual machine on top of an Azure SQL Server/data warehouse to model these in Azure - whereas this functionality is native (and therefore ~free) to Power BI.
As usual with microsoft, it feels like alot of these products cannibalise each other!
Thanks,
pbix
Anonymous I just commented on a simliar thread today, but I think one of things you gloss over here is that a large scale implementation is going to have different concerns than something that can be thrown together in Power BI for a small company/implementation.
The cross functionality between products is great, because the cost of entry is low, but that doesn't mean that because the functionality is there that it fits the needs of all organizations.
Is the Desktop tool great because it can do alot and offers that capabilities to model/mash up data? "Yes"
Because it can do these things would I create a large scale BI implementation in the Desktop? "No"
Some of the major differences are:
No size limit in SSAS solution as opposed to 250mb in Desktop file
Backup / recovery / version control ( all features that can be leveraged in a full SQL DW, SSAS, TFS solution)
Having an entire model and all logic in a Desktop file (which has shown can randomly corrupt) is not a good choice
Just my 2cents.
- Anonymous10 years agoNot applicableThanks Eno, again that's helpful. Do you have the link to your other post? I'd be interested to read more of your thoughts on this.
Are you talking about anything specific when you mention different concerns for a large scale implementation? I think the points you make about resilience/recovery, size etc are key though - our customer database(s) contain over 500,000 client records so scalability is key here (though still a shame that we need to buy additional functionality in Azure to use SSAS!).
Are you aware of any Microsoft documentation that outlines strengths/weaknesses of Power BI Vs traditional server/ data warehouse technologies?
Thanks
Pbix- Anonymous10 years agoNot applicable
Anonymous This is the other thread I was refrencing. The "concerns" I pretty much list out in the differences of my previous post. Size limitations, speed, version control, backup, scalable, re-usable - are all factors I think of when implementing larger solutions.
I'm not aware of any specific documentation, but I don't think Power BI is meant to replace those technologies. I think it is an offering that allows individuals, and small and mid-size companies to get analytics in front of themselves like never before. Traditional server/warehouse/SSAS, or some flavor of that, is still advisable for larger scale implementations for all of the reasons I list above.
- John_D10 years agoFrequent Visitor
I'm very new to Power BI, so I may be missing a technique here, but it seems to me that Power BI is great at aggregating raw data, and drilling through it, but once the source data has been pre-aggregated, I've found that difficulties can arise (like I say, maybe I'm missing a technique).
If the source data has already been averaged (as it has in my case), then you can't just let Power BI combine let's say team-level averages to get a department-level average, because the team sizes may differ significantly. We already have the department-level figures in our source data, but there doesn't seem to be a simple way of conveying the department-team hierarchy to Power BI, in order to drill up and down it.
Is this something to be considered when sourcing data from a data warehouse, or is there a way of dealing with this that I haven't encountered?
Cheers
John