It seems that the article makes a categorical error, arguing that OLAP cubes were replaced by columnar data stores. I always understood OLAP cube as an abstract concept that can have various technical implementations, while column store is a kind of optimization in that technical implementation.
The article is generalizing, as such articles do. Necessarily so. There are always exceptions. It is unfortunate that when such articles appear the dominant response is nitpicking or exception pointing (I'd say 80%+ of the comments thus far).
In the overwhelming bulk of cases firms have a column store that they generate cubes from. OLAP is run against the cubes. Some put warehousing in between, though that changes little. Cubes are fundamentally a form of caching because historically it was prohibitive to do large-scale aggregations in real-time. With massive memory servers, and more importantly flash storage that improves aggregate performance at the enterprise scale by many magnitudes -- a million times faster analysis and aggregation is entirely possible -- that historic caching step becomes a hindrance and maintenance/timeliness issue. So it's discarded.
That's all 100% true. It has happened in many orgs.
I went back to read most of the academic literature on OLAP cubes while working on this piece (which, unlike vendor marketing, is used with consistency since the early 80s). OLAP cubes or data cubes refer specifically to a data structure. An OLAP cube may be materialized from a column store, but a column store isn't an OLAP cube.
The proof of this? Go to any serious columnar database provider and search for the words 'OLAP cube'. You will find that they are careful to say 'OLAP workload', but not 'OLAP cube' — because in the strict definition of the term, an OLAP cube or data cube is an entirely different architecture.
Relevant sources are included at the bottom of the piece.
