什麼是麒麟(kylin)？查數據賊快的喲

前言

微信搜【 Java3y】關注這個有夢想的男人，點贊關注是對我最大的支持！

文本已收錄至個人GitHub：https://github.com/ZhongFuCheng3y/3y，有300多篇原創文章，最近在連載面試和項目系列！

今天想跟你們一塊兒入門一下kylin（麒麟）。

因爲工做須要，前段時間對kylin簡單入了個門，如今來寫寫筆記（個人文字或許能幫助到你入門kylin，至少看完這篇應該能知道kylin是幹什麼的）。

很少BB，開始吧

kylin介紹

kylin是咱們國人主導並貢獻到Apache基金會的開源項目，因此咱們會有中文文檔學習：

http://kylin.apache.org/cn/

從官方咱們能夠看到對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的步驟是什麼？官方已經幫咱們解答了：

1. 定義數據集上的一個星形或雪花形模型
2. 在定義的數據表上構建cube
3. 使用標準 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作了個簡單的入門，細節仍是得看官網（有中文，比較好讀，文檔也作得挺好的）。後面細節若是有必要我再來補充就行了（：

參考資料：

• https://blog.csdn.net/wangxiaojing123/category_8792666.html

三歪把【大廠面試知識點】、【簡歷模板】、【原創文章】所有整理成電子書，共有1263頁！點擊下方連接直接取就行了

• GitHub
• Gitee訪問更快

PDF文檔的內容均爲手打，有任何的不懂均可以直接來問我