Excellent.

When I first came across Palo, I was quite happy to see it a “good enough” alternative to the established OLAP tools. Sort of like the dog who can ride a bike, not so much how well the dog could ride but that the dog could ride at all.

No more. Palo is now a serious contender and from what I understand of future plans for the product, going to get even more capable.

We just need more people out there evangelising it, it’s undoubtedly the best kept secret in BI today.

Tom

Thanks again, I’ll do some more playing.
Last night I re-built Biker in TM1 9.4 (for interest 81,092,880,394,240 cells with <150,000 data points – nice and sparse) for a quick sparsity test.

A simple Currency calc (as above) would easily kill a bad sparsity handling OLAP but Palo and TM1 performed equally well – sub second response for a top level roll-up of the calculated member.

Next I’ll extend the TM1 model to try and get the response times to something I can actually measure and try the same with Palo – suggestions welcome!

Jason.

For that you’ll need the PALO.MARKER function

['EuroValue'] = N: PALO.MARKER (”Cube1″..) * PALO.DATA (”Currency”..)

..you can also mark PALO.DATA expressions by appending @PALO.MARKER. You’ll need this if source dimensions require functional modification (like SUBSTR for example) as MARKER parameters can only be static constants or variables …

['EuroValue'] = N: PALO.DATA (”Cube1″..)@PALO.MARKER (”Cube1″..)* PALO.DATA (”Currency”..)

Tom

I.E. ['EuroValue'] = N: PALO.DATA (“Cube1″..) * PALO.DATA (“Currency”..)

It’s possible that this isn’t the best way to build in Palo, but I’m comparing to TM1 where ‘feeders’ are often pushed from a source cube to a calculation cube.

Make sure you use “markers” otherwise it will result in a mass calculation.

i.e.

rather than

['EuroValue'] = N:['Units'] * ['EuroRate']

use.

['EuroValue'] = N:[['Units']] * ['EuroRate']

this will only calculate where Units are set.

Tom

In my case, what I’m evaluating in Palo is the handling of sparse data and rules/calcs.

I’ve added a duplicate cube in ‘Biker’ to the orders cube that multiplies the Units measure (at N:) by a notional currency value – simulating a currency translation. This -could- result in a mass calculation of every cell in the cube unless the sparsity is handled and it only calcs those cells with data in.

I’m waiting for the results as I read this, but it’s looking slow so far…

Excellent news, looking forward to June 25th.

@Andreas

I’ve seen it, I’m the “gleesoto” who raised the question

I still think you are going to have to allow for drill-through from consolidated coordinates, forcing users (who undoubtedly will be comparing the experience to Excel Pivot tables) to drill down to the base level of every single dimension is (a) unnecessary and (b) a huge inconvenience to the user.

Yes, such a drill-through might occasionally return a result-set of 100s of thousands, but that could be protected against. The argument that the required indexes on the drill-through “fact table” would slow down the load process could be addressed by using a faster database (SQLite!!!) and/or using an intermediate temp table during load (good idea anyway, allow for ETL process to happen, while drill-through functionality continues), then transfer to a “latest version” table, batch build indexes, finally point users to latest version. (This would also of course require Palo database versioning as well).

Nevertheless, as I’ve said before, the ETL Server is impressive. Keep up the good work.

Tom

Andreas,
Palo Team

Vlado,
Palo Team