Kylin術語

Data Warehouse（數據倉庫）

數據倉庫是一個各種數據（包括歷史數據和當前數據）的中心存儲系統，是BI（ business intelligence ，商業智能）的核心部件。

這里所談的數據包括來自企業業務系統的訂單、庫存、交易賬目、客戶和供應商等來自企業所處行業和競爭對手的數據以及來自企業所處的其他外部環境中的各種數據。

Business Intelligence（商業智能）

商業智能通常被理解為將企業中現有的數據轉化為知識，幫助企業做出明智的業務經營決策的工具。

為了將數據轉化為知識，需要利用數據倉庫、聯機分析處理（OLAP）工具和數據挖掘等技術。

OLAP（online analytical processing）

OLAP（online analytical processing）是一種軟件技術，它使分析人員能夠迅速、一致、交互地從各個方面觀察信息，以達到深入理解數據的目的。從各方面觀察信息，也就是從不同的維度分析數據，因此OLAP也成為多維分析。

分析訂單金額總和的規律，需要從不同的角度去觀察

角度1：地區

角度2：品類

角度3：時間

角度4：地區，品類

角度5：地區，時間

角度6：品類，時間

角度7：地區，品類，時間

OLAP 類型

星型模式

星型模式是多維的數據關系，它由事實表（Fact Table）和維表（Dimension Table）組成。每個維表中都會有一個維作為主鍵，所有這些維的主鍵結合成事實表的主鍵。事實表的非主鍵屬性稱為事實，它們一般都是數值或其他可以進行計算的數據。

事實表（Fact Table）和維表（Dimension Table）

Kylin的工作原理

Apache Kylin的工作原理本質上是MOLAP（Multidimensional Online Analytical Processing）Cube，也就是多維立方體分析。這是數據分析中相當經典的理論，在關系數據庫年代就已經有了廣泛的應用，下面將對其做簡要介紹。

維度和度量簡介

在說明MOLAP Cube之前需要先介紹一下維度（Dimension）和度量 （Measure）這兩個概念。 簡單來講，維度就是觀察數據的角度。比如電商的銷售數據，可以從時間的維度來觀察，

也可以進一步細化，從時間和地區的維度來觀察。

維度一般是一組離散的值，比如時間維度上的每一個獨立的日期，或者商品維度上的每一件獨立的商品。因此統計時可以把維度值相同的記錄聚合在一起，然后應用聚合函數做累加、平均、去重復計數等聚合計算。

度量就是被聚合的統計值，也是聚合運算的結果，它一般是連續的值，如上圖中的銷售額，抑或是銷售商品的總件數。通過比較和測算度量，分析師可以對數據進行評估，比如今年的銷售額相比去年有多大的增長，增長的速度是否達到預期，不同商品類別的增長比例是否合理等。

Cube和Cuboid

有了維度和度量，一個數據表或數據模型上的所有字段就可以分類了，它們要么是維度，要么是度量（可以被聚合）。于是就有了根據維度和度量做預計算的Cube理論。

給定一個數據模型，我們可以對其上的所有維度進行組合。對于N個維度來說，可以排列很多組合。對于每一種維度的組合，將度量做聚合運算，然后將運算的結果保存為一個物化視圖，稱為Cuboid。所有維度組合的Cuboid作為一個整體，被稱為Cube。所以簡單來說，一個 Cube就是許多按維度聚合的物化視圖的集合。

Cube構建原理

Cube構建算法

逐層構建算法（layer）

我們知道，一個N維的Cube，是由1個N維子立方體、N個(N-1)維子立方體、N*(N-1)/2個(N-2)維子立方體、......、N個1維子立方體和1個0維子立方體構成，總共有2^N個子立方體組成，在逐層算法中，按維度數逐層減少來計算，每個層級的計算（除了第一層，它是從原始數據聚合而來），是基于它上一層級的結果來計算的。比如，[Group by A, B]的結果，可以基于[Group by A, B, C]的結果，通過去掉C后聚合得來的；這樣可以減少重復計算；當 0維度Cuboid計算出來的時候，整個Cube的計算也就完成了。

每一輪的計算都是一個MapReduce任務，且串行執行；一個N維的Cube，至少需要N次MapReduce Job。

算法優點：

1）此算法充分利用了MapReduce的優點，處理了中間復雜的排序和shuffle工作，故而算法代碼清晰簡單，易于維護；

2）受益于Hadoop的日趨成熟，此算法非常穩定，即便是集群資源緊張時，也能保證最終能夠完成。

算法缺點：

1）當Cube有比較多維度的時候，所需要的MapReduce任務也相應增加；由于Hadoop的任務調度需要耗費額外資源，特別是集群較龐大的時候，反復遞交任務造成的額外開銷會相當可觀；

2）由于MApper邏輯中并未進行聚合操作，所以每輪MR的shuffle工作量都很大，導致效率低下。

3）對HDFS的讀寫操作較多：由于每一層計算的輸出會用做下一層計算的輸入，這些Key-Value需要寫到HDFS上；當所有計算都完成后，Kylin還需要額外的一輪任務將這些文件轉成HBase的HFile格式，以導入到HBase中去；

總體而言，該算法的效率較低，尤其是當Cube維度數較大的時候。

快速構建算法（inmem）

也被稱作“逐段”(By Segment) 或“逐塊”(By Split) 算法，從1.5.x開始引入該算法，該算法的主要思想是，每個Mapper將其所分配到的數據塊，計算成一個完整的小Cube 段（包含所有Cuboid）。每個Mapper將計算完的Cube段輸出給Reducer做合并，生成大Cube，也就是最終結果。如圖所示解釋了此流程。

與舊算法相比，快速算法主要有兩點不同：

1） Mapper會利用內存做預聚合，算出所有組合；Mapper輸出的每個Key都是不同的，這樣會減少輸出到Hadoop MapReduce的數據量，Combiner也不再需要；

2）一輪MapReduce便會完成所有層次的計算，減少Hadoop任務的調配。

Cube構建優化

在沒有采取任何優化措施的情況下，Kylin會對每一種維度的組合進行預計算，每種維度的組合的預計算結果被稱為Cuboid。假設有4個維度，我們最終會有2^4 =16個Cuboid需要計算。

但在現實情況中，用戶的維度數量一般遠遠大于4個。假設用戶有10 個維度，那么沒有經過任何優化的Cube就會存在210 =1024個Cuboid；而如果用戶有20個維度，那么Cube中總共會存在220 =1048576個Cuboid。雖然每個Cuboid的大小存在很大的差異，但是單單想到Cuboid的數量就足以讓人想象到這樣的Cube對構建引擎、存儲引擎來說壓力有多么巨大。因此，在構建維度數量較多的Cube時，尤其要注意Cube的剪枝優化（即減少Cuboid的生成）。

使用衍生維度（derived dimension）

衍生維度用于在有效維度內將維度表上的非主鍵維度排除掉，并使用維度表的主鍵（其實是事實表上相應的外鍵）來替代它們。Kylin會在底層記錄維度表主鍵與維度表其他維度之間的映射關系，以便在查詢時能夠動態地將維度表的主鍵“翻譯”成這些非主鍵維度，并進行實時聚合。

雖然衍生維度具有非常大的吸引力，但這也并不是說所有維度表上的維度都得變成衍生維度，如果從維度表主鍵到某個維度表維度所需要的聚合工作量非常大，則不建議使用衍生維度。

使用聚合組（Aggregation group）

聚合組（Aggregation Group）是一種強大的剪枝工具。聚合組假設一個Cube的所有維度均可以根據業務需求劃分成若干組（當然也可以是一個組），由于同一個組內的維度更可能同時被同一個查詢用到，因此會表現出更加緊密的內在關聯。每個分組的維度集合均是Cube所有維度的一個子集，不同的分組各自擁有一套維度集合，它們可能與其他分組有相同的維度，也可能沒有相同的維度。每個分組各自獨立地根據自身的規則貢獻出一批需要被物化的Cuboid，所有分組貢獻的Cuboid的并集就成為了當前Cube中所有需要物化的Cuboid的集合。不同的分組有可能會貢獻出相同的Cuboid，構建引擎會察覺到這點，并且保證每一個Cuboid無論在多少個分組中出現，它都只會被物化一次。

對于每個分組內部的維度，用戶可以使用如下三種可選的方式定義，它們之間的關系，具體如下。

1）強制維度（Mandatory），如果一個維度被定義為強制維度，那么這個分組產生的所有Cuboid中每一個Cuboid都會包含該維度。每個分組中都可以有0個、1個或多個強制維度。如果根據這個分組的業務邏輯，則相關的查詢一定會在過濾條件或分組條件中，因此可以在該分組中把該維度設置為強制維度。

2）層級維度（Hierarchy），每個層級包含兩個或更多個維度。假設一個層級中包含D1，D2…Dn這n個維度，那么在該分組產生的任何Cuboid中， 這n個維度只會以（），（D1），（D1，D2）…（D1，D2…Dn）這n+1種形式中的一種出現。每個分組中可以有0個、1個或多個層級，不同的層級之間不應當有共享的維度。如果根據這個分組的業務邏輯，則多個維度直接存在層級關系，因此可以在該分組中把這些維度設置為層級維度。

3）聯合維度（Joint），每個聯合中包含兩個或更多個維度，如果某些列形成一個聯合，那么在該分組產生的任何Cuboid中，這些聯合維度要么一起出現，要么都不出現。每個分組中可以有0個或多個聯合，但是不同的聯合之間不應當有共享的維度（否則它們可以合并成一個聯合）。如果根據這個分組的業務邏輯，多個維度在查詢中總是同時出現，則可以在該分組中把這些維度設置為聯合維度。

這些操作可以在Cube Designer的Advanced Setting中的Aggregation Groups區域完成，如下圖所示。

聚合組的設計非常靈活，甚至可以用來描述一些極端的設計。假設我們的業務需求非常單一，只需要某些特定的Cuboid，那么可以創建多個聚合組，每個聚合組代表一個Cuboid。具體的方法是在聚合組中先包含某個Cuboid所需的所有維度，然后把這些維度都設置為強制維度。這樣當前的聚合組就只能產生我們想要的那一個Cuboid了。

再比如，有的時候我們的Cube中有一些基數非常大的維度，如果不做特殊處理，它就會和其他的維度進行各種組合，從而產生一大堆包含它的Cuboid。包含高基數維度的Cuboid在行數和體積上往往非常龐大，這會導致整個Cube的膨脹率變大。如果根據業務需求知道這個高基數的維度只會與若干個維度（而不是所有維度）同時被查詢到，那么就可以通過聚合組對這個高基數維度做一定的“隔離”。我們把這個高基數的維度放入一個單獨的聚合組，再把所有可能會與這個高基數維度一起被查詢到的其他維度也放進來。這樣，這個高基數的維度就被“隔離”在一個聚合組中了，所有不會與它一起被查詢到的維度都沒有和它一起出現在任何一個分組中，因此也就不會有多余的Cuboid產生。這點也大大減少了包含該高基數維度的Cuboid的數量，可以有效地控制Cube的膨脹率。

Row Key優化

Kylin會把所有的維度按照順序組合成一個完整的Rowkey，并且按照這個Rowkey升序排列Cuboid中所有的行。

設計良好的Rowkey將更有效地完成數據的查詢過濾和定位，減少IO次數，提高查詢速度，維度在rowkey中的次序，對查詢性能有顯著的影響。

Row key的設計原則如下：

1）被用作where過濾的維度放在前邊。

2）基數大的維度放在基數小的維度前邊。

并發粒度優化

當Segment中某一個Cuboid的大小超出一定的閾值時，系統會將該Cuboid的數據分片到多個分區中，以實現Cuboid數據讀取的并行化，從而優化Cube的查詢速度。具體的實現方式如下：構建引擎根據Segment估計的大小，以及參數“kylin.hbase.region.cut”的設置決定Segment在存儲引擎中總共需要幾個分區來存儲，如果存儲引擎是HBase，那么分區的數量就對應于HBase中的Region數量。kylin.hbase.region.cut的默認值是5.0，單位是GB，也就是說對于一個大小估計是50GB的Segment，構建引擎會給它分配10個分區。用戶還可以通過設置kylin.hbase.region.count.min（默認為1）和kylin.hbase.region.count.max（默認為500）兩個配置來決定每個Segment最少或最多被劃分成多少個分區。

由于每個Cube的并發粒度控制不盡相同，因此建議在Cube Designer 的Configuration Overwrites（上圖所示）中為每個Cube量身定制控制并發粒度的參數。假設將把當前Cube的kylin.hbase.region.count.min設置為2，kylin.hbase.region.count.max設置為100。這樣無論Segment的大小如何變化，它的分區數量最小都不會低于2，最大都不會超過100。相應地，這個Segment背后的存儲引擎（HBase）為了存儲這個Segment，也不會使用小于兩個或超過100個的分區。我們還調整了默認的kylin.hbase.region.cut，這樣50GB的Segment基本上會被分配到50個分區，相比默認設置，我們的Cuboid可能最多會獲得5倍的并發量。