首先和大家分享下小米 BI 平臺的發(fā)展歷史。

2019 年之前，小米各業(yè)務(wù)以主題式 BI 建設(shè)為主，沒有一個全集團(tuán)共同使用的 BI 平臺，各個業(yè)務(wù)以自建的方式滿足業(yè)務(wù)需要。

2020 年，隨著小米成立大數(shù)據(jù)部，我們目標(biāo)是完成整個數(shù)據(jù)中臺的能力建設(shè)。當(dāng)時脫胎于互聯(lián)網(wǎng)體系，我們有打點(diǎn)統(tǒng)計、用戶行為分析產(chǎn)品和 BI 可視化建站等產(chǎn)品，在不同的單點(diǎn)場景上去滿足業(yè)務(wù)的需求。但由于產(chǎn)品太多，不同的產(chǎn)品之間不能拉通、數(shù)據(jù)不互通，為了統(tǒng)一數(shù)據(jù)平臺完成了多個產(chǎn)品的整合，牽引底層數(shù)據(jù)采集能力和集團(tuán)數(shù)倉能力的建設(shè)。

2021 年，BI 平臺達(dá)到了一定的成熟度，集團(tuán)大量的看板可視化需求涌現(xiàn)。在逐步支持大量需求的同時，切入了面向高管的集團(tuán)看板場景，增強(qiáng)了移動化的能力和 IM 強(qiáng)集成。

2022 年，成為了集團(tuán)公認(rèn)的 BI 平臺，從以往的互聯(lián)網(wǎng)體系、電商體系這些泛互聯(lián)網(wǎng)體系的業(yè)務(wù)上切入研產(chǎn)供財務(wù)體系的 BI 領(lǐng)域。原有的底層設(shè)計和產(chǎn)品形態(tài)無法支撐這么多不同行業(yè)體系下的交付，因此今年對整個底層架構(gòu)包括產(chǎn)品形態(tài)進(jìn)行重塑。另一方面以往看板的場景和形態(tài)下，消費(fèi)和生產(chǎn)的鏈路很重，“如何去帶動更多的數(shù)據(jù)消費(fèi)，升級出更簡單的產(chǎn)品場景”成為今年的工作目標(biāo)。

從整個發(fā)展演變過程來看，2021 年之前，小米的 BI 平臺是強(qiáng)貼合業(yè)務(wù)場景去做建設(shè)；2022 年之后，要真正成為一個集團(tuán)級的 BI 平臺，需要非常強(qiáng)的平臺基建，包括底層架構(gòu)、技術(shù)設(shè)計和產(chǎn)品形態(tài)。

BI 平臺建設(shè)的探索和實踐

那下面來介紹一下在這幾年過程中小米 BI 平臺經(jīng)歷的變化和打磨歷程。

BI 平臺建設(shè)的四個坑（難點(diǎn)）：

• 性能

BI 把查數(shù)和數(shù)據(jù)消費(fèi)的形態(tài)搬到了產(chǎn)品界面上。用戶在界面上操作，通常希望能夠秒級返回。優(yōu)秀的秒級性能表現(xiàn)依賴于數(shù)據(jù)量、OLAP引擎、查詢服務(wù)、建模復(fù)雜度和可視化環(huán)環(huán)相扣的設(shè)計和聯(lián)動，是建設(shè)BI平臺的最大挑戰(zhàn)。

• 建模

很多用戶并不清楚到底哪些數(shù)據(jù)應(yīng)該在數(shù)據(jù)處理環(huán)節(jié)解決，哪些應(yīng)該在建模層的環(huán)節(jié)去解決，數(shù)據(jù)處理和建模有很多模糊地帶。大家更傾向于把建模和算數(shù)的需求提到產(chǎn)品層面上。例如計算每個機(jī)型上市累計的銷量，每個機(jī)型都有自己的上市時間，匯總累加的時間范圍不同。這樣的累計計算如果在建模層解決，非常消耗性能且查詢體驗不好，需要考慮在數(shù)倉層面解決。實際上很多算數(shù)的需求依賴于數(shù)倉和用戶本身的建模能力，但是如果用戶對這些背后邏輯和限制不了解的話，會天然覺得 BI 產(chǎn)品要解決所有算數(shù)需求。

• 可視化

可視化的需求是一個無底洞，因為可視化的標(biāo)準(zhǔn)是很難建立的。過往很多業(yè)務(wù)系統(tǒng)，根據(jù)業(yè)務(wù)需求做了大量定制的“看板”頁面，但是這些定制的頁面實現(xiàn)通用化是非常困難的。但是往往用戶希望BI平臺可以對標(biāo)以往的定制頁面，因為使用習(xí)慣有遷移成本。

• 權(quán)限

大部分的權(quán)限需求說起來很簡單，“希望按照組織結(jié)構(gòu)或者業(yè)務(wù)線開通權(quán)限”。但實際上在 BI 平臺一側(cè)，除了看板、數(shù)據(jù)模型有權(quán)限，看板上可能又需要設(shè)置某個人只能看到某一個國家或者某一個機(jī)型的細(xì)粒度管控，整套權(quán)限如何建設(shè)，又如何跟公司的組織結(jié)構(gòu)掛鉤，其實也是一個很復(fù)雜的過程。

下面詳細(xì)講一下圍繞這些難點(diǎn)的具體實踐。

數(shù)據(jù)系統(tǒng)選型上的嘗試分為兩部分：數(shù)據(jù)源的支持和引擎的選擇。

小米 BI 平臺建設(shè)之初，數(shù)據(jù)源只支持了 MySQL 和 Doris，因為這兩個數(shù)據(jù)源在分析的場景下，性能以及查詢的效果更好。由于業(yè)務(wù)需求過大，業(yè)務(wù)上頻繁被問起為什么不能支持 Hive，因此做了 Hive 的支持，結(jié)果性能非常差，一個結(jié)果要離線跑個幾分鐘，在界面上是不可接受的。

反思：即便數(shù)據(jù)源要支持不同底層的數(shù)據(jù)類型，在引擎層要把不同的數(shù)據(jù)源類型性能做拉齊。BI 平臺的終端用戶是數(shù)據(jù)消費(fèi)者，并不是數(shù)據(jù)生產(chǎn)者，數(shù)據(jù)生產(chǎn)者因為對背后的技術(shù)有了解對離線查詢的性能可以接受，但數(shù)據(jù)消費(fèi)者是很難接受的。

類似還有 Excel 支持的需求，剛開始很多業(yè)務(wù)反饋有些數(shù)據(jù)是本地文件的形式，需要支持；但是上線了之后，Excel 能力沒有得到業(yè)務(wù)線的廣泛使用。因為本地文件的數(shù)據(jù)依賴于用戶自己手工維護(hù)以及追加數(shù)據(jù)，較為麻煩，成本上用戶不愿意去持續(xù)地去做；因此在數(shù)據(jù)源以及查詢的過程中，自動更新的能力非常重要。

今年切到研產(chǎn)供體系，非互聯(lián)網(wǎng)體系的數(shù)據(jù)有非常大不同。以前接觸到的數(shù)據(jù)類型都是比較開放的生態(tài)。研產(chǎn)供體系更多是 SAP 比較封閉的生態(tài)，例如今年使用的 HANA 數(shù)據(jù)庫跟原有的數(shù)據(jù)類型非常不一樣，語法要支持斜杠，在其他數(shù)據(jù)源上斜杠代表除號，在語法上要做特別的兼容。

引擎的選擇決定了 BI 平臺的性能、穩(wěn)定性以及靈活性，不僅影響到技術(shù)層面，也會影響到查詢功能產(chǎn)品層面。小米最開始用 Kylin 的方案做面向主題式的報表，后面做通用的 BI 平臺，查詢的靈活性 Kylin 是無法支持的，轉(zhuǎn)到了 Kudu，但因為 Kudu 太貴，然后又轉(zhuǎn)到了 Doris。Doris 對寬表 JOIN 的分析場景是比較易用的。2019 年引入了 Doris，2020 年開始全面推廣，但當(dāng)時 Doris 的成熟度不高，經(jīng)常幾個大查詢，可能就會把集群搞掛，線上事故和穩(wěn)定性是很大的問題，存在很大的運(yùn)維成本。今年 Hive 使用 Presto 引擎支持，性能有了很大的提升。BI 平臺的加速能力非常重要。

不管是數(shù)據(jù)源還是引擎的設(shè)計，對整個 BI 框架都有非常重要的影響，決定了 BI 平臺的性能和穩(wěn)定性表現(xiàn)。

• 數(shù)據(jù)量和查詢策略

具體工作包括裁剪數(shù)據(jù)量、聚合維度、縮減時間范圍、數(shù)據(jù)抽樣、根據(jù)集群忙閑程度調(diào)度；把不同的查詢區(qū)分成大查詢還是小查詢、做實時或離線查詢的拆分、查詢排隊機(jī)制，以及大量的 SQL 優(yōu)化工作。

• 產(chǎn)品功能優(yōu)化

耗時預(yù)估的功能能夠大幅地降低用戶在查詢上的焦慮感；提供性能分析功能，讓用戶知道真正的查詢耗時在什么地方，是查詢條件很復(fù)雜或者本身數(shù)據(jù)量就是比較大。其他細(xì)節(jié)優(yōu)化還包括去重合計功能拆分、去掉模糊匹配的 Like 和正則匹配的查詢、維度值查詢和更新策略，在查詢需求和性能上取得一個平衡。

• 前端加載優(yōu)化

包括重點(diǎn)保障首屏加載，首 Tab 加載和分頁加載策略等。

在查詢體驗優(yōu)化上，環(huán)環(huán)相扣的設(shè)計非常重要，涉及數(shù)據(jù)底層、查詢策略、前端和產(chǎn)品功能設(shè)計的匹配，是一個相當(dāng)精密復(fù)雜的過程。

建模層面，去年之前以 SQL 的方式建模。每一個查詢條件通過 SQL 拼接的方式查詢，復(fù)雜的計算通過 SQL 片段實現(xiàn)；但是今年發(fā)現(xiàn)切入到研產(chǎn)供體系了之后，大量的算數(shù)需求增多，尤其是年度累計、季度累計、各種同環(huán)比的指標(biāo)，SQL 的支持門檻較高。

今年轉(zhuǎn)向 MDX 的語法查詢和建模能力。MDX 是多維查詢表達(dá)式，也是 PowerBI 和 Tableau 使用的建模方案，其優(yōu)勢是對復(fù)雜指標(biāo) MDX 天然支持了很多的函數(shù)，減少了很多開發(fā)成本。同時，在時間層級和維度層級上，MDX 天然地支持了很多上卷下鉆的能力。架構(gòu)演進(jìn)上，業(yè)界已經(jīng)有一些很好的實踐，實踐中應(yīng)該去做靠齊。雖然今年轉(zhuǎn)到 MDX 的查詢和建模上，但是實際上也兼容了原來 SQL 的方式。

可視化是 BI 平臺最核心的能力。

圖表的可視化是業(yè)界很成熟的能力，但為什么很多圖表在 BI 平臺上還是畫不出來呢？核心原因是這些圖表基礎(chǔ)組件只解決了最基礎(chǔ)的展示需求，只是把數(shù)據(jù)能夠描繪和展示出來。但是很多業(yè)務(wù)有自己看數(shù)或可視化的習(xí)慣，這是很業(yè)務(wù)領(lǐng)域的一件事情。

小米 BI 平臺在樣式上進(jìn)行了大量工作，如各種可配置線條、顏色、條件格式等，但仍然只解決了一些相對通用和基礎(chǔ)的能力，還有大量業(yè)務(wù)的樣式無法支持，樣式是非常難以通用化的。

不同的展示又有不同的需求，移動端場景與 PC 有明顯不同。在 PC 的場景中，用戶可以接受圖表平鋪，但在移動的場景下，聯(lián)動和篩選的交互非常重要，對提升看板體驗有很大的影響。

總結(jié)來說，大量定制的需求其實很難通用，或者說通用成本是非常高的。如果可以滿足業(yè)務(wù)定制的需求，其實體驗會非常好，比提供通用基礎(chǔ)的組件在數(shù)據(jù)消費(fèi)和使用上是更符合業(yè)務(wù)習(xí)慣的。在通用的架構(gòu)上怎么能更好地跟定制結(jié)合，我們希望通過支持三方組件引入的方式來解決，也是后面要繼續(xù)去做的事情。

權(quán)限方面小米實現(xiàn)了數(shù)據(jù)資源、功能資源以及 RBAC 管理的整套體系：數(shù)據(jù)資源自定義，包括維度分組、指標(biāo)分組和模型關(guān)聯(lián)；頁面和看板操作資源細(xì)粒管控，區(qū)分看板作為頁面資源管理編輯、查看的權(quán)限；權(quán)限 RBAC 管理，包括用戶跟角色如何對應(yīng)、角色跟資源如何綁定等等。

這個體系看起來很對，但是實際上非常復(fù)雜又很難用。在日常的工作當(dāng)中，并不是很多權(quán)限真的按照組織架構(gòu)開就可以的，很多時候的數(shù)據(jù)是一種橫向協(xié)作的方式，很多協(xié)作導(dǎo)致權(quán)限要足夠的靈活，粒度也要足夠的簡單。

BI 平臺建設(shè)最大的挑戰(zhàn)，是產(chǎn)品邊界問題。在 BI 平臺建設(shè)的過程中，業(yè)務(wù)側(cè)希望一個平臺能解決所有看數(shù)和可視化的問題，產(chǎn)研側(cè)也曾經(jīng)以為所有的查數(shù)和可視化需求都應(yīng)該是BI 平臺服務(wù)范疇，造成的結(jié)果就是：A 業(yè)務(wù)拿他們的一個定制的系統(tǒng)提需求，BI 平臺要對標(biāo) A 系統(tǒng)，B 業(yè)務(wù)找另外一個他們定制的系統(tǒng)，對標(biāo) B 系統(tǒng)。對于 BI 平臺建設(shè)而言這是一個很可怕的無底洞，因為所有的功能都在做加法的堆砌，導(dǎo)致系統(tǒng)復(fù)雜度非常高，維護(hù)起來也非常困難。

BI 平臺解決的終極問題不是一個平臺所有看數(shù)查數(shù)可視化的問題，而是要解決報表生產(chǎn)和數(shù)據(jù)消費(fèi)效率問題，如何能帶動更多的數(shù)據(jù)消費(fèi)讓公司數(shù)據(jù)化。

03

BI 平臺目前產(chǎn)品架構(gòu)

小米 BI 平臺的產(chǎn)品結(jié)構(gòu)，一共分為四層：數(shù)據(jù)源層、語義模型層、能力層、場景層。

最下是數(shù)據(jù)源層，支持離線的 Hive、Iceberg 類型數(shù)據(jù)，也支持在線的 MySQL、Doris 以及剛提到的 SAP Hana 數(shù)據(jù)庫，包括本地文件和在線表格等。

語義模型層，對數(shù)據(jù)源進(jìn)行建模、定義指標(biāo)維度，支持日期轉(zhuǎn)換、層次結(jié)構(gòu)，以及擁有強(qiáng)大的函數(shù)處理能力。支持在建模之后做自動的數(shù)據(jù)加速，自動加速能力包括本身的加速庫，查詢引擎選擇和查詢層的緩存。

能力層，不只是可視化能力?？梢暬鋵嵤窍鄬Ρ容^成熟的能力模塊，近期重點(diǎn)發(fā)展的是數(shù)據(jù)百科和智能分析的能力。平臺當(dāng)前已經(jīng)支持那么多數(shù)據(jù)看板的建設(shè)，但是整個集團(tuán)或者各個業(yè)務(wù)領(lǐng)域的數(shù)據(jù)還是無法打通。數(shù)據(jù)百科是基于語義模型能力，去自動構(gòu)建指標(biāo)體系和口徑認(rèn)證，通過在模型和看板層的數(shù)據(jù)，實現(xiàn)血緣溯源和指標(biāo)分發(fā)。智能分析算法包括異常檢測/根因分析、智能預(yù)警等能力。數(shù)據(jù)分析效率的提升強(qiáng)烈依賴數(shù)據(jù)智能。以往的報表量可控，但隨著公司數(shù)據(jù)化的進(jìn)程，報表量在膨脹和增長，怎么能更有效率地去做數(shù)據(jù)分析和數(shù)據(jù)消費(fèi)，智能分析是一條必經(jīng)之路。

最上層的場景層包括三種場景。第一是原始的報表場景，包括 PC、移動看板和交互式探索的能力。第二是報告場景，包括在線文檔和訂閱簡報。第三是智能場景，通過智能分析和數(shù)據(jù)機(jī)器人，帶動整個數(shù)據(jù)智能的場景。

右側(cè)是權(quán)限模塊。目前權(quán)限的實現(xiàn)是以分享為核心做的整套設(shè)計，包括的看板支持分享、模型知識分享、簡報百科知識分享，以及跟 IM 強(qiáng)集成，背后是數(shù)據(jù)中臺體系統(tǒng)一的權(quán)限服務(wù)，負(fù)責(zé)統(tǒng)一鑒權(quán)和統(tǒng)一登錄能力。

04

未來規(guī)劃和演進(jìn)方向

整體來講，未來的數(shù)據(jù)消費(fèi)趨勢一定是從數(shù)據(jù)分析到數(shù)據(jù)智能。數(shù)據(jù)分析其實已經(jīng)提了太多年，但是整體的產(chǎn)品形態(tài)還是偏靜態(tài)、固定式的報表或看板查詢，更多的是一種人找數(shù)據(jù)的狀態(tài)。

但在 ToC 領(lǐng)域，內(nèi)容找人已經(jīng)相當(dāng)成熟了，很多的消費(fèi)和分發(fā)的方式大家已經(jīng)爐火純青。但數(shù)據(jù)層其實更多的還是在固化的內(nèi)容消費(fèi)上其實是不對的，所以后面更多的是考慮是怎么去做一種互動式的消費(fèi)。

一般想獲取一份數(shù)據(jù)的時候，背后其實是想要獲取具體的數(shù)值或者想知道它的波動原因是什么？通過機(jī)器人觸點(diǎn)和簡報推送的場景去牽引碎片式、互動式的數(shù)據(jù)消費(fèi)方式。

未來的規(guī)劃兩個關(guān)鍵詞——更業(yè)務(wù)，更簡單。

更業(yè)務(wù)：作為集團(tuán)級的 BI 平臺，一定是要去解決業(yè)務(wù)問題。當(dāng)轉(zhuǎn)向研產(chǎn)供財領(lǐng)域時，不同行業(yè)領(lǐng)域上還存在很大的差距。怎么去支撐規(guī)模化的交付，能讓業(yè)務(wù)跑得更快，要考慮怎么能夠結(jié)合更靈活的定制能力，在基礎(chǔ)架構(gòu)上夠支撐更大體量的業(yè)務(wù)。

更簡單：基于怎么能讓集團(tuán)的員工在數(shù)據(jù)使用上更簡單、效率更高來思考。這非常依賴于產(chǎn)品力的更新，以及整個產(chǎn)品形態(tài)是不是更符合比較輕的消費(fèi)方式。目前看板的消費(fèi)方式有很長的生產(chǎn)鏈條，用戶需要經(jīng)歷開發(fā)數(shù)據(jù)表、建模、搭報表各種環(huán)節(jié)的研發(fā)才能獲取到數(shù)據(jù)。怎么可以讓數(shù)據(jù)獲取鏈路更短，讓分析變得更簡單，是我現(xiàn)在在考慮的路線，打破原有的傳統(tǒng)報表模式、引入智能能力、結(jié)合小米的場景創(chuàng)造一個更易用的消費(fèi)形態(tài)。

今天的分享就到這里，謝謝大家。