kylin介紹

本文轉載自查看原文 2018-07-10 07:41 6138 kylin

架構

官網很直接，上來就給出了kylin的架構，也很清晰。可以把kylin看成3個部分。

cube管理查詢
cube構建引擎
cube存儲引擎

其中，構建引擎和存儲引擎可以自由擴展，默認是mapreduce和hbase

術語

OLTP

在線事務處理是傳統的關系型數據庫的主要應用，主要是基本的、日常的事務處理，例如銀行交易。OLAP是數據倉庫系統的主要應用，支持復雜的分析操作，側重決策支持，並且提供直觀易懂的查詢結果。

OLAP

數據在線分析處理引擎。通過對數據的各個維度，實時之間構建出cube來分析數據的價值。kylin就是一款針對OLAP的系統。

OLAP和OLTP的區別可以理解為，OLAP是主觀的需求產物，OLTP是客觀的需求產物。

cube

cube和傳統的關系數據庫和二維表不一樣，可以有很多個維度，比如需要獲取維度a,b,c之間任意組合的數據結果，這在sql中表達可能是group by a; group a,b; group b，看似簡單，實則計算量很大。在數據分析中，cube非常重要，下面章節會針對kylin中的cube進行詳細描述。

MXD

MDX語句（MultiDimensionalExpressions）是一種語言，支持多維對象與數據的定義和操作。它可以表達在線分析出來數據卡上的選擇、計算和一些元數據定義等操作，並賦予用戶表現查詢結果的能力。

如同SQL查詢一樣，每個MDX 查詢都要求有數據請求（SELECT子句）、起始點（FROM子句）和篩選（WHERE子句）。這些關鍵字以及其它關鍵字提供了各種工具，用來從多維數據集析取數據特定部分。MDX還提供了可靠的函數集，用來對所檢索的數據進行操作，同時還具有用戶定義函數擴展 MDX的能力。

語法：
   最基本的語法：select 軸1,軸2，…… from 立方體模型名 where 切片
   可以看到，非常類似於SQL的語法：Select 列1,列2…… from 表1,表2…… where 條件子句。
   首先，需要理解軸的概念：
   軸：相當於SQL里的列，想象軸，需要有點立體概念，或者，我們把問題簡化，對於平面表的展示，只會存在兩個軸，也就是列軸和行軸。現有的大多數OLAP展示，也只體現這兩個軸，我們公司的產品也不例外。說具體一點，軸對應於一個集合。
   集合：由元組形成，
   元組：可包括多個維度中的成員，也可包括來自同一個維度的多個成員。
   成員：維度中一次或多次數據出現的項。

再看看立方體模型：這個很好理解，也就是主題分析時形成的模型方案了，MDX只支持單一模型。

最后看一下切片：這和SQL中的篩選一樣。不過，因為OLAP的數據是立體的，多維的，要變成平面，就需要切啊，切啊，把一些不需要展示的維度設定固定值(也就是切一下)。注意：當不指定任何切片時，一般的實現是將未出現的維度的默認成員值做為切片值。

事實表 & 維度 & 度量

事實表

每個數據倉庫都包含一個或者多個事實數據表。事實數據表可能包含業務銷售數據，如銷售商品所產生的數據，與軟件中實際表概念一樣。

維度

說明數據，維度是指可指定不同值的對象的描述性屬性或特征。例如，地理位置的維度可以包括“緯度”、“經度”或“城市名稱”。“城市名稱”維度的值可以為“舊金山”、“柏林”或“新加坡”。可以用於從不同角度來分析數據，例如常見的時間，地點維度

度量

事實表和維度交叉匯聚的點，度量和維度構成OLAP的主要概念，這里面對於在事實表或者一個多維立方體里面存放的數值型的、連續的字段，就是度量。這符合上面的意思，有標准，一個度量字段肯定是統一單位，例如元、戶數。如果一個度量字段，其中的度量值可能是歐元又有可能是美元，那這個度量可沒法匯總。在統一計量單位下，對不同維度的描述。

維度 & 度量

維度是指審視數據的角度，它通常是數據記錄的一個屬性，例如時間、地點等。度量是基於數據所計算出來的考量值；它通常是一個數值，如總銷售額、不同的用戶數等。分析人員往往要結合若干個維度來審查度量值，以便在其中找到變化規律。在一個SQL查詢中，Group By的屬性通常就是維度，而所計算的值則是度量

例子1：
有item A，time t， location l。那么item A位於事實表，time t和location l位於維度表。假如對time t按天做group by，對 item A做sum()。那么得到的數據就是度量。

維度表 & 事實表

事實表（Fact Table）是指存儲有事實記錄的表，如系統日志、銷售記錄等；事實表的記錄在不斷地動態增長，所以它的體積通常遠大於其他表。
維度表（Dimension Table）或維表，有時也稱查找表（Lookup Table），是與事實表相對應的一種表，注意OLAP的lookup table主要是指數據的基礎維度以及一些衍生維度；它保存了維度的屬性值，可以跟事實表做關聯；相當於將事實表上經常重復出現的屬性抽取、規范出來用一張表進行管理。常見的維度表有：日期表（存儲與日期對應的周、月、季度等的屬性）、地點表（包含國家、省／州、城市等屬性）等。使用維度表有諸多好處，具體如下。
·縮小了事實表的大小。
·便於維度的管理和維護，增加、刪除和修改維度的屬性，不必對事實表的大量記錄進行改動。
·維度表可以為多個事實表重用，以減少重復工作。

多維分析模型

數據倉庫常用的建模思路通常有基於維度的建模和實體建模。實體建模就是按照數據庫3范式，規規矩矩的設計好每一張表，在進行多維分析的時候做大量的表關系得到數據。維度建模則是盡可能的抽象出業務過程，細化業務粒度，然后將該業務過程中相關的數據字段看成一個個維度，將業務的核心數據看成是事實，從而簡化表結構，提高數據獲取效率。

星型模型

星型架構是一種非正規化的結構，多維數據集的每一個維度都直接與事實表相連接，不存在漸變維度，所以數據有一定的冗余，如在地域維度表中，存在國家 A 省 B 的城市 C 以及國家 A 省 B 的城市 D 兩條記錄，那么國家 A 和省 B 的信息分別存儲了兩次，即存在冗余。

雪花模型

雪花模型是對星型模型的擴展。它對星型模型的維表進一步層次化，原有的各維表可能被擴展為小的事實表，形成一些局部的 " 層次 " 區域，這些被分解的表都連接到主維度表而不是事實表。如圖 2，將地域維表又分解為國家，省份，城市等維表。其實就是把一張事實表拆成多張小維度表，並通過key關鍵。它的優點是 : 通過最大限度地減少數據存儲量以及聯合較小的維表來改善查詢性能。雪花型結構去除了數據冗余。

區別

星型模型因為數據的冗余所以很多統計查詢不需要做外部的連接，因此一般情況下效率比雪花型模型要高。星型結構不用考慮很多正規化的因素，設計與實現都比較簡單。雪花型模型由於去除了冗余，有些統計就需要通過表的聯接才能產生，所以效率不一定有星型模型高。正規化也是一種比較復雜的過程，相應的數據庫結構設計、數據的 ETL、以及后期的維護都要復雜一些。因此在冗余可以接受的前提下，實際運用中星型模型使用更多，也更有效率。目前kylin只支持星型模型，或者通過ETL工具建星型模型轉換成一張寬表再進行多維分析。。

cube

介紹

cube的設計是olap系統的核心，這會影響到查詢分析的覆蓋程度和性能。如果cube設計的維度太多，那么會導致構建速度很慢，存儲空間浪費，查詢性能低的現象。所以在滿足需求的條件下，對cube不斷的優化。

針對N維的數據分析而言，一共可以衍生出2ⁿ中聚合結果，如圖所示，4個維度的排列組合。用數學的公式來說就是 C₄⁰+ C₄¹ + C₄² + C₄³ + C₄⁴。一個星型模型的維度數量最好控制在15以內，由於cube構建數量和維度是指數關系，所以維度太高會導致cube構建時間很長，並且，數據量的增大也會導致查詢速度下降。如果真的有這么多的維度需要分析，那么可以拆成多個星型模型。

kylin維度組合模式

概述

cube的維度很容易爆炸，因為是指數增長的，所以降維是cube設計中的核心，下面是kylin支持的幾種cube組合模式。

Normal

正常模式。也就是N個維度構建成2^N個cube。

例子：假設有三個維度A,B,C每個維度都為Normal模式，那么構建的cube如圖2，cube的總數為C₃⁰+C₃¹+C₃²+C₃³。

圖2

Mandatory

維度強制模式。當某個維度設置為Mandatory模式，那么該維度會出現在所有cube的構建中，比如時間維度，可以強綁定到cube的構建中。這種構建模式可以很大程度降低最后生成的cube數量，但是會導致分析失去一定的靈活性。

例子：假設有三個維度A,B,C 其中維度A為Mandatory模式，那么構建的cube如圖3，最終生成的cube數為C₂⁰+C₂¹+C₂²

圖3

Hierarchy

依賴模式。維度間通過依賴關系來決定構建cube的組合關系，只有父維度存在，子維度才會有效。常見的有國家，省份，城市這類字段。在做分析的時候，一般場景為：

group by 國家；

group by 國家，省份；

group by 國家，省份，城市；

例子：假設有維度A,B,C 其中B依賴於A，C依賴於B，那么構建的cube如圖4。

圖4

Derived

衍生模式。衍生模式的使用場景為，一個或多個維度可以由另一個維度生成。這是什么意思呢，假設在事實表中有外鍵列A， lookup表中B,C列，其中B為主鍵，列A和列B是映射關系，那么在查詢事實表中的列A同時，kylin會自動的查詢到lookup表中的B列。從維度數量的角度來看，Normal模式下有ABC,AB,AC,BC,A,B,C這幾種組合情況，而在Derived模式下，cube的構建組合只有AC,A,C。

那么當請求的sql為`select count(*) from lookup group by B`的時候，由於沒有對B列做預處理，所以kylin先查詢A列的count，然后再實時計算出對應的B列的count 。

如圖5，ID列為已知的某個維度列，A,C,B為ID列的衍生列，那么最終cube構建組合只有ID列。