前言
微信搜【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的步驟是什么？官方已經幫我們解答了：
定義資料集上的一個星形或雪花形模型 在定義的資料表上構建 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做了個簡單的入門，細節還是得看官網（有中文，比較好讀，檔案也做得挺好的），后面細節如果有必要我再來補充就好了（：
參考資料：
https://blog.csdn.net/wangxiaojing123/category_8792666.html
三歪把【大廠面試知識點】、【簡歷模板】、【原創文章】全部整理成電子書，共有1263頁！點擊下方鏈接直接取就好了
GitHub Gitee訪問更快
PDF檔案的內容均為手打，有任何的不懂都可以直接來問我
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/213515.html
標籤：其他
上一篇：Python網路編程 —— socket（套接字）及通信
下一篇：python谷歌序列化傳輸