本篇文章就概念、工作機制、數據備份、優勢與不足4個方面詳細介紹了Apache Kylin。
Apache Kylin 簡介
1. Apache kylin 是一個開源的海量數據分布式預處理引擎。它通過 ANSI-SQL 接口，提供基於 hadoop 的超大數據集（TB-PB 級）的多維分析（OLAP）功能。
2. kylin 可實現超大數據集上的亞秒級（sub-second latency）查詢。
1）確定 hadoop 上一個星型模式的數據集。
2）構建數據立方體 cube。
3）可通過 ODBC, JDBC,RESTful API 等接口在亞秒級的延遲內查詢相
Apache Kylin 核心概念
1. 表（Table ）：表定義在 hive 中，是數據立方體（Data cube）的數據源，在 build cube 之前，必須同步在 kylin 中。
2. 模型（model）: 模型描述了一個星型模式的數據結構，它定義了一個事實表（Fact Table）和多個查找表（Lookup Table）的連接和過濾關系。
3. 立方體（Cube）：它定義了使用的模型、模型中的表的維度（dimension）、度量（measure , 一般指聚合函數，如：sum、count、average 等）、如何對段分區（ segments partition）、合並段（segments auto-merge）等的規則。
4. 立方體段（Cube Segment）：它是立方體構建（build）后的數據載體，一個 segment 映射 hbase 中的一張表，立方體實例構建（build）后，會產生一個新的 segment，一旦某個已經構建的立方體的原始數據發生變化，只需刷新（fresh）變化的時間段所關聯的 segment 即可。
5. 作業（Job）：對立方體實例發出構建（build）請求后，會產生一個作業。該作業記錄了立方體實例 build 時的每一步任務信息。作業的狀態信息反映構建立方體實例的結果信息。如作業執行的狀態信息為 RUNNING 時，表明立方體實例正在被構建；若作業狀態信息為 FINISHED ，表明立方體實例構建成功；若作業狀態信息為 ERROR ，表明立方體實例構建失敗！作業的所有狀態如下：
1）NEW - This denotes one job has been just created.
2）PENDING - This denotes one job is paused by job scheduler and waiting for resources.
3）RUNNING - This denotes one job is running in progress.
4）FINISHED - This denotes one job is successfully finished.
5）ERROR - This denotes one job is aborted with errors.
6）DISCARDED - This denotes one job is cancelled by end users.
Apache Kylin 工作機制
1. Apache kylin 能提供低延遲（sub-second latency）的秘訣就是預計算，即針對一個星型拓撲結構的數據立方體，預計算多個維度組合的度量，然后將結果保存在 hbase 中，對外暴露 JDBC、ODBC、Rest API 的查詢接口，即可實現實時查詢。數據立方體一般由 Hive 中的一個事實表, 多個查找表組成。預計算的過程在 kylin 中就是 Cube 的 build 過程，如下圖：
2. 當前 Apache kylin 構建（build）數據立方體，采用逐層算法（By Layer Cubing）。未來的發布中將采用快速立方體算法（Fast Cubing）。
下面簡單介紹一下逐層算法：
一個完整的數據立方體，由 N-dimension 立方體，N-1 dimension 立方體，N-2 維立方體，0 dimension 立方體這樣的層關系組成，除了 N-dimension 立方體，基於原數據計算，其他層的立方體可基於其父層的立方體計算。所以該算法的核心是 N 次順序的 MapReduce 計算。
在 MapReduce 模型中，key 由維度的組合的構成，value 由度量的組合構成，當一個 Map 讀到一個 key-value 對時，它會計算所有的子立方體（child cuboid），在每個子立方體中，Map 從 key 中移除一個維度，將新 key 和 value 輸出到 reducer 中。直到當所有層計算完畢，才完成數據立方體的計算。過程如下圖：
3. 在數據立方體計算完畢后，有一個任務（Convert Cuboid Data to HFile），其職責是將 reduce 輸出的運算結果（Cuboid Data）轉化成 Hbase 中的存儲載體（HFile），最終將 HFile 加載到 Hbase 表中便於查詢。其中表的 rowkey 由維度組合而成，維度組合對應的度量值構成了 column family，為了查詢減少存儲空間，會對 RowKey 和 column family 的值進行編碼，默認編碼是 Snappy。
4. 整個數據立方體的構建流程如下：
5. Apache kylin 架構如下：
6. 核心組件：
1）數據立方體構建引擎（Cube Build Engine）：當前底層數據計算引擎支持 MapReduce1、MapReduce2、Spark 等。
2）Rest Server：當前 kylin 采用的 rest API、JDBC、ODBC 接口提供 web 服務。
3）查詢引擎（Query Engine）：Rest Server 接收查詢請求后，解析 sql 語句，生成執行計划，然后轉發查詢請求到 Hbase 中，最后將結構返回給 Rest Server。
Apache Kylin 元數據備份
1. 備份元數據
Kylin 將它全部的元數據（包括 cube 描述和實例、項目、倒排索引描述和實例、任務、表和字典）組織成層級文件系統的形式。然而，Kylin 使用 hbase 來存儲元數據，而不是一個普通的文件系統。如果你查看過 Kylin 的配置文件（kylin.properties），你會發現這樣一行：
## The metadata store in hbase
kylin.metadata.url=kylin_metadata@hbase
這表明元數據會被保存在一個叫作 “kylin_metadata” 的 htable 里。你可以在 hbase shell 里 scan 該 htbale 來獲取它。
2. 使用二進制包來備份 Metadata Store 有時你需要將 Kylin 的 Metadata Store 從 hbase 備份到磁盤文件系統。在這種情況下，假設你在部署 Kylin 的 hadoop 命令行（或沙盒）里，你可以到 KYLIN_HOME 並運行：
./bin/metastore.sh backup
來將你的元數據導出到本地目錄，這個目錄在 KYLIN_HOME/metadata_backps 下，它的命名規則使用了當前時間作為參數：KYLIN_HOME/meta_backups/meta_year_month_day_hour_minute_second 。
3. 使用二進制包來恢復 Metatdara Store
萬一你發現你的元數據被搞得一團糟，想要恢復先前的備份：
首先，重置 Metatdara Store（這個會清理 Kylin 在 hbase 的 Metadata Store 的所有信息，請確保先備份）：
./bin/metastore.sh reset
然后上傳備份的元數據到 Kylin 的 Metadata Store：
./bin/metastore.sh restore $KYLIN_HOME/meta_backups/meta_xxxx_xx_xx_xx_xx_xx
4. 在開發環境備份 / 恢復元數據在開發調試 Kylin 時，典型的環境是一台裝有 IDE 的開發機上和一個后台的沙盒，通常你會寫代碼並在開發機上運行測試案例，但每次都需要將二進制包放到沙盒里以檢查元數據是很麻煩的。這時有一個名為 SandboxMetastoreCLI 工具類可以幫助你在開發機本地下載 / 上傳元數據。
5. 從 Metadata Store 清理無用的資源
隨着運行時間增長，類似字典、表快照的資源變得沒有用（cube segment 被丟棄或者合並了），但是它們依舊占用空間，你可以運行命令來找到並清除它們：
首先，運行一個檢查，這是安全的因為它不會改變任何東西：
./bin/metastore.sh clean
將要被刪除的資源會被列出來：
接下來，增加 “–delete true” 參數來清理這些資源；在這之前，你應該確保已經備份 metadata store：
./bin/metastore.sh clean --delete true
Apache Kylin 的優勢與不足
1. 性能非常穩定。因為 Kylin 依賴的所有服務，比如 Hive、HBase 都是非常成熟的，Kylin 本身的邏輯並不復雜，所以穩定性有一個很好的保證。目前在生產環境中，穩定性可以保證在 99.99% 以上。同時查詢時延也比較理想。
2. 特別重要的一點，就是數據的精確性要求。其實現在能做到的只有 Kylin，在這一點上也沒有什么太多其他的選擇。
3. 從易用性上來講，Kylin 也有非常多的特點。首先是外圍的服務，不管是 Hive 還是 HBase，只要大家用 Hadoop 系統的話基本都有了，不需要額外工作。在部署運維和使用成本上來講，都是比較低的。Kylin 有一個通用的 Web Server 開放出來，所有用戶都可以去測試和定義，只有上線的時候需要管理員再 review 一下，這樣體驗就會好很多。
4. 查詢靈活性。經常有業務方問到，如果 Cube 沒定義的話怎么辦？現在當然查詢只能失敗。這個說明有的查詢模式不是那么固定的，可能突然要查一個數，但以后都不會再查了。實際上在需要預定義的 OLAP 引擎上，這種需求普遍來講支持都不是太好。 從維度的角度來看，一般維度的個數在 5-20 個之間，相對來說還是比較適合用 Kylin 的。另一個特點是一般都會有一個日期維度，有可能是當天，也有可能是一個星期，一個月，或者任意一個時間段。另外也會有較多的層次維度，比如組織架構從最上面的大區一直到下面的蜂窩，就是一個典型的層次維度。 從指標的角度來講，一般情況下指標個數在 50 個以內，相對來說 Kylin 在指標上的限制並沒有那么嚴格，都能滿足需求。其中有比較多的表達式指標，在 Kylin 里面聚合函數的參數只能是單獨的一列，像 sum(if…) 這種就不能支持，因此需要一些特別的解決方法。另外一個非常重要的問題是數據的精確性，目前在 OLAP 領域，各個系統都是用 hyperloglog 等近似算法做去重計數，這主要是出於開銷上的考慮，但業務場景有時要求數據必須是精確的。因此這也是要重點解決的問題
【本文轉載自小米運維】