kylin介紹
kylin是國人主導並貢獻到Apache基金會的開源項目，所以我們會有中文文檔學習：
從官方我們可以看到對kylin的介紹：Apache Kylin™是一個開源的、分布式的分析型數據倉庫，提供Hadoop/Spark 之上的SQL查詢接口及多維分析（OLAP）能力以支持超大規模數據，最初由 eBay 開發並貢獻至開源社區，它能在亞秒內查詢巨大的表。
OLTP和OLAP
- OLTP：On-Line Transaction Processing（聯機事務處理）
- OLAP：On-Line Analytical Processing（聯機分析處理）
他倆的區別一個是「事務」，一個是「分析」
從應用層面看，我們可以簡單地認為：
OLTP主要用於業務系統，對事務的要求比較高，例如下單/交易（銀行轉賬等業務）。
OLAP主要用於數據倉庫系統，支持復雜的分析操作，側重決策支持，並且提供直觀易懂的查詢結果。
我再畫張思維導圖圖來給大家看一下，基本就懂了：
支持超大規模數據的多維分析（OLAP）能力，讓人很容易和Hive聯想起來（Hive底層是HDFS：支持超大規模的數據）。
那既然說到Hive了，你會發現kylin前半段話，Hive好像幾乎都可以支持，但除了最后一句「它能在亞秒內查詢巨大的表」。
每次跑Hive可能都得跑幾分鍾，甚至幾個小時，我們從業務上就希望用來分析的數據可以跑得更快，支持這種需求的kylin就火起來了。
除了kylin就沒其他選擇了嗎？那顯然不是的。
有人會說：你用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上。
使用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（['mændə.tɔri]強制維度）又是用得比較多的。
比如說，本來我有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做了個簡單的入門，細節還得看官網，有中文：
http://kylin.apache.org/cn/docs/gettingstarted/kylin-quickstart.html