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

weixin_33763244發表於2018-12-03

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

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

業務團隊亟需統一、低門檻的 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 許可權及儲存空間的使用，避免出現不同使用者之間的互相干擾。