I was googling about "How does SSAS Multidimensional works?" but unfortunately couldn't get any related post.
Basically my question is how does it's engine works and why it works faster than the SQL server database. I actually want to know the backend of it's engine.
Please help me with the links or post to get the brief knowledge about it's evaluation context.
I've been working on SSAS tabular model since last around one year now I've got a projects where in I've to develop a Multidimensional Model.
Thanks in Advance.
Related
I'm assigned to design multidimensional cube in SSAS.
As I am very new to SSAS, and currently this is in analysis phase.
Just wanted to see , is there any standard process or guideline should I follow or any general questions should I prepare prior to cube designing?
One thing client specifically mentioned about the volume of data as
One service area has 3 million rows, 3 years of data
Does it mean, we should plan for partition strategy ? if yes then what are the things should I be looking ? one thing comes in my mind
what field should we consider to split the cube (am I heading in right direction ?)
What are the other factor should I consider during analysis ?
SSAS design is a large topic with different angels. If i were in your shoes, I'd google for "SSAS Design" or something along those lines to learn more. For example, here's a model chapter from a book provided by Microsoft themselves: https://www.microsoftpressstore.com/articles/article.aspx?p=2812063
I'd skip for partitioning at this stage. See how it performs first and tune it later if really necessary. Usually partitioning is done on some accumulating field , like a date, where old data is not processed daily and only the latest data (partition) is updated (processed). This of course depends on the data you're dealing with.
I hope you are doing well.
I'm working on a migration from an on premise ssas multidimensionnal cube to an azure analysis services tabular model.
Is there a way , a method or a tool to do it quickly and efficiently?
It's a large cube and it will take time to develop it from scratch with tabular model.
Thank you for your help
SSAS Multi Dimensional (MD) and Tabular are fundamentally different technologies, there is no quick method of converting one to the other, you will have to rebuild the model from scratch, and the measures etc.
Be aware that some of the things MD models are good at, like calculating up and down hierarchies, Tabular really struggles with. If the cube is fundamentally sound and has good performance, and you want to move it into the cloud service, use a VM in Azure, with SQL Server on it, it may work out cheaper that Azure AS, per month.
We know that over a decade ago with very limited compute power and storage available, the invention of multi-dimensional model (cube) was to solve the above problem, e.g.SSAS. However with recent cloud technology advancement, compute power and storage are cheap, I struggle to see the point of using multi-dimensional model (cube,) in a enterprise business analytic solution?
Anyone has any other thoughts to share please?
Thank you.
Per my opinion the greatest advantage of having SSAS model in an enterprise business analytic solution is that the end user can connect to it through Excel and just drag and drop measures and dimensions and create all kinds of useful reports with all kinds of calculations that are built in the cube (year to date, rolling 12, etc...), and without this model, they will have to rely on relational database to create much of complicated SQL calculations on their own, and first of all they will have to know SQL in details to do this, so they will probably have to rely on some kind of IT stuff to help them on daily basis to do this.
In SSAS, besides multidimensional there is also a tabular model, but the answer would be the same.
I'm considering migrating a database from SQL server to PostgreSQL.
The proposed new Postges Database will have a slightly different design to the old SQL server model.
I heard about model transformation languages and thought they might be worth considering for this task.
I have used TEFKAT to a limited extent some years ago, but it did not strike me as being mature enough for this task (although that was many years ago).
But there are other options available like ATLAS, which I have not used yet.
Are there any model transformation languages out there that would be suitable?
Or is this whole model transformation stuff the wrong way to go about this?
I'm a few months into developing a reporting solution. Currently I am loading a relational data warehouse (Fact and Dimension tables) using SSIS. SSAS cubes and dimensions are then created from the relational Data warehouse. I then use SSRS to build reports using MDX queries.
The problem I have is that things are starting to get rather complicated trying to understand how multidimensional modelling works as well as MDX and cubes. Since the organization it's being designed for is rather small, I'm thinking that I should re-evaluate my approach.
I think maybe I should just eliminate SSAS from the picture and simply create reports that report directly off the relational data warehouse using SQL queries. The relational data warehouse could still be loaded nightly to allow up to date data for reporting.
I'm just wondering if that would be a good idea considering I'm not very experienced with data warehousing and SSAS. Also I wanted to know if keeping my relational data warehouse in dimension and fact tables would still work with SQL queries or would I need to redesign the tables. I don't want to make the decision to eliminate SSAS if that will end up causing more headaches or issues.
The reports will not include complicated calculations besides row counts and YTD percentages. For example "How many callers were male?" and "How many callers called for Product A?" Which are then broken down by month.
Any comments or suggestion are much appreciated cause I'm starting to feel rather frustrated with trying get SSAS cubes developed properly.
I was in a similar situation at my company. I had never used SSAS, and I was asked to do research on the benefits of using cubes to do some reporting. It was a pretty steep learning curve because my background is in development not data and reporting. SSAS is most useful when aggregate queries on a relational database are time consuming and if reports need to be broken down into hierarchies that an analyst can use to better understand the state of the business. Since SSAS stores aggregate info, queries of that nature are very quick. If your organization's data is small, the relational queries might be quick enough that you don't really need the benefit of storing aggregates.
Also you need to take into consideration the maintainability of using SSAS. If you're having trouble figuring out SSAS and MDX then how easy of a time will others? I tried to explain an MDX query I wrote to my boss who is experienced with SQL, but it's really quite different from relational queries. How easy is it going to be to add more complex reports?
A benefit to using SSAS is it can put the analyst in control of the report. Second, there are great tools and support. Finally, it's pretty easy to deploy and connect.
You can remove SSAS from your architecture yes because all the results you can get from an MDX query to SSAS, you can get from a T-SQL query to your datawarehouse because the cube was built reading data from the DW. BUT, bear in mind the following: the main advantage on an OLAP cube, in my point of view, are aggregations.
Very simple explanation: lets say you have a fact table called orders with 1 million orders per month. If you want to know how much you sold on that month, using sql you need to read row by row and sum the value to produce the total. That's like 1 million reads on your DB. If you have a cube, with the propper agrregations configured, you can have that value pre-calculated and pre-stored on your cube so if you need to know how much you sold on a month, you will have only one read to your cube.
Its a matter of analyse your situation, if you have a small cube, maybe aggregations are not necessary and you cna do fine with SQL, but depending on the situation, they can be very helpfull