【三歪教你些能裝逼的】麒麟入門教程
三歪第399篇原創(chuàng)文章
今天想跟大家一起入門一下kylin（麒麟）。
由于工作需要，前段時(shí)間對(duì)kylin簡(jiǎn)單入了個(gè)門，現(xiàn)在來(lái)寫寫筆記（我的文字或許能幫助到你入門kylin，至少看完這篇應(yīng)該能知道kylin是干什么的）。
不多BB，開始吧
kylin介紹
kylin是我們國(guó)人主導(dǎo)并貢獻(xiàn)到Apache基金會(huì)的開源項(xiàng)目，所以我們會(huì)有中文文檔學(xué)習(xí)：
http://kylin.apache.org/cn/
從官方我們可以看到對(duì)kylin的介紹：Apache Kylin?是一個(gè)開源的、分布式的分析型數(shù)據(jù)倉(cāng)庫(kù)，提供Hadoop/Spark 之上的SQL查詢接口及多維分析（OLAP）能力以支持超大規(guī)模數(shù)據(jù)，最初由 eBay 開發(fā)并貢獻(xiàn)至開源社區(qū)，它能在亞秒內(nèi)查詢巨大的表。
看到這個(gè)介紹，只能用兩個(gè)字來(lái)形容kylin：牛逼?。那牛逼在哪呢？下面再說(shuō)
第一眼看過(guò)去，可能有的同學(xué)不知道OLAP是什么東西，我下面來(lái)簡(jiǎn)單解釋一下吧。（Hadoop/Spark/SQL/大數(shù)據(jù)這些詞天天能看見，即便不懂它的原理，你都知道這些東西是有什么用，是用來(lái)干嘛的，對(duì)吧？）
看到OLAP就不得不提它的兄弟OLTP，我們簡(jiǎn)單來(lái)看看他們的全稱和翻譯的中文是什么：
OLTP：On-Line Transaction Processing（聯(lián)機(jī)事務(wù)處理） OLAP：On-Line Analytical Processing（聯(lián)機(jī)分析處理）
中文的翻譯我們怕是看不懂的了，但我們可以發(fā)現(xiàn)他倆的區(qū)別一個(gè)是「事務(wù)」，一個(gè)是「分析」
從應(yīng)用層面看，我們可以簡(jiǎn)單地認(rèn)為：OLTP主要用于業(yè)務(wù)系統(tǒng)，對(duì)事務(wù)的要求比較高，例如下單/交易（銀行轉(zhuǎn)賬等業(yè)務(wù)）。OLAP主要用于數(shù)據(jù)倉(cāng)庫(kù)系統(tǒng)，支持復(fù)雜的分析操作，側(cè)重決策支持，并且提供直觀易懂的查詢結(jié)果。
我再畫張思維導(dǎo)圖圖來(lái)給大家看一下，基本就懂了：
看到這里，你應(yīng)該對(duì)OLAP有個(gè)基本的了解了。那再回到上面那句話：多維分析（OLAP）能力以支持超大規(guī)模數(shù)據(jù)，你第一反應(yīng)會(huì)想到什么？
三歪第一反應(yīng)想到的就是Hive（Hive底層是HDFS：支持超大規(guī)模的數(shù)據(jù)）。
那既然說(shuō)到Hive了，你會(huì)發(fā)現(xiàn)kylin前半段話，Hive好像幾乎都可以支持，但除了最后一句「它能在亞秒內(nèi)查詢巨大的表」。
沒(méi)錯(cuò)，到這里就可以知道kylin的用途了：它可以在亞秒內(nèi)查詢巨大的表，來(lái)完成數(shù)據(jù)分析和決策
每次跑Hive我們可能都得跑幾分鐘（像我SQL寫得爛的，跑半小時(shí)也是經(jīng)常有的事），我們從業(yè)務(wù)上就希望用來(lái)分析的數(shù)據(jù)可以跑得更快，支持這種需求的kylin就火?起來(lái)了。
我以Hive來(lái)引申kylin，除了kylin就沒(méi)其他選擇了嗎？那顯然不是的。
當(dāng)年我剛進(jìn)公司的時(shí)候，吐槽Hive跑得太慢了，隔壁的小哥就告訴我：你用presto啊，我們大數(shù)據(jù)平臺(tái)都支持的。
OLAP所提供的工具框架還是很多的，下面我們來(lái)簡(jiǎn)單認(rèn)識(shí)一下吧
眾所周知，執(zhí)行Hive實(shí)際上是跑Map-Reduce任務(wù)去HDFS拿數(shù)據(jù)。執(zhí)行的過(guò)程涉及到計(jì)算和存儲(chǔ)。
有的人覺(jué)得Hive跑Map-Reduce計(jì)算這個(gè)過(guò)程太慢了，所以就不用Map-Reduce，用別的計(jì)算引擎，比如用MPP架構(gòu)來(lái)跑，但存儲(chǔ)沒(méi)變...
有的人覺(jué)得，存儲(chǔ)在HDFS去拿數(shù)據(jù)太慢了，改個(gè)存儲(chǔ)的地方，不從HDFS拿...
有的人覺(jué)得，這啥破玩意，計(jì)算和存儲(chǔ)我都改了，用我的框架一站式給你解決掉...
有的人覺(jué)得，Hadoop生態(tài)還是可以的，我先聚合一把，你查的時(shí)候直接拿聚合后的數(shù)據(jù)，也是很快的...
由于每個(gè)公司的業(yè)務(wù)場(chǎng)景和背景不一樣，每個(gè)OLAP框架的長(zhǎng)處也不一樣，所以現(xiàn)在有如此多的OLAP技術(shù)在發(fā)光發(fā)熱...
Kylin入門
從前面我們已經(jīng)知道為什么會(huì)出現(xiàn)如此多的OLAP的技術(shù)了，從本質(zhì)上來(lái)說(shuō)就是我們希望分析的數(shù)據(jù)可以讓我們查得更快，而kylin是這些技術(shù)其中的一員。
從上圖也可以看到kylin是完全依賴Hadoop生態(tài)的，那kylin是怎么實(shí)現(xiàn)提速的呢？答案就是：預(yù)聚合
假設(shè)我們從MySQL檢索日期大于2020-10-20的所有數(shù)據(jù)，只要我們?cè)?strong>日期列加上索引，可以很快就能查出相關(guān)的數(shù)據(jù)。
但如果我們從MySQL檢索日期大于2020-10-20的所有數(shù)據(jù)且每個(gè)用戶在這段時(shí)間內(nèi)消費(fèi)了多少錢且xxxx，只要數(shù)據(jù)量大，不論你怎么建索引，查詢的速度就不盡人意了。
那如果我按天的維度先做好對(duì)每個(gè)用戶的統(tǒng)計(jì)，寫到一張表中，等到用戶按日期檢索的時(shí)候是不是就很快了（因?yàn)槲乙呀?jīng)按天聚合了一次數(shù)據(jù)，這張表比起原來(lái)的原始表數(shù)量會(huì)大大減少）
kylin就是用預(yù)聚合這種思路來(lái)提高查詢的速度，使它可以在亞秒內(nèi)實(shí)現(xiàn)查詢響應(yīng)。
那我們使用kylin的步驟是什么？官方已經(jīng)幫我們解答了：
定義數(shù)據(jù)集上的一個(gè)星形或雪花形模型 在定義的數(shù)據(jù)表上構(gòu)建 cube使用標(biāo)準(zhǔn) SQL通過(guò)ODBC、JDBC或RESTFUL API進(jìn)行查詢，僅需亞秒級(jí)響應(yīng)時(shí)間即可獲得查詢結(jié)果
上面幾個(gè)步驟，可能你不太了解的幾個(gè)詞有以下 星形模型、雪花模型、cube，下面我來(lái)簡(jiǎn)單解釋一下：
在數(shù)據(jù)倉(cāng)庫(kù)領(lǐng)域上，我們的主表叫做事實(shí)表，事實(shí)表外鍵依賴的表叫做維度表。
「星形模型」：所有的維度表都直連到事實(shí)表。（上圖）
「雪花形模型」：當(dāng)有一個(gè)或多個(gè)維度表沒(méi)有直接連接到事實(shí)表上，而需要通過(guò)其他維表連接到事實(shí)表（下圖）
在kylin里，分析數(shù)據(jù)的角度叫做「維度」，被分析的指標(biāo)叫做「度量」
好了，我們?cè)賮?lái)看看cube是什么意思吧：
一個(gè)多維數(shù)據(jù)集稱為一個(gè)OLAP Cube：上面的幾張二維表我們可以形成一個(gè)數(shù)據(jù)立方體，這個(gè)數(shù)據(jù)立方體就是Cube
一個(gè)Cube可以由不同的角度去看，可以看似這多個(gè)角度都是從一個(gè)完整的Cube拆分出來(lái)的，例如：
結(jié)合上面所說(shuō)的：Cube實(shí)際上就是從數(shù)據(jù)集中通過(guò)不同的維度構(gòu)建出來(lái)的一個(gè)立方體（雖然圖上的都是三維，但你構(gòu)建的Cube可以遠(yuǎn)超三維）
kylin就是在Cube這個(gè)立方體來(lái)獲取數(shù)據(jù)的，從官方的說(shuō)法也很明確，可以通過(guò)JDBC/RESTful的方式來(lái)獲取數(shù)據(jù)。
那kylin是將聚合的數(shù)據(jù)存儲(chǔ)在哪的呢（肯定是有存儲(chǔ)的地方的嘛）？在HBase上。如果還沒(méi)學(xué)過(guò)HBase的同學(xué)，可以先看看我以往的文章：HBase入門
使用kylin步驟：
首先你得有數(shù)據(jù)（一般來(lái)自 Hive/Kafka)，在Kylin上定義對(duì)應(yīng)的數(shù)據(jù)模型(結(jié)構(gòu))通過(guò) kylin系統(tǒng)配置需要聚合以及統(tǒng)計(jì)的字段（這塊就是上面所提到的維度和度量），然后構(gòu)建出Cube（這塊就是kylin的預(yù)聚合，把需要統(tǒng)計(jì)的維度都定義好，提前計(jì)算）kylin會(huì)把數(shù)據(jù)存放在HBase上，你可以通過(guò)JDBC/RESTful的方式來(lái)查詢數(shù)據(jù)
使用kylin
在官網(wǎng)上也列出比較常見的QA，大家可以看看：http://kylin.apache.org/cn/docs/gettingstarted/faq.html
雖然kylin能支持多維度的聚合，但我們?cè)诮?code style="font-size: 14px;padding: 2px 4px;border-radius: 4px;margin-right: 2px;margin-left: 2px;color: rgb(30, 107, 184);background-color: rgba(27, 31, 35, 0.05);font-family: "Operator Mono", Consolas, Monaco, Menlo, monospace;word-break: break-all;">Cube一般要對(duì)Cube進(jìn)行剪枝（即減少Cuboid的生成）
假設(shè)我們有10 個(gè)維度，那么沒(méi)有經(jīng)過(guò)任何優(yōu)化的Cube就會(huì)存在2的十次方 =1000+個(gè)Cuboid。
Cube 的最大物理維度數(shù)量 (不包括衍生維度) 是 63，但是不推薦使用大于 30 個(gè)維度的 Cube，會(huì)引起維度災(zāi)難。
常用的剪枝方式會(huì)用聚合組(Aggregation group)配置來(lái)實(shí)現(xiàn)，而在聚合組中，Mandatory（強(qiáng)制維度）又是用得比較多的。
比如說(shuō)，本來(lái)我有A、B、C三個(gè)維度，如果我不做任何優(yōu)化，我的組合應(yīng)該會(huì)有7個(gè)，分別是（A）（B）（C）（AB）（ABC）（AC）（BC），如果我指定A維度為強(qiáng)制維度，那最后的組合就只有（A）（AB）（ABC）（AC）。強(qiáng)制索引指的就是：指定的字段一定會(huì)被查詢條件中
除了強(qiáng)制維度（Mandatory），還有層級(jí)維度（Hierarchy）和聯(lián)合維度（Joint）幫助我們剪枝（即減少Cuboid的生成），一般強(qiáng)制維度和聯(lián)合維度用得比較多。
我們?nèi)ゲ?code style="font-size: 14px;padding: 2px 4px;border-radius: 4px;margin-right: 2px;margin-left: 2px;color: rgb(30, 107, 184);background-color: rgba(27, 31, 35, 0.05);font-family: "Operator Mono", Consolas, Monaco, Menlo, monospace;word-break: break-all;">kylin數(shù)據(jù)的時(shí)候，是已經(jīng)被聚合過(guò)存放在HBase的，所以查詢起來(lái)是相當(dāng)快的，但是構(gòu)建Cube這個(gè)過(guò)程其實(shí)是挺慢的（十幾分鐘到半小時(shí)都是正常的）。
這就會(huì)帶來(lái)延遲（Cube需要時(shí)間構(gòu)建，同時(shí)也不可能秒級(jí)去請(qǐng)求構(gòu)建一次Cube）那這能忍受嗎？這意味著最新的數(shù)據(jù)得等Cube任務(wù)調(diào)度到了且Cube構(gòu)建完成才能查到數(shù)據(jù)
畫外音：構(gòu)建Cube一般都是定時(shí)任務(wù)的方式請(qǐng)求kylin的api進(jìn)行構(gòu)建的。
Kylin 沒(méi)有內(nèi)置的調(diào)度程度。您可以通過(guò) REST API 從外部調(diào)度程度服務(wù)中觸發(fā) Cube 的定時(shí)構(gòu)建，如 Linux 的命令
crontab、Apache Airflow 等。
但在新的kylin版本中已經(jīng)支持realtime_olap了，kylin存儲(chǔ)了實(shí)時(shí)的數(shù)據(jù)再加上HBase的數(shù)據(jù)merge后返回就實(shí)現(xiàn)了realtime
最后
這篇文章對(duì)kylin做了個(gè)簡(jiǎn)單的入門，細(xì)節(jié)還是得看官網(wǎng)（有中文，比較好讀，文檔也做得挺好的）。后面細(xì)節(jié)如果有必要我再來(lái)補(bǔ)充就好了（：
參考資料：
https://blog.csdn.net/wangxiaojing123/category_8792666.html
原創(chuàng)電子書原創(chuàng)思維導(dǎo)圖
掃碼或微信搜 Java3y?回復(fù)「888」領(lǐng)取1000+頁(yè)原創(chuàng)電子書和思維導(dǎo)圖。
 |
|
