Kylin 賦能物聯網大資料分析
工業網際網路和 5G 時代正逐步到來，萬物智慧網聯、智慧互聯已成為一種趨勢。目前物聯網應用在很多場景下，如智慧製造、智慧城市、智慧農業等。本文以智慧城市為背景，介紹西安中服軟體有限公司是如何利用大資料分析神獸 Apache Kylin，讓物聯網的感測器資訊，通過雲化的大資料物聯網雲平臺，對感知的資料進行分析處理，進而滿足智慧城市的建設需求。
業務背景
作為智慧城市的重要組成部分，智慧樓宇也以驚人的速度發展著，挖掘和處理樓宇資料，並以此來精準控制並降低樓宇能耗成為一個重要問題。以 IoT 裝置完成能源網路搭建，並進行資料採集，然後推送到流處理工具，樓宇管理者可以通過常規的資料分析，根據不同的用能區域、能耗型別，對建築能耗進行分時段計量和分項計量，分別計算指定時間範圍內電、水、氣等能源的使用量，並且對未來能耗使用進行一定程度的預測。管理者可通過梳理不同能源的使用情況，實現對能源的高效管理。
做一個單點的能源管理系統並不存在技術難點，但是在裝置上雲後，要將其做成一個 Saas 產品，我們就需要考慮很多問題，如效能問題等。傳統的做法，不同的租戶將物聯網裝置在雲端繫結後，系統自動為他們生成對應的資料庫表，以此來做到資源隔離。這些物聯裝置的事實資料和維度資料都存放於 Oracle 中，但是使用關係型資料庫存在一些問題：
- 無法支撐大資料量，當資料量達到一定程度時，需要進行倒庫。
- 為了解決查詢的效能問題，往往需要建立多張中間表，去存放按屬性查詢過的歷史資料結果。
- 使用者在修改裝置的配置表時，涉及到多表聯動修改。這種處理方法不僅可靠性低，並且對開發人員和資料分析人員來說都是極為複雜的。
因此，需要一個能支援快速查詢且易維護的資料儲存及分析引擎，來解決關係型資料庫存在的這些瓶頸。
技術選型
我們團隊在引入 Kylin 之前，曾經嘗試過很多種解決方案。
第一種方法是將所有的資料都載入到 Hive 中，這種方式雖然能夠支撐較大資料量，但查詢時需要等待很長時間才能獲取到結果，查詢延時無法滿足即時性要求。
我們嘗試過使用 Druid。Druid 已經是目前市面上較為成熟的實時 OLAP 引擎，但是它只支援單表查詢，而我們的能耗分析通常需要多表聯查。此外，Druid 的原生查詢語句是一種自定義的 json 格式，並非我們所熟悉的 SQL，這對於非專業人員來說上手存在一定的難度。
後來，我們使用 Kylin 進行能耗分析測試，在這過程中我們發現它有以下幾大特點：百億資料集支援、SQL 支援、準實時、亞秒級響應，對外提供 REST API 和JDBC/ODBC 兩種訪問方式。Kylin 架構如下圖所示。這些特點能夠滿足智慧樓宇能效查詢的大部分場景，因此我們最終決定選用 Apache Kylin 作為中服樓宇能耗管理平臺的儲存引擎和查詢引擎。
樓宇能耗 OLAP 架構
中服的樓宇能耗 OLAP 架構如下圖所示，考慮到裝置感測器採集到的資料並非每次都是完整的，因此需要流處理工具提前做適配、計算、校驗以及轉換成 json 格式，最終輸入到 Kafka 指定的 topic 中。該架構中使用的 Kylin 版本為 2.6.2，此版本相對穩定，且修改了 Kafka 對接 Kylin 會出現 8 個小時時差的錯誤，保證了在幾個衍生時間維度上的準確性。
Kylin的事實表是來自 Kafka topic 裡的裝置感測器的json 資料（不同裝置型別的資料通過流處理工具進入到不同的 topic 中），維度表是存放於 Hive 中使用者定義的配置表，例如裝置表、裝置區域表等，事實表與維度表連線構成星型模型。資料分析工程師根據可能要查詢到的場景來分析這些表中的維度和度量，以此來配置相應水、電、氣的 Model 和 Cube，再依託於 MR 進行 Cube 的構建。
根據業務場景，整個流資料是源源不斷的，需要每小時 build 一次Cube，待 Cube 構建完成，對外提供兩種方式查詢能耗資料，一種採用 JDBC/REST API 的方式為前端能耗管理介面提供資料，另一種是採用 JDBC 的方式無縫對接 BI 工具，用以能耗的 Display 和 Dashboard 展示。
使用 Kylin 實現能源管理 SaaS 平臺
我們的初衷是做一個能耗管理雲平臺，通過對實際需求進行詳細的分析，在使用者將物聯網裝置上雲後，系統能夠自動協助該裝置繫結至特定型別的 Cube 中，比如能耗管理場景下某個區域的電錶會自動繫結到 IoT_Electric_Cube中。換句話說，使用者只關心將自己的裝置連上，再到視覺化面板檢視相關能耗使用情況，不需要知道背後的資料分析引擎具體是怎麼操作的。因此，我們需要解決兩個問題：Cube 的自動化建立以及多租戶的問題。
1. Kylin 各模組的自動化建立
由於使用 Kylin 有一定的門檻，需要進行一些專業的分析和操作。而使用我們雲平臺的使用者更多的只希望在完成裝置繫結之後，就能查詢到相關能耗資訊，此外，從一定程度上來說，大部分使用者並未掌握 Kylin 的使用方法，因此如果讓使用者根據繫結的裝置線上去配置Model、Cube，將會成為一個很大的難題。為了解決該問題，我們進行了下圖的配置。
我們針對能效分析場景中的水、電、氣、油等能耗型別，提前建立好一個預置的Cube，後期使用者在繫結裝置後，系統會根據預置的 Cube 和新的裝置維度，分析出常量維度、特殊維度以及度量，生成新的Cube 描述資訊，用以自動化建立 Model 以及 Cube。另外，針對於使用者可能更改裝置配置表的內容，我們對其提供了一個 API，可跟隨配置表的內容動態更改 Kylin 維度表中的資料。
2. 平臺多租戶的資源隔離
針對於平臺的多租戶問題，由於 Kylin 目前對多租戶的支援較為簡單，只是簡單將使用者分成了幾個角色，不同角色的使用者對元資料及 Cube 有不同的操作許可權，而我們平臺的租戶只需在查詢時保證相互之間資料的獨立性即可，因此我們只做資源資料的上層隔離，對下面的 HBase 儲存來說還是統一的。我們的做法就是在 Project 層做處理，一個租戶建立一個 Project，再根據 Project 對應繫結不同 DataSource、Model 以及 Cube，再由整個平臺的管理者對所有 Project進行管理。但如果租戶量達到一定量時，此種方法並不可取，目前我們正積極針對多租戶的問題做相應的優化。
此外，多租戶機制下會產生大量的垃圾資料，包括Kylin 在構建 Cube 過程中會在 HDFS 上生成中間資料，以及在執行 drop/purge/merge 等操作時，HBASE 的表可能不會及時地被 Kylin 清理，一直保留在 HBASE 中，久而久之對 HBASE 的運維查詢都必將造成一定的壓力。因此，我們做了一些調整，每隔一段時間執行一些清理工作，以保證各叢集的正常工作。
Cube 維度優化
隨著維度數目的增加，Cuboid 的數量成指數級增長。針對能效分析場景下水、電、氣各個 Cube，以電為例，電錶採集點有 A 相電流、B 相電流、C 相電流、AB 相電流等近 40 個維度，以及正向有功電度和、正向無功電度和等4個度量，這麼龐大的維度指標如果不做維度優化，將會有 2^40 個 Cuboid，Kylin 會提示無法建立該 Cube。
為了緩解 Cube 的構建壓力，Kylin 提供了 Cube 的高階設定。這些高階設定包括聚合組（Aggregation Group）、聯合維度（Joint Dimension）、層級維度（Hierarchy Dimension）和強制維度（Mandatory Dimension）等。通過對電錶裝置的維度進行分析，最終確定了 2 個強制維度，電壓、電流等多項常量維度組合成一組聯合維度，year_start、month_start 等時間衍生維度組合成一組聯合維度，正向有功電度等特殊維度不做處理。優化後的維度配置如下圖所示。
同時，我們也嘗試過將常量維度和特殊維度拆分開，獨立構建不同的 Cube 並對外提供查詢，但考慮到多租戶場景下要維護多個 Cube，因此放棄了這種做法。
對維度進行合理配置，可有效對 Cuboid 進行剪枝優化，減少不必要的資源浪費，篩選出真正需要的 Cuboid，有效降低構建時間，提高叢集資源的利用效率。我們根據 Kylin 的高階配置對維度進行配置後，雖然犧牲了某些場景的查詢效能，但是極大的優化了聚合的效能。以下是優化之後的效能指標（一個小時 Build）：
運維監控
由於多租戶情況下，存在並行的 Build Cube 操作，那麼就可能存在 Cube 構建失敗的情況，從而導致資料分析結果不準確。為了避免這種情況，我們做了兩部分工作：在 Job 構建成功時會在系統日誌中打印出相關資訊；Job 構建失敗時會及時給運維人員傳送簡訊通知，哪個租戶的哪個 Cube 構建時出現錯誤，以便運維人員能夠快速的定位構建失敗的 Job Name 並解決相關問題。
總結
針對 SaaS 平臺下物聯網的能耗管理問題，使用 Kylin 作為 OLAP 引擎，有諸多優勢。
- 對開發人員來說，在協同開發時，Kylin 工程師只需定義好各模組的自動化建立 API，如建立 Project、繫結 Kafka DataSource、同步 Hive 維度表、建立 Model、建立 Cube等，其他部門按一定規則呼叫就可完成 SaaS 形式的系統建立。此外，開發人員不再需要擔心庫滿而進行倒庫操作。
- 資料分析師使用 Davinci 建立視覺化面板時，以 Kylin 作為分析引擎，實現海量資料分析結果的實時展示。
- 對於使用者而言，通過前端檢視相關資料時，對比傳統關係型資料庫查詢方式，Kylin 能夠以更低的延時呈現出資料分析的結果。
這裡僅僅展示的是 Kylin 賦能物聯網的一個應用場景，我們後期將繼續探索更多的應用可能。