THE SQL Server Blog Spot on the Web

Welcome to - The SQL Server blog spot on the web Sign in | |
in Search

SQLBI - Marco Russo

Please visit the same blog at - comments are now disabled here but you can comment on the new blog (all blog posts available here are available there, too).
You can follow me on Twitter: @marcorus

Embed Analysis Services Tabular in your service or application #ssas #tabular

Since 2012 I have seen many companies adopting SQL Server Analysis Services Tabular as the analytical engine for their product or service. I think that this is still a fraction of the companies that might do the same choice. Why? Because…

The features already existing in Tabular might be enough to justify its adoption as analytical engine.

This short statements needs more explanations, so I wrote a longer article titles SSAS Tabular as Analytical Engine, which is available also as a downloadable PDF that can be read offline and shared by mail. There are many other companies that are looking for an analytical engine for their applications. I hope that the experiences I tried to share will help these companies to better evaluate whether Tabular could be a model good for their needs or not.

Have you made this choice? Have you considered (and maybe adopted) other products in one of the described scenarios?
Feedbacks are welcome!

Published Tuesday, September 9, 2014 10:35 AM by Marco Russo (SQLBI)
Filed under: ,



David Beavon said:

This is a common idea.  But I liked your long article.  In short it sounds like you are looking for a programmer's API that will allow an OLAP engine to be linked into any application (just like it was into Excel - via "PowerPivot").

The biggest problem with this idea (which I've been told) is that Microsoft can make money on Excel licenses, and they can make money on a back-end SQL service license, but they can't easily make money on a (.Net) programmer's API.  It is hard to monetize.

Here was my version of the idea and there are others on Connect that are similar.

Just because something makes sense to those of us who live in the real world doesn't mean it is appealing or profitable to Microsoft.  The conclusion that I finally came to was that any application that needs to embed an OLAP engine probably wants multi-dimensional benefits (per your matrix, especially good analytical query language and good data visualization), but can live without ultra-fast performance that you might get out of a back-end server.

I think an **open source** (gasp) solution (Pentaho / Mondrian) would be a much more appealing option for companies that might want to embed OLAP.  Open source software has a lot of advantages.  To name a few, it lends to better interoperability, easier troubleshooting, closer partnerships.  In my web browsing tonight, not only did I come across your article but I see on that Hitachi Data Systems is now acquiring Pentaho.  Apparently they see all the same opportunities that you do for embedding analytics.  There is tons of marketing information on that site to this effect.

I challenge you to take off your Microsoft T-shirt and give it a look!  (PS.  I'm still quite a bit upset with Microsoft for shutting down development on multidimensional.  I think it is five years and counting since we've seen anything new from them in this technology.  Maybe the original developers all retired.  I'd like to hear the inside story some day...)  

February 28, 2015 10:42 PM

Marco Russo (SQLBI) said:

David, I understand (and agree) on your points. I prefer to not enter into comparison about products/platforms, because my knowledge about the Microsoft one is so deeper than I would like to get the same depth before doing a comparison, and this would require too much time. Same thing about licensing comparison. I think that the general answer is "it depends" and I would consider the choice on a case-by-case scenario.

The main point about my article is that doing a comparison between Tabular and other engines, there are many reasons why certain applications might favor Tabular over Multidimensional, because it's easier to implement. In terms of development (and support), an open source solution could require a larger investment, and these companies oftentimes already have the MS license. But, as I said, "it depends".

I have a long list of tools/products that I would like to test, but it's hard to find the time to go deeper enough to be able to write anything that is not just a first impression, and it would not worth the effort.

By the way, all the companies I supported using Tabular as an analytical egnine had a critical requirement for performance. A simple semantic layer on top of SQL would not be enough, performance was critical in every single case (for the combination of volume of data and calculations required). But I see many companies not having this requirement, and many of them already implement alternative Technologies/products (QlikView and Pentaho are the most common in this case).

March 1, 2015 3:14 AM

David Beavon said:

Performance is a much easier problem to tackle these days than it used to be.  In fact, one of the main reasons "tabular" was even able to steal away so many of the projects that would have otherwise gone to "multidimensional" is because of the big tech-related changes that came after the heyday of MOLAP (ie. 64 bit machines with dozens of GB's and cheap SSD's).

In short, the applications where I would have liked to embed OLAP would have done just fine as a sematic layer over an "in-memory" database and/or one living on an SSD.  

Of course a "processing" stage would be needed to move the data from its larger original storage (conventional RDBMS).

March 1, 2015 10:01 AM
New Comments to this post are disabled

About Marco Russo (SQLBI)

Marco Russo is a consultant, writer and trainer specialized in Business Intelligence with Microsoft technologies. He runs the SQLBI.COM website, which is dedicated to distribute resources useful for BI developers, like Integration Services components, Analysis Services models, tools, technical information and so on. Marco is certified as MCT, MCDBA, MCSD.NET, MCSA, MCSE+I.

This Blog



Privacy Statement