Kylin基礎教程(一)


一、Kylin介紹

1.1 現狀

Hadoop於2006年初步實現,改變了企業級的大數據存儲(基於HDFS)和批處理(主要基於MR)問題,10幾年過去了,數據量隨着互聯網的發展井噴式增長,如何高速、低延遲的分析數據成為后續面臨的挑戰,辟如我們面臨的一些質疑:Hadoop老矣,尚能飯否?

其中也出現過各種各樣的框架來協助Hadoop降低訪問數據的延遲,比如列存儲框架(Columnar Storage)例如:HBase,以及一些“SQL on Hadoop”的批處理框架,其中以Hive為代表的,Impala,Presto,Drill,SparkSQL緊隨其后。

大規模並行處理可以利用多台機器,並行計算,用線性增加的硬件資源,來換取計算時間的線性下降。列式存儲則是將數據按照列來存放,這樣可以在訪問數據時只讀取需要的列,“硬件橫向插拔式拓展”和“面向列存儲”大大提高了基於Hadoop查詢分析數據的效率,從原來的幾個小時,縮小到了幾分鍾,但是面臨完整的業務分析體系,依然需要以小時甚至天來衡量從提交任務到得到結果的時間。這造成了數據分析師大部分時間都停留在等待結果上——一杯咖啡喝完,又打了把王者榮耀,結果依然沒出來。

舉個例子,假設查詢1億條數據耗時1分鍾,那么可能會有如下對應關系:

 
 

也就是說我們提到的之前存在並一直在使用的優化機制並沒有改變查詢本身的時間復雜度,也有解決得到查詢時間與數據量成線性增長這一問題。顯然,無限制的橫向拓展硬件部署,理論上可以無限的縮小查詢時間,但是硬件成本極其昂貴,亦然於運維成本。

1.2 Kylin 出發思路

要解決問題,先分析問題核心矛盾點:

1) 大數據查詢大多為統計結果,即多條數據經過聚合函數計算后的統計值,原始記錄直接作為結果返回的概率極低。

2) 數據分析與描述必須按照維度來進行,業務范圍不可能無限大,即,維度也不會大到天文數字這樣的級別,展示需求也是如此,那么有價值的“維度組合個數”也是相對有限的,一般不會隨着數據量的增加,維度也跟着不斷的增加。

舉個例子,如下查詢:

SELECT telephone, sum(duration)

FROM tb_call_records

where call_date=’2018-02’

group by telephone

order by sum(duration) desc;

傳統方式則是先全表掃描,然后找到符合2月的日期,再按照電話號碼聚合,統計每個電話號碼這一天所有的通話時長總和,最后排序輸出,如果2月份的通話記錄有1億條,則查詢會先訪問1億條記錄,如果記錄增加5倍,則查詢效率下降5倍,等待時間提高5倍。

OK,基於以上矛盾,Kylin,出發了。

使用預計算,即把上面例子中的查詢結果先計算好,保存下來,下次做相同訪問時,就會變得非常快。我們可以先按照維度[call_date, telephone]計算sum(duration),並存儲下來,下次如果查詢2月,或者其他月份的通話時長時,就可以直接返回了。這樣一來,假如之前1億條記錄中有10萬個電話號碼,那么預計算之后,2月份的通話記錄就只有10萬條記錄了,是原來的1000分之1。無論2月份的通話記錄如何增加,我的查詢速度也不會改變。那么各種統計結果保存也是需要消耗存儲空間的,Kylin核心之一即:空間換時間,閑時定期對已有數據做預計算,並保存結果。這也是除“多硬件大規模並行處理”、“面向列存儲”之外的提供大數據快速分析查詢的第三技術——“預計算”。

還是那個例子,假設我們的原始數據是:

 

 
 

我們此處稱:

前兩列為:維度

后一列為:度量

我們的預計算便是通過各種不同的“維度”組合,來聚合“度量”。

1.3 Kylin工作原理 

給定一個數據模型,我們找到所有可能的維度組合,對於N個維度來說,組合的可能性就有2^N種。對於每一種維度進行度量的聚合運算,將運算結果保存為一個物化視圖,稱之為:Cuboid。所有維度組合的Cuboid作為一個整體,我們稱之為:Cube。所以一個Cube就是多種維度聚合度量的物化視圖集。

所以剛才的例子,我們再稍微復雜一點,加上location維度列(通話位置),構建Cube就變成了如下樣子:

 
 

0維度和3維度的共有2個,1維度3個,2維度3個。共2^3 = 8個維度組合。

總結Kylin的工作流程:

1) 指定數據模型,定義維度和度量。

2) 預計算Cube,得到所有Cuboid並保存為物化視圖。

3) 執行查詢,讀取Cuboid並計算,返回查詢結果。

即,Kylin在查詢時,不再去掃描原始數據集,萬億級數據的查詢也可以提升到壓秒級別。

但存儲Cube所消耗的空間一般是原始數據集大小的20~100倍,即原始數據100GB,那么構建出的物化視圖大概為20 * 100GB = 2TB。

那么顯而易見,Kylin的使命就是OLAP(Online Analytical Processing),即,使得大數據分析快速而簡潔。



作者:Z盡際
鏈接:https://www.jianshu.com/p/f62119eeb8c0
來源:簡書
著作權歸作者所有。商業轉載請聯系作者獲得授權,非商業轉載請注明出處。


免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM