前言
微信搜【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文件的內容均為手打，有任何的不懂都可以直接來問我
