【硬剛Kylin】Kylin入門/原理/調(diào)優(yōu)/OLAP解決方案和行業(yè)典型應(yīng)用

一：背景歷史和使命

背景和歷史

現(xiàn)今，大數(shù)據(jù)行業(yè)發(fā)展得如火如荼，新技術(shù)層出不窮，整個(gè)生態(tài)欣欣向榮。作為大數(shù)據(jù)領(lǐng)域最重要的技術(shù)的 Apache Hadoop 最初致力于簡單的分布式存儲，然后在此基礎(chǔ)之上實(shí)現(xiàn)大規(guī)模并行計(jì)算，到如今在實(shí)時(shí)分析、多維分析、交互式分析、機(jī)器學(xué)習(xí)甚至人工智能等方面有了長足的發(fā)展。

2013 年年初，在 eBay 內(nèi)部使用的傳統(tǒng)數(shù)據(jù)倉庫及商業(yè)智能平臺碰到了“瓶頸”。年中，eBay 公司啟動(dòng)了一個(gè)大數(shù)據(jù)項(xiàng)目，其中有一部分內(nèi)容就是 BI on Hadoop 的預(yù)研。經(jīng)過一年多的研發(fā)，2014 年 9 月底，代號 Kylin 的大數(shù)據(jù)平臺在 eBay 內(nèi)部正式上線。10 月 1 日，Kylin 項(xiàng)目負(fù)責(zé)人韓卿將 Kylin 的源代碼提交到 github.com 并正式開源。當(dāng)天就得到了業(yè)界專家的關(guān)注和認(rèn)可。

圖片所示為 Hortonworks 的 CTO 對 Apache Kylin 的 Twitter 評價(jià)。

Hadoop 社區(qū)的許多朋友都鼓勵(lì) eBay 將該項(xiàng)目貢獻(xiàn)到 Apache 軟件基金會(ASF)，讓它與其他大數(shù)據(jù)項(xiàng)目一起獲得更好的發(fā)展。Kylin 項(xiàng)目于 2014 年 11 月正式加入 Apache 孵化器項(xiàng)目。2015 年 11 月，Apache 軟件基金會宣布 Apache Kylin 正式成為頂級項(xiàng)目。這是第一個(gè)完全由中國團(tuán)隊(duì)貢獻(xiàn)到全球最大的開源軟件基金會的頂級項(xiàng)目。

2016 年 3 月，由 Apache Kylin 核心開發(fā)者組建的創(chuàng)業(yè)公司 Kyligence 正式成立。

2015 年 9 月，Apache Kylin 與 Apache Spark、Apache Kafka、H2O、Apache Zeppelin 等一同獲得了 2015 年度“最佳開源大數(shù)據(jù)工具獎(jiǎng)”。這是業(yè)界對 Apache Kylin 的充分認(rèn)可和褒獎(jiǎng)。2016 年的 InfoWorld 獲獎(jiǎng)榜單進(jìn)一步收窄，獲獎(jiǎng)?wù)邤?shù)量較前一年減少一半，值得驕傲的是，Apache Kylin 再次登上領(lǐng)獎(jiǎng)臺，蟬聯(lián)“最佳開源大數(shù)據(jù)工具獎(jiǎng)”。

Apache Kylin 在社區(qū)開發(fā)者的共同努力下進(jìn)一步發(fā)展和完善，先后發(fā)布了 1.6、2.0～ 2.5 多個(gè)版本，涵蓋近實(shí)時(shí)流、Spark 引擎、RDBMS 數(shù)據(jù)源、Cube Planner，支持 Hadoop 3.0 等眾多新功能，還有一些新功能正在進(jìn)行公開 beta 測試，如 Parquet 存儲引擎、完全實(shí)時(shí)流數(shù)據(jù)等，預(yù)計(jì)在不遠(yuǎn)的將來會正式發(fā)布。同時(shí)，Apache Kylin 用戶群也在不斷發(fā)展壯大，跨越亞洲、美洲、歐洲、澳洲等地。據(jù)粗略計(jì)算，全球已經(jīng)有超過一千家企業(yè)將 Apache Kylin 用于自身的關(guān)鍵業(yè)務(wù)分析。

Apache Kylin 的使命

Apache Kylin 的使命是實(shí)現(xiàn)超高速的大數(shù)據(jù) OLAP 分析，也就是要讓大數(shù)據(jù)分析像使用數(shù)據(jù)庫一樣簡單迅速，用戶的查詢請求可以在秒級返回，交互式數(shù)據(jù)分析以前所未有的速度釋放大數(shù)據(jù)里潛藏的知識和信息，以使我們在面對未來的挑戰(zhàn)時(shí)占得先機(jī)。

二：工作原理

工作原理本質(zhì)上是 MOLAP（Multidimensional Online Analytical Processing） Cube，也就是多維立方體分析。下面對其做簡要介紹。

維度和度量簡介

在說明 MOLAP Cube 之前，需要先介紹一下維度（dimension）和度量（measure）這兩個(gè)概念。

維度就是觀察數(shù)據(jù)的角度，比如電商的銷售數(shù)據(jù)，可以從時(shí)間的維度來觀察（如圖 1 的左圖所示），也可以進(jìn)一步細(xì)化從時(shí)間和地區(qū)的維度來觀察（如圖 1 的右圖所示）。維度一般是一組離散的值，比如時(shí)間維度上的每一個(gè)獨(dú)立的日期，或者商品維度上的每一件獨(dú)立的商品。因此，統(tǒng)計(jì)時(shí)可以把維度值相同的記錄聚合起來，應(yīng)用聚合函數(shù)做累加、平均、去重復(fù)計(jì)數(shù)等聚合計(jì)算。

圖 1　維度和度量

度量就是被聚合的統(tǒng)計(jì)值，也是聚合運(yùn)算的結(jié)果，它一般是連續(xù)值，如圖 1 中的銷售額，抑或是銷售商品的總件數(shù)。通過比較和測算度量，分析師可以對數(shù)據(jù)進(jìn)行評估，比如今年的銷售額相比去年有多大的增長、增長的速度是否達(dá)到預(yù)期、不同商品類別的增長比例是否合理等。

Cube 和 Cuboid

了解了維度和度量，就可以對數(shù)據(jù)表或者數(shù)據(jù)模型上的所有字段進(jìn)行分類了，它們要么是維度，要么是度量（可以被聚合）。于是就有了根據(jù)維度、度量做預(yù)計(jì)算的 Cube 理論。

給定一個(gè)數(shù)據(jù)模型，我們可以對其上所有維度進(jìn)行組合。對于 N 個(gè)維度來說，所有組合的可能性有 2N 種。對每一種維度的組合，將度量做聚合運(yùn)算，運(yùn)算的結(jié)果保存為一個(gè)物化視圖，稱為 Cuboid。將所有維度組合的 Cuboid 作為一個(gè)整體，被稱為 Cube。所以簡單來說，一個(gè) Cube 就是許多按維度聚合的物化視圖的集合。

計(jì)算 Cuboid，就是按維度來聚合銷售額(GMV)。如果用 SQL 來表達(dá)計(jì)算 Cuboid [Time, Location]，那就是：

select Time, Location, Sum(GMV) as GMV from Sales group by Time, Location

圖 2　四維 Cube

將計(jì)算的結(jié)果保存為物化視圖，所有 Cuboid 物化視圖的總稱就是 Cube 了。

工作原理

Apache Kylin 的工作原理就是對數(shù)據(jù)模型做 Cube 預(yù)計(jì)算，并利用計(jì)算的結(jié)果加速查詢。過程如下：

1.指定數(shù)據(jù)模型，定義維度和度量。
2.預(yù)計(jì)算 Cube，計(jì)算所有 Cuboid 并將其保存為物化視圖。
3.執(zhí)行查詢時(shí)，讀取 Cuboid，進(jìn)行加工運(yùn)算產(chǎn)生查詢結(jié)果。

由于 Kylin 的查詢過程不會掃描原始記錄，而是通過預(yù)計(jì)算預(yù)先完成表的關(guān)聯(lián)、聚合等復(fù)雜運(yùn)算，并利用預(yù)計(jì)算的結(jié)果來執(zhí)行查詢，因此其速度相比非預(yù)計(jì)算的查詢技術(shù)一般要快一個(gè)到兩個(gè)數(shù)量級。并且在超大數(shù)據(jù)集上其優(yōu)勢更明顯。當(dāng)數(shù)據(jù)集達(dá)到千億乃至萬億級別時(shí)，Kylin 的速度甚至可以超越其他非預(yù)計(jì)算技術(shù) 1000 倍以上。

三：技術(shù)架構(gòu)

Apache Kylin 系統(tǒng)可以分為在線查詢和離線構(gòu)建兩部分，其技術(shù)架構(gòu)如圖 1 所示。在線查詢主要由上半?yún)^(qū)組成，離線構(gòu)建在下半?yún)^(qū)。

先看離線構(gòu)建的部分。從圖 1 中可以看到，數(shù)據(jù)源在左側(cè)，目前主要是 Hadoop、Hive、Kafka 和 RDBMS，其中保存著待分析的用戶數(shù)據(jù)。根據(jù)元數(shù)據(jù)定義，下方構(gòu)建引擎從數(shù)據(jù)源中抽取數(shù)據(jù)，并構(gòu)建 Cube。數(shù)據(jù)以關(guān)系表的形式輸入，且必須符合星形模型（Star Schema）或雪花模型（Snowflake Schema）。用戶可以選擇使用 MapReduce 或 Spark 進(jìn)行構(gòu)建。構(gòu)建后的 Cube 保存在右側(cè)的存儲引擎中，目前 HBase 是默認(rèn)的存儲引擎。

完成離線構(gòu)建后，用戶可以從上方查詢系統(tǒng)發(fā)送 SQL 來進(jìn)行查詢分析。Kylin 提供了多樣的 REST API、JDBC/ODBC 接口。無論從哪個(gè)接口進(jìn)入，最終 SQL 都會來到 REST 服務(wù)層，再轉(zhuǎn)交給查詢引擎進(jìn)行處理。這里需要注意的是，SQL 語句是基于數(shù)據(jù)源的關(guān)系模型書寫的，而不是 Cube。Kylin 在設(shè)計(jì)時(shí)刻意對查詢用戶屏蔽了 Cube 的概念，分析師只需要理解簡單的關(guān)系模型就可以使用 Kylin，沒有額外的學(xué)習(xí)門檻，傳統(tǒng)的 SQL 應(yīng)用也更容易遷移。查詢引擎解析 SQL，生成基于關(guān)系表的邏輯執(zhí)行計(jì)劃，然后將其轉(zhuǎn)譯為基于 Cube 的物理執(zhí)行計(jì)劃，最后查詢預(yù)計(jì)算生成的 Cube 產(chǎn)生結(jié)果。整個(gè)過程不訪問原始數(shù)據(jù)源。

注意　

對于查詢引擎下方的路由選擇，在最初設(shè)計(jì)時(shí)考慮過將 Kylin 不能執(zhí)行的查詢引導(dǎo)到 Hive 中繼續(xù)執(zhí)行。但在實(shí)踐后發(fā)現(xiàn) Hive 與 Kylin 的執(zhí)行速度差異過大，導(dǎo)致用戶無法對查詢的速度有一致的期望，大多語句很可能查詢幾秒就返回了，而有些要等幾分鐘到幾十分鐘，用戶體驗(yàn)非常糟糕。最后這個(gè)路由功能在發(fā)行版中默認(rèn)被關(guān)閉。

Apache Kylin v1.5 版本引入了“可擴(kuò)展架構(gòu)”的概念。圖 1 所示為 Rest Server、Cube Build Engine 和數(shù)據(jù)源表示的抽象層。可擴(kuò)展是指 Kylin 可以對其三個(gè)主要依賴模塊—數(shù)據(jù)源、構(gòu)建引擎和存儲引擎，做任意的擴(kuò)展和替換。在設(shè)計(jì)之初，作為 Hadoop 家族的一員，這三者分別是 Hive、MapReduce 和 HBase。但隨著 Apache Kylin 的推廣和使用的深入，用戶發(fā)現(xiàn)它們存在不足之處。

這也為 Kylin 技術(shù)的與時(shí)俱進(jìn)奠定了基礎(chǔ)。如果將來有更先進(jìn)的分布式計(jì)算技術(shù)可以取代 MapReduce，或者有更高效的存儲系統(tǒng)全面超越了 HBase，Kylin 可以用較小的代價(jià)將一個(gè)子系統(tǒng)替換掉，從而保證 Kylin 緊跟技術(shù)發(fā)展的最新潮流，保持最高的技術(shù)水平。

可擴(kuò)展架構(gòu)也帶來了額外的靈活性，比如，它可以允許多個(gè)引擎并存。例如，Kylin 可以同時(shí)對接 Hive、Kafka 和其他第三方數(shù)據(jù)源；抑或用戶可以為不同的 Cube 指定不同的構(gòu)建引擎或存儲引擎，以期達(dá)到極致的性能和功能定制。

Apache Kylin 的主要特點(diǎn)

主要特點(diǎn)包括支持 SQL 接口、支持超大數(shù)據(jù)集、秒級響應(yīng)、可伸縮性、高吞吐率、BI 及可視化工具集成等。

四：核心概念

數(shù)據(jù)倉庫、OLAP 與 BI

數(shù)據(jù)倉庫（Data Warehouse）是一種信息系統(tǒng)的資料儲存理論，此理論強(qiáng)調(diào)的是利用某些特殊資料儲存方式，讓所包含的資料特別有利于分析處理，從而產(chǎn)生有價(jià)值的資訊并依此做決策。

OLAP（Online Analytical Process），即聯(lián)機(jī)分析處理，它可以以多維度的方式分析數(shù)據(jù)，并且能彈性地提供上卷（Roll-up）、下鉆（Drill-down）和透視分析（Pivot）等操作，是呈現(xiàn)集成性決策信息的方法，其主要功能在于方便大規(guī)模數(shù)據(jù)分析及統(tǒng)計(jì)計(jì)算，多用于決策支持系統(tǒng)、商務(wù)智能或數(shù)據(jù)倉庫。與之相區(qū)別的是聯(lián)機(jī)交易處理（OLTP），聯(lián)機(jī)交易處理側(cè)重于基本的、日常的事務(wù)處理，包括數(shù)據(jù)的增、刪、改、查。

• OLAP 需要以大量歷史數(shù)據(jù)為基礎(chǔ)，配合時(shí)間點(diǎn)的差異并對多維度及匯整型的信息進(jìn)行復(fù)雜的分析。

• OLAP 需要用戶有主觀的信息需求定義，因此系統(tǒng)效率較高。

BI（Business Intelligence），即商務(wù)智能，是指用現(xiàn)代數(shù)據(jù)倉庫技術(shù)、在線分析技術(shù)、數(shù)據(jù)挖掘和數(shù)據(jù)展現(xiàn)技術(shù)進(jìn)行數(shù)據(jù)分析以實(shí)現(xiàn)商業(yè)價(jià)值。

維度建模

維度建模用于決策制定，并側(cè)重于業(yè)務(wù)如何表示和理解數(shù)據(jù)?；镜木S度模型由維度和度量兩類對象組成。維度建模嘗試以邏輯、可理解的方式呈現(xiàn)數(shù)據(jù)，以使得數(shù)據(jù)的訪問更加直觀。維度設(shè)計(jì)的重點(diǎn)是簡化數(shù)據(jù)和加快查詢。

維度模型是數(shù)據(jù)倉庫的核心。它經(jīng)過精心設(shè)計(jì)和優(yōu)化，可以為數(shù)據(jù)分析和商業(yè)智能(BI)，檢索并匯總大量的相關(guān)數(shù)據(jù)。在數(shù)據(jù)倉庫中，數(shù)據(jù)修改僅定期發(fā)生，并且是一次性開銷，而讀取是經(jīng)常發(fā)生的。對于一個(gè)數(shù)據(jù)檢索效率比數(shù)據(jù)處理效率重要得多的數(shù)據(jù)結(jié)構(gòu)而言，非標(biāo)準(zhǔn)化的維度模型是一個(gè)不錯(cuò)的解決方案。

在數(shù)據(jù)挖掘中有幾種常見的多維數(shù)據(jù)模型，如星形模型（Star Schema）、雪花模型（Snowflake Schema）、事實(shí)星座模型（Fact Constellation）等。

事實(shí)表和維度表

事實(shí)表（Fact Table）是指存儲事實(shí)記錄的表，如系統(tǒng)日志、銷售記錄等，并且是維度模型中的主表，代表著鍵和度量的集合。事實(shí)表的記錄會不斷地動(dòng)態(tài)增長，所以它的體積通常遠(yuǎn)大于其他表，通常事實(shí)表占據(jù)數(shù)據(jù)倉庫中 90%或更多的空間。

維度表（Dimension Table），也稱維表或查找表（Lookup Table），是與事實(shí)表相對應(yīng)的一種表。維度表的目的是將業(yè)務(wù)含義和上下文添加到數(shù)據(jù)倉庫中的事實(shí)表和度量中。維度表是事實(shí)表的入口點(diǎn)，維度表實(shí)現(xiàn)了數(shù)據(jù)倉庫的業(yè)務(wù)接口。它們基本上是事實(shí)表中的鍵引用的查找表。它保存了維度的屬性值，可以與事實(shí)表做關(guān)聯(lián)，相當(dāng)于將事實(shí)表上經(jīng)常出現(xiàn)的屬性抽取、規(guī)范出來用一張表進(jìn)行管理，常見的維度表有：日期表（存儲日期對應(yīng)的 周、月、季度等屬性）、地點(diǎn)表（包含國家、?。?、城市等屬性）等。使用維度表的好處如下：

• 減小了事實(shí)表的大小；

• 便于維度的管理和維護(hù)，增加、刪除和修改維度的屬性時(shí)，不必對事實(shí)表的大量記錄進(jìn)行改動(dòng)；

• 維度表可以為多個(gè)事實(shí)表同時(shí)使用，減少重復(fù)工作。

維度和度量

維度是人們觀察數(shù)據(jù)的特定角度，是考慮問題時(shí)的一類屬性。它通常是數(shù)據(jù)記錄的一個(gè)特征，如時(shí)間、地點(diǎn)等。同時(shí)，維度具有層級概念，可能存在細(xì)節(jié)程度不同的描述方面，如日期、月份、季度、年等。

可以在數(shù)學(xué)上求和的事實(shí)屬性稱為度量。例如，可以對度量進(jìn)行總計(jì)、平均、以百分比形式使用等。度量是維度模型的核心。通常，在單個(gè)查詢中檢索數(shù)千個(gè)或數(shù)百萬個(gè)事實(shí)行，其中對結(jié)果集執(zhí)行數(shù)學(xué)方程。

Cube、Cuboid 和 Cube Segment

Cube（或稱 Data Cube），即數(shù)據(jù)立方體，是一種常用于數(shù)據(jù)分析與索引的技術(shù)，它可以對原始數(shù)據(jù)建立多維度索引，大大加快數(shù)據(jù)的查詢效率。

Cuboid 特指 Apache Kylin 中在某一種維度組合下所計(jì)算的數(shù)據(jù)。

Cube Segment 指針對源數(shù)據(jù)中的某一片段計(jì)算出來的 Cube 數(shù)據(jù)。通常，數(shù)據(jù)倉庫中的數(shù)據(jù)數(shù)量會隨時(shí)間的增長而增長，而 Cube Segment 也是按時(shí)間順序構(gòu)建的。

五：快速開始

這里是一份從下載安裝到體驗(yàn)亞秒級查詢的完整流程，分別介紹了有hadoop環(huán)境（基于hadoop環(huán)境的安裝）和沒有hadoop環(huán)境（從docker鏡像安裝）兩種場景下kylin的安裝使用，用戶可以根據(jù)自己的環(huán)境選擇其中的任意一種方式。

你可以按照文章里的步驟對kylin進(jìn)行初步的了解和體驗(yàn)，掌握kylin的基本使用技能，然后結(jié)合自己的業(yè)務(wù)場景使用kylin來設(shè)計(jì)模型，加速查詢。

一、 從docker鏡像安裝使用kylin（不需要提前準(zhǔn)備hadoop環(huán)境）

為了讓用戶方便的試用 Kylin，我們提供了 Kylin 的 docker 鏡像。該鏡像中，Kylin 依賴的各個(gè)服務(wù)均已正確的安裝及部署，包括：

• JDK 1.8

• Hadoop 2.7.0

• Hive 1.2.1

• Hbase 1.1.2 (with Zookeeper)

• Spark 2.3.1

• Kafka 1.1.1

• MySQL 5.1.73

我們已將面向用戶的 Kylin 鏡像上傳至 docker 倉庫，用戶無需在本地構(gòu)建鏡像，只需要安裝docker，就可以體驗(yàn)kylin的一鍵安裝。

step1.首先執(zhí)行以下命令從 docker 倉庫 pull 鏡像：

docker pull apachekylin/apache-kylin-standalone:3.1.0

此處的鏡像包含的是kylin最新Release版本kylin 3.1.0。由于該鏡像中包含了所有kylin依賴的大數(shù)據(jù)組件，所以拉取鏡像需要的時(shí)間較長，請耐心等待。Pull成功后顯示如下：

step2.執(zhí)行以下命令來啟動(dòng)容器：

docker run -d \
-m 8G \
-p 7070:7070 \
-p 8088:8088 \
-p 50070:50070 \
-p 8032:8032 \
-p 8042:8042 \
-p 16010:16010 \
apachekylin/apache-kylin-standalone:3.1.0

容器會很快啟動(dòng)，由于容器內(nèi)指定端口已經(jīng)映射到本機(jī)端口，可以直接在本機(jī)瀏覽器中打開各個(gè)服務(wù)的頁面，如：

• Kylin 頁面：http://127.0.0.1:7070/kylin/

• Hdfs NameNode 頁面：http://127.0.0.1:50070

• Yarn ResourceManager 頁面：http://127.0.0.1:8088

• HBase 頁面：http://127.0.0.1:60010

容器啟動(dòng)時(shí)，會自動(dòng)啟動(dòng)以下服務(wù)：

• NameNode, DataNode

• ResourceManager, NodeManager

• HBase

• Kafka

• Kylin

并自動(dòng)運(yùn)行 $KYLIN_HOME/bin/sample.sh及在 Kafka 中創(chuàng)建 kylin_streaming_topic topic 并持續(xù)向該 topic 中發(fā)送數(shù)據(jù)。這是為了讓用戶啟動(dòng)容器后，就能體驗(yàn)以批和流的方式的方式構(gòu)建 Cube 并進(jìn)行查詢。用戶可以通過docker exec命令進(jìn)入容器，容器內(nèi)相關(guān)環(huán)境變量如下：

JAVA_HOME=/home/admin/jdk1.8.0_141
HADOOP_HOME=/home/admin/hadoop-2.7.0
KAFKA_HOME=/home/admin/kafka_2.11-1.1.1
SPARK_HOME=/home/admin/spark-2.3.1-bin-hadoop2.6
HBASE_HOME=/home/admin/hbase-1.1.2
HIVE_HOME=/home/admin/apache-hive-1.2.1-bin
KYLIN_HOME=/home/admin/apache-kylin-3.1.0-bin-hbase1x

使用ADMIN/KYLIN的用戶名和密碼組合登陸Kylin后，用戶可以使用sample cube來體驗(yàn)cube的構(gòu)建和查詢，也可以按照下面“基于hadoop環(huán)境安裝使用kylin”中從step8之后的教程來創(chuàng)建并查詢屬于自己的model和cube。

二、 基于hadoop環(huán)境安裝使用kylin

對于已經(jīng)有穩(wěn)定hadoop環(huán)境的用戶，可以下載kylin的二進(jìn)制包將其部署安裝在自己的hadoop集群。安裝之前請根據(jù)以下要求進(jìn)行環(huán)境檢查：

• 前置條件：

Kylin 依賴于 Hadoop 集群處理大量的數(shù)據(jù)集。您需要準(zhǔn)備一個(gè)配置好 HDFS，YARN，MapReduce，Hive， HBase，Zookeeper 和其他服務(wù)的 Hadoop 集群供 Kylin 運(yùn)行。
Kylin 可以在 Hadoop 集群的任意節(jié)點(diǎn)上啟動(dòng)。方便起見，您可以在 master 節(jié)點(diǎn)上運(yùn)行 Kylin。但為了更好的穩(wěn)定性，我們建議您將 Kylin 部署在一個(gè)干凈的 Hadoop client 節(jié)點(diǎn)上，該節(jié)點(diǎn)上 Hive，HBase，HDFS 等命令行已安裝好且 client 配置（如 core-site.xml，hive-site.xml，hbase-site.xml及其他）也已經(jīng)合理的配置且其可以自動(dòng)和其它節(jié)點(diǎn)同步。
運(yùn)行 Kylin 的 Linux 賬戶要有訪問 Hadoop 集群的權(quán)限，包括創(chuàng)建/寫入 HDFS 文件夾，Hive 表， HBase 表和提交 MapReduce 任務(wù)的權(quán)限。

• 硬件要求：

運(yùn)行 Kylin 的服務(wù)器建議最低配置為 4 core CPU，16 GB 內(nèi)存和 100 GB 磁盤。

• 操作系統(tǒng)要求：

CentOS 6.5+ 或Ubuntu 16.0.4+

• 軟件要求：

Hadoop 2.7+,3.0
Hive 0.13+,1.2.1+
Hbase 1.1+，2.0（從kylin 2.5開始支持）
JDK: 1.8+

建議使用集成的Hadoop環(huán)境進(jìn)行kylin的安裝與測試，比如Hortonworks HDP 或Cloudera CDH ，kylin發(fā)布前在 Hortonworks HDP 2.2-2.6 and 3.0, Cloudera CDH 5.7-5.11 and 6.0, AWS EMR 5.7-5.10, Azure HDInsight 3.5-3.6上測試通過。

當(dāng)你的環(huán)境滿足上述前置條件時(shí) ，你可以開始安裝使用kylin。

step1.下載kylin壓縮包

cd /usr/local/
wget http://apache.website-solution.net/kylin/apache-kylin-3.1.0/apache-kylin-3.1.0-bin-cdh57.tar.gz

step2.解壓kylin

tar -zxvf  apache-kylin-3.1.0-bin-cdh57.tar.gz
cd apache-kylin-3.1.0-bin-cdh57
export KYLIN_HOME=`pwd`

step3.下載SPARK

export SPARK_HOME=/path/to/spark

如果沒有已經(jīng)下載好的Spark環(huán)境，也可以使用kylin自帶腳本下載spark:

$KYLIN_HOME/bin/download-spark.sh

step4.環(huán)境檢查

$KYLIN_HOME/bin/check-env.sh

step5.啟動(dòng)kylin

啟動(dòng)kylin：

$KYLIN_HOME/bin/kylin.sh start

如果啟動(dòng)成功，命令行的末尾會輸出如下內(nèi)容：

A new Kylin instance is started by root. To stop it, run 'kylin.sh stop'
Check the log at /usr/local/apache-kylin-3.1.0-bin-cdh57/logs/kylin.log
Web UI is at http://<hostname>:7070/kylin

step6.訪問kylin

Kylin 啟動(dòng)后可以進(jìn)行訪問。其中 為具體的機(jī)器名、IP 地址或域名，port為kylin端口，默認(rèn)為7070。初始用戶名和密碼是 ADMIN/KYLIN。服務(wù)器啟動(dòng)后，可以通過查看 $KYLIN_HOME/logs/kylin.log 獲得運(yùn)行時(shí)日志。

step7.創(chuàng)建Sample Cube

Kylin提供了一個(gè)創(chuàng)建樣例Cube的腳本，以供用戶快速體驗(yàn)Kylin。在命令行運(yùn)行：

$KYLIN_HOME/bin/sample.sh

完成后登陸kylin，點(diǎn)擊System->Configuration->Reload Metadata來重載元數(shù)據(jù)
元數(shù)據(jù)重載完成后你可以在左上角的Project中看到一個(gè)名為learn_kylin的項(xiàng)目，它包含kylin_sales_cube和kylin_streaming_cube, 它們分別為batch cube和streaming cube，你可以直接對kylin_sales_cube進(jìn)行構(gòu)建，構(gòu)建完成后就可以查詢。
對于kylin_streaming_cube，需要設(shè)置KAFKA_HOME指向你的kafka安裝目錄:

export KAFKA_HOME=/path/to/kafka

然后執(zhí)行

${KYLIN_HOME}/bin/sample-streaming.sh

step8.創(chuàng)建project

登陸kylin后，點(diǎn)擊左上角的+號來創(chuàng)建Project：

step9.加載Hive表

點(diǎn)擊Model->Data Source->Load Table From Tree，Kylin會讀取到Hive數(shù)據(jù)源中的表并以樹狀方式顯示出來，你可以選擇自己要使用的表，然后點(diǎn)擊sync進(jìn)行將其加載到kylin。

step10.創(chuàng)建模型

點(diǎn)擊Model->New->New Model：

輸入Model Name點(diǎn)擊Next進(jìn)行下一步，選擇Fact Table和Lookup Table，添加Lookup Table時(shí)需要設(shè)置與事實(shí)表的JOIN條件。

然后點(diǎn)擊Next到下一步添加Dimension：

點(diǎn)擊Next下一步添加Measure：

點(diǎn)擊Next下一步跳轉(zhuǎn)到設(shè)置時(shí)間分區(qū)列和過濾條件頁面，時(shí)間分區(qū)列用于增量構(gòu)建時(shí)選擇時(shí)間范圍，如果不設(shè)置時(shí)間分區(qū)列則代表該model下的cube都是全量構(gòu)建。過濾條件會在打平表時(shí)用于where條件。

最后點(diǎn)擊Save保存模型。

step11.創(chuàng)建Cube

選擇Model->New->New Cube

點(diǎn)擊Next到下一步添加Dimension，Lookup Table的維度可以設(shè)置為Normal（普通維度）或者Derived（衍生維度）兩種類型，默認(rèn)設(shè)置為衍生維度，衍生維度代表該列可以從所屬維度表的主鍵中衍生出來，所以實(shí)際上只有主鍵列會被Cube加入計(jì)算。

點(diǎn)擊Next到下一步，點(diǎn)擊+Measure來添加需要預(yù)計(jì)算的度量。Kylin會默認(rèn)創(chuàng)建一個(gè)Count(1)的度量。Kylin支持SUM、MIN、MAX、COUNT、COUNT_DISTINCT、TOP_N、EXTENDED_COLUMN、PERCENTILE八種度量。請為COUNT_DISTINCT和TOP_N選擇合適的返回類型，這關(guān)系到Cube的大小。添加完成之后點(diǎn)擊ok，該Measure將會顯示在Measures列表中

添加完所有Measure后點(diǎn)擊Next進(jìn)行下一步，這一頁是關(guān)于Cube數(shù)據(jù)刷新的設(shè)置。在這里可以設(shè)施自動(dòng)合并的閾值（Auto Merge Thresholds）、數(shù)據(jù)保留的最短時(shí)間（Retention Threshold）以及第一個(gè)Segment的起點(diǎn)時(shí)間。

點(diǎn)擊Next跳轉(zhuǎn)到下一頁高級設(shè)置。在這里可以設(shè)置聚合組、RowKeys、Mandatory Cuboids、Cube Engine等。

對于高級設(shè)置不是很熟悉時(shí)可以先保持默認(rèn)設(shè)置，點(diǎn)擊Next跳轉(zhuǎn)到Kylin Properties頁面，你可以在這里重寫cube級別的kylin配置項(xiàng)，定義覆蓋的屬性。

配置完成后，點(diǎn)擊Next按鈕到下一頁，這里可以預(yù)覽你正在創(chuàng)建的Cube的基本信息，并且可以返回之前的步驟進(jìn)行修改。如果沒有需要修改的部分，就可以點(diǎn)擊Save按鈕完成Cube創(chuàng)建。之后，這個(gè)Cube將會出現(xiàn)在你的Cube列表中。

step12.構(gòu)建Cube

上一個(gè)步驟創(chuàng)建好的Cube只有定義，而沒有計(jì)算好的數(shù)據(jù)，它的狀態(tài)是‘DISABLED’，是不可以查詢的。要想讓Cube有數(shù)據(jù)，還需要對它進(jìn)行構(gòu)建。

Cube的構(gòu)建方式通常有兩種：全量構(gòu)建和增量構(gòu)建。

點(diǎn)擊要構(gòu)建的Cube的Actions列下的Action展開，選擇Build，如果Cube所屬M(fèi)odel中沒有設(shè)置時(shí)間分區(qū)列，則默認(rèn)全量構(gòu)建，點(diǎn)擊Submit直接提交構(gòu)建任務(wù)。

如果設(shè)置了時(shí)間分區(qū)列，則會出現(xiàn)如下頁面，在這里你要選擇構(gòu)建數(shù)據(jù)的起止時(shí)間：

設(shè)置好起止時(shí)間后，點(diǎn)擊Submit提交構(gòu)建任務(wù)。然后你可以在Monitor頁面觀察構(gòu)建任務(wù)的狀態(tài)。Kylin會在頁面上顯示每一個(gè)步驟的運(yùn)行狀態(tài)、輸出日志以及MapReduce任務(wù)?？梢栽?{KYLIN_HOME}/logs/kylin.log中查看更詳細(xì)的日志信息。

任務(wù)構(gòu)建完成后，Cube狀態(tài)會變成READY，并且可以看到Segment的信息。

step13.查詢Cube

Cube構(gòu)建完成后，在Insight頁面的Tables列表下面可以看到構(gòu)建完成的Cube的table，并可以對其進(jìn)行查詢.查詢語句擊中Cube后會返回存儲在Hbase中的預(yù)計(jì)算結(jié)果。

調(diào)優(yōu)和原理進(jìn)階

優(yōu)化實(shí)戰(zhàn)(一)：資源調(diào)整

首先，就是資源方面，實(shí)際上對于Kylin的計(jì)算來說，要求的資源不算多，因?yàn)榈讓?默認(rèn))計(jì)算引擎是M-S-R范式基于磁盤的計(jì)算框架MapReduce，尤其是CPU，要求很低很低，但是內(nèi)存配置高點(diǎn)的話， 還是對性能提升有好處的,一方面是計(jì)算，緩沖區(qū)大小變大，對計(jì)算幫助很大；另外一反面就是查詢，因?yàn)镵ylin中間結(jié)果的存儲是依托于HBase的，HBase本身就很吃內(nèi)存。

MapReduce方面，可以通過在Kylin的配置文件中覆蓋掉原有MapReduce的參數(shù)配置。在conf目錄下，kylin_job_conf.xml 和 kylin_job_conf_inmem.xml 中參數(shù)，以鍵值對的性質(zhì)，按照如下格式替換： 

kylin.engine.mr.config-override.<key> = <value>

從 Yarn上 獲得更多內(nèi)存，可以這樣設(shè)置：

kylin.engine.mr.config-override.mapreduce.map.java.opts=-Xmx7g 和 kylin.engine.mr.config-override.mapreduce.map.memory.mb=10240

指定MR任務(wù)的資源隊(duì)列，可以設(shè)置(在此之前，需要現(xiàn)在yarn上配置資源隊(duì)列)：

kylin.engine.mr.config-override.mapreduce.job.queuename={queueName}

配置MR任務(wù)執(zhí)行時(shí)的一些內(nèi)存參數(shù)：

mapreduce.reduce.shuffle.merge.percent（default0.66）溢寫到磁盤
mapreduce.task.io.sort.mb（default：100）根據(jù)不同的硬件尤其是內(nèi)存的大小來調(diào)整，調(diào)大的話，會減少磁盤spill的次數(shù)此時(shí)如果內(nèi)存足夠的話，一般都會顯
著提升性能

這個(gè)配置可以在項(xiàng)目或者cube級別。HBase方面，根據(jù)自己集群配置的硬件條件，盡量給大內(nèi)存。在cube構(gòu)建過程中，對HBase的讀寫會非常頻繁，合理的分配內(nèi)存至關(guān)重要。

HBase 存儲
kylin.storage.hbase.table-name-prefix：默認(rèn)值為 KYLIN_
kylin.storage.hbase.namespace：指定 HBase 存儲默認(rèn)的 namespace，默認(rèn)值為 default
kylin.storage.hbase.coprocessor-local-jar：指向 HBase 協(xié)處理器有關(guān) jar 包
kylin.storage.hbase.coprocessor-mem-gb：設(shè)置 HBase 協(xié)處理器內(nèi)存大小，默認(rèn)值為 3.0(GB)
kylin.storage.hbase.run-local-coprocessor：是否運(yùn)行本地 HBase 協(xié)處理器，默認(rèn)值為 FALSE
kylin.storage.hbase.coprocessor-timeout-seconds：設(shè)置超時(shí)時(shí)間，默認(rèn)值為 0
kylin.storage.hbase.region-cut-gb：單個(gè) Region 的大小，默認(rèn)值為 5.0
kylin.storage.hbase.min-region-count：指定最小 Region 個(gè)數(shù)，默認(rèn)值為 1
kylin.storage.hbase.max-region-count：指定最大 Region 個(gè)數(shù)，默認(rèn)值為 500
kylin.storage.hbase.hfile-size-gb：指定 HFile 大小，默認(rèn)值為 2.0(GB)
kylin.storage.hbase.max-scan-result-bytes：指定掃描返回結(jié)果的最大值，默認(rèn)值為 5242880(byte)，即 5(MB)
kylin.storage.hbase.compression-codec：是否壓縮，默認(rèn)值為 none，即不開啟壓縮
kylin.storage.hbase.rowkey-encoding：指定 Rowkey 的編碼方式，默認(rèn)值為 FAST_DIFF
kylin.storage.hbase.block-size-bytes：默認(rèn)值為 1048576
kylin.storage.hbase.small-family-block-size-bytes：指定 Block 大小，默認(rèn)值為 65536(byte)，即 64(KB)
kylin.storage.hbase.owner-tag：指定 Kylin 平臺的所屬人，默認(rèn)值為 [email protected]
kylin.storage.hbase.endpoint-compress-result：是否返回壓縮結(jié)果，默認(rèn)值為 TRUE
kylin.storage.hbase.max-hconnection-threads：指定連接線程數(shù)量的最大值，默認(rèn)值為 2048
kylin.storage.hbase.core-hconnection-threads：指定核心連接線程的數(shù)量，默認(rèn)值為 2048
kylin.storage.hbase.hconnection-threads-alive-seconds：指定線程存活時(shí)間，默認(rèn)值為 60
kylin.storage.hbase.replication-scope：指定集群復(fù)制范圍，默認(rèn)值為 0
kylin.storage.hbase.scan-cache-rows：指定掃描緩存行數(shù)，默認(rèn)值為 1024

JVM參數(shù)調(diào)優(yōu)(在HBase的env腳本中進(jìn)行調(diào)整)
export HBASE_OPTS="-verbose:gc -XX:+PrintGCDetails -Xloggc:${HBASE_LOG_DIR}/hbase-gc.log -XX:+PrintGCTimeStamps -XX:+PrintGCApplicationConcurrentTime -XX:+PrintGCApplicationStoppedTime \
-server -Xmx20480m -Xms20480m -Xmn10240m -Xss256k  -XX:SurvivorRatio=4 -XX:MaxPermSize=256m -XX:MaxTenuringThreshold=15 \
-XX:ParallelGCThreads=16 -XX:+UseConcMarkSweepGC -XX:+UseParNewGC  -XX:CMSFullGCsBeforeCompaction=5 -XX:+UseCMSCompactAtFullCollection \
-XX:+CMSClassUnloadingEnabled  -XX:CMSInitiatingOccupancyFraction=70 -XX:+UseCMSInitiatingOccupancyOnly -XX:CMSMaxAbortablePrecleanTime=5000     \

Kylin的參數(shù)調(diào)整方面，有關(guān)cube設(shè)計(jì)、大小、以及合并等參數(shù)：

數(shù)據(jù)類型精度(一般不做修改)：
kylin.source.hive.default-varchar-precision：指定 varchar 字段的最大長度，默認(rèn)值為256
kylin.source.hive.default-char-precision：指定 char 字段的最大長度，默認(rèn)值為 255
kylin.source.hive.default-decimal-precision：指定 decimal 字段的精度，默認(rèn)值為 19
kylin.source.hive.default-decimal-scale：指定 decimal 字段的范圍，默認(rèn)值為 4

Cube 設(shè)計(jì)：

kylin.cube.ignore-signature-inconsistency：Cube desc 中的 signature 信息能保證 Cube 不被更改為損壞狀態(tài)，默認(rèn)值為 FALSE
kylin.cube.aggrgroup.max-combination：指定一個(gè) Cube 的聚合組 Cuboid 上限，默認(rèn)值為 32768
kylin.cube.aggrgroup.is-mandatory-only-valid：是否允許 Cube 只包含 Base Cuboid，默認(rèn)值為 FALSE，當(dāng)使用 Spark Cubing 時(shí)需設(shè)置為 TRUE
kylin.cube.rowkey.max-size：指定可以設(shè)置為 Rowkeys 的最大列數(shù)，默認(rèn)值為 63，且最大不能超過 63
kylin.cube.allow-appear-in-multiple-projects：是否允許一個(gè) Cube 出現(xiàn)在多個(gè)項(xiàng)目中
kylin.cube.gtscanrequest-serialization-level：默認(rèn)值為 1
kylin.metadata.dimension-encoding-max-length：指定維度作為 Rowkeys 時(shí)使用 fix_length 編碼時(shí)的最大長度，默認(rèn)值為 256
kylin.web.hide-measures: 隱藏一些可能不需要的度量，默認(rèn)值是RAW

Cube 大小估計(jì)：

kylin.cube.size-estimate-ratio：普通的 Cube，默認(rèn)值為 0.25
kylin.cube.size-estimate-memhungry-ratio：已廢棄，默認(rèn)值為 0.05
kylin.cube.size-estimate-countdistinct-ratio：包含精確去重度量的 Cube 大小估計(jì)，默認(rèn)值為 0.5
kylin.cube.size-estimate-topn-ratio：包含 TopN 度量的 Cube 大小估計(jì)，默認(rèn)值為 0.5

Cube 構(gòu)建算法：

kylin.cube.algorithm：指定 Cube 構(gòu)建的算法，參數(shù)值可選 auto，layer 和 inmem， 默認(rèn)值為 auto，即 Kylin 會通過采集數(shù)據(jù)動(dòng)態(tài)地選擇一個(gè)算法 (layer or inmem)，如果用戶很了解 Kylin 和自身的數(shù)據(jù)、集群，可以直接設(shè)置喜歡的算法
kylin.cube.algorithm.layer-or-inmem-threshold：默認(rèn)值為 7
kylin.cube.algorithm.inmem-split-limit：默認(rèn)值為 500
kylin.cube.algorithm.inmem-concurrent-threads：默認(rèn)值為 1
kylin.job.sampling-percentage：指定數(shù)據(jù)采樣百分比，默認(rèn)值為 100

Cube 構(gòu)建：

kylin.storage.default：指定默認(rèn)的構(gòu)建引擎，默認(rèn)值為 2，即 HBase
kylin.source.hive.keep-flat-table：是否在構(gòu)建完成后保留 Hive 中間表，默認(rèn)值為 FALSE
kylin.source.hive.database-for-flat-table：指定存放 Hive 中間表的 Hive 數(shù)據(jù)庫名字，默認(rèn)值為 default，請確保啟動(dòng) Kylin 實(shí)例的用戶有操作該數(shù)據(jù)庫的權(quán)限
kylin.source.hive.flat-table-storage-format：指定 Hive 中間表的存儲格式，默認(rèn)值為 SEQUENCEFILE
kylin.source.hive.flat-table-field-delimiter：指定 Hive 中間表的分隔符，默認(rèn)值為 \u001F
kylin.source.hive.redistribute-flat-table：是否重分配 Hive 平表，默認(rèn)值為 TRUE
kylin.source.hive.redistribute-column-count：重分配列的數(shù)量，默認(rèn)值為 3
kylin.source.hive.table-dir-create-first：默認(rèn)值為 FALSE
kylin.storage.partition.aggr-spill-enabled：默認(rèn)值為 TRUE
kylin.engine.mr.lib-dir：指定 MapReduce 任務(wù)所使用的 jar 包的路徑
kylin.engine.mr.reduce-input-mb：MapReduce 任務(wù)啟動(dòng)前會依據(jù)輸入預(yù)估 Reducer 接收數(shù)據(jù)的總量，再除以該參數(shù)得出 Reducer 的數(shù)目，默認(rèn)值為 500（MB）
kylin.engine.mr.reduce-count-ratio：用于估算 Reducer 數(shù)目，默認(rèn)值為 1.0
kylin.engine.mr.min-reducer-number：MapReduce 任務(wù)中 Reducer 數(shù)目的最小值，默認(rèn)值為 1
kylin.engine.mr.max-reducer-number：MapReduce 任務(wù)中 Reducer 數(shù)目的最大值，默認(rèn)值為 500
kylin.engine.mr.mapper-input-rows：每個(gè) Mapper 可以處理的行數(shù)，默認(rèn)值為 1000000，如果將這個(gè)值調(diào)小，會起更多的 Mapper
kylin.engine.mr.max-cuboid-stats-calculator-number：用于計(jì)算 Cube 統(tǒng)計(jì)數(shù)據(jù)的線程數(shù)量，默認(rèn)值為 1
kylin.engine.mr.build-dict-in-reducer：是否在構(gòu)建任務(wù) Extract Fact Table Distinct Columns 的 Reduce 階段構(gòu)建字典，默認(rèn)值為 TRUE
kylin.engine.mr.yarn-check-interval-seconds：構(gòu)建引擎間隔多久檢查 Hadoop 任務(wù)的狀態(tài)，默認(rèn)值為 10（s）

優(yōu)化實(shí)戰(zhàn)(二)：Cube的高級設(shè)置

隨著維度數(shù)目的增加，Cuboid 的數(shù)量會爆炸式地增長。為了緩解 Cube 的構(gòu)建壓力，Apache Kylin 引入了一系列的高級設(shè)置，幫助用戶篩選出真正需要的 Cuboid。這些高級設(shè)置包括聚合組（Aggregation Group）、聯(lián)合維度（Joint Dimension）、層級維度（Hierachy Dimension）和必要維度（Mandatory Dimension）等。”

眾所周知，Apache Kylin 的主要工作就是為源數(shù)據(jù)構(gòu)建 N 個(gè)維度的 Cube，實(shí)現(xiàn)聚合的預(yù)計(jì)算。理論上而言，構(gòu)建 N 個(gè)維度的 Cube 會生成 2N 個(gè) Cuboid， 如圖 1 所示，構(gòu)建一個(gè) 4 個(gè)維度（A，B，C, D）的 Cube，需要生成 16 個(gè)Cuboid。

圖一

隨著維度數(shù)目的增加 Cuboid 的數(shù)量會爆炸式地增長，不僅占用大量的存儲空間還會延長 Cube 的構(gòu)建時(shí)間。為了緩解 Cube 的構(gòu)建壓力，減少生成的 Cuboid 數(shù)目，Apache Kylin 引入了一系列的高級設(shè)置，幫助用戶篩選出真正需要的 Cuboid。這些高級設(shè)置包括聚合組（Aggregation Group）、聯(lián)合維度（Joint Dimension）、層級維度（Hierachy Dimension）和必要維度（Mandatory Dimension）等，本系列將深入講解這些高級設(shè)置的含義及其適用的場景。

聚合組（Aggregation Group）

用戶根據(jù)自己關(guān)注的維度組合，可以劃分出自己關(guān)注的組合大類，這些大類在 Apache Kylin 里面被稱為聚合組。例如圖 1 中展示的 Cube，如果用戶僅僅關(guān)注維度 AB 組合和維度 CD 組合，那么該 Cube 則可以被分化成兩個(gè)聚合組，分別是聚合組 AB 和聚合組 CD。如圖 2 所示，生成的 Cuboid 數(shù)目從 16 個(gè)縮減成了 8 個(gè)。

圖二

用戶關(guān)心的聚合組之間可能包含相同的維度，例如聚合組 ABC 和聚合組 BCD 都包含維度 B 和維度 C。這些聚合組之間會衍生出相同的 Cuboid，例如聚合組 ABC 會產(chǎn)生 Cuboid BC，聚合組 BCD 也會產(chǎn)生 Cuboid BC。這些 Cuboid不會被重復(fù)生成，一份 Cuboid 為這些聚合組所共有，如圖 3 所示。

圖三

有了聚合組用戶就可以粗粒度地對 Cuboid 進(jìn)行篩選，獲取自己想要的維度組合。

聯(lián)合維度（Joint Dimension）

用戶有時(shí)并不關(guān)心維度之間各種細(xì)節(jié)的組合方式，例如用戶的查詢語句中僅僅會出現(xiàn) group by A, B, C，而不會出現(xiàn) group by A, B 或者 group by C 等等這些細(xì)化的維度組合。這一類問題就是聯(lián)合維度所解決的問題。例如將維度 A、B 和 C 定義為聯(lián)合維度，Apache Kylin 就僅僅會構(gòu)建 Cuboid ABC，而 Cuboid AB、BC、A 等等Cuboid 都不會被生成。最終的 Cube 結(jié)果如圖4所示，Cuboid 數(shù)目從 16 減少到 4。

圖四

層級維度（Hierarchy Dimension）

用戶選擇的維度中常常會出現(xiàn)具有層級關(guān)系的維度。例如對于國家（country）、省份（province）和城市（city）這三個(gè)維度，從上而下來說國家／省份／城市之間分別是一對多的關(guān)系。也就是說，用戶對于這三個(gè)維度的查詢可以歸類為以下三類:

• group by country

• group by country, province（等同于group by province）

• group by country, province, city（等同于 group by country, city 或者group by city）

以圖5所示的 Cube 為例，假設(shè)維度 A 代表國家，維度 B 代表省份，維度 C 代表城市，那么ABC 三個(gè)維度可以被設(shè)置為層級維度，生成的Cube 如圖5所示。

圖五

例如，Cuboid [A,C,D]=Cuboid[A, B, C, D]，Cuboid[B, D]=Cuboid[A, B, D]，因而 Cuboid[A, C, D] 和 Cuboid[B, D] 就不必重復(fù)存儲。

圖6展示了 Kylin 按照前文的方法將冗余的Cuboid 剪枝從而形成圖 2 的 Cube 結(jié)構(gòu)，Cuboid 數(shù)目從 16 減小到 8。

圖六

必要維度 （Mandatory Dimension）

用戶有時(shí)會對某一個(gè)或幾個(gè)維度特別感興趣，所有的查詢請求中都存在group by這個(gè)維度，那么這個(gè)維度就被稱為必要維度，只有包含此維度的Cuboid會被生成（如圖7）。

圖七

以圖 1中的Cube為例，假設(shè)維度A是必要維度，那么生成的Cube則如圖8所示，維度數(shù)目從16變?yōu)?。

圖八

在Kylin的高級設(shè)置中，用戶可以根據(jù)查詢需求對Cube構(gòu)建預(yù)計(jì)算的結(jié)果進(jìn)行優(yōu)化（剪枝），從而減少占用的存儲空間。而優(yōu)化得當(dāng)?shù)腃ube可以在占用盡量少的存儲空間的同時(shí)提供極強(qiáng)的查詢性能。

優(yōu)化實(shí)戰(zhàn)(三)：Kylin官方案例詳細(xì)剖析及剪枝優(yōu)化

Kylin官方案例是一個(gè)非常經(jīng)典的案例，包含的技術(shù)細(xì)節(jié)通過深挖能呈現(xiàn)出更具價(jià)值的信息，如：數(shù)據(jù)倉庫理論，星型模型，雪花模型，角色扮演維度，維度剪枝等。官方案例是一個(gè)訂單案例，其中包含了訂單事實(shí)表，訂單日期表，商品分類維度，賬號維度（購買者和銷售者）以及區(qū)域維度（購買者和銷售者）。

一、Kylin官方案例表關(guān)系及字段詳解

Kylin官方案例表簡要說明

• KYLIN_SALES是事實(shí)表，保存了銷售訂單的明細(xì)信息。各列分別保存著賣家、商品分類、訂單金額、商品數(shù)量等信息，每一行對應(yīng)著一筆交易訂單。

• KYLIN_CATEGORY_GROUPINGS是維表，保存了商品分類的詳細(xì)介紹，例如商品分類名稱等。

• KYLIN_CAL_DT也是維表，保存了時(shí)間的擴(kuò)展信息。如單個(gè)日期所、月始、周始、年份、月份等。

• KYLIN_ACCOUNT也是維表，作為角色扮演維度，包含購買者和開發(fā)者賬號。

• KYLIN_COUNTRY包含區(qū)域維度，作為角色扮演維度，包含購買者和開發(fā)者所在區(qū)域信息。

KYLIN_SALES 事實(shí)表字段詳解：

KYLIN_CATEGORY_GROUPINGS主要字段：

• LEAF_CATEG_ID：主鍵

• SITE_ID：外鍵

KYLIN_CATEGORY_GROUPINGS 對外連接關(guān)系：

KYLIN_CATEGORY_GROUPINGS 主要字段解釋：

KYLIN_COUNTRY 主要字段詳解：

KYLIN_ACCOUNT 主要字段詳解：

雪花模型關(guān)系總覽：

二、建立模型（Model）

Kylin 官方模型 model關(guān)系圖如下：

第一步：雪花和星型模型，建立inner join關(guān)系，重要的是確定字段關(guān)聯(lián)，對于角色維度（KYLIN_ACCOUNT和KYLIN_COUNTRY），需要?jiǎng)e名處理。

對 “Add Lookup Table” 頁面的幾點(diǎn)說明：

1.數(shù)據(jù)關(guān)系不僅僅是事實(shí)表與維度表之間（星型模型），維度表和維度表之間（雪花模型）也可以建立聯(lián)系；
2.表與表之間的連接添加有三種：“Left Join”、“Inner Join”、“Right Join”；
3.Skip snapshot for this lookup table 選項(xiàng)指的是是否跳過生成 snapshotTable，由于某些 Lookup 表特別大（大于 300M），如果某一個(gè)維度的基數(shù)比較大 ，可能會導(dǎo)致內(nèi)存出現(xiàn) OOM，所以在創(chuàng)建 snapshotTable 的時(shí)候會限制原始表的大小不能超過配置的一個(gè)上限值（kylin.snapshot.max-mb，默認(rèn)值300）;
4.跳過構(gòu)建 snapshot 的 lookup 表將不能搜索，同時(shí)不支持設(shè)置為衍生維度（Derived）；
5.大部分情況下都是使用 “Left Join”，其他兩種 Join 方式不是很常用。

每一個(gè) Snapshot 是和一個(gè) Hive 維度表對應(yīng)的，生成的過程是：

從原始的hive維度表中順序得讀取每一行每一列的值;

使用 TrieDictionary 方式對這些所有的值進(jìn)行編碼（一個(gè)值對應(yīng)一個(gè) Id）；

再次讀取原始表中每一行的值，將每一列的值使用編碼之后的 Id 進(jìn)行替換，得到了一個(gè)只有 Id 的新表；

同時(shí)保存這個(gè)新表和 Dictionary 對象（Id 和值的映射關(guān)系）就能夠保存整個(gè)維度表；

Kylin 將這個(gè)數(shù)據(jù)存儲到元數(shù)據(jù)庫中。

雪花模型關(guān)系圖

第二步：資格維度選擇:

在 Dimensions 頁面選擇可能參與計(jì)算的維度，這里被選擇的只是在 Cube 構(gòu)建的時(shí)候擁有被選擇資格的維度，并不是最后參與 Cube 構(gòu)建的維度，推薦將維度表中的字段都選擇上。

如下展示了Dimensions的選擇：

• 對于KYLIN_SALES，其中SLR_SEGMENT_CD，PRICE，ITEM_COUNT沒有選擇，所以沒有資格參與cubeId構(gòu)建

• 對于KYLIN_CAL_DT，其中僅選擇了部分參與的維度，其他沒有資格參與cubeId構(gòu)建

• 對于KYLIN_CATEGORY_GROUPING，其中僅選擇了部分參與的維度，其他沒有資格參與cubeId構(gòu)建

• 對于BUYER_ACCOUNT 與 SELLER_ACCOUNT，全部有資格參與cubeId構(gòu)建

• 對于BUYER_COUNTRY，只有COUNTRY , NAME 有資格參與cubeId構(gòu)建

• 對于SELLER_COUNTRY，只有COUNTRY , NAME 有資格參與cubeId構(gòu)建

資格維度選擇結(jié)果總覽：

第三步：Measures 度量指標(biāo)選擇：

在 Measures 頁面選擇可能用于計(jì)算的度量。一般而言，銷售額、流量、溫濕度等會作為度量。

第四步：Settings設(shè)置

在 Settings 頁面可以設(shè)置分區(qū)以及過濾條件，其中分區(qū)是為了系統(tǒng)可以進(jìn)行增量構(gòu)建而設(shè)計(jì)的，目前 Kylin 支持基于日期的分區(qū)，在 “Partition Date Column” 后面選擇事實(shí)表或者維度表中的日期字段，然后選擇日期格式即可；過濾條件設(shè)置后，Kylin 在構(gòu)建的時(shí)候會選擇符合過濾條件的數(shù)據(jù)進(jìn)行構(gòu)建。

需要注意的幾點(diǎn)：

1.時(shí)間分區(qū)列可以支持日期或更細(xì)粒度的時(shí)間分區(qū)；
2.時(shí)間分區(qū)列支持的數(shù)據(jù)類型有 time/date/datetime/integer等；
3.過濾條件不需要寫 WHERE；
4.過濾條件不能包含日期維度。

三、構(gòu)建cube模型

維度選擇

在選擇維度時(shí)，每一個(gè)維度列可以作為普通維度（Normal），也可以作為衍生維度（Derived）。相對于普通維度來說，衍生維度并不參與維度的 Cuboid，衍生維度對應(yīng)的外鍵（FK）參與維度 Cuboid，從而降低 Cuboid 數(shù)。在查詢時(shí)，對衍生維度的查詢會首先轉(zhuǎn)換為對外鍵所在維度的查詢，因此會犧牲少量性能（大部分情況下可以接受）。

維度剪枝優(yōu)化

如何進(jìn)行維度優(yōu)化，首先請確認(rèn)你設(shè)置的cube維度都是你查詢時(shí)會使用到的。

目前Kylin可以使用的維度優(yōu)化手段有以下幾種：

• 聚集組

• 衍生緯度

• 強(qiáng)制維度

• 層次維度

• 聯(lián)合維度

• Extended Column

在一個(gè)多維數(shù)據(jù)集合中，維度的個(gè)數(shù)決定著維度之間可能的組合數(shù)，而每一個(gè)維度中成員集合的大小決定著每一個(gè)可能的組合的個(gè)數(shù)，例如有三個(gè)普通的維度A、B、C，他們的不同成員數(shù)分別為10/100/1000，那么一個(gè)維度的組合有2的3次方個(gè)，分別是{空、A、B、C、AB、BC、AC、ABC}，每一個(gè)成員我們稱為cuboid（維度的組合），而這些集合的成員組合個(gè)數(shù)分別為1、10、100、1000、10*100、100 1000、101000和10 *100 *1000。我們稱每一個(gè)dimension中不同成員個(gè)數(shù)為cardinatily，我們要盡量避免存儲cardinatily比較高的維度的組合。

在上面的例子中我們可以不緩存BC和C這兩個(gè)cuboid，可以通過計(jì)算的方式通過ABC中成員的值計(jì)算出BC或者C中某個(gè)成員組合的值，這相當(dāng)于是時(shí)間和空間的一個(gè)權(quán)衡吧。在kylin中存在的四種維度是為了減少cuboid的個(gè)數(shù)，而不是每一個(gè)維度是否緩存的，當(dāng)前kylin是對所有的cuboid中的所有組合都進(jìn)行計(jì)算和存儲的，對于普通的dimension，從上面的例子中可以看出N個(gè)維度的cuboid個(gè)數(shù)為2的N次方，而kylin中設(shè)置了一些維度可以減少cuboid個(gè)數(shù)，當(dāng)然，這需要使用者對自己需要的維度十分了解，知道自己可能根據(jù)什么進(jìn)行g(shù)roup by。

Mandatory維度

這種維度意味著每次查詢的group by中都會攜帶的，將某一個(gè)dimension設(shè)置為mandatory可以將cuboid的個(gè)數(shù)減少一半，如下圖：

這是因?yàn)槲覀兇_定每一次group by都會攜帶A，那么就可以省去所有不包含A這個(gè)維度的cuboid了。

hierarchy維度

這種維度是最常見的，尤其是在mondrian中，我們對于多維數(shù)據(jù)的操作經(jīng)常會有上卷下鉆之類的操作，這也就需要要求維度之間有層級關(guān)系，例如國家、省、城市，年、季度、月等。有層級關(guān)系的維度也可以大大減少cuboid的個(gè)數(shù)。如下圖：

這里僅僅局限于A/B/C是一個(gè)層級，例如A是年份，B是季度、C是月份，那么查詢的時(shí)候可能的組合只有年、xx年的季度、xx年xx季度的xx月，這就意味著我們不能再單獨(dú)的對季度和月份進(jìn)行聚合了，例如我們查詢的時(shí)候不能使用group by month，而必須使用group by year，quart，month。如果需要單獨(dú)的對month進(jìn)行聚合，那么還需要再使用month列定義一個(gè)單獨(dú)的普通維度。

derived維度

這類維度的意思是可推導(dǎo)的維度，需要該維度對應(yīng)的一個(gè)或者多個(gè)列可以和維度表的主鍵是一對一的，這種維度可以大大減少cuboid個(gè)數(shù)，如下圖：

聯(lián)合維度（Joint）

聯(lián)合維度：將幾個(gè)維度視為一個(gè)維度。

適用場景：

1.可以將確定在查詢時(shí)一定會同時(shí)使用的幾個(gè)維度設(shè)為一個(gè)聯(lián)合維度。
2.可以將基數(shù)很小的幾個(gè)維度設(shè)為一個(gè)聯(lián)合維度。
3.可以將查詢時(shí)很少使用的幾個(gè)維度設(shè)為一個(gè)聯(lián)合維度。

優(yōu)化效果：將N個(gè)維度設(shè)置為聯(lián)合維度，則這N個(gè)維度組合成的cuboid個(gè)數(shù)會從2的N次方減少到1。

粒度優(yōu)化

粒度優(yōu)化對應(yīng)的是提高Cube的并發(fā)度，其設(shè)置是在自定義屬性中的 一共有三個(gè)屬性可以提高并發(fā)度。

1.kylin.hbase.region.cut（共使用幾個(gè)分區(qū)）
2.kylin.hbase.region.count.min（最少使用幾個(gè)分區(qū)) 3.kylin.hbase.region.count.max（最多使用幾個(gè)分區(qū)）

根據(jù)相對應(yīng)的情況調(diào)高最少使用分區(qū)，降低最大使用分區(qū)，能夠有效增加系統(tǒng)的并行度。

RowKey優(yōu)化

Rowkeys: 是由維度編碼值組成。”Dictionary” （字典）是默認(rèn)的編碼方式; 字典只能處理中低基數(shù)（少于一千萬）的維度；如果維度基數(shù)很高（如大于1千萬), 選擇 “false” 然后為維度輸入合適的長度，通常是那列的最大長度值; 如果超過最大值，會被截?cái)?。請注意，如果沒有字典編碼，cube 的大小可能會非常大。

你可以拖拽維度列去調(diào)整其在 rowkey 中位置; 位于rowkey前面的列，將可以用來大幅縮小查詢的范圍。通常建議將 mandantory 維度放在開頭, 然后是在過濾 ( where 條件)中起到很大作用的維度；如果多個(gè)列都會被用于過濾，將高基數(shù)的維度（如 user_id）放在低基數(shù)的維度（如 age）的前面。

Kylin 以 Key-Value 的方式將 Cube 存儲到 HBase 中，HBase 的 key，也就是 Rowkey，是由各維度的值拼接而成的；為了更高效地存儲這些值，Kylin 會對它們進(jìn)行編碼和壓縮；每個(gè)維度均可以選擇合適的編碼（Encoding）方式，默認(rèn)采用的是字典（Dictionary）編碼技術(shù)；字段支持的基本編碼類型如下：

• dict：適用于大部分字段，默認(rèn)推薦使用，但在超高基情況下，可能引起內(nèi)存不足的問題；對于使用該種編碼的維度，每個(gè)Segment在構(gòu)建的時(shí)候都會為這個(gè)維度所有可能的值創(chuàng)建一個(gè)字典，然后使用字典中每個(gè)值的編號來編碼。Dict的優(yōu)勢是產(chǎn)生的編碼非常緊湊，尤其在維度值的基數(shù)較小且長度較大的情況下，特別節(jié)約空間。由于產(chǎn)生的字典是在查詢時(shí)加載入構(gòu)建引擎和查詢引擎的，所以在維度的基數(shù)大、長度也大的情況下，容易造成構(gòu)建引擎或查詢引擎的內(nèi)存溢出。

• boolean：適用于字段值為true, false, TRUE, FALSE, True, False, t, f, T, F, yes, no, YES, NO, Yes, No, y, n, Y, N, 1, 0；

• integer：適用于字段值為整數(shù)字符，支持的整數(shù)區(qū)間為[ -2^(8N-1), 2^(8N-1)]；Integer編碼需要提供一個(gè)額外的參數(shù)“Length”來代表需要多少個(gè)字節(jié)。Length的長度為1~8。如果用來編碼int32類型的整數(shù)，可以將Length設(shè)為4；如果用來編碼int64類型的整數(shù)，可以將Length設(shè)為8。在更多情況下，如果知道一個(gè)整數(shù)類型維度的可能值都很小，那么就能使用Length為2甚至是1的int編碼來存儲，這將能夠有效避免存儲空間的浪費(fèi)。

• date：適用于字段值為日期字符，支持的格式包括yyyyMMdd、yyyy-MM-dd、yyyy-MM-dd HH:mm:ss、yyyy-MM-dd HH:mm:ss.SSS，其中如果包含時(shí)間戳部分會被截?cái)啵粚⑷掌陬愋偷臄?shù)據(jù)使用三個(gè)字節(jié)進(jìn)行編碼，其支持從0000-01-01到9999-01-01中的每一個(gè)日期。

• time：適用于字段值為時(shí)間戳字符，支持范圍為[ 1970-01-01 00:00:00, 2038/01/19 03:14:07]，毫秒部分會被忽略，time編碼適用于 time, datetime, timestamp 等類型；Time編碼僅僅支持到秒。但是Time編碼的優(yōu)勢是每個(gè)維度僅僅使用4個(gè)字節(jié)，這相比普通的長整數(shù)編碼節(jié)約了一半。如果能夠接受秒級的時(shí)間精度，請選擇Time編碼來代表時(shí)間的維度。

• fix_length：適用于超高基場景，將選取字段的前 N 個(gè)字節(jié)作為編碼值，當(dāng) N 小于字段長度，會造成字段截?cái)?，?dāng) N 較大時(shí)，造成 RowKey 過長，查詢性能下降，只適用于 varchar 或 nvarchar 類型；編碼需要提供一個(gè)額外的參數(shù)“Length”來代表需要多少個(gè)字節(jié)。該編碼可以看作Dict編碼的一種補(bǔ)充。對于基數(shù)大、長度也大的維度來說，使用Dict可能不能正常工作，于是可以采用一段固定長度的字節(jié)來存儲代表維度值的字節(jié)數(shù)組，該數(shù)組為字符串形式的維度值的UTF-8字節(jié)。如果維度值的長度大于預(yù)設(shè)的Length，那么超出的部分將會被截?cái)唷?/p>

• fixed_length_hex：適用于字段值為十六進(jìn)制字符，比如 1A2BFF 或者 FF00FF，每兩個(gè)字符需要一個(gè)字節(jié)，只適用于 varchar 或 nvarchar 類型。

• 和Hbase 的RowKey優(yōu)化類似，在查詢的過程中，被用作過濾條件的維度可能放在其他維度的前面，經(jīng)常出現(xiàn)的維度應(yīng)該放在前面，基數(shù)比較大的維度應(yīng)該放在前面

Kylin 大數(shù)據(jù)下的OLAP解決方案和行業(yè)典型應(yīng)用

Apache Kylin在百度地圖的實(shí)踐

對于 Apache Kylin 在實(shí)際生產(chǎn)環(huán)境中的應(yīng)用，在國內(nèi)，百度地圖數(shù)據(jù)智能組是最早的一批實(shí)踐者之一。目前，百度地圖大數(shù)據(jù) OLAP 多維分析平臺承載百度地圖內(nèi)部多個(gè)基于 Apache Kylin 引擎的億級多維分析查詢項(xiàng)目，共計(jì)約 80 個(gè) cube，平均半年時(shí)間的歷史數(shù)據(jù)，共計(jì)約 50 億行的源數(shù)據(jù)規(guī)模，單表最大數(shù)據(jù)量為 20 億 + 條源數(shù)據(jù)，滿足大時(shí)間區(qū)間、復(fù)雜條件過濾、多維匯總聚合的單條 SQL 查詢毫秒級響應(yīng)，較為高效地解決了億級大數(shù)據(jù)交互查詢的性能需求。

Kylin 有效解決的痛點(diǎn)問題：

• 痛點(diǎn)一：百億級海量數(shù)據(jù)多維指標(biāo)動(dòng)態(tài)計(jì)算耗時(shí)問題，Apache Kylin 通過預(yù)計(jì)算生成 Cube 結(jié)果數(shù)據(jù)集并存儲到 HBase 的方式解決。

• 痛點(diǎn)二：復(fù)雜條件篩選問題，用戶查詢時(shí)，Apache Kylin 利用 router 查找算法及優(yōu)化的 HBase Coprocessor 解決；

• 痛點(diǎn)三：跨月、季度、年等大時(shí)間區(qū)間查詢問題，對于預(yù)計(jì)算結(jié)果的存儲，Apache Kylin 利用 Cube 的 Data Segment 分區(qū)存儲管理解決。

百度地圖大數(shù)據(jù) OLAP 平臺系統(tǒng)架構(gòu)

主要模塊包括：

• 數(shù)據(jù)接入：主要負(fù)責(zé)從數(shù)據(jù)倉庫端獲取業(yè)務(wù)所需的最細(xì)粒度的事實(shí)表數(shù)據(jù)。

• 任務(wù)管理：主要負(fù)責(zé)Cube 的相關(guān)任務(wù)的執(zhí)行、管理等。

• 任務(wù)監(jiān)控：主要負(fù)責(zé)Cube 任務(wù)在執(zhí)行過程中的狀態(tài)及相應(yīng)的操作管理。

• 集群監(jiān)控：主要包括Hadoop 生態(tài)進(jìn)程的監(jiān)控及Kylin 進(jìn)程的監(jiān)控。

基于倉庫端 join 好的 fact 事實(shí)表建 Cube，減少對小規(guī)模集群帶來的 hive join 壓力

對于 Cube 的設(shè)計(jì)，官方有專門的相關(guān)文檔說明，里面有較多的指導(dǎo)經(jīng)驗(yàn)，比如: cube 的維度最好不要超過 15 個(gè)， 對于 cardinality 較大的維度放在前面，維度的值不要過大，維度 Hierarchy 的設(shè)置等等。

實(shí)踐中，百度地圖將某個(gè)產(chǎn)品需求分為多個(gè)頁面進(jìn)行開發(fā)，每個(gè)頁面查詢主要基于事實(shí)表建的 cube，每個(gè)頁面對應(yīng)多張維度表和 1 張事實(shí)表，維度表放在 MySQL 端，由數(shù)據(jù)倉庫端統(tǒng)一管理，事實(shí)表計(jì)算后存放在 HDFS 中，事實(shí)表中不存儲維度的名稱，僅存儲維度的 id，主要基于 3 方面考慮：

• 第一：減少事實(shí)表體積

• 第二：由于我們的 Hadoop 集群是自己單獨(dú)部署的小集群，MapReduce 計(jì)算能力有限，join 操作希望在倉庫端完成，避免給 Kylin 集群帶來的 Hive join 等計(jì)算壓力

• 第三：減少回溯代價(jià)

假設(shè)我們把維度名稱也存在 Cube 中，如果維度名稱變化必然導(dǎo)致整個(gè) cube 的回溯，代價(jià)很大。這里可能有人會問，事實(shí)表中只有維度 id 沒有維度 name，假設(shè)我們需要 join 得到查詢結(jié)果中含有維度 name 的記錄，怎么辦呢？對于某個(gè)產(chǎn)品的 1 個(gè)頁面，我們查詢時(shí)傳到后臺的是維度 id，維度 id 對應(yīng)的維度 name 來自 MySQL 中的維度表，可以將維度 name 查詢出來并和維度 id 保存為 1 個(gè)維度 map 待后續(xù)使用。同時(shí)，一個(gè)頁面的可視范圍有限，查詢結(jié)果雖然總量很多，但是每一頁返回的滿足條件的事實(shí)表記錄結(jié)果有限，那么，我們可以通過之前保存的維度 map 來映射每列 id 對應(yīng)的名稱，相當(dāng)于在前端邏輯中完成了傳統(tǒng)的 id 和 name 的 join 操作。

Aggregation cube 輔助中高維度指標(biāo)計(jì)算，解決向上匯總計(jì)算數(shù)據(jù)膨脹問題

比如我們的事實(shí)表有個(gè) detail 分區(qū)數(shù)據(jù)，detail 分區(qū)包含最細(xì)粒度 os 和 appversion 兩個(gè)維度的數(shù)據(jù) (注意: cuid 維度的計(jì)算在倉庫端處理)，我們的 cube 設(shè)計(jì)也選擇 os 和 appversion，hierarchy 層次結(jié)構(gòu)上，os 是 appversion 的父親節(jié)點(diǎn)，從 os+appversion(group by os, appversion) 組合維度來看，統(tǒng)計(jì)的用戶量沒有問題，但是按照 os(group by os) 單維度統(tǒng)計(jì)用戶量時(shí)，會從基于這個(gè) detail 分區(qū)建立的 cube 向上匯總計(jì)算，設(shè)上午用戶使用的是 android 8.0 版本，下午大量用戶升級到 android 8.1 版本，android 8.0 組合維度 + android 8.1 組合維度向上計(jì)算匯總得到 os=android(group by os, where os=android) 單維度用戶，數(shù)據(jù)會膨脹且數(shù)據(jù)不準(zhǔn)確。因此我們?yōu)槭聦?shí)表增加一個(gè) agg 分區(qū)，agg 分區(qū)包含已經(jīng)從 cuid 粒度 group by 去重后計(jì)算好的 os 單維度結(jié)果。這樣，當(dāng)用戶請求 os 維度匯總的情況下，Apache Kylin 會根據(jù) router 算法，計(jì)算出符合條件的候選 cube 集合，并按照權(quán)重進(jìn)行優(yōu)選級排序 (熟悉 MicroStrategy 等 BI 產(chǎn)品的同學(xué)應(yīng)該知道這類案例)，選擇器會選中基于 agg 分區(qū)建立的 os 單維度 agg cube，而不從 detail 這個(gè)分區(qū)建立的 cube 來自底向上從最細(xì)粒度往高匯總，從而保證了數(shù)據(jù)的正確性。

新增留存類分析，如何更高效更新歷史記錄

對應(yīng)小規(guī)模集群，計(jì)算資源是非常寶貴的，假設(shè)我們對于某個(gè)項(xiàng)目的留存分析到了日對 1 日到日對 30 日，日對 1 周到日對 4 周，日對 1 月到日對 4 月，周對 1 周到周對 4 周，月對 1 月到月對 4 月。那么對于傳統(tǒng)的存儲方案，我們將遇到問題。

假如今天是 2015-12-02，我們計(jì)算實(shí)際得到的是 2015-12-01 的數(shù)據(jù)。

此方案的思路是，當(dāng)今天是2015-12-02，實(shí)際是2015-12-01 的數(shù)據(jù)，如上示例存儲，但日對第n 日的留存表示的是n 日前對應(yīng)的那個(gè)日期的留存量，相當(dāng)于旋轉(zhuǎn)了紅色對角線。

此方案的優(yōu)勢：

1.如果要查看某個(gè)時(shí)間范圍內(nèi)的某 1 個(gè)指標(biāo)，直接選擇該范圍的該列指標(biāo)即可
2.如果今后增加新的留存，比如半年留存，年留存等指標(biāo)，不需要級聯(lián)更新歷史天數(shù)的數(shù)據(jù)，只需要更新 2015-12-01 這 1 天的數(shù)據(jù)，時(shí)間復(fù)雜度 O(1) 不變，對物理機(jī)器資源要求不高。

此方案的缺點(diǎn)：

1.如果涉及到某 1 天或者某個(gè)時(shí)間范圍的多列指標(biāo)查詢，需要前端開發(fā)留存分析特殊處理邏輯，根據(jù)相應(yīng)的時(shí)間窗口滑動(dòng)，從不同的行，選擇不同的列，然后渲染到前端頁面。

Apache Kylin在鏈家的實(shí)踐

鏈家Kylin平臺的架構(gòu)如圖：

如上，為鏈家 Olap 平臺結(jié)構(gòu)，于 16 年底搭建。Kylin 采用集群部署模式，共部署 6 臺機(jī)器，3 臺用于分布式構(gòu)建 Cube，3 臺用于負(fù)載均衡查詢，query 單臺可用內(nèi)存限制在 80G。同時(shí)，計(jì)算集群一旦運(yùn)行大任務(wù)，內(nèi)存壓力大的時(shí)候，HBase 就會性能非常差，為避免和計(jì)算集群互相影響，Kylin 集群依賴獨(dú)立的 Hbase 集群。同時(shí)，對 Hbase 集群做了相應(yīng)的優(yōu)化，包括：讀寫分離、SSD_FIRST 優(yōu)先讀取遠(yuǎn)程 SSD、并對依賴的 hdfs 做了相應(yīng)優(yōu)化。

由于 Kylin 只專注預(yù)計(jì)算，不保存明細(xì)數(shù)據(jù)，對于即席查詢和明細(xì)查詢，通過自研 QE 引擎實(shí)現(xiàn)，底層依賴 spark、presto、hive，通過特定規(guī)則，路由到相應(yīng)查詢引擎執(zhí)行查詢。多維分析查詢，由 Kylin 集群提供查詢服務(wù)，可實(shí)現(xiàn)簡單的實(shí)時(shí)聚合計(jì)算。

當(dāng)前 Kylin 主要查詢方為指標(biāo) API 平臺，能根據(jù)查詢 sql 特征，做相應(yīng)緩存。指標(biāo) API 作為數(shù)據(jù)統(tǒng)一出口，衍生出其他一些業(yè)務(wù)產(chǎn)品。使用統(tǒng)計(jì)，如下：Cube 數(shù)量 500+，覆蓋公司 12 個(gè)業(yè)務(wù)線。Cube 存儲總量 200+TB，數(shù)據(jù)行萬億級，單 Cube 最大 40+億行。日查詢量 27 萬+，緩存不命中情況下，時(shí)延 < 500ms(70%), < 1s(90%)，少量復(fù)雜 sql 查詢耗時(shí) 10s 左右。

當(dāng)前，kylin 在用版本為 1.6，最新版本為 2.3。自 2.0 版本之后，又新增了一些新的特性，配置文件和屬性也做了一些調(diào)整。由于，Cube 數(shù)據(jù)量大，涉及業(yè)務(wù)方多，在當(dāng)前無明顯瓶頸的情況下，沒有實(shí)時(shí)更新新版本。但是，引入了 2.0+新增的一些重要特性，如分布式構(gòu)建和分布式鎖。

鏈家維護(hù)了自己的一套 Kylin 代碼，使用過程中，針對特定場景的進(jìn)行一些優(yōu)化開發(fā)，包括：

支持分布式構(gòu)建。原生 kylin 是只能有一臺機(jī)器進(jìn)行構(gòu)建。的當(dāng) kylin 上的 cube 越來越多，單臺機(jī)器顯然不能滿足任務(wù)需求，除了任務(wù)數(shù)據(jù)有限制，任務(wù)多時(shí)也會互相影響數(shù)據(jù)構(gòu)建的效率。通過修改 kylin 的任務(wù)調(diào)度策略，支持了多臺機(jī)器同時(shí)構(gòu)建數(shù)據(jù)。使 kylin 的構(gòu)建能力可以橫向擴(kuò)展，來保證數(shù)據(jù)構(gòu)建；

優(yōu)化構(gòu)建時(shí)字典下載策略。原生 kylin 在 build cubiod data 時(shí)用的字典，會將該字段的全部字典下載到節(jié)點(diǎn)上，當(dāng)字段的字典數(shù)量很多或者字典文件很大時(shí)，會在文件傳輸上消耗很多不必要的時(shí)間。通過修改代碼，使任務(wù)只下載需要的字典文件，從而減少文件傳輸時(shí)間消耗，加快構(gòu)建；

全局字典鎖，在同一 Cube 所任務(wù)構(gòu)建時(shí)，由于共享全局字典鎖，當(dāng)某執(zhí)行任務(wù)異常時(shí)，會導(dǎo)致其他任務(wù)獲取不到鎖，此 bug 已修復(fù)并提交官方；

支持設(shè)置 Cube 強(qiáng)制關(guān)聯(lián)維表，過濾事實(shí)表中無效的維度數(shù)據(jù)。kylin 創(chuàng)建的臨時(shí)表作為數(shù)據(jù)源。當(dāng)使用 olap 表和維表關(guān)聯(lián)字段作為維度時(shí)，會默認(rèn)不關(guān)聯(lián)維表，直接使用 olap 中的字段做維度。而在 Build Cube 這一步又會使用維表的字典來轉(zhuǎn)換維度的值。如果 olap 中的值維表中沒有就會產(chǎn)生問題。我們通過增加配置項(xiàng)，可以使 kylin 強(qiáng)制關(guān)聯(lián)維表，來過濾掉 olap 表中的臟數(shù)據(jù)；

Kylin query 機(jī)器，查詢或者聚合，會加載大量的數(shù)據(jù)到內(nèi)存，內(nèi)存占用大，甚至存在頻繁 Full GC 的情況。這種情況下，CMS 垃圾回收表現(xiàn)不是很好，因此更換為 G1 收集器，盡量做到 STW 時(shí)間可控，并及時(shí)調(diào)優(yōu)。

Kylin在滴滴OLAP引擎中的應(yīng)用

下圖為 Kylin 在滴滴 OLAP 引擎中的部署情況，Kylin 集群包含 2 臺分布式構(gòu)建節(jié)點(diǎn)、8 臺查詢節(jié)點(diǎn)，其中 2 臺查詢節(jié)點(diǎn)作為集群接口承接 REST 請求，REST 請求主要包含兩類：構(gòu)建作業(yè)狀態(tài)查詢和創(chuàng)建類操作，創(chuàng)建類操作如裝載表、建模、創(chuàng)建立方體以及對等的刪除操作等等。對于構(gòu)建作業(yè)狀態(tài)查詢輪詢請求兩臺節(jié)點(diǎn)，而對創(chuàng)建類操作則請求其中固定的一臺節(jié)點(diǎn)，另一臺作為 Standby 存在，這樣設(shè)計(jì)的主要目的是避免集群接口的單點(diǎn)問題，同時(shí)解決因 Kylin 集群元數(shù)據(jù)同步機(jī)制導(dǎo)致的可能出現(xiàn)的創(chuàng)建類操作失敗問題。

Kylin 作為固化分析場景引擎，主要負(fù)責(zé)對有聚合緩存需求的表進(jìn)行查詢加速。什么樣的表會有這樣的需求呢？

• 報(bào)表類產(chǎn)品使用的表

• 經(jīng) OLAP 引擎數(shù)據(jù)轉(zhuǎn)移決策識別認(rèn)為需要進(jìn)行聚合緩存的表

前者不難理解，后者則如引擎中的表，表數(shù)據(jù)規(guī)模較大，且被頻繁執(zhí)行某種聚合分析，在一段時(shí)間內(nèi)達(dá)到一定的頻次，引擎會識別并認(rèn)為該表需要執(zhí)行聚合緩存，進(jìn)而觸發(fā)調(diào)度將數(shù)據(jù)“復(fù)制”到 Kylin。這樣，下次針對該表的聚合分析如果可被 Kylin 的聚合緩存覆蓋，就會直接查詢 Kylin 中的聚合數(shù)據(jù)“副本”而非原始的明細(xì)數(shù)據(jù)“副本”。

Apache Kylin 在場景引擎中的使用效果

目前，Kylin 集群維護(hù)了700+ 的立方體，每日運(yùn)行2000+ 的構(gòu)建作業(yè)，平均構(gòu)建時(shí)長37 分鐘，立方體存儲總量30+TB（已去除HDFS 副本影響）；對未使用緩存的查詢進(jìn)行統(tǒng)計(jì)，80% 的查詢耗時(shí)小于500ms，90% 的查詢耗時(shí)小于2.8 秒。需要說明的是，由于OLAP 引擎中“數(shù)據(jù)轉(zhuǎn)移決策”模塊會根據(jù)查詢場景觸發(fā)數(shù)據(jù)“復(fù)制”到Kylin 中來，在近期的統(tǒng)計(jì)中，立方體數(shù)量一度會達(dá)到1100+。

在業(yè)務(wù)方面，Kylin 間接服務(wù)了下游數(shù)易（面向全公司的報(bào)表類數(shù)據(jù)產(chǎn)品）、開放平臺（面向全公司的查詢?nèi)肟冢┑榷鄠€(gè)重要數(shù)據(jù)產(chǎn)品，覆蓋了快車、專車等十多個(gè)業(yè)務(wù)線的分析使用，間接用戶3000+，Kylin 的引入為用戶提供了穩(wěn)定、可靠、高效的固化分析性能。

使用 Apache Kylin 遇到的挑戰(zhàn)

滴滴使用 Kylin 的方式與傳統(tǒng)方式有異，Kylin 在架構(gòu)設(shè)計(jì)上與業(yè)務(wù)緊耦合，傳統(tǒng)方式中業(yè)務(wù)分析人員基于 Kylin 建模、構(gòu)建立方體（Cube），然后執(zhí)行分析查詢。但滴滴將 Kylin 作為固化分析場景下的引擎使用，提供針對表的聚合緩存服務(wù)，這樣作為一個(gè)通用數(shù)據(jù)組件的 Kylin 就剝離了業(yè)務(wù)屬性，且與用戶相割裂，對外透明。

在最初的使用中，由于沒有控制 OLAP 引擎的內(nèi)部并發(fā)，來自調(diào)度的聚合緩存任務(wù)會在某些情況下高并發(fā)地執(zhí)行 Kylin 的表加載、模型和立方體的創(chuàng)建，因?yàn)?Kylin Project 元數(shù)據(jù)的更新機(jī)制導(dǎo)致操作存在失敗的可能。當(dāng)前，我們通過在 OLAP 引擎內(nèi)部使用隊(duì)列在一定程度上緩解了問題的發(fā)生，此外，結(jié)合重試機(jī)制，基本可以保證操作的成功完成。最后我們也注意到，該問題在最新的 Kylin 版本中已經(jīng)進(jìn)行了修復(fù)。

另外，Kylin 默認(rèn)地，在刪除立方體時(shí)不會卸載 HBase 中的 Segment 表，而需定期執(zhí)行腳本進(jìn)行清理。這樣，就導(dǎo)致引擎運(yùn)行時(shí)及時(shí)卸載無效的立方體無法級聯(lián)到 HBase，給 HBase 造成了較大的運(yùn)維壓力。因此我們也對源碼進(jìn)行了調(diào)整，在立方體刪除時(shí)增加了 HBase Segment 表清理的功能等等。