本篇文章就概念、工作機制、資料備份、優勢與不足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

[email protected]

這表明元資料會被儲存在一個叫作 “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 等近似演算法做去重計數，這主要是出於開銷上的考慮，但業務場景有時要求資料必須是精確的。因此這也是要重點解決的問題

【本文轉載自小米運維】