Kylin基礎教程(一)

2021-09-29 04:46:46 字數 2550 閱讀 2249

hadoop於2023年初步實現,改變了企業級的大資料儲存(基於hdfs)和批處理(主要基於mr)問題,10幾年過去了,資料量隨著網際網路的發展井噴式增長,如何高速、低延遲的分析資料成為後續面臨的挑戰,闢如我們面臨的一些質疑:hadoop老矣,尚能飯否?

其中也出現過各種各樣的框架來協助hadoop降低訪問資料的延遲,比如列儲存框架(columnar storage)例如:hbase,以及一些「sql on hadoop」的批處理框架,其中以hive為代表的,impala,presto,drill,sparksql緊隨其後。

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

舉個例子,假設查詢1億條資料耗時1分鐘,那麼可能會有如下對應關係:

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

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

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核心之一即:空間換時間,閒時定期對已有資料做預計算,並儲存結果。這也是除「多硬體大規模並行處理」、「面向列儲存」之外的提供大資料快速分析查詢的第三技術——「預計算」。

還是那個例子,假設我們的原始資料是:

我們此處稱:

前兩列為:維度

後一列為:度量

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

給定乙個資料模型,我們找到所有可能的維度組合,對於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),即,使得大資料分析快速而簡潔。

IOS OpenGLES 基礎教程 一

今天起本站將推出ios opengles基礎教程,當然本人也是一面自學一面將學習中所用到的和學到的東西一併分享給大家,在本教程中,本人會對 進行逐行的注釋講解,資源來自於網路和書籍的整合,如在教程中有錯誤的地方,希望大家及時指正,可隨時傳送郵件到helmsmansoft 163.com 與本人取得聯...

C 基礎教程(一)

1.清單 1 1.乙個簡單的歡迎程式 welcome.cs namespace declaration using system program start class class welcomecss 結束。任何位於 之間的語句定義為塊。塊定義了程式元素的活動範圍 或者稱為生命期和可見性 這些概念...

GLSL基礎教程(一)

高階著色語言 hlsl high level shading language 是用來在頂點和畫素著色器 shader 中程式設計的語言。其實,說白了他們就是我們寫的短小的自定義程式,他們是在圖形卡的gpu graphic processor unit圖形處理單元 上執行的,代替了固定的渲染管線的一...