大資料OLAP Kylin
在傳統的關係型資料庫中通過預計算預快取來實現OLAP分析查詢並不新鮮, 微軟的SSAS就是典型的代表.
不過由於SSAS在國外興起的時候, 國內的大公司還沒有意識到SSAS對於企業管理和業務支援的作用, 加上SSAS的正版售價問題. 這項技術在中國國內並不是很流行.
現在大資料炙手可熱, 通過預計算預快取的手段來提高大資料的OLAP能力變得自然而然. 於是Kylin應運而生.
Kylin的預設資料來源是Hive, 聚合快取結果預設存放在HBase中, 但是這些只是預設配置, Kylin有靈活性, 可以底層的依賴系統: 比如用Spark替換MR, 用cassandra替換HBase.
所謂預計算其實就是把某個維度上的聚合值預先計算好的意思, 這裡的聚合值可以是最大(小)值也可以是平均值或者總和值等等.
比如有一個維度叫 婚姻狀況, 其選項有3個: 未婚/已婚/離異. 聚合值是數量(count), 那麼就是預先計算未婚的人數, 已婚的人數, 離異人數. 3個選項又可以說這個維度的基數(cardinality)是3.
對於一個星型模型, 假設其維度有3個, 那麼我們要統計2^3=8個不同的層次(cuboid). 怎麼理解?
假設這三個維度分別是 年份,地點,婚姻狀況:
1.不同年份的聚合值
2.不同地點的聚合值
3.不同婚姻狀況的聚合值
4.不同年份中各個地點的聚合值
5.不同年份中各個婚姻狀況的聚合值
6.不同地點中各個婚姻狀況的聚合值
7.不同年份中各個地點中的各中婚姻狀況的聚合值
8.以及一個總聚合值
所以這個cuboid總是等於2^n, 其中n是維度個數
可想而知當維度一多, 要預計算預快取的cuboid數量呈指數上升, 對Process時間和快取空間都是極大的挑戰. 所以kylin提供了一些概念來避免過多的cuboid.
mandatory dimension: 這個維度總會被聚合.假設上例中年份是一個mandatory dimension. 那麼序號2,3,7,8的聚合就不必計算了, 因為將來的查詢總是要年份這個聚合值的, cuboid變成了2^(n-m), 其中n為維度個數, m是mandatory dimension個數.
derived dimension: 不同維度互相之間有層級關係, 可以合併成一個維度, 比如年/月/日. 最低粒度是"日". 當我們的查詢在"年"上聚合時, 可以利用 預先計算好的 "日"粒度的聚合結果. 所以沒有必要特地為"年"預先計算聚合值了
hierarchy dimension: 這個比derived dimension更進一層, 表示聚合總是發生在整個hierarchy上. 還是以年月日為例, 比如月份是屬於一個hierarchy dimension的(層級關係是年月日), kylin不會單獨去預先計算月份上的聚合, 而總是計算年/月的聚合值. 所以keylin的快取結果中不會有所有3月份的聚合值, 而只有各個年份上3月的聚合值, 因為月份屬於一個hierarchy dimension, 必定和它的上一層年份連用.
參考:
https://mail-archives.apache.org/mod_mbox/kylin-dev/201507.mbox/%[email protected]%3E