本文已收錄於Github倉庫：《大數據成神之路》
地址：https://github.com/wangzhiwubigdata/God-Of-BigData
研發背景
今天隨着移動互聯網、物聯網、大數據、AI等技術的快速發展，數據已成爲所有這些技術背後最重要，也是最具價值的“資產”，同時數據也是每一個商業決策的基石，越來越多的企業選擇數字化轉型，但數據驅動增長然充滿挑戰，企業數據孤島嚴重、數據一致性難以保證、數據資產沉澱數據分散難以共用、數據分析項目上線經歷數月，報表查詢響應慢難以應對瞬息萬變的市場環境，成本問題在數據量呈指數增長的前提下難以控制，因此在大數據的背景下，如何從海量的超大規模數據中快速獲取有價值的信息，已經成爲新時代的挑戰。
Hadoop誕生以來，大數據的存儲和批處理問題均得到了妥善解決，而如何高速地分析數據也就成爲了下一個挑戰。於是各式各樣的“SQL on Hadoop”技術應運而生，其中以Hive爲代表，Impala、Presto、Phoenix、Drill、SparkSQL、FlinkSQL等緊隨其後。它們的主要技術是“大規模並行處理”（Massive Parallel Processing，MPP）和“列式存儲”（Columnar Storage）。大規模並行處理可以調動多臺機器一起進行並行計算，用線性增加的資源來換取計算時間的線性下降。列式存儲則將記錄按列存放，這樣做不僅可以在訪問時只讀取需要的列，還可以利用存儲設備擅長連續讀取的特點，大大提高讀取的速率。這兩項關鍵技術使得Hadoop上的SQL查詢速度從小時提高到了分鐘級。
然而分鐘級別的查詢響應仍然離交互式分析的現實需求還很遠，市面上主流的開源OLAP引擎目前還沒有一個系統能夠滿足各種場景的查詢需求。其本質原因是，沒有一個系統能同時在數據量、性能、和靈活性三個方面做到完美，每個系統在設計時都需要在這三者間做出取捨。
大數據查詢要的一般是統計結果，是多條記錄經過聚合函數計算後的統計值。原始的記錄則不是必需的，或者訪問頻率和概率都極低。
聚合是按維度進行的，由於業務範圍和分析需求是有限的，有意義的維度聚合組合也是相對有限的，一般不會隨着數據的膨脹而增長。
基於以上兩點，我們可以得到一個新的思路——“預計算”。應儘量多地預先計算聚合結果，在查詢時刻應儘量使用預算的結果得出查詢結果，從而避免直接掃描可能無限增長的原始記錄，預計算系統是在入庫時對數據進行預聚合，進一步犧牲靈活性換取性能，以實現對超大數據集的秒級響應。
Apache Kylin是一個開源的、分佈式的分析型數據倉庫，提供Hadoop/Spark/Flink 之上的 SQL 查詢接口及多維分析（OLAP）能力以支持超大規模數據，通過預計算它能在亞秒內查詢巨大的表，其中的關鍵就是要打破查詢時間隨着數據量成線性增長的這個規律。
BI（Business Intelligence），即商務智能，指用現代數據倉庫技術、在線分析技術、數據挖掘和數據展現技術進行數據分析以實現商業價值，隨着業務數據的規模增長，傳統數據倉庫不堪重負，數據的存儲和批量處理成了瓶頸，查詢分析速度無法滿足日益增長的數據需求，傳統關係型多維分析ROLAP引擎遇到極大挑，越來越多的企業引入大數據平臺架構。
BI大數據分析平臺致力於幫助用戶快速在業務場景中應用大數據，助力業務發展和產業升級，讓數據更高效地驅動生產力。因此必須集成整合Kylin實現賦能基於大數據Hadoop 生態 MOLAP(Kylin)及 HOLAP （多引擎）的查詢分析，實現支持識別、管理和優化最有價值數據、提升整合底層複雜數據源的能力，通過數據服務將複雜的數據映射爲業務語言，統一業務口徑。採用預計算技術可打破查詢時間隨數據量線性增長的現狀，提供穩定高效的查詢性能。
研發目標
BI平臺無縫集成Apache Kylin，託管Kylin用戶、權限管理統一的安全認證，統一界面樣式、操作流程，並對一些功能進行擴展改造以適配BI系統，整合SparkSQL、FlinkSQL、Presto等多種引擎結合起來實現智能路由，充分發揮每種引擎的長處優勢，賦能用戶極速數據分析體驗，形成統一、一站式的大數據OLAP解決方案。
數據立方體構建引擎（Cube Build Engine）：當前底層數據計算引擎支持、MapReduce、Spark、Flink等。
Rest Server：當前kylin採用的REST API、JDBC、ODBC接口提供web服務。
查詢引擎（Query Engine）：Rest Server接收查詢請求後，解析sql語句，生成執行計劃，然後轉發查詢請求到Hbase中，最後將結果返回給 Rest Server。
存儲引擎：Kylin默認使用分佈式、面向列的開源數據庫Hbase作爲存儲庫引擎。
設計架構
Mondrian爲一個OLAP引擎，而且是一個ROLAP引擎，實現了以下規範：
MDX(多維查詢語言，相當於數據庫的SQL)
XMLA(通過SOAP使用OLAP)
olap4j(Java API規範，相當於JDBC關係數據庫)
數據應用，包括智能報告、支持生成SQL或多維分析查詢MDX語句組件、托拉拽自助式分析可視化組件等
Mondrian Schema，數據多維分析模型
Mondrian引擎，根據Schema生成標準SQL
目標數據源，包括關係型數據源、非關係型數據源、企業數據倉庫
功能架構設計
存儲引擎，Kylin默認使用分佈式、面向列的開源數據庫Hbase作爲存儲庫引擎，基於Apache Kylin插件架構實現數據庫存儲接入。
Presto，分佈式SQL查詢引擎，適用於交互式分析查詢，數據量支持GB到PB字節。
用戶/權限
Kylin的Web模塊使用Spring框架構建，在安全實現上選擇了Spring Security。Spring Security是Spring項目組中用來提供安全認證服務的框架，它廣泛支持各種身份驗證模式，這些驗證模型大多由第三方提供， Spring Security也提供了自己的一套驗證功能。Kylin提供了三種用戶驗證方式“testing”、“ldap”和“saml”，依次爲：自定義驗證、LDAP驗證和單點登錄驗證。
BI平臺已實現一套成熟且完善的用戶權限控制體系，爲了便於系統的安全管理需要將Kylin用戶權限管理和BI平臺用戶管理打通，可以利用現成的機制對Kylin的訪問、資源的訪問控制、修改做保護性的限制，使得大數據下的交互式報表分析成爲可能。
數據模型
BI數據主題基於數據源元數據信息創建數據模型，支持簡單可拖拉拽、靈活快速的方式實現可視化數據建模，需打通BI數據建模與Kylin數據建模功能，將BI數據模型適配至Kylin數據模型，支持事實表、維度、度量定義。
每次Cube構建都會從數據源中批量讀取數據，而對於大多數業務場景來說，數據源中的數據處於不斷增長的狀態，爲了支持Cube中的數據能夠不斷地得到更新，且無需重複地爲已經處理過的歷史數據構建Cube，Cube支持增量構建，每個Cube都關聯着一個數據模型Model，增量構建Cube需要指定分割時間列。
對於維度表可選擇配置是否將其以快照(Snapshot)形式存儲到內存中以供查詢。當維表小於300M時推薦啓用，可以簡化Cube計算提高效率。
CUBE配置
頁面，佈局、樣式統一、中文顯示
用戶權限，統一安全認證
Cube管理查詢
構建引擎，計算引擎默認選擇Flink作爲構建引擎
Cube運行監控
Apache Kylin通過日誌和報警對任務進行監控、瞭解整體的運行情況，Kylin支持顯示每個構建任務的進度條和構建狀態，並可以展開明細，列出任務的每一步詳細信息，數據模型下總Cube數，及空間佔用。
狀態
禁用(Disabled) 只有定義，沒有構建數據
錯誤(ERROR) 報錯並停止後續執行
準備(Ready) 構建完成可以提供查詢服務。
執行控制
恢復(Resume) 在上次錯誤位置恢復執行
放棄(Discard) 如要修改Cube或重新開始構建，可以放棄此次構建。
構建(Build) 全量構建，增量構建採用
刷新(Refresh) 對相應分區(Segment)歷史數據進行重建
合併(Merge) 合分區(Segment)，提高查詢性能
數據查詢
Cube構建好以後，狀態變爲“READY”，就可以進行查詢，查詢語言爲標準SQL SELECT語句。
只有當查詢的模式跟Cube定義相匹配的時候，Kylin才能夠使用Cube的數據來完成查詢，“Group by”的列和“Where”條件裏的列，必須是維度中定義的列，而SQL中的度量應跟Cube中定的義的度量一致。
Kylin提供了靈活的前端連接方式，包括Rest API、JDBC和ODBC。用戶可以根據需要查詢訪問。
存儲引擎
基於Apache Kylin較強可伸縮性的插件架構實現數據庫存儲接入。
Kylin旨在減少Hadoop在10億及百億規模以上數據級別的情況下的查詢延遲，目前底層數據存儲基於HBase，具有較強的可伸縮性。插件架構旨在使 Kylin 在計算框架，數據源和cube 存儲方面具有可擴展性。從 v1 開始，Kylin 與作爲計算框架的 Hadoop MapReduce，作爲數據源的 Hive，作爲存儲的 HBase緊密結合。
本文分享自微信公衆號 - 大數據技術與架構（import_bigdata）。
如有侵權，請聯繫 [email protected] 刪除。
本文參與“OSC源創計劃”，歡迎正在閱讀的你也加入，一起分享。
