前言
微信搜【Java3y】關注這個有夢想的男人，點贊關注是對我最大的支持！
文本已收錄至我的GitHub：https://github.com/ZhongFuCheng3y/3y，有300多篇原創文章，最近在連載面試和項目系列！
今天想跟大家一起入門一下kylin（麒麟）。
由於工作需要，前段時間對kylin簡單入了個門，現在來寫寫筆記（我的文字或許能幫助到你入門kylin，至少看完這篇應該能知道kylin是干什么的）。
不多BB，開始吧
kylin介紹
kylin是我們國人主導並貢獻到Apache基金會的開源項目，所以我們會有中文文檔學習：
從官方我們可以看到對kylin的介紹：Apache Kylin™是一個開源的、分布式的分析型數據倉庫，提供Hadoop/Spark 之上的SQL查詢接口及多維分析（OLAP）能力以支持超大規模數據，最初由 eBay 開發並貢獻至開源社區，它能在亞秒內查詢巨大的表。
看到這個介紹，只能用兩個字來形容kylin：牛逼🐂。那牛逼在哪呢？下面再說
第一眼看過去，可能有的同學不知道OLAP是什么東西，我下面來簡單解釋一下吧。（Hadoop/Spark/SQL/大數據這些詞天天能看見，即便不懂它的原理，你都知道這些東西是有什么用，是用來干嘛的，對吧？）
看到OLAP就不得不提它的兄弟OLTP，我們簡單來看看他們的全稱和翻譯的中文是什么：
-
OLTP：On-Line Transaction Processing（聯機事務處理） -
OLAP：On-Line Analytical Processing（聯機分析處理）
中文的翻譯我們怕是看不懂的了，但我們可以發現他倆的區別一個是「事務」，一個是「分析」
從應用層面看，我們可以簡單地認為：OLTP主要用於業務系統，對事務的要求比較高，例如下單/交易（銀行轉賬等業務）。OLAP主要用於數據倉庫系統，支持復雜的分析操作，側重決策支持，並且提供直觀易懂的查詢結果。
我再畫張思維導圖圖來給大家看一下，基本就懂了：
看到這里，你應該對OLAP有個基本的了解了。那再回到上面那句話：多維分析（OLAP）能力以支持超大規模數據，你第一反應會想到什么？
三歪第一反應想到的就是Hive（Hive底層是HDFS：支持超大規模的數據）。
那既然說到Hive了，你會發現kylin前半段話，Hive好像幾乎都可以支持，但除了最后一句「它能在亞秒內查詢巨大的表」。
沒錯，到這里就可以知道kylin的用途了：它可以在亞秒內查詢巨大的表，來完成數據分析和決策
每次跑Hive我們可能都得跑幾分鍾（像我SQL寫得爛的，跑半小時也是經常有的事），我們從業務上就希望用來分析的數據可以跑得更快，支持這種需求的kylin就火🔥起來了。
我以Hive來引申kylin，除了kylin就沒其他選擇了嗎？那顯然不是的。
當年我剛進公司的時候，吐槽Hive跑得太慢了，隔壁的小哥就告訴我：你用presto啊，我們大數據平台都支持的。
OLAP所提供的工具框架還是很多的，下面我們來簡單認識一下吧
眾所周知，執行Hive實際上是跑Map-Reduce任務去HDFS拿數據。執行的過程涉及到計算和存儲。
有的人覺得Hive跑Map-Reduce計算這個過程太慢了，所以就不用Map-Reduce，用別的計算引擎，比如用MPP架構來跑，但存儲沒變...
有的人覺得，存儲在HDFS去拿數據太慢了，改個存儲的地方，不從HDFS拿...
有的人覺得，這啥破玩意，計算和存儲我都改了，用我的框架一站式給你解決掉...
有的人覺得，Hadoop生態還是可以的，我先聚合一把，你查的時候直接拿聚合后的數據，也是很快的...
由於每個公司的業務場景和背景不一樣，每個OLAP框架的長處也不一樣，所以現在有如此多的OLAP技術在發光發熱...
Kylin入門
從前面我們已經知道為什么會出現如此多的OLAP的技術了，從本質上來說就是我們希望分析的數據可以讓我們查得更快，而kylin是這些技術其中的一員。
從上圖也可以看到kylin是完全依賴Hadoop生態的，那kylin是怎么實現提速的呢？答案就是：預聚合
假設我們從MySQL檢索日期大於2020-10-20的所有數據，只要我們在日期列加上索引，可以很快就能查出相關的數據。
但如果我們從MySQL檢索日期大於2020-10-20的所有數據且每個用戶在這段時間內消費了多少錢且xxxx，只要數據量大，不論你怎么建索引，查詢的速度就不盡人意了。
那如果我按天的維度先做好對每個用戶的統計，寫到一張表中，等到用戶按日期檢索的時候是不是就很快了（因為我已經按天聚合了一次數據，這張表比起原來的原始表數量會大大減少）
kylin就是用預聚合這種思路來提高查詢的速度，使它可以在亞秒內實現查詢響應。
那我們使用kylin的步驟是什么？官方已經幫我們解答了：
-
定義數據集上的一個星形或雪花形模型 -
在定義的數據表上構建 cube -
使用標准 SQL通過ODBC、JDBC或RESTFUL API進行查詢，僅需亞秒級響應時間即可獲得查詢結果
上面幾個步驟，可能你不太了解的幾個詞有以下 星形模型、雪花模型、cube，下面我來簡單解釋一下：
在數據倉庫領域上，我們的主表叫做事實表，事實表外鍵依賴的表叫做維度表。
「星形模型」：所有的維度表都直連到事實表。（上圖）
「雪花形模型」：當有一個或多個維度表沒有直接連接到事實表上，而需要通過其他維表連接到事實表（下圖）
在kylin里，分析數據的角度叫做「維度」，被分析的指標叫做「度量」
好了，我們再來看看cube是什么意思吧：
一個多維數據集稱為一個OLAP Cube：上面的幾張二維表我們可以形成一個數據立方體，這個數據立方體就是Cube
一個Cube可以由不同的角度去看，可以看似這多個角度都是從一個完整的Cube拆分出來的，例如：
結合上面所說的：Cube實際上就是從數據集中通過不同的維度構建出來的一個立方體（雖然圖上的都是三維，但你構建的Cube可以遠超三維）
kylin就是在Cube這個立方體來獲取數據的，從官方的說法也很明確，可以通過JDBC/RESTful的方式來獲取數據。
那kylin是將聚合的數據存儲在哪的呢（肯定是有存儲的地方的嘛）？在HBase上。如果還沒學過HBase的同學，可以先看看我以往的文章：HBase入門
使用kylin步驟：
-
首先你得有數據（一般來自 Hive/Kafka)，在Kylin上定義對應的數據模型(結構) -
通過 kylin系統配置需要聚合以及統計的字段（這塊就是上面所提到的維度和度量），然后構建出Cube（這塊就是kylin的預聚合，把需要統計的維度都定義好，提前計算） -
kylin會把數據存放在HBase上，你可以通過JDBC/RESTful的方式來查詢數據
使用kylin
在官網上也列出比較常見的QA，大家可以看看：http://kylin.apache.org/cn/docs/gettingstarted/faq.html
雖然kylin能支持多維度的聚合，但我們在建Cube一般要對Cube進行剪枝（即減少Cuboid的生成）
假設我們有10 個維度，那么沒有經過任何優化的Cube就會存在2的十次方 =1000+個Cuboid。
Cube 的最大物理維度數量 (不包括衍生維度) 是 63，但是不推薦使用大於 30 個維度的 Cube，會引起維度災難。
常用的剪枝方式會用聚合組(Aggregation group)配置來實現，而在聚合組中，Mandatory（強制維度）又是用得比較多的。
比如說，本來我有A、B、C三個維度，如果我不做任何優化，我的組合應該會有7個，分別是（A）（B）（C）（AB）（ABC）（AC）（BC），如果我指定A維度為強制維度，那最后的組合就只有（A）（AB）（ABC）（AC）。強制索引指的就是：指定的字段一定會被查詢條件中
除了強制維度（Mandatory），還有層級維度（Hierarchy）和聯合維度（Joint）幫助我們剪枝（即減少Cuboid的生成），一般強制維度和聯合維度用得比較多。
我們去查kylin數據的時候，是已經被聚合過存放在HBase的，所以查詢起來是相當快的，但是構建Cube這個過程其實是挺慢的（十幾分鍾到半小時都是正常的）。
這就會帶來延遲（Cube需要時間構建，同時也不可能秒級去請求構建一次Cube）那這能忍受嗎？這意味着最新的數據得等Cube任務調度到了且Cube構建完成才能查到數據
畫外音：構建Cube一般都是定時任務的方式請求kylin的api進行構建的。
Kylin 沒有內置的調度程度。您可以通過 REST API 從外部調度程度服務中觸發 Cube 的定時構建，如 Linux 的命令
crontab、Apache Airflow 等。
但在新的kylin版本中已經支持realtime_olap了，kylin存儲了實時的數據再加上HBase的數據merge后返回就實現了realtime
最后
這篇文章對kylin做了個簡單的入門，細節還是得看官網（有中文，比較好讀，文檔也做得挺好的）。后面細節如果有必要我再來補充就好了（：
參考資料：
三歪把【大廠面試知識點】、【簡歷模板】、【原創文章】全部整理成電子書，共有1263頁！點擊下方鏈接直接取就好了
PDF文檔的內容均為手打，有任何的不懂都可以直接來問我
