Slashdot Mirror

The prerequisites to making the switch is first and most importantly having an appropriate business case for OLAP. The second prerequisite is that you've tried doing analytics in a traditional RDMS, perhaps jumped on to the NoSQL bandwagon, and you've failed at it (i.e. success for a little while but then your data eventually brings your queries down to its knees). Don't worry, failure isn't necessarily wrong, it's just you and your team needed the experience before you could make the next leap.

The risks are a knowledge jump in to an OLAP mindset from a traditional SQL mindset. Invest in you and your fellow developer's knowledge. Push back on management and sales when they want more immediate results and let them know that it will take 3-5 months to replace your current system. Do your proper technology evaluations. Learn FoodMart and Adventureworks and let them guide you down the path of good fact and dimension design. Don't snub your nose at Microsoft as they absorbed the company in the 80's that basically pioneered this stuff and made billions, but also don't take their stuff too literally as there are several products out there and some that do things better.

Read The Data Warehouse Toolkit thoroughly and practice using Mondrian which is an open source Java OLAP engine that can sit on top of PostgreSQL, MySQL, and others. Find a good ETL tool rather than trying to write your own at first and don't be afraid to force your internal users to use this tool to create their facts. Don't worry if you don't get it the first time, but keep trying and keep discussing with your fellow developers as it takes a team to work out all the kinks. Later on you'll probably end up seeing how you did things wrong, but hopefully you can get most things right in the beginning.

It's unfortunate but experience tells us that unless you sweeten the deal with extras like documentation, configuration/monitoring/EE software, repositories and the like, very few companies would buy anything. That experience is contrary to what I once believed.

So you can complain that you can't get your hands on nice documentation, the dashboard designer or the console, all part of the enterprise edition. However, when you really compare it to closed source software it's still a lot cheaper. This analyst report shows the difference: http://www.pentaho.com/lower_bi_costs/ Heck, you can get all that for free for 30 days to test-drive things.

The lack of consultants *is* a problem. However, there's Pentaho related work to be found out there and with 2 Pentaho books out and a third coming out in September I'm sure the problem is short-lived.

I'm going to expand on this one a bit. When it said data integration, I immediately found out that ETL might be Extract, transform, load. The only reason I know this is because I work for a TLA type company. Kettle seems to be the name of something that already has a name, "Pentaho Data Integration". I'm not sure why it has two names. It is also part of the Pentaho BI suite.

A good review would give us a link to this tool, so we can figure out if the book is even relevant. Otherwise the assumption is that everyone knows what it is an everyone is using it. http://kettle.pentaho.org/ There's a FAQ which deals with usage, not what it's about, and no overview. So despite finding the website myself I still have no idea what this thing does. Does it solve the problem of exporting data from MS SQL Server and re-loading it somewhere else? Cos that's what I need.

A good review would also indicate if it's a free and/or open source tool, so we can decide if we're even interested in the tool, let alone the book. The source is available and hosted on sourceforge, so that answers that. But there is a separate link under Products for PDI, with links to Buy. Is this a poor attempt at a slashvertisement? Why would I use kettle instead of PDI? Is there a difference? http://www.pentaho.com/products/data_integration/

A good review would also identify the audience of the book, letting people know who might use it. It's a datbase tool - if I'm a Microsoft shop would I have any interest in reading about this?

Pentaho rules them all :)

Pentaho's code is funny. Check the 158 undocumented classes all called "Messages". http://javadoc.pentaho.com/kettle/index.html Or references in the code to previous clients. And the sheer amount of constructor of some classes (most of them of type String). Or classes (lots) with 6,000 lines (check TransMeta.java). My brain rots with the stupid amount of code they use to do some things. And remove System.outs already wtf!

However, it works.

Some may call "Business Intelligence" an oxymoron, the open source project Mondrian is nicely packaged under http://www.pentaho.com/ (added ETL, scheduler, portal, and presentations are written in a language the audience would expect it). The open-source analytic engine called Mondrian is quite good, can serve XMLA (hint: MS Analytic Services). With little time and luck, it might become worthy competitor to Cognos & Business Objects & MSAS.

Ultimately, the suitability of the software depends on your requirements, doesn't it? Do you require source? Do you require a lower cost solution? Do you require support? These are common reasons to evaluate open software replacements for commercial offerings. Chances are you won't find an open source solution that will match the features, functions and support of the commercial offerings available. This, I suspect, will change in time with projects like BIRT http://www.actuate.com/birt and companies like MARVELit http://www.marvelit.com/ and Pentaho http://www.pentaho.com/ adding functions, features and support.
Highlight your reporting requirements and I suspect the /.ers can give you a better answer than calling Cognos. :)