我們部門為公司其他業務線提供各種大數據平臺，如麒麟、HBase、Spark、Flink等。提供統壹的平臺系統，必然會涉及到用戶管理、資源隔離、部門內各種平臺整合等問題。然而，Kylin現有的用戶管理和資源隔離機制無法滿足我們的需求。基於此，我們對麒麟進行了平臺化改造。平臺改造完成後，希望在以下幾個方面做壹些改進:
1.用戶管理
為了方便系統的管理和安全，公司有自己的認證系統，需要通過個人賬號進行驗證。所以麒麟作為壹個對外提供服務的平臺，需要接入系統。因此，我們增加了壹個用戶管理界面，它顯示了Kylin平臺中的所有用戶。管理員可以將任何用戶添加到Kylin平臺。添加用戶時會填寫企業微信名稱，用戶角色，是否激活用戶。當用戶登錄系統時，系統會自動檢測用戶賬號以及該賬號是否在平臺註冊。如果沒有註冊，就沒有權限，否則會自動登錄系統。
2.內部配置單元兼容性
由於歷史原因，我部的THive版本與Kylin不兼容，導致Kylin無法正常訪問Kylin集群，所以我們采用了上圖所示的兼容方案。首先，我們使用社區Hive版本構建壹個全新的Hive，並將其作為Kylin的默認Hive。其次，kylin加載源表時，我們通過內部的UPS系統讀取THive的元數據信息。最後，當負載源表轉移到Kylin時，我們根據表的元數據信息在Kylin的Hive上創建相同的表，但表的存儲路徑仍然指向THive的路徑，而用戶在構建cube時訪問新創建的表，從而解決了Kylin訪問THive的問題。
3.可配置的計算資源
目前Kylin配置計算資源信息有兩種方式:壹種是在Kylin配置文件中配置壹個全局計算集群和隊列；其次，在創建項目或多維數據集時，在擴展參數中指定集群配置。這兩種配置方式靈活性和便捷性都較差，我們內部有壹個接口獲取某個用戶的計算集群和計算隊列的計算資源。因此，在創建項目或立方體時，我們使用下拉框選擇方式，讓用戶選擇提交任務的計算資源和隊列，從而大大簡化了用戶的使用流程。
4.通知機制
麒麟只提供郵件通知的功能，而微信和企業微信作為目前使用最廣泛的工具，在實時性和便捷性上遠遠優於郵件，所以我們提供郵件、微信和企業微信三種方式供用戶選擇。
5.定時調度
Kylin系統本身不提供預定調度功能，但基本上每個公司都有自己的統壹調度平臺，我們也不例外。通過Kylin提供的API接口，我們將Cube的正則構造的功能作為插件集成到公司內部的統壹調度平臺中。
6.服務訪問
經過上述平臺化改造，麒麟平臺基本具備了接入不同類型服務的能力，用戶應用接入流程如上圖所示。
商業用途:
麒麟是今年年初才被介紹到我們團隊的。目前已經使用的業務主要有QQ音樂、騰訊視頻、廣點通、財付通等。立方體數量為10，單個數據存儲總量為5 T，數據規模約30億。
弗林克立方發動機的原理與實踐
目前Kylin已經支持使用MapReduce和Spark作為構建引擎，但是大數據這種比較熱的流和批的計算引擎怎麽會缺席呢？所以我用Flink開發了壹個高性能的構建引擎:Flink Cube Engine。
Flink Cube Engine是騰訊基於Kylin插件Cube Engine架構開發的高性能建築引擎。目前已經具備了在線使用的能力。有興趣的同學可以體驗壹下。目前該引擎已經在騰訊生產環境上線1個月+，非常穩定有效。
總括問題:
/Apache/kylin/tree/engine-flink
1.支持Flink引擎子任務。
Kylin的立方體構建任務包含許多子任務，其中最重要的是立方體構建步驟。因此，在構建和合並立方體這兩個任務中，立方體構建步驟是優先考慮的，其他計算步驟仍然使用MapReduce來實現。
2.如何使用Flink Cube引擎
選擇Flink Cube引擎的方法與選擇Map Reduce和Spark任務的方法類似。我們提供了壹個前臺可視化界面供用戶選擇。
3.Flink Cube引擎和Spark(在線業務)
上圖是我們內部業務推出Flink Cube引擎後的性能對比。從圖中可以看出，這壹步的施工時間從49分鐘縮減到了13分鐘，優化效果明顯。兩種情況下的資源分配如下:
Flink配置為:
-YTM 4G-yjm 2G-ys 1-p 100-yn 100
Spark采用以下資源動態分配:
kylin . engine . spark-conf . spark . dynamic allocation . enabled = true
kylin . engine . spark-conf . spark . dynamic allocation . minexecutors = 2
kylin . engine . spark-conf . spark . dynamic allocation . max executors = 1000
kylin . engine . spark-conf . spark . dynamic allocation . executor idle time out = 300
kylin . engine . spark-conf . spark . shuffle . service . enabled = true
kylin . engine . spark-conf . spark . shuffle . service . port = 7337
雖然Spark使用的是動態分配資源，但是在任務執行過程中，我們觀察到Spark實際分配的資源遠遠多於Flink。
那為什麽性能提升這麽明顯？
4.弗林克立方發動機的優化
性能提升的原因只有兩個，壹個是參數的優化，壹個是代碼的優化。
1)參數調整
影響Flink任務性能的核心參數有幾個:並行度、單個TM槽數和TM容器數，其中單個TM容器數=並行度/單個TM槽數。
在調優過程中，我們采用了控制變量法，即固定並行度和固定作業總內存數。通過不斷調整單個TM的槽數，我們發現如果單個TM的槽數減少，拉起更多TM容器的性能會更好。
此外，我們還使用了對象重用、內存預分配等方法，發現對性能提升並沒有太大作用。
2)代碼優化(合並計算)
在實現Flink Cube引擎的時候，我們壹開始用了Map/Reduce算子，發現性能很差，比Spark差很多。後來，我們通過調整Flink的mapPartition/reduceGroup運算符，明顯提高了性能。
Flink Cube引擎的下壹步計劃:
1.全鏈接Flink
如上所述，目前在立方體構建過程中，只有最關鍵的立方體構建子任務使用Flink，其他子任務仍然使用MapReduce。我們將繼續改進Flink Cube引擎，並使用Flink構建所有子任務。
2.Flink升級到1.9
Flink最近發布了1.9.0，包含了很多重要的特性，性能也有所提升，所以我們會將Flink Cube引擎使用的Flink版本升級到1.9.0。