大数据之Kylin入门——第四章Kylin之cube构建算法

第三章中步骤4中的多维度构建cube其实非常巧妙，不得不佩服最开始想出这些算法的人真的非常聪明，算法不复杂但非常巧妙。

cube的构建算法有两种。早期的是逐层构建算法，后来改进之后又有了快速构建算法。

 

1.逐层构建算法

如图所示，数据总共有4维，全量的数据从下往上构建而不是从上往下构建。这是为什么了？因为从4维表能得到3维表，从3维表能得到2维表，这样就节省了很多运算。不用每次都从4维表计算。如果从上往下构建。每次都必须使用全量数据来构建。

全量数据构建三维cube，总共只需要一个mapreduce。从三维到二维cube也只需要一个mapreduce。我一开始怎么也想不通，为什么全量数据构建三维cube不是3个mapreduce。如果让我来做，我会每一种情况写一个sql，三种情况所以需要3个mapreduce。

大神就是想的不一样。。如下图MR-1所示，全量数据构建三维cube，进行一个map，就把一条数据分成了3类（一条数据每个维度降一维就变成了3条），然后再shuffle分发之后，最后对所有数据reduce聚合即可，总共只有一个mapreduce。如图MR-2，从二维到一维也是同理。为啥我就是死脑筋了，想不到还可以这么做。。。

每一轮的计算都是一个MapReduce任务，且串行执行；一个N维的Cube，至少需要N次MapReduce Job。

现在来说说这个算法的缺点。

1.如果是个100维的cube，那就需要100个mapreduce了，对集群的资源消耗特别大。

2.map阶段未做任何处理，聚合操作都是在reduce阶段完成的，shuffle压力大导致效率低下。

3.所有操作都是在hdfs上完成的，对hdfs读写操作多，效率低下。

 

2.快速构建算法

逐层构建算法效率还是很低，所以这里就有了快速构建算法，真的是跪了，已经觉得逐层构建不错了，没想到还有更好的，这些人是咋想出来的。。

回想一下逐层构建算法哪里有缺陷了或者说哪里感觉没有充分利用上了，就是map阶段。map阶段它只是做了数据拆分和分发，并没有做任何统计计算。我们平常做shuffle优化的时候不是就尽可能把reduce端的聚合放在map端进行聚合吗，快速构建算法也是这样。在map阶段每个文件构建好每个文件的cube（所有维度都构建好），reduce端把所有map端的文件进行聚合就可以了。现在看来，是不是觉得kylin的cube构建算法不复杂但是的确很巧妙了。