Apache Kylin權威指南2.4 建構Cube

<b>2.4　建構cube</b>

<b></b>

本節将快速介紹建構cube相關的操作說明和設定，因受到篇幅的限制，許多具體内容無法深入展開，讀者可以從後續的第3章和第4章中獲得更詳細的介紹。

新建立的cube隻有定義，而沒有計算的資料，它的狀态是“disabled”，是不會被查詢引擎挑中的。要想讓cube有資料，還需要對它進行建構。cube的建構方式通常有兩種：全量建構和增量建構；兩者的建構步驟是完全一樣的，差別隻在于建構時讀取的資料源是全集還是子集。

cube的建構包含如下步驟，由任務引擎來排程執行。

1）建立臨時的hive平表（從hive讀取資料）。

2）計算各次元的不同值，并收集各cuboid的統計資料。

3）建立并儲存字典。

4）儲存cuboid統計資訊。

5）建立htable。

6）計算cube（一輪或若幹輪mapreduce）。

7）将cube的計算結果轉成hfile。

8）加載hfile到hbase。

9）更新cube中繼資料。

10）垃圾回收。

以上步驟中，前5步是為計算cube而做的準備工作，例如周遊次元值來建立字典，對資料做統計和估算以建立htable等；第6）步是真正的cube計算，取決于所使用的cube算法，它可能是一輪mapreduce任務，也可能是n（在沒有優化的情況下，n可以被視作是次元數）輪疊代的mapreduce。由于cube運算的中間結果是以sequencefile的格式存儲在hdfs上的，是以為了導入到hbase中，還需要第7）步将這些結果轉換成hfile（hbase檔案存儲格式）。第8）步通過使用hbase bulkload工具，将hfile導入進hbase叢集，這一步完成之後，htable就可以查詢到資料了。第9）步更新cube的資料，将此次建構的segment的狀态從“new”更新為“ready”，表示已經可供查詢了。最後一步，清理建構過程中生成的臨時檔案等垃圾，釋放叢集資源。

monitor頁面會顯示目前項目下近期的建構任務。圖2-19顯示了一個正在運作的cube建構的任務，目前進度為46%多。

圖2-19　任務清單

單擊任務右邊的“”按鈕，展開可以得到任務每一步的詳細資訊，如圖2-20所示。

如果任務中的某一步是執行hadoop任務的話，那麼會顯示hadoop任務的連結，單擊即可跳轉到對應的hadoop任務監測頁面，如圖2-21所示。

如果任務執行中的某一步出現報錯，那麼任務引擎會将任務狀态置為“error”并停止後續的執行，等待使用者排錯。在錯誤排除之後，使用者可以單擊“resume”從上次失敗的地方恢複執行。或者如果需要修改cube或重新開始建構，那麼使用者需要單擊“discard”來丢棄此次建構。

接下來将介紹幾種不同的建構方式。

圖2-21　mapreduce任務監測頁面

2.4.1　全量建構和增量建構

1.?全量建構

對資料模型中沒有指定分割時間列資訊的cube，kylin會采用全量建構，即每次從hive中讀取全部的資料來開始建構。通常它适用于以下兩種情形。

事實表的資料不是按時間增長的。

事實表的資料比較小或更新頻率很低，全量建構不會造成太大的開銷。

2.?增量建構

增量建構的時候，kylin每次都會從hive中讀取一個時間範圍内的資料，然後進行計算，并以一個segment的形式進行儲存。下次再建構的時候，會自動以上次結束的時間為起點時間，再選擇新的終止時間進行建構。經過多次建構，cube中将會有多個segment依次按時間順序進行排列，如seg-1, seg-2，…，seg-n。查詢的時候，kylin會查詢一個或多個segment然後再做聚合計算，以便傳回正确的結果給請求者。

使用增量建構的好處是，每次隻需要對新增資料進行計算，進而避免了對曆史資料進行重複計算。對于資料量很大的cube，使用增量建構是非常有必要的。

圖2-22是建構一個segment的cube時的輸入框，需要使用者選擇時間範圍。

圖2-22　送出增量建構

在從hive讀取源資料的時候，kylin會帶上此時間條件，如圖2-23所示。

圖2-23　增量建構的sql

增量建構抽取資料的範圍，采用了前包後閉的原則，即包含了開始時間，但不包含結束時間，進而保證上一個segment的結束時間與下一個segment的起始時間相同，但資料不會重複。

下一次建構的時候，起始時間必須是上一次的結束時間。如果使用kylin的web gui觸發，那麼起始時間會被自動填寫，使用者隻需要選擇結束時間。如果使用rest api觸發，使用者則需要確定時間範圍不會與已有的segment有重合。

2.4.2　曆史資料重新整理

cube建構完成以後，如果某些曆史資料發生了改動，那麼需要針對相應的segment進行重新計算，這種建構稱為重新整理。重新整理通常隻針對增量建構的cube而言，因為全量建構的cube隻要重新全部建構就可以得到更新；而增量更新的cube因為有多個segment，是以需要先選擇要重新整理的segment，然後再進行重新整理。

圖2-24是送出重新整理的請求頁面，使用者需要在下拉清單中選擇一個時間區間。

圖2-24　重新整理已有的segment

送出以後，生成的建構任務與最初的建構任務完全一樣。

在重新整理的同時，cube仍然可以被查詢，隻不過傳回的是陳舊資料。當segment重新整理完畢時，新的segment會立即生效，查詢開始傳回最新的資料。老segment則成為垃圾，等待回收。

2.4.3　合并

随着時間的遷移，cube中可能會存在較多數量的segment，使得查詢性能下降，并且會給hbase叢集管理帶來壓力。對此，需要适時地将一些segment進行合并，将若幹個小segment合并成較大的segment。

合并的好處具體如下。

合并相同的key，進而減少cube的存儲空間。

由于segment減少了，是以可以減少查詢時的二次聚合，提高了查詢性能。

htable的數量得以減少，更便于叢集的管理。

下面來看看合并的操作步驟，圖2-25中的cube有兩個segment。

現在觸發一個合并，單擊actions →merge；選擇要合并的起始segment和結束segment，生成一個合并的任務，如圖2-26所示。

圖2-26　送出合并任務

合并的時候，kylin将直接以當初各個segment建構時生成的cuboid檔案作為輸入内容，而不需要從hive加載原始資料。後續的步驟跟建構時基本一緻。直到新的htable加載完成後，kylin才會解除安裝舊的htable，進而確定在整個合并過程中，cube都是可以查詢的。

合并完成之後，此cube的segment減少為1個，如圖2-27所示。