Apache Kylin在鏈家的實踐

作者：王龍帥、張如松

作者簡介：鏈家網工程師，大數據架構團隊成員，目前主要負責OLAP平台建設及大數據應用拓展。

前言

伴隨鏈家業務線的拓寬和發展，以及數據生態的建設，數據規模快速增長。從2015年大數據部門成立至今，集群數據存儲量為9PB，伺服器規模為200台+。與此同時，數據需求也隨著業務的發展落地不斷增長，如統計分析、指標API、運營報表等，不同業務需求差異較大，維度越來越多，需要定製化開發。面對數十億行級別的數據，低延遲響應的特性，保障服務穩定、數據準確，鏈家的數據分析引擎經歷了如下的發展歷程。

早期的ROLAP架構

起初，數據規模不大，增長不是很快。而且，數據需求比較零散，處於摸索階段。採用如下ROLAP引擎，支撐數據分析：

具體處理流程：數據源接入HDFS，載入進HIVE。數據開發工程師根據業務需求，開發ETL腳本，配置OOZIE任務調度執行，根據數據倉庫分層模型，逐層生成數據，最終推送到mySQL，根據維度篩選、聚合展示。

隨著數據規模的增長和需求的增多，瓶頸逐漸顯現。每個需求都要開發數據腳本，維度增加，開發周期拉長，同時需要耗費更多的人力，無法快速產出數據和響應需求變化。

鏈家OLAP平台及Kylin使用

如上，為鏈家OLAP平台結構，於16年底搭建。Kylin採用集群部署模式，共部署6台機器，3台用於分散式構建Cube，3台用於負載均衡查詢，query單台可用內存限制在80G。同時，計算集群一旦運行大任務，內存壓力大的時候，Hbase 就會性能非常差，為避免和計算集群互相影響，Kylin集群依賴獨立的Hbase集群。同時，對Hbase集群做了相應的優化，包括：讀寫分離、SSD_FIRST 優先讀取遠程SSD、並對依賴的HDFS做了相應優化。

由於Kylin只專註預計算，不保存明細數據，對於即席查詢和明細查詢，通過自研QE引擎實現，底層依賴Spark、Presto、HIVE，通過特定規則，路由到相應查詢引擎執行查詢。多維分析查詢，由Kylin集群提供查詢服務，可實現簡單的實時聚合計算。

當前Kylin主要查詢方為指標API平台，能根據查詢SQL特徵，做相應緩存。指標API作為數據統一出口，衍生出其他一些業務產品。使用統計，如下：Cube數量350+，覆蓋公司12個業務線。Cube存儲總量200+TB，數據行萬億級，單Cube最大40+億行。日查詢量27萬+，緩存不命中情況下，時延<500ms(70%), <1s(90%)，少量複雜SQL查詢耗時10s左右。

Kylin應用場景及使用規範

適用場景：數據規模大，非實時，目前能支持小時級別；維度組合和查詢條件組合在可預見的範圍內；查詢條件掃描範圍不會太大；不適合需要大範圍模糊搜索排序的場景（類似Search）。

如何能規範的使用Kylin很重要，在Kylin建設初期，踩過很多坑。並不是程序的錯誤，而是未能詳細了解Kylin使用流程及規範，逐漸摸清積累了一些經驗，沉澱到公司wiki，供相關人員參考。大致如下：

一、維度優化，預計算的結果需要存儲到Hbase，且支持實時查詢，因此，在配置維度時，要考慮到存儲和查詢的優化。包括：維度的編碼，根據維度的值類型，選擇合適的存儲類型，可節省空間，加快Hbase scan效率；可根據業務需要，對維度進行分片存儲，增加查詢的並發度，縮短查詢時間；基數允許範圍內的維度，盡量採用字典編碼；對於分區欄位，一般格式為yy-MM-dd hh:mm:ss，若只需要細化到天級別，可保存為數字類型yyMMdd，極大降低維度基數。

二、根據Hbase的查詢特性，rowkeys是由維度組合拼接而成，因此要考慮到以後查詢場景：對於查詢頻繁的維度，在設置rowkeys時，優先放在前面。

三、維度組合優化，由於維度的組合影響最終的數據量，因此如何能減少維度的組合，是Cube配置時所要考慮的。根據業務需要，及Kylin支持的特性，可進行的維度組合優化有：使用衍生維度，只物化維度表的主鍵，犧牲部分運行時性能進行實時join聚合；使用聚合組，將相關維度內聚成一組，並在聚合組內，根據維度的特徵，配置強制維度、層級維度、聯合維度。聚合組的設計可以非常靈活，例如，高基數的維度，可以單獨一個group。

四、及時清理失效數據。由於構建過程出錯或者集群故障，會導致一些垃圾文件，隨著時間積累的一些無用segment，不但佔用存儲空間，增加namenode內存壓力，以及佔用Hbase、HIVE及Kylin元數據空間，因此需要定期清理掉，保持存儲環境乾淨。

應該實時監控集群狀態，重點關注Cube構建和查詢的低延遲，不斷優化數據模型及Cube的設計和存儲，根據用戶真正的需求，在存儲、構建及查詢性能間找到最佳的平衡點。

鏈家Kylin能力擴展

當前，Kylin在用版本為1.6，最新版本為2.3。自2.0版本之後，又新增了一些新的特性，配置文件和屬性也做了一些調整。由於，Cube數據量大，涉及業務方多，在當前無明顯瓶頸的情況下，沒有實時更新新版本。但是，引入了2.0+新增的一些重要特性，如分散式構建和分散式鎖。 我們維護了自己的一套Kylin代碼，使用過程中，針對特定場景的進行一些優化開發，包括：

一、支持分散式構建。原生Kylin是只能有一台機器進行構建。的當Kylin上的Cube越來越多，單台機器顯然不能滿足任務需求，除了任務數據有限制，任務多時也會互相影響數據構建的效率。通過修改Kylin的任務調度策略，支持了多台機器同時構建數據。使Kylin的構建能力可以橫向擴展，來保證數據構建；

二、優化構建時字典下載策略。原生Kylin在build cubiod data時用的字典，會將該欄位的全部字典下載到節點上，當欄位的字典數量很多或者字典文件很大時，會在文件傳輸上消耗很多不必要的時間。通過修改代碼，使任務只下載需要的字典文件，從而減少文件傳輸時間消耗，加快構建；

三、全局字典鎖，在同一Cube所任務構建時，由於共享全局字典鎖，當某執行任務異常時，會導致其他任務獲取不到鎖，此bug已修復並提交官方（https://issues.apache.org/jira/browse/KYLIN-3087）；

四、當有多台query情況下，元數據同步時，RestClient採用的BasicClientConnManager會遇到並發瓶頸，拋出異常，解決方案為替換成PoolingClientConnectionManager，並提交官方（https://issues.apache.org/jira/browse/KYLIN-2862）；

五、同一Cube構建多個segment時，假如第一次構建的segment時間段晚於第二個segment，會取第一次的last_build_time作為最後一次構建時間，取值錯誤，已修復提交官方（https://issues.apache.org/jira/browse/KYLIN-2789）；

六、支持設置Cube強制關聯維表，過濾事實表中無效的維度數據。Kylin創建的臨時表作為數據源。當使用OLAP表和維表關聯欄位作為維度時，會默認不關聯維表，直接使用OLAP中的欄位做維度。而在Build Cube這一步又會使用維表的字典來轉換維度的值。如果OLAP中的值維表中沒有就會產生問題。我們通過增加配置項，可以使Kylin強制關聯維表，來過濾掉OLAP表中的臟數據；

七、Kylin query機器，查詢或者聚合，會載入大量的數據到內存，內存佔用大，甚至存在頻繁Full GC的情況。這種情況下，CMS垃圾回收表現不是很好，因此更換為G1收集器，盡量做到STW時間可控，並及時調優。

除了上述對Kylin本身的修改外，我們開發了Kylin中間件實現了任務調度、狀態監控、許可權管理等功能。

Kylin中間件

中間件承接Cube管理及任務的調度，對外屏蔽了Kylin集群，架構圖如下

可實現如下功能增強：

一、理論上，可實現無限容量隊列，現實中不會有這麼大任務量，也不會一直堆積；

二、同時，針對特定的Cube，實現優先調度，保障重要數據的及時產出；

三、元數據管理平台，可通過中間件執行SQL查詢，而指標API平台，需要預先在元數據管理平台配置API查詢介面，配置時可看到自身許可權對應的數據，由此實現許可權的管控；

四、當任務執行失敗，可進行有限次數重試，重試不成功會報警；

五、同時，可實現並發控制，由於Kylin集群的承載能力有限，過多的任務同時執行，會造成大量任務失敗，目前設置最多提交50個構建任務同時運行。

總結

Kylin引擎核心組件可擴展，支持超大規模數據，ANSI SQL易用性高，作為鏈家OLAP平台的關鍵組件，基本承載了全部的多維分析需求，提升了數據產出效率和查詢性能。相比rOLAP架構，現在只需關注基礎數據建設和數據探索，節省了大量人力，並提高了整體可維護性。

在OLAP平台建設期間，Kyligence給予我們很大幫助，並和其他公司保持技術交流。Kylin社區很活躍，核心開發團隊也非常熱心、高效，作為國人主持開源的apache頂級項目，希望Kylin和社區有更好的發展。

未來，我們會持續跟蹤業務需求，不斷優化集群性能，提升集群穩定性和易用性。並重點關注大結果集查詢性能、Spark構建引擎、任務資源隔離等。 關於鏈家大數據架構團隊

鏈家網大數據架構團隊負責公司大數據存儲平台、計算平台、實時數據流平台的架構、性能優化、研發等，提供高效的大數據OLAP引擎、以及大數據工具鏈組件研發，為公司提供穩定、高效、開放的大數據基礎組件與基礎平台。