原文地址：https://kylin.apache.org/docs16/howto/howto_optimize_build.html

Kylin將一個cube的build過程分解為若干個子步驟，然后串行執(zhí)行這些子步驟。這些步驟包括Hive操作，MR任務(wù)和其他類型的工作。如果每天都有許多cube進(jìn)行build操作，那么肯定會辦法加速這一過程。這里有一些建議可以參考，我們就按照build的順序依次介紹。

Create Intermediate Flat Hive Table

該步驟會從源Hive表中抽取數(shù)據(jù)（將所有的相關(guān)表join之后的數(shù)據(jù)），并且插入到一個臨時的扁平表中。如果cube是帶有分區(qū)列的，Kylin將會增加一個時間條件，這樣就會保證只有符合條件的數(shù)據(jù)才會被抓取?？梢栽谌罩局胁榭磁c該步驟相關(guān)的Hive命令。如下所示：

當(dāng)執(zhí)行Hive命令的時候，Kylin會使用conf/kylin_hive_conf.xml中的配置項，例如，使用更少的副本數(shù)和允許Hive的mapper連接操作。如果有需要的話，也可以添加其他的配置項。

如果Cube的分區(qū)列（這里是“FLIGHTDATE ”）與Hive表的分區(qū)列是同一個列，那么對于該列進(jìn)行過濾將會使Hive非?？焖俚靥蕹环蠗l件的分區(qū)。因此強(qiáng)烈建議使用Hive的分區(qū)列（如果該分區(qū)列是日期）作為Cube的分區(qū)列。這對于數(shù)據(jù)非常多的表來說幾乎是必須的，否則在執(zhí)行這一步驟的時候，Hive每次都需要掃描所有的文件，會耗費很多時間。

如果你的Hive允許文件合并，你可以在“conf/kylin_hive_conf.xml”中通過配置項來禁用這一功能。因為Kylin有它自己的文件合并方法（我們將在下面介紹）：

Redistribute intermediate table

經(jīng)過上一個步驟之后，Hive會在HDFS的目錄中生成一些數(shù)據(jù)文件，但是一些文件可能會很大，而另外一些文件可能會很小甚至是空的。文件大小分布的不均衡也會導(dǎo)致后續(xù)的MR任務(wù)執(zhí)行的不平衡：一些mapper任務(wù)會執(zhí)行的很快，而其他的mapper可能會執(zhí)行的很慢。為了使這些數(shù)據(jù)分布的更均勻一些，Kylin增加了該步驟用來重新分配各個數(shù)據(jù)文件中的數(shù)據(jù)。下面是一個簡單的輸出：

重分配數(shù)據(jù)之后執(zhí)行的Hive命令如下所示：

首先，Kylin會獲取臨時表的行數(shù)；然后，基于這個行數(shù)就可以獲取需要進(jìn)行數(shù)據(jù)重分配的文件的數(shù)量。Kylin默認(rèn)一個文件包含1百萬行的數(shù)據(jù)。在這個例子中，一共有1.6億行數(shù)據(jù)和160個reducer，并且每個reducer寫一個文件。在后續(xù)的MR步驟中，Hadoop將會啟動相同數(shù)量的mapper來對這些文件進(jìn)行處理（通常1百萬行數(shù)據(jù)的大小會比一個HDFS塊要?。?。如果日常的數(shù)據(jù)規(guī)模不是很大或者Hadoop集群有足夠的資源，可以通過在“conf/kylin.properties”中將配置項“kylin.job.mapreduce.mapper.input.rows”設(shè)置為更小的值來獲取更高的并發(fā)度，如下所示：

其次，Kylin通過運行一個HiveQL “INSERT OVERWIRTE TABLE … DISTRIBUTE BY …” 來為指定數(shù)目的reducer重新分配數(shù)據(jù)行。

在大多數(shù)情況下，Kylin會要求Hive隨機(jī)地為這些reducer重新分配數(shù)據(jù)行，以保證這些文件在大小上相近。此時，重分配語句就是 “DISTRIBUTE BY RAND()”。

如果Cube中確定了一個“shard by”維度列（在Cube的“Advanced setting”界面進(jìn)行設(shè)置），該維度列是一個基數(shù)很大的維度列（例如“USER_ID”），那么Kylin會要求Hive通過該維度列的值來重新分配數(shù)據(jù)。對于該列擁有相同值的數(shù)據(jù)行將會被分配在同一個文件中。這比隨機(jī)分配要好，因為數(shù)據(jù)不僅被重新分配了，而且在沒有消耗額外成本的情況下就對數(shù)據(jù)進(jìn)行了重新分類，這對于后續(xù)的Cube構(gòu)建過程是有幫助的。在特定的情況下，這種優(yōu)化可以減少40%的構(gòu)建時間。這種情況下的重分配語句就是 “DISTRIBUTE BY USER_ID”。

請注意： 1.設(shè)置為“shard by”的維度列應(yīng)該是一個基數(shù)很大的維度列，并且它會出現(xiàn)在很多cuboid中（不會是僅僅出現(xiàn)在很少的cuboid中）。使用它進(jìn)行重分配可能會在每一個時間間隔上獲得等分布；反之則會造成數(shù)據(jù)傾斜，而這則會減少構(gòu)建速度。典型的適合情景就是：“USER_ID”，“SELLER_ID”，“PRODUCT”，“CELL_NUMBER”等等，一般基數(shù)應(yīng)該大于1000（應(yīng)該遠(yuǎn)遠(yuǎn)大于reducer的數(shù)目）。 2.使用“shard by”在Cube存儲中還有其他的優(yōu)勢，但不在本文的討論范圍中。

Extract Fact Table Distinct Columns

在此步驟中，Kylin通過運行一個MR任務(wù)來獲取維度列的distinct值，用于進(jìn)行字典編碼。

實際上，該步驟還做了其他的工作：通過使用HyperLogLog計數(shù)器預(yù)估每個cuboid的行數(shù)，依次來收集cube的統(tǒng)計信息。如果你發(fā)現(xiàn)mapper任務(wù)執(zhí)行非常慢，通過就意味著cube設(shè)計的太復(fù)雜，可以參考：Cube設(shè)計優(yōu)化，對cube進(jìn)行優(yōu)化，使cube更加精簡。如果reducer發(fā)生了OOM錯誤，通常意味著cuboid的維度組合數(shù)太多或者默認(rèn)的yarn內(nèi)存分配不能滿足需求。如果此步驟不能在合理的時間內(nèi)完成，請重新對cube進(jìn)行設(shè)計，因為真正的build過程會花費更長的時間。

你可以減少采樣比例（通過在kylin.properties中設(shè)置kylin.job.cubing.inmem.sampling.percent配置項），來加速該步驟的執(zhí)行，但是這可能不會有太大的效果，而且還會影響cube統(tǒng)計信息的準(zhǔn)確性，因此一般不推薦這么做。

Build Dimension Dictionary

在上一步中已經(jīng)獲得了所有維度列的distinct值，接著Kylin將會在內(nèi)存中構(gòu)建字典（在下個版本中將會將此操作移到MR任務(wù)中）。通常這一步會很快，但是如果distinct值的集合很大，Kylin可能會報錯，例如，“Too high cardinality is not suitable for dictionary”。對于UHC（超大容量）列，請使用其他編碼方式，例如“fixed_length”，“integer”等。

Save Cuboid Statistics and Create HTable

這兩個步驟是輕量級的，并且很快。

Build Base Cuboid

這一步是通過臨時表構(gòu)建基本的cuboid，這是逐層算法的第一輪MR任務(wù)。Mapper的數(shù)量等于步驟二中reducer的數(shù)量；而Reducer（這里指的是本步驟中啟動的reducer）的數(shù)量是通過cube的統(tǒng)計信息預(yù)估出來的：默認(rèn)每500M使用一個reducer。如果你發(fā)現(xiàn)reducer的數(shù)目很少，可以通過在kylin.properties中對配置項“kylin.job.mapreduce.default.reduce.input.mb”設(shè)置更小的值，來獲取更多的集群資源，如下所示： kylin.job.mapreduce.default.reduce.input.mb=200

Build N-Dimension Cuboid

這些步驟是逐層算法的處理過程，每一步都使用前一步的輸出作為輸入，然后去除某個維度進(jìn)行聚合，生成一個子cuboid。例如，對于cuboid ABCD，去除維度A可以獲得cuboid BCD，去除維度B可以獲得cuboid ACD等。

有些cuboid可以通過一個以上的父cuboid聚合而成，在這種情況下，Kylin將會選擇最小的父cuboid。例如，AB能夠通過ABC（id：1110）和ABD（id：1101）聚合生成，因此ABD會被作為父cuboid使用，因為它的id比ABC要小。基于以上處理，如果D的基數(shù)很小，那么此次聚合操作就會花費很小的代價。因此，當(dāng)設(shè)計cube的rowkey順序的時候，請記住，將低基數(shù)的維度列放在尾部。這不僅對cube的構(gòu)建過程有好處，而且對cube查詢也有好處，因為后聚合（應(yīng)該是指在HBase查找對應(yīng)cuboid的過程）也遵循這個規(guī)則。

通常從N-D到(N/2)-D的構(gòu)建過程很慢，因為這是一個cuboid爆炸增長的過程：N-D有1個cuboid，(N-1)-D有N個cuboid，(N-1)-D有N*(N-1)個cuboid等等。在(N/2)-D步驟之后，構(gòu)建過程會越來越快。

Build Cube

這一步驟使用了一種新的算法來構(gòu)建cube：逐塊算法（也稱作“in-mem”算法）。該算法只使用一輪MR任務(wù)來構(gòu)建所有的cuboid，但它比逐層算法需要更多占用更多的內(nèi)存。該步驟在執(zhí)行的時候會使用“conf/kylin_job_conf_inmem.xml”中的相關(guān)配置項。默認(rèn)情況下，每個mapper需要3G的內(nèi)存。如果集群有足夠大的內(nèi)存，可以在“conf/kylin_job_conf_inmem.xml”中通過修改配置來獲取更大的內(nèi)存，這樣就可以處理更多的數(shù)據(jù)，并且性能也會更好。修改配置如下所示：

請注意，Kylin會根據(jù)數(shù)據(jù)分布（通過cube統(tǒng)計信息獲取）自動地選擇合適的cube構(gòu)建算法。一般不需要顯示地選擇使用哪個算法。

Convert Cuboid Data to HFile

這一步會啟動一個MR任務(wù)用來將cuboid文件（順序文件格式）轉(zhuǎn)換為Hbase的HFile文件。Kylin通過cube的統(tǒng)計信息來計算HBase的region個數(shù)，默認(rèn)每個region大小是5G。Region數(shù)越多，就會使用更多的reducer。如果發(fā)現(xiàn)reducer的數(shù)目很少，并且性能很差，就可以在“conf/kylin.properties”中增加如下配置項：

如果不能確定一個HBase的region該設(shè)置為多大，請聯(lián)系HBase管理員。

Load HFile to HBase Table

這一步使用了HBase API將HFile導(dǎo)入到HBase的region中，這一步很簡單，也很快。

Update Cube Info

將數(shù)據(jù)導(dǎo)入Hbase中之后，Kylin會將新生成的segment在元數(shù)據(jù)中的狀態(tài)修改為ready。這一步也非?？?。

Cleanup

這一步主要就是從Hive中刪除臨時表。由于在上一步中，已經(jīng)將segment的狀態(tài)修改為ready，所以這一步的操作不會對segment產(chǎn)生任何影響。即使這一步執(zhí)行發(fā)生了錯誤，也不需要擔(dān)心，因為所有的垃圾都會在Kylin執(zhí)行StorageCleanupJob的時候進(jìn)行回收。