1.构建流程:
1.1创建中间表:
红色:维度
黄色:度量
1.2将中间表的数据均匀分配到不同的文件
比如中间表一共有1.6亿的左右的数据,计算处每个mapper大概有多少行,比如100万行,那么就会生成160个文件,这160个文件的数据行是均匀的。
其中DISTRIBUTE BY param,相当于将大表根据param分配成一个个小的表。比如这里就是根据160以内的随机值进行分配(存疑,求解答)。
1.3创建维度字典表:
如果存真实的字段值,可能数据量会很大,但是如果将字段值设置一个代替值,数据量就会大大减少。(度量没有)
1.4构建cube(执行select语句)
其中预聚合表中已经是字典表中的值了。
1.5 K-V如何替换字典表中的值
rowkey的前半部分是cuboid值,其中111代表三个维度都有,110代表地点分类的维度有,时间维度没有;
后半部分是纬度值:比如地点维度0是北京,1是上海,第一行就是000;
第三行没有分类维度,所有维度值就是上海和1月9号,就是1和0,纬度值就是10
1.6 将cube data转成HFile格式并导入HBase
2. 构建算法
2.1 逐层构建算法(layer)
我们知道,一个N维的Cube,是由1个N维子立方体、N个(N-1)维子立方体、N*(N-1)/2个(N-2)维子立方体、…、N个1维子立方体和1个0维子立方体构成,总共有2^N个子立方体组成,在逐层算法中,按维度数逐层减少来计算,每个层级的计算(除了第一层,它是从原始数据聚合而来),是基于它上一层级的结果来计算的。比如,[Group by A, B]的结果,可以基于[Group by A, B, C]的结果,通过去掉C后聚合得来的;这样可以减少重复计算;当 0维度Cuboid计算出来的时候,整个Cube的计算也就完成了。
每一轮的计算都是一个MapReduce任务,且串行执行;一个N维的Cube,至少需要N次MapReduce Job。
如图:
- 第一次(MR-1中第一列)计算全部的维度的数据(黄色的111代表三个维度都计算,红色001代表维度值)
- 第二次(MR-1中第二列)计算只有2个维度的数据,有三种可能性,分别是011,101,110
- 第三次(MR-2中第二列)根据MR-1中的011这个数据去计算只有一个维度的数据,分别是001和010
- …
图中MR-1中黄色的111,代表3个维度都有,红色001代表维度对应的值
算法优点:
1)此算法充分利用了MapReduce的优点,处理了中间复杂的排序和shuffle工作,故而算法代码清晰简单,易于维护;
2)受益于Hadoop的日趋成熟,此算法非常稳定,即便是集群资源紧张时,也能保证最终能够完成。
算法缺点:
1)当Cube有比较多维度的时候,所需要的MapReduce任务也相应增加;由于Hadoop的任务调度需要耗费额外资源,特别是集群较庞大的时候,反复递交任务造成的额外开销会相当可观;
2)由于Mapper逻辑中并未进行聚合操作,所以每轮MR的shuffle工作量都很大,导致效率低下。
3)对HDFS的读写操作较多:由于每一层计算的输出会用做下一层计算的输入,这些Key-Value需要写到HDFS上;当所有计算都完成后,Kylin还需要额外的一轮任务将这些文件转成HBase的HFile格式,以导入到HBase中去;
总体而言,该算法的效率较低,尤其是当Cube维度数较大的时候。
2.2 快速构建算法(inmem)
也被称作“逐段”(By Segment) 或“逐块”(By Split) 算法,从1.5.x开始引入该算法,该算法的主要思想是,每个Mapper将其所分配到的数据块,计算成一个完整的小Cube 段(包含所有Cuboid)。每个Mapper将计算完的Cube段输出给Reducer做合并,生成大Cube,也就是最终结果。
如图:
-
将总的数据分为多个mapper
-
在一个mapper中有111三个维度,纬度值001和101的,他们拆分为2个维度的话都会与011这个维度:
-
由于这2个维度是一样的,所以内存中会将他们聚合
-
…
与旧算法相比,快速算法主要有两点不同:
1) Mapper会利用内存做预聚合,算出所有组合;Mapper输出的每个Key都是不同的,这样会减少输出到Hadoop MapReduce的数据量,Combiner也不再需要;
2)一轮MapReduce便会完成所有层次的计算,减少Hadoop任务的调配。
具体构建流程可参考:
https://www.cnblogs.com/xiaodf/p/10855174.html
https://blog.csdn.net/SONGCHUNHONG/article/details/78028951