小米大數據：藉助Apache Kylin打造高效、易用的一站式OLAP解決方案

做者 | 小米大數據

現在的小米不只是一家手機公司，更是一家大數據與人工智能公司。隨着小米公司各項業務的快速發展，數據中的商業價值也愈發突顯。而與此同時，各業務團隊在數據查詢、分析等方面的壓力一樣正在劇增。所以，爲幫助公司各業務線解決這些數據方面的挑戰，小米大數據團隊不斷地嘗試經過不一樣的技術手段打造新的解決方案。

小米大數據，是一支以「融匯公司全景數據，經過數據驅動、AI 賦能公司核心業務」爲使命的研發技術團隊，目前主要負責設計、完善公司級數據倉庫解決方案，提供完備及全鏈條的數據治理一站式平臺，連通各業務線數據，開發通用的畫像平臺與分析引擎。小米大數據團隊的目標，在於不斷提高數據產品與服務品質，並依託數據科學、機器學習等技術賦能核心業務。

1 業務團隊亟需統1、低門檻的 OLAP 解決方案

2012 年小米大數據團隊成立以後，數據平臺、用戶畫像等通用性的技術體系相繼在公司內部創建了起來。然而因爲業務需求的快速變化，新的挑戰也不斷隨之出現，好比在多維數據分析及 OLAP 需求中所遇到的諸多困難，就是其中的典型。

OLAP 的價值可體如今實現精細化運營、提高數據處理效率、改善數據可視化效果等多個方面。但小米公司內部的業務種類異常繁雜，各業務團隊爲了具有多維數據分析能力而各自創建了獨立的 OLAP 分析系統。這些 OLAP 引擎大可能是採用指標數據先進入 MySQL，再在前端進行展現的方法，而這樣就將面臨如下問題：

1. 基於 MySQL 的架構，在大數據上的查詢效率低下；
2. 業務間 OLAP 引擎不統一，數據管道冗長，數據複用率極低，開發工做週期變長，維護成本增長；
3. 缺少統一的維表和事實表，同主題下數據統計口徑不一致；
4. 新增業務須要投入較大的成本才能得到基礎的 OLAP 能力。

通過充分的內部溝通以後，發現各業務團隊的基礎需求主要包括如下四點：

1. 報表能力；
2. 提供 OLAP 查詢接口，支持各類即席分析； 儘量下降使用門檻（ETL 以及查詢的門檻）；
3. 初級階段只需支持離線分析需求。

舉例來講，其中最多見的一類需求是——開發資源至關有限的新業務，如何能在 1 天時間內開發出關鍵指標的多維分析看板？在這種狀況下又該如何系統性地設計、搭建技術架構與解決方案？

2 以小米大數據平臺核心——數據金字塔體系爲基礎

爲了進一步知足各業務線的實際需求，小米大數據認爲有必要基於自行設計的數據治理體系——「數據金字塔」，來開發一套端到端的 OLAP 解決方案。

數據金字塔體系的結構

數據金字塔，是小米大數據平臺技術架構中的核心部分，其目標是承載、管理、促進小米公司內的數據生態環境。該體系可將數據由下至上分佈在源數據層、中間層、彙總層、應用層，共四個層面中：

• 源數據層：對來源於業務線的數據進行採集、存放等最粗粒度的處理工做。這些業務數據進入源數據層以前，須要遵循科學的打點規範並準備好數據同步策略及工具。


• 中間層：對源數據層的數據進行 ETL，合乎規範的數據表將被存放在該層中。數據表包含事實表和維表，事實表用於記錄業務過程的事實數據，而維表則記錄維度關係。事實表和維表都須要遵循嚴格的命名與操做規範。

• 彙總層：公司級或業務級的主題數據都歸屬於該層。典型的主題表每每會對跨業務線的多張中間表進行彙總。例如小米用戶畫像，就是來源於公司內部多項業務數據的挖掘彙總而成。主題表是業務數據的高度歸納，基本上能知足業務團隊 80% 以上的數據需求。


• 應用層：結合中間層與彙總層中的數據，對其進行優化，並開發定製化的數據能力與工具，或提供業務級甚至公司級的數據服務。 公司各業務線的在線服務日誌以及其餘數據源的數據（MySQL 等等），可經過數據流服務下沉到 HDFS、Kudu、HBase 等引擎中，通過數據金字塔建模後再提供給業務團隊使用。

源數據層中的數據能夠類比爲數據湖（Data Lake），包含多種原始數據。通過源數據層的加工，數據會向上進入中間層。在中間層中，將清洗髒數據，統一數據統計口徑，再經歷一系列的 Join 操做和其餘 ETL 過程後，會生成彙總層數據。彙總層的數據一般會更面向主題，且具備必定的通用性，例如訂單、畫像等等。最後在應用層中，針對業務團隊的分析需求，可直接基於彙總層與中間層數據的集合，構建個性化的數據集市。

梳理數據流程，簡化數據模型

所以，爲了節約重複開發成本，基於上述數據治理體系，小米大數據開發了一系列通過優化的解決方案，其中就包括本文所涉及的核心內容——UnionSQL。

3 利用 Apache Kylin 的特性構建定製化 OLAP 解決方案

OLAP 常見的應用場景可分爲數據看板、即席查詢這兩種，每種場景對於查詢效率與數據新鮮度都有着不一樣的要求。而在最初階段下，小米大數據的主要目標是集中精力解決對於離線數據 OLAP 能力的問題。

針對 OLAP 解決方案的技術選型問題，小米大數據鑑於以前在 Elasticsearch 上所積累的經驗，對於數據量不太大的業務，首先嚐試了基於 Elasticsearch+Logstash+Kibana 的解決方案。儘管 Elasticsearch 在查詢效率方面表現不錯，也對地理位置信息類數據進行了特殊優化，可是其自己更適用於原始數據的檢索，而在數據攝入、查詢語法等方面的表現也並非很理想。在此以後，Apache Kylin、Druid、ClickHouse 等方案也成爲了候選項，小米大數據在結合了實際業務需求與環境後，決定從如下方面進行考量：

• 可知足大多數需求，支持常見的算子，以及數據的攝入、查詢速度足夠快；


• 保證良好的 SLA；

• 使用門檻相對較低。

Apache Kylin 架構

做爲候選方案之一的 Apache Kylin，基本支持常見的 SQL 語法，並能知足一般狀況下的需求。數據攝入主要依賴 MapReduce、Spark 任務將 Hive 中的數據轉換爲對應 Cube 的 Segment（HFile），效率方面尚可，而在查詢速度方面也能提供秒級支持。對於一些如 distinct 等複雜場景而言，Apache Kylin 也提供了高精度但低效，以及高效但存在可容忍偏差，這兩種計算方式，以適用不一樣的業務場景需求。

在 SLA 方面，鑑於以前小米相關團隊在 Hadoop 技術棧上積累的經驗，所以一樣也能針對 Apache Kylin 而提供良好的 SLA 保障。此外，Apache Kylin 自己的設計與傳統數據倉庫相一致，學習構建 Cube 的門檻不高，而數據的查詢基於 SQL 語法，同時還提供了 JDBC 接口和 Rest API，便於現有系統對接。同時 Apache Kylin 也能較好地與 Apache Superset 等開源可視化方案進行整合，易於進行數據可視化處理。目前小米公司的部分業務已實如今日誌進入數據流以後，基於現有解決方案生成數據看板等可視化的功能。

因而可知，Apache Kylin 知足了上述考量要求，並最終做爲 OLAP 引擎方案而進入了小米大數據平臺的技術架構，而這套完整的 OLAP 解決方案則被命名爲 UnionSQL。

4 愈來愈多的內部業務開始受益於 UnionSQL

在引入 Apache Kylin 做爲 OLAP 引擎以後，就可將須要進行分析的數據抽象成星型模型，其中的受益之處包括：

1. 只需維護最細粒度的事實分析數據，進行簡單的 ETL 處理；
2. 數據流變得更清晰；
3. 維護成本進一步下降。

截止到 2018 年第三季度，小米公司內部已有超過 50 個業務接入 UnionSQL 解決方案, 其中涉及手機、MIUI、小愛同窗、新零售等相關核心業務，Cube 存儲空間已超過 50TB，且 95% 的查詢都能在 0.35 秒內返回。UnionSQL 的架構以下圖所示：

SQL 計劃器會將用戶的查詢進行解析與重排，而 SQL 轉發器則會把改寫後的結果分發給不一樣的引擎。例如，當最終用戶想知道某個區域的實時運營活動點擊率的時候，會基於 Lambda 架構，將歷史數據的查詢分發給 Apache Kylin，而實時數據的查詢則分發給 Elasticsearch。

衆所周知，點擊率 = 點擊 / 曝光，但若是直接在不一樣引擎中計算點擊率，並將獲得的結果相加，就會獲得一個錯誤的點擊率。所以，UnionSQL 引擎則會將原始 SQL 進行重寫，再分別計算點擊量和曝光量，最後在 UnionSQL 引擎中從新計算點擊率，並將正確的結果返回給最終用戶。

UnionSQL 的核心理念是「快」——上手快、數據更新快、查詢響應快，同時還能越用越快。

UnionSQL 解決方案的諸多優點

在上手方面，UnionSQL 基於 SQL 語法向最終用戶提供服務，極大地下降了使用門檻，同時還內置支持 Lambda 架構以及多機房訪問。最終用戶無需瞭解多種查詢引擎，只需經過 SQL 語句描述需求，UnionSQL 就能基於元數據將 SQL 改寫後分發給正確的引擎，並以統一的數據格式返回給最終用戶。

在數據更新方面，UnionSQL 基於公司內部的數據流服務與 Lambda 架構，成功將數據延遲控制在了 2 分鐘時間之內。

在查詢響應方面，UnionSQL 基於 Apache Kylin 等優秀的 OLAP 引擎，以及內置的 Cache/ 自動擴容能力，使 P95 查詢低於 320 毫秒。

此外，UnionSQL 還能基於慢查詢智能優化引擎，可發現問題並提供慢查詢優化建議，進行不一樣引擎的切換，或 Apache Kylin 中 Cube 的構建優化等，實現查詢得越多速度就越快。

Lambda on OLAP 架構

5 三類主要的 OLAP 落地場景

通常狀況下，業務團隊的 OLAP 需求可大致分爲三類——用戶畫像、數據運營、數據分析。

在用戶畫像方面，小米擁有公司級的通用畫像表，可爲各業務提供人羣畫像支持。以小米之家爲例, 該業務的數據進入數據金字塔的彙總層後，能夠和通用畫像表相結合, 對用戶人羣進行多維分析。

用戶畫像分析的效果

在數據運營方面，小米內部的每一項業務均可能會產生海量的數據，那麼如何才能讓運營人員便捷、 快速地查看整個業務的各項關鍵性指標以及歷史趨勢，正是業務團隊的剛性需求。以小米音樂爲例，運營人員須要天天看到用戶活躍狀況，以及熱門歌曲、熱門歌單、播放時長等相關指標。而經過 Apache Kylin 與 Apache Superset 的配合，就能夠實現這些指標的快速可視化並展現給運營人員。

在數據分析方面，以小愛同窗的相關業務爲例，在一些運營活動中，會主動向用戶推送具備引導性的內容。在 2018 年俄羅斯世界盃進行期間，小愛同窗就加入了相似的運營幹預。例如，用戶向小愛同窗詢問與天氣相關的問題，小愛同窗在完成回答以後還將加上一個「小提示」，如「世界盃來了，足球知識早知道，堅定不作僞球迷，快對我說：什麼是越位」等等。小米大數據團隊內部將其稱之爲「素材」，而要想評估素材的效果，就須要經過數據分析來了解用戶後續是否進行了小愛同窗所提示的操做。

6 小米針對 Apache Kylin 進行了諸多定製化擴展

在小米公司內部，針對 Apache Kylin 的開發主要基於社區所發佈的版本，根據公司內部業務的具體需求，再進行定製化的改進或擴展，以便更好地服務各業務團隊。

在當前階段下，對 Apache Kylin 的優化工做主要集中在監控與部署、同外部系統的集成與整合、以及服務限制，這三個方面上。

1、監控與部署

在監控方面：

1. 支持 Apache Kylin 將內部 Metrics 推送到 Faclon 監控系統上；
2. 實現做業構建成功時 HTTP 回調以及構建失敗時發送短信通知；
3. 支持週期性的 Query 探測，可將 Kylin 集羣的實時可用性推送到 Falcon 監控系統上，便於及時報警。

在部署方面：

• 修改了 Apache Kylin 的打包方式，去掉了默認的 Spark、Hadoop 依賴，添加了小米公司內部維護的 Hadoop、Spark、HBase、Hive 版本，並打包成了一個完整的發佈包；


• 與公司內部的自動化部署平臺進行整合，將發佈包和配置進行分離，支持自動化包與配置升級，加快開發與迭代的速度。

2、同外部系統的集成與整合在 HBase 方面：

1. 支持 HBase 0.98，可設置 HBase 命名空間，經過 HBase Namespace Quota，避免 Apache Kylin 在共用 HBase 集羣時建立太多的表；
2. 支持 HBase 使用獨立的 HDFS 集羣。

在用戶管理方面：

因爲安全性問題，公司內部沒法使用 LDAP 服務，所以修改了 Apache Kylin 的用戶管理功能，將其用戶密碼加密存儲在了 Kylin 的元數據中，並增長了新的用戶管理功能，以便管理員直接添加用戶或修改相關權限。

3、服務限制

爲避免最終用戶誤用，保證服務質量，而在 Apache Kylin 社區版本的基礎上添加了一些必要限制：

1. 限制 Query 中 IN 語句裏值的個數，避免過大 in values 從而致使請求變慢；
2. 限制 Query 的最大長度以及一個 Query 執行涉及的 Segment 個數；
3. 限制 Segment 構建數據的膨脹率，使膨脹率超過限制的構建直接失敗，經過線下的方式再單獨協助最終用戶優化及調整 Cube；
4. 在線上環境中增長了對 Cube 的最大數據量限制， 避免 HDFS 過量使用；
5. 添加了構建過程當中如 distinct 等聚合函數使用 buffer 大小的限制，避免在 HBase 上寫入一個 Key-Value 存儲過大的數據。

此外，對於一些具備通用性質的修改，小米內部相關團隊也將會逐步反饋給社區。

7 將來將嘗試進一步解決多租戶支持問題

儘管 Apache Kylin 項目已發展地較爲成熟、穩定，但其在小米公司內部環境下的推廣與使用過程當中，仍然還有一些問題須要進一步解決，好比針對多租戶的支持問題。

目前 Apache Kylin 對多租戶並不友好，僅支持不一樣構建做業運行在不一樣的 Hadoop 隊列上。 在開啓安全的 Hadoop、Hive、HBase 集羣上，若是最終用戶使用相同的 Kerberos 賬號， 以及相同的 HDFS 路徑與和 HBase 命名空間，將很難避免不一樣項目之間互相產生影響。

將來計劃以項目爲基本單位，支持設置獨立的 Kerberos 賬號，可設置 HDFS、HBase 空間和名稱，隔離不一樣項目的 Kerberos 權限及存儲空間的使用，避免出現不一樣用戶之間的互相干擾。

8 更多探索未完待續

藉助 Apache Kylin 的諸多特性，UnionSQL 解決方案爲小米公司內部各業務團隊提供了簡潔、快速、統一的數據查詢服務，實現了對公司核心業務的賦能。

隨着在內部業務上的落地與應用，小米大數據團隊在 UnionSQL 上，還針對支持跨境 OLAP 能力以及 Lambda 架構等方向，進行了更多的深刻實踐。在後續的文章中，小米大數據將進一步介紹小米公司在這些不一樣技術方向上的探索過程，敬請關注！

小米大數據負責人 司馬雲瑞

「UnionSQL 是小米大數據的核心項目，其目的就是爲了「快」—— 上手快、數據更新快、查詢速度快、越用越快。Apache Kylin 在該項目中不只扮演着舉足輕重的角色，同時也成爲了 UnionSQL 架構的核心組成部分。在通過長達一年的實戰演練以後，Apache Kylin 的查詢效率、穩定性及可擴展性都完美地達到了最初的既定目標，並已開始在公司內部進行大規模推廣。Kylin 做爲全球華人的首個 Apache 頂級項目，通過多年時間的沉澱與積累，在大數據領域中正發揮着愈來愈重要的做用。小米公司期待和社區共同推動 Apache Kylin 的發展與演進。」

Apache Kylin PMC 史少鋒

「小米做爲一家領先的智能設備與互聯網服務供應商，近些年發展十分迅速，業務遍佈海內外，已成爲國人爲之驕傲的品牌。隨着大數據與人工智能技術的成熟與普及，以數據爲驅動的發展模式愈來愈獲得承認。咱們很高興看到 Apache Kylin 成爲小米大數據平臺的核心 OLAP 引擎，爲衆多數據分析師與業務團隊創造價值。小米一直以來都是開源軟件的積極參與者和貢獻者，爲開源社區貢獻了不少很是好的組件和功能。在過去的時間裏，咱們與小米大數據團隊進行了深刻的探討和交流，將來咱們會繼續合做，將小米積累和沉澱的諸多經驗和實踐回饋給 Apache Kylin 社區。」

【特別感謝小米雲技術、小米運維等相關團隊的工程師們共同參與了本文內容的撰寫】