Conversation

Replying to
I so wish this were true. When you push things to the extreme (you're dealing with PBs of high cardinality input data processed into complex metrics/pivots) materialized views on MPP DBs are no longer an option and you end up pushing your OLAP cubes into columnar storage instead!
1
Replying to and
Hm, I’m unsure if I understand that last clause — data from cubes into columnar storage? Most clients we see at Holistics do ok on MPP columnar data warehouses, without need for extraction into cubes. Your use case could differ though (and I’ll defer to you on that)
1
1
Replying to and
Can't go into specifics, but at a certain scale, a set of tables (even if columnar) can't be joined through a view to produce an OLAP-like analysis UI in a reasonable time. Instead, I am suggesting an ETL process that takes columnar raw data and produces columnar OLAP cubes.
1
2
Replying to and
So the way we get around this is that we persist the materialised views to a new table within the same warehouse. Most tools, Holistics included, allow you to schedule this materialisation+persistence.
1
At this point you may (rightly!) say “well, how is this different from scheduling cube materialisation?” But there are benefits to having it all in one tool: you can track the data lineage, edit metadata and notes for catalog purposes, etc.
1
Replying to and
No need to apologize, it's hard to discuss complex topics in 280 character chunks :) I think we're both saying the same thing. I am also suggesting persisting the cube views as columnar. Either way, since we'd still persist OLAP-like data, it's clear OLAP is not going away!
1
Show replies