Kylin系列(一)—— 入門

總目錄

Kylin系列(一)—— 入門
Kylin系列(二)—— Cube 構造算法


因爲平常只會使用kylin而不知其原理,故寫下此篇文章。文章不是自己原創,是看過很多資料,查過很多博客,有自己的理解,覺得精華的部分的一個集合。算是自己對Kylin學習完的一個總結和概括吧。文章最後有鏈接,需要請自取。

前言

企業中的查詢大致可分爲即席查詢和定製查詢兩種。很多的OLAP引擎包括Hive、Presto、SparkSQL,雖然很大成都上能降低數據分析的難度,但是他們都只適用於即席查詢的場景。但是隨着數據量和計算複雜度的增長,響應時間是無法保證的,這其實和業務需要是相違背的,數據分析師以及業務部門人員需要的對數據實時的反饋,才能更好對業務產生指導。

Kylin的產生就是爲了解決如何對海量數據進行OLAP查詢

Kylin是一個開源的分佈式分析引擎,提供Hadoop之上的SQL查詢接口及多維分析(OLAP)能力,也可以說Kylin就是基於Hadoop平臺。

Kylin構建在Hadoop等分佈式計算平臺之上,充分利用了MapReduce的並行處理能力和可擴展基礎設施,高效處理超大數據規模(其實kylin的中的cuboid都是基於MapReduce任務的),可根據數據的規模實現架構的可伸縮。

過程:
- 數據源(Hive、Kafla)
- 計算:構建多維立方體用MapRedue
- 存儲:Hbase
- SQL查詢解析: kylin SQL解析器

Kylin採用預計算的模式,用戶只需提前定義好查詢維度,Kylin將會幫助我們進行計算,並將結果存儲到HBase中,爲海量數據的查詢和分析提供亞秒級返回,是空間換時間的解決方案。

其實就是用窮舉的辦法把所有可能涉及到的維度的組合數都算一遍。利用sql解析,利用Hbase的性能,從算好的結果中提取數據。

提一下,Apache Kylin是第一個由中國人主導的Apache頂級項目。

核心概念

數據倉庫

Data Warehouse 簡稱DW,即數據倉庫,是BI中的核心部分。主要是將不同數據源的數據整合到一起,通過多維分析等方式爲企業提供決策支持和報表生成。

數據倉庫和傳統型數據倉庫的用途是不同的。傳統型數據倉庫面向事務,而DW面向分析。傳統型數據庫更多的是對業務作出實時反應,涉及增刪改查,所以需要遵循三大範式,需要ACID。而數據倉庫中的數據多爲歷史數據,主要目的是爲企業決策提供支持,所以可能存在大量數據冗餘,但利於多個維度查詢,爲決策者提供更多觀察角度。

傳統BI中,數據倉庫的數據會存儲在Mysql、Sql Sever等數據庫,而大數據領域常用的是Hive。Hive也是Kylin的默認數據源。

傳統數倉和大數據數倉的區別

那麼這裏順帶提一句傳統型數據倉庫和大數據數據倉庫之間的區別。爲什麼一定要是使用大數據數據倉庫。

這裏有幾點理由:
1.數據源多樣化
原來的數據源可能更多來自於交易數據,但是可能有:行爲數據、財務數據等。
2.數據量暴漲
原來的數據源可能較單一,但是數據源多樣化後,數據量暴漲,單機的運算無法滿足。比如處理行爲日誌數據的需求,是沒辦法處理的。使用Hive後,可利用分佈式和分區特效加快效率。
3.數據類型
傳統數倉只能解決結構化的數據的問題,而無法解決非結構化數據。而大數據數倉可以通過Hbase接受非結構化數據,利用hive外部表來讀取數據。
4.服務對象
傳統數倉可能更多針對於高管、運營、財務人員,大數據數倉不僅用於上述人羣,而且可以爲各個系統提供接口數據,例如推薦系統、內部風控系統等等。
5.處理速度快
大數據數倉採用分佈式架構,利用分佈式計算效率遠高於傳統數倉,且可按需進行動態擴展,無需擔心性能問題。

OLAP和OLTP

OLAP(online analytical process)聯機事物處理,是以多維度分析,提供決策支持,多應用於數倉。OLTP(online transcation process),聯機事物處理,多用於傳統數據庫,如mysql\Oracle\sql Sever等,專注於對業務系統的反饋進行對單行數據的增刪改查。

維度和度量

維度指的是觀察數據的角度,如對於一張訂單表來說,維度有訂單生成時間、地區、產品類別、產品等等。

維度一般是一個離散的值,比如時間維度上的每一個獨立日期,地區上每一個地點,因此統計時可以將相同維度的記錄聚合在一起,進行聚合計算。

度量就是被聚合的統計值,也就是運算的結果,如對於一張訂單,他的銷售量和銷售金額是兩種度量,是需要統計聚合的值。

維度的基數

指的是該維度在數據集中出現的不同值的個數。

例如一個國家是一個維度,如果有200個不同的值,那麼此維度的基數是200。

通常一個維度的基數會從幾十到幾萬個不等,個別維度如“用戶ID”的基數會超過百萬甚至千萬。

基數超過1百萬的維度通常被稱爲超高基數維度。

Cube中所有維度的基數決定了Cube的複雜度,如果有好幾個超高基數的維度,那麼Cube膨脹的概率就會很高。

事實表和維度表

事實表(factTable)指的是存儲有事實記錄的表,包含了每個時間的具體要素,以及具體發生的事情如系統記錄、銷售記錄以及庫存記錄等等。

事實表的體積是遠大於其他表的。

維度表(DimensionTable)是對事實表中事件要素的描述信息。

它保存了維度屬性值,可以跟事實表關聯:相當於把事實表上經常重複出現的屬性抽取、規範出來用作一張表。

常見的維度表:日期表(日期對應的周月季度等屬性)、地點表(包含國家、省州、城市)。

維度表的好處:
- 縮小了事實表的大小
- 便於維度的管理和維護,對維度表的修改不必對事實表進行大量的改動。
- 維度表可以爲多個事實表重用。

提一句,再Kylin種採用的是星型模型,即維度表全部和事實表直接關聯。

星型模型

星型模型是數據挖掘種常用的幾種多維度數據模型之一。他的特點是隻有一張事實表,以及零到多個維度表,事實表和維度表通過主表外鍵相關聯,維度表之間沒有關聯。

(注意在kylin中,維度表的主鍵是唯一的,並且事實表中,除了join的關聯字段,不允許和維度表中的字段相同,並且維度表和維表之間字段也不能相同。並且事實表和維度表join關聯的字段類型必須相同。這在構建cube的時候是經常會遇到錯誤。)

Kylin中維度表的設計

Kylin對於維度表來說是有一定要求的。

要具有數據一致性,主鍵值必須是唯一的。即與維度表相關聯的列在維度表中一定是唯一的,否則會報錯。這在後續的kylin報錯解析會有所提及。

維度表越小越好,因爲Kylin會將維度表加載到內存中供以查詢;默認閾值爲300MB.

改變頻率低,Kylin在每次構建中試圖重用維度表的快照,若經常改變,重用會失效,這就導致會經常性的對維度表創建快找。

維度表不要是hive視圖,因爲視圖其實是一個邏輯結構,並不實際存在,每次使用都需要進行一個物化,從而導致額外時間的開銷。

Cube和Cuboid

瞭解維度和度量,就可以將數據模型上的所有字段進行分類:他們要麼是維度,要麼是度量,沒有第三種字段。根據定義的維度和度量就可以構建cube了。

對於一個給定的數據模型,我們可以對其上所有的維度進行組合,對於N個維度來說,組合的可能性共有2的N次方種。即一個N維的cube,是由1個N維子立方體,N個(N-1)維子立方體、N*(N-1)/2個(N-2)維子立方體… N個1維子立方體和1個0維子立方體構成。其實就是排列組合。

對於每一種維度的組合,將度量做聚合運算,然後將運算的結果保存爲一個物化視圖,稱爲cuboid。所有維度組合的cuboid作爲一個整體,被稱爲Cube.

舉個例子,假設有維度A、B、C,那麼2的2的3次方,即8種。

0維度0D:一種
一維度1D:[A][B][C]
二維度2D:[AB][AC][BC]
三維度3D:[ABC]

SQL表達計算Cuboid[A,B]

select A,B,Sum(amount) from table1
group by A,B

將計算結果保存爲物化視圖,所有cuboid物化視圖的總稱就是Cube.

Kylin的技術架構

Apache Kylin系統主要可以分爲在線查詢和離線構建兩部分,具體架構圖如下:
此處輸入圖片的描述

首先來看離線構建部分。從圖中可以看出,左側位數據源,目前kylin默認的數據源是Hive,保存着待分析的用戶數據。根據元數據的定義,構建引擎從數據源抽取數據,並構建Cube.數據以關係表的形式輸入,並且符合星形模型。構建技術主要爲MapReduce。構建後的Cube保存在右側存儲引擎中,目前Kylin默認的存儲引擎是HBase。

完成離線構建後,用戶可以從上方的查詢系統發送SQL進行查詢分析。Kylin提供了RESTful API、JDBC/ODBC接口供用戶調用。無論從哪個接口進入,SQL最終都會來到REST服務層,再轉交給查詢引擎進行處理。查詢引擎解析SQL,生成基於關係表的邏輯執行計劃,然後將其轉譯爲基於Cube的物理執行計劃,最後查詢預計算生成的Cube併產生結果。整個過程不會訪問原始數據源。如果用戶提交的查詢語句未在Kylin中預先定義,Kylin會返回一個錯誤。

值得一提的是,Kylin對數據源、執行引擎和Cube存儲三個核心模塊提取出了抽象層,這意味着這三個模塊可以被任意地擴展和替換。

Kylin的核心模塊

REST Server

REST Server是一套面向應用程序開發的入口點。此類應用程序可以提供查詢、獲取結果、觸發cube構建任務、獲取元數據以及用戶權限等等。另外可以通過Restful藉口實現SQL查詢。

查詢引擎(Query Engine)

當cube準備就緒後,查詢引擎能夠獲取並解析用戶查詢。他隨後會與系統中的其他組件進行交互,從而向用戶返回對應的結果。

Routing

負責將解析SQL生成的執行計劃轉換成cube緩存查詢,cube是通過預計算緩存在hbase中。

元數據管理工具

Kylin是一款元數據驅動型應用程序。元數據管理工具十一大關鍵性組件,用於對保存在Kylin當中的所有元數據進行管理,其中包括最爲重要的cube元數據。其他全部組件的正常運作都需以元數據管理工具爲基礎。Kylin的元數據存儲在Hbase中。

任務引擎(Cube Build Engine)

這套引擎的設計目的在於處理所有離線任務,其中包括shell腳本、Java API以及MapReduce任務等等。任務引擎對Kylin當中的全部任務加以管理與協調,從而確保每一項任務都能得到切實執行並解決其間出現的故障。

Kylin Cube三種構造

我們來談談Cube構建。Kylin的Cube構建分爲三種:全量構建、增量構建、流式構建。最簡單的是全量構建,就是每次構建都Hive表進行全表構建。但是全量構建在實際環境中並不常用,因爲大多數業務場景蝦,事實數據都在不斷地增長中,所以最常用的構建方式其實是增量構建。

這裏提出一個全量構建的例子。比如鏈家的相關數據必須使用全量構建,如成交業績相關,因爲一單成交時間有2個月之久,可能存在中間關於某單的修改,那麼業績也隨之修改。故只能採用全量構建,dm表爲全量整年的業績。但是維度控制在較少範圍,故壓力不大。總體來說,這是通過控制DM表來控制實現的,且在kylin中只保留一個最新的segment。

增量構建可以使Cube每次只構建Hive表中新增部分的數據,而不是全部數據,因此大大降低了構建成本。Kylin將Cube分爲多個Segment,每個Segment用起始時間和結束時間來標識。

增量構建與全量構建的不同之處:

  1. 創建model時需要指定Partition Date Column,用日期字段來對Cube進行分割。

增量構建
2. 創建Cube時需要指定Partition Start Date,即Cube默認的第一個Segment的起始時間。
可看文章
Kylin Cube Creation
Kylin Cube Build and Job Monitoring

增量構建的方式解決了業務數據動態增長的問題。但是卻不能滿足分鐘級近實時返回結果的需求,因爲增量構建他們使用的時Hive作爲數據源,Hive中的數據由ETL定時導入(如每天一次)。數據的時效性對於數據價值的重要性不言而喻。Kylin給出了流式構建方案。

流式構建使用Kafka作爲數據源,構建引擎定時從Kafka中拉去數據進行構建。這一個設計與Spark Streaming的微批次思想非常像。需要注意流式構建在1.6版本後存在。

Kylin提供:
- Cube構建可以在Web UI界面和RESTful API
- 數據查詢可以在Web UI界面和RESTful API和JDBC/ODBC接口

用戶可以根據自身情況選擇合適的構建和查詢方式。

博客參考

kylin的基本介紹
http://cxy7.com/articles/2018/06/09/1528544157772.html
https://www.jianshu.com/p/abd5e90ab051
http://www.liuhaihua.cn/archives/451581.html

傳統數倉和大數據平臺的區別

https://blog.csdn.net/Gospelanswer/article/details/78208761
https://support.huaweicloud.com/dws_faq/dws_03_0005.html

Inmon Kimball 數據倉庫架構之爭
https://blog.csdn.net/paicMis/article/details/53236869
https://blog.csdn.net/yanshu2012/article/details/55254300

OLTP與OLAP的介紹
https://www.cnblogs.com/hhandbibi/p/7118740.html

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章