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

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

小米大數據，目前主要負責設計、完善公司級數據倉庫解決方案，提供完備及全鏈條的數據治理一站式平臺，連通各業務線數據，開發通用的畫像平臺與分析引擎。小米大數據團隊的目標，在于不斷提升數據產品與服務品質，并依托數據科學、機器學習等技術賦能核心業務。

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

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

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

基于 MySQL 的架構，在大數據上的查詢效率低下；
業務間 OLAP 引擎不統一，數據管道冗長，數據復用率極低，開發工作周期變長，維護成本增加；
缺乏統一的維表和事實表，同主題下數據統計口徑不一致；
新增業務需要投入較大的成本才能獲得基礎的 OLAP 能力。

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

報表能力；
提供 OLAP 查詢接口，支持各種即席分析；
盡可能降低使用門檻（ETL 以及查詢的門檻）；
初級階段只需支持離線分析需求。

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

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

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

$\"1\"$

數據金字塔體系的結構

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

源數據層：對來源于業務線的數據進行采集、存放等最粗粒度的處理工作。這些業務數據進入源數據層之前，需要遵循科學的打點規范并準備好數據同步策略及工具。
中間層：對源數據層的數據進行 ETL，合乎規范的數據表將被存放在該層中。數據表包含事實表和維表，事實表用于記錄業務過程的事實數據，而維表則記錄維度關系。事實表和維表都需要遵循嚴格的命名與操作規范。
匯總層：公司級或業務級的主題數據都歸屬于該層。典型的主題表往往會對跨業務線的多張中間表進行匯總。例如小米用戶畫像，就是來源于公司內部多項業務數據的挖掘匯總而成。主題表是業務數據的高度概括，基本上能滿足業務團隊 80% 以上的數據需求。
應用層：結合中間層與匯總層中的數據，對其進行優化，并開發定制化的數據能力與工具，或提供業務級甚至公司級的數據服務。

公司各業務線的在線服務日志以及其他數據源的數據（MySQL 等等），可通過數據流服務下沉到 HDFS、Kudu、HBase 等引擎中，經過數據金字塔建模后再提供給業務團隊使用。

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

$\"2\"$

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

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

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

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

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

可滿足大多數需求，支持常見的算子，以及數據的攝入、查詢速度足夠快；
保證良好的 SLA；
使用門檻相對較低。

$\"3\"$

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。

越來越多的內部業務開始受益于 UnionSQL

在引入 Apache Kylin 作為 OLAP 引擎之后，就可將需要進行分析的數據抽象成星型模型，其中的受益之處包括：

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

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

$\"4\"$

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

眾所周知，點擊率 = 點擊 / 曝光，但如果直接在不同引擎中計算點擊率，并將得到的結果相加，就會得到一個錯誤的點擊率。因此，UnionSQL 引擎則會將原始 SQL 進行重寫，再分別計算點擊量和曝光量，最后在 UnionSQL 引擎中重新計算點擊率，并將正確的結果返回給最終用戶。

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

$\"5\"$

UnionSQL 解決方案的諸多優勢

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

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

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

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

$\"6\"$

Lambda on OLAP 架構

三類主要的 OLAP 落地場景

一般情況下，業務團隊的 OLAP 需求可大體分為三類——用戶畫像、數據運營、數據分析。

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

$\"7\"$

用戶畫像分析的效果

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

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

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

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

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

一、監控與部署

在監控方面：

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

在部署方面：

修改了 Apache Kylin 的打包方式，去掉了默認的 Spark、Hadoop 依賴，添加了小米公司內部維護的 Hadoop、Spark、HBase、Hive 版本，并打包成了一個完整的發布包；
與公司內部的自動化部署平臺進行整合，將發布包和配置進行分離，支持自動化包與配置升級，加快開發與迭代的速度。

二、同外部系統的集成與整合

在 HBase 方面：

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

在用戶管理方面：

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

三、服務限制

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

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

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

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

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

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

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