多年后再思考MOLAP、HOLAP和ROLAP

ROLAP(relational OLAP)，明细数据、聚合后的数据都保存在关系型的数据库中。这种方式查询效率最低，每次查询都需要计算，效率高不高完全靠数据库。数据库需要持续调优。

HOLAP(hybrid OLAP)，明细数据保留在关系型数据库的事实表中，但是聚合后的数据保存在cube中。

MOLAP(multidimensional OLAP)，将明细数据和聚合后的数据均保存在cube中，在查询性能上有很大提高，其实就是空间换时间。需要额外购买产品，而且会而外增加管理维护成本。

我们原来在某大行里面试过多次Cube，虽然都知道MOLAP效率快，但是因为早期版本（现在不知道是否改善）权限、数据刷新、模型不稳定维度经常变化以及产品功能原因，屡试屡败。我们最终方案是ROLAP，采用greenplum搭建了128台机器的集群作为访问数据库，底层全部存储明细数据，前端采用cognos query studio 作为自由拖拽。实现了灵活查询与效率之间的一个相互平衡和制约，查询效率不会太高，但是业务更关注的是能够出数据而不是效率本身，当然也感谢业务部门的包容。而且咨询过同业经验，基本都抛弃了CUBE，采用ROLAP。

基于明细数据的多维模型、雪花模型能够支持业务灵活用数的问题，但是性能问题是一大头痛的事情，ROLAP开发简单但是效率完全依靠数据库本身，当数据量到一定程度后很难保证性能，所以在模型之后又出现了大量为了解决性能而开发的报表物理表（宽表）。MOLAP固然能解决效率方面很多的问题，但是相对ROLAP也会带来产品本身的管理运维成本的增加，而且屡试屡败的经验确实留下了阴影。

套用一句话，我们要的是金融服务而不是银行，时至今日我们一年还有几次步入银行柜台，但是银行生意照样红火我们每天也离不开金融服务。其实不管是ROLAP还是MOLAP，我们要的是查询效率和业务期待之间的平衡，而不在乎后台的实现技术本身。是否有一种产品，既具备ROLAP开发设计、使用的灵活性，又能够很好解决查询效率问题？同时支持横向扩展，支持海量数据的大并发查询。