nosql适合OLAP吗 ？

[开发运营者]

求指教：nosql适合OLAP吗 ？谢谢！

[dingybin]

使用OLAP有三个过程。一是定义一个立方体（定义CUBE），然后填充数据（打CUBE），最后查询数据（使用MDX或其他语言）。 定义立方体的时候可以设计一个XML的配置文件，通过这个文件来定义一个CUBE。需要的要素包括CUBE的名称，存储的HBASE的表名，维度信息，度量信息等，完善点的话可能还有权限信息和其他管理性内容。 然后就是打CUBE了。需要从关系数据库中将包含维度和度量的笛卡尔宽表通过SQOOP软件或者其他数据库提供的接口导入到HDFS上，并通过PIG或者HIVE来完成立方体的棱的计算。原始信息和计算后的信息填充到HBASE的表中供访问。当然另外一种可能的方法是计算不要放在Hadoop中，而是在数据库中做好，具体那种方式更加高效低成本也许需要放到实际的项目中才知道，但是我直观上认为在Hadoop上做更好，因为简单嘛。 最后是查询CUBE了。通过一个解释器将前台发来的MDX或其他查询语言进行翻译，然后通过API去HBASE数据库中取得对应的结果，最后返回。这个方式看起来简单，其实还是有一些需要考虑的。那就是是否所有的查询在之前都预先计算过了，如果是，那直接取得那一个单元格即可，如果没有，还需要将对应的维度的数据全部取出来，重新预计算一次，再返回。这个时候或许可以考虑将计算后的结果写会HBASE，供下次查询的时候使用。其实Mondrian的方法类似于此。到底哪些要预计算，哪些不要，则取决于需求，可以在设计立方体的时候制定，或者系统自动调整。 以最简单的两个维度一个度量来举例。具体的打CUBE的流程可能如下: 1、在事实表中，可能有如下数据： 时间 地域 收入 2009 北京 1W 2009 上海 2W 2010 北京 3W 2010 上海 4W 2、这些数据被按照代码的方式抽取到HDFS上，然后进行预先计算，第一层预计算添加了如下行 2009 ALL 3W 2010 ALL 7W ALL 北京 4W ALL 上海 6W 3、第二层预计算添加了如下行 ALL ALL 10W 4、由于只有两个维度，预计算结束，然后原始数据和两次预先计算后的数据一并录入到HBASE中，KEY为时间+地区，VALUE为收入。 在查询的时候按照进行返回，没有在WHERE条件中的维度用ALL代替就可以了，很简单的不是。如果没有预计算的，那么就需要返回所有满足条件的度量，然后自己聚合起来。 通过这样的方式将需要大量聚合的查询通过预计算的方式转移成了几乎单条的查询，可以充分利用HBASE低时延和高吞吐的能力。而预计算本省则通过Hadoop的MapReduce来实现高效处理，自己实现MR如果困难的话，也可以用PIG嘛，那个简单，搞个脚本就行，上面指出的一个开源软件似乎就是使用的PIG脚本生成器然后解释执行的。 只不过这是最简单的方法而已，如果需要考虑动态维度的话，恐怕是将共性维度作为KEY，然后再用一个COLUMN FAMILY来存动态的维度，对于动态维度的预计算也需要考虑，因为查询语言的翻译可能会根据CUBE的定义而变得复杂一些。具体的我还没有进行过仔细的思考。 最后在设计上，有一个细节需要考虑，我们可能会面临很多的度量，我们系统中的指标可能有成百上千。这些指标可能本身就是“稀疏”的。所以我们应该设计一个指标维度的维度，而仅保留两个度量即可，一可以累加的，二不可累加的。也就是增加一个KPI_NAME的维度，其中的值就是KPI_ID。这样可能更加简单一些。 通过上述的方法，在NOSQL数据库上可以构建一个提供指标库访问服务的OLAP系统。既可以直接为指标库服务，也可以提供标准的MDX服务，为原来那些前台软件的多维分析服务。