一、系統(tǒng)選型和應(yīng)用現(xiàn)狀

首先來介紹一下小米集團(tuán)OLAP系統(tǒng)選型與應(yīng)用現(xiàn)狀。

1、系統(tǒng)選型

在小米內(nèi)部，OLAP引擎主要的應(yīng)用場景是BI看板和報(bào)表分析。早期通過引入Kylin來滿足面向主題式的報(bào)表分析的需求，當(dāng)時(shí)沒有集團(tuán)層面通用的BI平臺(tái)，都是各個(gè)業(yè)務(wù)部門自建自己的BI看板。后來小米決定要建立全集團(tuán)通用的BI平臺(tái)，Kylin的靈活性就不太夠了，我們就需要做一次選型，選擇一款在各個(gè)業(yè)務(wù)場景之間更通用的OLAP方案，通過調(diào)研我們選擇了SparkSQL+Kudu+HDFS這種方案。

【資料圖】

計(jì)算層使用了SparkSQL，存儲(chǔ)層使用了Kudu和HDFS。存儲(chǔ)層做了冷熱數(shù)據(jù)的分離，熱數(shù)據(jù)會(huì)寫入到Kudu，冷數(shù)據(jù)會(huì)存儲(chǔ)在HDFS。數(shù)據(jù)的存儲(chǔ)做了按天分區(qū)，每天會(huì)將Kudu的一部分?jǐn)?shù)據(jù)轉(zhuǎn)冷，在晚上集群負(fù)載比較低的時(shí)候，將數(shù)據(jù)轉(zhuǎn)儲(chǔ)到HDFS。在查詢層做了Kudu和HDFS的聯(lián)合視圖，當(dāng)用戶需要查詢看板的時(shí)候，就通過Spark SQL查詢Kudu和HDFS的聯(lián)合視圖，把查詢的結(jié)果通過看板進(jìn)行展示。

早期這一方案在一定程度上能夠滿足小米的需求，但仍然存在一些問題，比如需要維護(hù)的組件過多，運(yùn)維成本相對(duì)較高。另外，Spark底層是基于批處理的機(jī)制，數(shù)據(jù)在做Shuffle的時(shí)候，中間的結(jié)果可能需要落盤，就會(huì)導(dǎo)致使用SparkSQL查詢時(shí)性能相對(duì)較低。隨著小米內(nèi)部業(yè)務(wù)的持續(xù)增長，對(duì)于OLAP 的需求越來越多，之前的方案在一些場景上已難以滿足業(yè)務(wù)需求，因此我們希望能夠選擇一款更加優(yōu)秀的系統(tǒng)來替代之前的SparkSQL+Kudu+HDFS的架構(gòu)。

經(jīng)過調(diào)研，我們選擇了Apache Doris，這個(gè)系統(tǒng)是存算一體的，查詢性能也相對(duì)較好。小米內(nèi)部在2019年的時(shí)候首次引入了Apache Doris，當(dāng)時(shí)的版本還比較老，是一個(gè)非向量化的版本，數(shù)據(jù)在內(nèi)存里是按照行存的形式來做計(jì)算的，所以就是沒有很好地使用到CPU的向量化計(jì)算的能力。早期這個(gè)系統(tǒng)在性能方面也能夠滿足業(yè)務(wù)需求，但隨著近幾年公司業(yè)務(wù)的快速發(fā)展，一些業(yè)務(wù)對(duì)OLAP系統(tǒng)的查詢性能提出了更高的要求，非向量化版本的查詢性能確實(shí)在一些場景上顯得捉襟見肘了。

在2022年的時(shí)候，我們又進(jìn)行了一次系統(tǒng)選型，希望能夠引入更優(yōu)秀的OLAP系統(tǒng)。我們調(diào)研了ClickHouse，它是一款非常優(yōu)秀的OLAP系統(tǒng)。我們?cè)谛∶變?nèi)部也使用了實(shí)際業(yè)務(wù)進(jìn)行了測(cè)試，測(cè)試結(jié)果是它的單表查詢性能非常好，但在多表查詢上還是不能滿足我們的業(yè)務(wù)需求。另外，數(shù)據(jù)導(dǎo)入方面， ClickHouse沒有事務(wù)來保證數(shù)據(jù)寫入的原子性。用戶如果有一部分?jǐn)?shù)據(jù)寫入失敗并進(jìn)行了重試，可能最終的數(shù)據(jù)就會(huì)出現(xiàn)部分?jǐn)?shù)據(jù)的重復(fù)，這種情況在一些業(yè)務(wù)上是難以接受的，所以我們最終就放棄了 Clickhouse 的方案。

隨著Doris向量化版本的發(fā)布，且最近幾年Apache Doris社區(qū)也發(fā)展非常迅速，底層的引擎也進(jìn)行了更新?lián)Q代，支持了向量化的存儲(chǔ)和計(jì)算引擎。我們又進(jìn)行了向量化版本的測(cè)試，當(dāng)時(shí)在小米內(nèi)部使用了Doris 1.1.2 這個(gè)版本在實(shí)際業(yè)務(wù)場景進(jìn)行測(cè)試，發(fā)現(xiàn)相比之前的0.13這個(gè)非向量化版本，查詢的性能整體提升有1倍以上，在部分場景上查詢性能提升有3- 5倍。最終我們就選擇繼續(xù)留在了Apache Doris上，并推動(dòng)了Apache Doris向量化版本的上線。

以上就是我們內(nèi)部系統(tǒng)選型的歷史。

2、Apache Doris優(yōu)勢(shì)

我們選型使用Apache Doris主要是因?yàn)镈oris 有以下幾個(gè)方面的優(yōu)勢(shì)：

首先，Doris查詢性能比較好，它的底層支持了比較多的索引，能夠提升查詢效率，用戶也可以創(chuàng)建物化視圖或者是RollUp 來加速查詢。當(dāng)然在支持了向量化引擎以后，查詢的性能就更好了。

其次，我們選擇 Doris 是因?yàn)橹С值氖菢?biāo)準(zhǔn)的SQL，對(duì)用戶使用非常友好，用戶可以使用 MySQL 客戶端直接連接 Doris 來進(jìn)行查詢，用戶使用成本低。

Doris 的第三個(gè)優(yōu)勢(shì)是它不依賴于外部的組件，運(yùn)維非常簡單。另外，它對(duì)于分布式的支持比較好，可以很方便地進(jìn)行集群的擴(kuò)容和縮容。數(shù)據(jù)是多副本的存儲(chǔ)，如果有副本出現(xiàn)了異常，系統(tǒng)具有副本自動(dòng)修復(fù)的能力。

我們選擇 Doris 的最后也是最重要的一個(gè)原因，就是它完全開源，社區(qū)比較活躍，便于后期的維護(hù)和升級(jí)。現(xiàn)在Apache Doris 背后也有商業(yè)化公司的支持，我們內(nèi)部線上服務(wù)遇到的問題，如果內(nèi)部不能自己解決，也能夠很快得到社區(qū)的支持，幫助我們解決。

以上這些就是我們選擇Apache Doris的主要原因。

3、應(yīng)用現(xiàn)狀

我們?cè)?019年的時(shí)候引入Doris，經(jīng)過幾年的發(fā)展，目前 Doris 在小米內(nèi)部已經(jīng)得到了非常廣泛的應(yīng)用，比較核心的、較大的業(yè)務(wù)有幾十個(gè)，還有數(shù)百個(gè)小一些的業(yè)務(wù)。

內(nèi)部使用Doris比較大的業(yè)務(wù)，包括用戶行為分析、AB實(shí)驗(yàn)、用戶畫像、小米造車、小米有品、新零售、天星數(shù)科、廣告投放、廣告BI和智能制造等等。Doris 的集群在我們內(nèi)部現(xiàn)在有數(shù)十個(gè)，其中最大的集群有 99 個(gè) Be 節(jié)點(diǎn)， 3 個(gè) Fe 節(jié)點(diǎn)，集群的規(guī)模比較大。最大的集群每天有幾十個(gè)流式的數(shù)據(jù)導(dǎo)入任務(wù)，單表每天最大的數(shù)據(jù)增量有 120 億，這個(gè)集群每天能夠承擔(dān)2萬次以上的有效查詢。

二、小米數(shù)據(jù)生態(tài)中的Doris

在第二部分，將介紹小米內(nèi)部數(shù)據(jù)生態(tài)中的Doris。

1、小米BI平臺(tái)架構(gòu)

在小米內(nèi)部，Doris 的一個(gè)較大的應(yīng)用場景是作為BI 平臺(tái)的底層的數(shù)據(jù)源。在 BI 平臺(tái)底層，除了使用 Doris 作為數(shù)據(jù)源之外，還有MySQL、 Hive 和Iceberg。MySQL 和 Doris 主要面向的是實(shí)時(shí)分析的業(yè)務(wù)場景，MySQL 針對(duì)的是數(shù)據(jù)量比較小，但是查詢非常敏感，要求查詢延遲非常低的業(yè)務(wù)。相比于MySQL ，Doris 面向的是大數(shù)據(jù)量的業(yè)務(wù)，查詢的延遲要求比 MySQL 可能會(huì)稍微低一些，一般支持的是秒級(jí)的查詢延遲。Hive 和 Iceberg 主要針對(duì)的是數(shù)據(jù)量更大、離線分析的場景。

在小米的 BI 平臺(tái)，用戶可以直接在語義模型層通過拖拽組件或者是編寫 SQL 的方式進(jìn)行語義建模，模型創(chuàng)建完成之后就可以對(duì)數(shù)據(jù)源進(jìn)行分析查詢，并且把查詢的結(jié)果在看板上進(jìn)行可視化展示。語義模型層除了支持拖拽組或編寫 SQL 來建模之外，還支持了指標(biāo)和維度定義、日期轉(zhuǎn)換、函數(shù)處理等一些比較復(fù)雜的能力。

另外，在語義模型層，也支持了查詢的自動(dòng)加速。用戶在創(chuàng)建看板的時(shí)候選擇了 Hive 或Iceberg作為數(shù)據(jù)源，同時(shí)選擇使用 Doris 進(jìn)行查詢加速，那么用戶創(chuàng)建好看板之后，就會(huì)由平臺(tái)生成數(shù)據(jù)同步任務(wù)，根據(jù)用戶看板的數(shù)據(jù)分析需求，使用 Spark或Presto查詢Hive或Iceberg生成中間表，再把中間表數(shù)據(jù)導(dǎo)入到 Doris 里。用戶在查詢看板的時(shí)候就不用直接通過Presto或Spark來查 Hive 或Iceberg的數(shù)據(jù)了，可以直接路由到 Doris 查詢中間表的數(shù)據(jù)，進(jìn)行加速查詢。

小米 BI 平臺(tái)除了支持PC 端看板，也支持了移動(dòng)端看板。小米內(nèi)部也引入了Apache Kyuubi組件，主要是盡量對(duì)上層的用戶屏蔽底層的具體查詢引擎。之前每一個(gè)查詢引擎都是上層用戶直連的，引入Kyuubi之后可以提供統(tǒng)一的 SQL 入口，由Kyuubi進(jìn)行具體引擎的連接。當(dāng)然對(duì)于歷史的、直接使用 Doris 的用戶場景，還是支持上層業(yè)務(wù)通過 JDBC 的方式來連接Doris進(jìn)行分析查詢。

這就是Doris在小米 BI 平臺(tái)的使用情況。

2、數(shù)據(jù)工場

小米內(nèi)部使用了數(shù)據(jù)工場對(duì)底層的存儲(chǔ)和計(jì)算引擎進(jìn)行了封裝。數(shù)據(jù)工場是小米自研的一款面向數(shù)據(jù)開發(fā)和數(shù)據(jù)分析人員的數(shù)據(jù)平臺(tái)，底層集成了Doris、Iceberg、Hive、MySQL、Kudu等的存儲(chǔ)能力，同時(shí)也集成了Spark、Flink、Presto等的計(jì)算能力，對(duì)底層的存儲(chǔ)和計(jì)算能力進(jìn)行了統(tǒng)一的封裝，提供給集團(tuán)各個(gè)業(yè)務(wù)來進(jìn)行數(shù)據(jù)的存儲(chǔ)和計(jì)算。數(shù)據(jù)工場對(duì)底層的這些存儲(chǔ)和計(jì)算引擎也提供了統(tǒng)一的元數(shù)據(jù)管理、統(tǒng)一的權(quán)限管理、數(shù)據(jù)作業(yè)管理以及數(shù)據(jù)治理的能力。

3、統(tǒng)一元數(shù)據(jù)管理

對(duì)于底層的每一個(gè)存儲(chǔ)和計(jì)算引擎，在數(shù)據(jù)工場都做了統(tǒng)一的元數(shù)據(jù)管理，由數(shù)據(jù)工場給上層的業(yè)務(wù)提供了統(tǒng)一的元數(shù)據(jù)視圖。比如對(duì)于Doris來說，底層的元數(shù)據(jù)就包括Doris服務(wù)信息、集群信息、庫信息、表信息和分區(qū)信息，在統(tǒng)一元數(shù)據(jù)管理系統(tǒng)提供的元數(shù)據(jù)視圖就是“doris.集群名.庫名.表名.分區(qū)名”。通過這種方式對(duì)上層服務(wù)提供了統(tǒng)一的元數(shù)據(jù)視圖。通過元數(shù)據(jù)管理對(duì)所有的存儲(chǔ)資源可以進(jìn)行統(tǒng)一管理，形成了統(tǒng)一的資源視圖，可以對(duì)所有的資源變更和訪問進(jìn)行有效的審計(jì)。對(duì)于每一次Doris集群的查詢或?qū)懭朐L問，都可以在元數(shù)據(jù)管理系統(tǒng)里進(jìn)行記錄和審計(jì)。

4、統(tǒng)一權(quán)限管理

底層不同的引擎可能具有不同的權(quán)限體系，Doris使用的是用戶名和密碼的方式進(jìn)行鑒權(quán)、小米內(nèi)部的Hive使用的是Kerberos的方式來鑒權(quán)、小米內(nèi)部的Talos這種自研的消息隊(duì)列使用的是AKSK這種方式來進(jìn)行鑒權(quán)。

為了對(duì)上層用戶屏蔽底層不同系統(tǒng)的權(quán)限體系，小米在數(shù)據(jù)工場做了權(quán)限的代理，給上層用戶提供統(tǒng)一的權(quán)限管理能力。在數(shù)據(jù)工場引入了用戶空間這一概念，在用戶空間下包含不同的用戶，每一個(gè)用戶都具有不同的角色。owner角色是用戶空間的所有者，這個(gè)用戶空間下發(fā)生的所有賬單都會(huì)掛在 owner 所在的團(tuán)隊(duì)下面；Admin角色是用戶空間的管理者，可以增加或者是刪除用戶；Dev這個(gè)角色是普通的用戶，可以訪問這個(gè)用戶空間下所有的存儲(chǔ)和計(jì)算的引擎。用戶不需要針對(duì)每一個(gè)引擎使用不同的鑒權(quán)體系來進(jìn)行鑒權(quán)，而是由用戶空間進(jìn)行權(quán)限的代理，比如用戶需要在數(shù)據(jù)工場查詢某一個(gè) Doris 表，不需要自己傳入用戶名和密碼，員工 ID 就會(huì)和這個(gè)用戶空間進(jìn)行綁定，員工查詢的時(shí)候會(huì)由他所在的用戶空間去查詢自己所擁有的表的用戶名和密碼，代替用戶進(jìn)行鑒權(quán)。

如果有業(yè)務(wù)想接入Doris，就需要在數(shù)據(jù)工場提交建庫的申請(qǐng)，他需要選擇具體的集群名稱，描述自己的業(yè)務(wù)場景，提供查詢的延遲要求，提供預(yù)估的數(shù)據(jù)量。當(dāng)用戶提交了請(qǐng)求之后，Doris運(yùn)維的同學(xué)就會(huì)收到用戶提交的建庫請(qǐng)求，然后針對(duì)建庫請(qǐng)求里的場景信息，進(jìn)行審批，同時(shí)給用戶提供一些使用方面的指導(dǎo)。用戶完成建庫審批之后，就可以直接在對(duì)應(yīng)的集群上去做建表的操作了。建表的操作可以直接在數(shù)據(jù)工場來提交，可以通過DDL 的方式寫SQL來建表，也可以通過可視化的方式來選擇建表。用戶建好表之后就可以進(jìn)行數(shù)據(jù)的寫入和數(shù)據(jù)查詢了。

5、數(shù)據(jù)作業(yè)管理

小米的數(shù)據(jù)工場也提供了數(shù)據(jù)作業(yè)管理的能力，比如用戶數(shù)據(jù)需要從業(yè)務(wù)側(cè)寫到 Doris ，可以在數(shù)據(jù)工場直接提交數(shù)據(jù)寫入的作業(yè)，用戶數(shù)據(jù)會(huì)首先寫入到小米自研的消息隊(duì)列Talos里，再從 Talos寫到各個(gè)不同的系統(tǒng)里。

如果用戶的數(shù)據(jù)是離線數(shù)據(jù)，會(huì)先寫到Hive或者Iceberg里，如果是實(shí)時(shí)數(shù)據(jù)，就會(huì)經(jīng)過Flink或Spark做一些簡單的處理，再通過Stream Load的方式寫到Doris里面來。如果用戶的離線數(shù)據(jù)是在 Hive里，后期想把數(shù)據(jù)同步到 Doris 里進(jìn)行分析查詢，就可以直接在數(shù)據(jù)工場提交Broker Load作業(yè)，把Hive的表數(shù)據(jù)通過Broker Load 的方式寫入到Doris，也可以通過在數(shù)據(jù)工場寫 FlinkSQL或者是SparkSQL的方式，從 Hive或Iceberg里查數(shù)據(jù)，然后把查到的數(shù)據(jù)通過 Stream Load 的方式寫入到Doris里。FlinkSQL和SparkSQL底層其實(shí)是對(duì)Doris的Stream Load數(shù)據(jù)寫入方式進(jìn)行了封裝，通過Stream Load的方式把數(shù)據(jù)并發(fā)地寫入到Doris里面。

6、數(shù)據(jù)治理

小米針對(duì) Doris 也提供了數(shù)據(jù)治理的能力，包括數(shù)據(jù)安全管理，數(shù)據(jù)質(zhì)量管理，數(shù)據(jù)成本管理。

數(shù)據(jù)安全管理方面，我們會(huì)定期去掃 Doris 全量集群的庫和表，對(duì)每一個(gè)字段進(jìn)行安全等級(jí)的定義，對(duì)于隱私級(jí)別高的數(shù)據(jù)，需要做加密的存儲(chǔ)或者在網(wǎng)絡(luò)層面進(jìn)行隔離。

數(shù)據(jù)質(zhì)量管理，就是針對(duì)服務(wù)的可用性進(jìn)行持續(xù)地監(jiān)測(cè)和治理，對(duì)于一些可用性方面的隱患進(jìn)行持續(xù)跟進(jìn)，并與不同的用戶進(jìn)行 SLA 的確定和握手。

數(shù)據(jù)成本管理，主要是做數(shù)據(jù)的分層存儲(chǔ)以及數(shù)據(jù)生命周期的管理，把常用的數(shù)據(jù)分區(qū)保存在Doris上，把一些歷史的、不常訪問的分區(qū)從 Doris 里刪除，這些數(shù)據(jù)在Hive或者Iceberg上面是有備份的。有了這種數(shù)據(jù)生命周期的管理，能夠極大地降低Doris存儲(chǔ)的成本，通過數(shù)據(jù)治理來實(shí)現(xiàn)數(shù)據(jù)安全、服務(wù)可靠和成本降低的目標(biāo)。

三、小米用戶行為分析實(shí)踐

在第三部分，向大家介紹一下Doris在小米用戶行為分析場景的實(shí)踐。

1、小米用戶行為分析平臺(tái)

小米的用戶行為分析平臺(tái)是一個(gè)基于海量數(shù)據(jù)的一站式、全場景、多模型、多維度、自助式和可視化的分析平臺(tái)。平臺(tái)底層可以對(duì)接不同的業(yè)務(wù)數(shù)據(jù)，所以它是一個(gè)通用的分析平臺(tái)。在集團(tuán)內(nèi)部需要做用戶行為分析的業(yè)務(wù)都可以接入到這個(gè)平臺(tái)來進(jìn)行分析。這個(gè)平臺(tái)目前支持了事件分析、留存分析、漏斗分析、分布分析和路徑分析等分析方式。平臺(tái)用戶在小米用戶行為分析平臺(tái)根據(jù)分析需求配置查詢?nèi)蝿?wù)，生成SQL，并下發(fā)給Doris引擎執(zhí)行分析查詢，并將查詢結(jié)果在平臺(tái)進(jìn)行可視化展示。

2、事件模型

業(yè)務(wù)要做行為分析，數(shù)據(jù)源主要是來自于各個(gè)業(yè)務(wù)在網(wǎng)頁或者APP上面的埋點(diǎn)數(shù)據(jù)。用戶在網(wǎng)頁或者APP上面的各種操作都會(huì)抽象成一個(gè)事件的實(shí)體，這個(gè)事件實(shí)體稱為事件的模型。小米的用戶行為分析平臺(tái)主要是基于事件模型進(jìn)行建模。

事件模型主要包含五個(gè)要素，分別是Who、When、Where、How和What。Who 表示這次事件是誰觸發(fā)的，在 Doris 的表中會(huì)對(duì)應(yīng)一個(gè)字段，即用戶ID；When 表示事件觸發(fā)的時(shí)間，在Doris表里對(duì)應(yīng)的字段是一個(gè)時(shí)間戳，一般會(huì)精確到毫秒級(jí)別；Where表示事件觸發(fā)的地點(diǎn)，這個(gè)字段在Doris表里對(duì)應(yīng)的字段可能是通過 IP 解析出來的省份或城市；How表示這個(gè)事件是通過什么方式來觸發(fā)的，一般是 APP 的版本號(hào)或者瀏覽器，或者是用戶手機(jī)的信息等等；What表示這個(gè)事件到底是什么類型的事件，比如它是一個(gè) APP 的下載事件，或者是音樂的播放事件，或者是一個(gè)點(diǎn)擊事件等等。這就是我們進(jìn)行用戶行為分析的一個(gè)事件模型。

3、事件分析

在小米業(yè)務(wù)中，進(jìn)行用戶行為分析最多的方式是事件分析。事件分析也包含了三個(gè)要素，分別是事件、指標(biāo)和維度。平臺(tái)用戶可以針對(duì)不同的事件、指標(biāo)、維度去做靈活的組合。事件就是用戶在網(wǎng)頁或者是 APP 上面的行為，表示業(yè)務(wù)的過程。指標(biāo)是具體的數(shù)值，比如頁面的訪問量、訪問的時(shí)長等等。要做事件分析，就需要數(shù)據(jù)的實(shí)時(shí)采集，事件的實(shí)時(shí)分析，事件、維度和指標(biāo)的靈活選擇。通過事件分析能夠研究到某個(gè)行為發(fā)生對(duì)業(yè)務(wù)的影響以及影響的程度。

這里舉一個(gè)簡單的例子，在小米的用戶行為分析平臺(tái)，要做事件分析，需要選擇具體的分析數(shù)據(jù)源，這個(gè)數(shù)據(jù)源對(duì)應(yīng)了一張Doris表，然后需要選擇事件、維度和指標(biāo)。如上圖中所示，要做事件分析，先選擇事件分析的時(shí)間，比如5月30號(hào)的0點(diǎn)到5月30號(hào)的 23 點(diǎn)，針對(duì)某一個(gè) APP 按小時(shí)來統(tǒng)計(jì)下載這個(gè)事件觸發(fā)的用戶數(shù)。

我們?cè)谶@個(gè)頁面上執(zhí)行事件、維度和指標(biāo)的選擇之后，點(diǎn)擊查詢，系統(tǒng)中就會(huì)生成一條SQL，接著由平臺(tái)下發(fā)SQL到 Doris 系統(tǒng)進(jìn)行查詢，再把查詢結(jié)果返回給平臺(tái)，平臺(tái)再根據(jù)結(jié)果做可視化的展示。我們可以在圖中看到明顯的變化趨勢(shì)。

4、留存分析

小米的用戶行為分析平臺(tái)也支持做留存分析。留存分析是一種用來分析用戶參與情況和活躍程度的分析模型，能夠考察進(jìn)入初始行為的用戶中有多少人進(jìn)行了后續(xù)的行為。留存分析也是用來衡量產(chǎn)品對(duì)于用戶價(jià)值高低的重要方法。

為了支持留存分析，我們基于Apache Doris 的聚合函數(shù)的框架，開發(fā)了兩個(gè)聚合函數(shù)，分別用來計(jì)算單用戶的留存數(shù)據(jù)和全量用戶的留存數(shù)據(jù)。

單用戶的留存函數(shù)retention_info()，可以傳入以下幾個(gè)參數(shù)：第一個(gè)參數(shù)start_time，只有在這個(gè)時(shí)間之后發(fā)生的事件，我們才認(rèn)為是有效的事件。在這個(gè)時(shí)間點(diǎn)之前的事件都可以忽略；第二個(gè)參數(shù)是unit，是留存分析的時(shí)間單位，現(xiàn)在支持的主要是按天來做留存，所以這個(gè)參數(shù)可以傳入“day”的字符串；第三個(gè)參數(shù)就是event_time，每一個(gè)事件發(fā)生的時(shí)間可以通過這個(gè)參數(shù)傳進(jìn)去；第四個(gè)參數(shù)是 event_type，用來判斷傳入的這個(gè)事件是初次事件，還是留存事件。

前面圖片示例中的SQL，在內(nèi)層查詢里是按照distinct_id來做的分組，每一個(gè)distinct_id對(duì)應(yīng)的是一個(gè)用戶，所以內(nèi)層查詢能夠計(jì)算出每一個(gè)用戶的留存數(shù)據(jù)。我們?cè)谶@個(gè)例子里，可以看到傳給retention_info的實(shí)參，把view作為初次事件，buy作為留存事件，在傳入事件類型的時(shí)候，初次事件傳1，留存事件傳2，對(duì)于不屬于初次事件也不屬于留存事件的其它事件，傳入的就是0。通過內(nèi)層查詢我們就可以計(jì)算出每一個(gè)用戶實(shí)際的留存數(shù)據(jù)，再結(jié)合外層的查詢 retention_count()做一次聚合，最終計(jì)算出全量用戶的留存數(shù)據(jù)。

上圖是小米用戶行為分析平臺(tái)進(jìn)行留存分析的一個(gè)示例，也是需要選擇數(shù)據(jù)源，數(shù)據(jù)源對(duì)應(yīng)一個(gè)具體的業(yè)務(wù)，在Doris引擎里邊對(duì)應(yīng)了一張具體的表，我們需要在這個(gè)頁面上選擇初始行為是什么，后續(xù)行為是什么，以及留存的時(shí)間是7日的留存還是 14 日的留存，還要選擇留存分析的時(shí)間范圍。在這個(gè)實(shí)例中，我們選擇了最近 14 天，點(diǎn)擊查詢之后就會(huì)生成一條SQL，這條 SQL 就是我們前邊看到的，由我們自定義的兩個(gè)聚合函數(shù)來進(jìn)行留存分析的查詢，然后查詢下發(fā)到Doris引擎來執(zhí)行，查到的結(jié)果返回給用戶行為分析平臺(tái)，進(jìn)行可視化的展示。

不同顏色的線表示的是初始行為發(fā)生的日期，每一條線表示的是初始行為發(fā)生之后，在第 0 天、第1天、第2天、第3天分別的留存率。第 0 天就是發(fā)生了初始行為的當(dāng)天就發(fā)生了留存事件的用戶的留存率，第1天就表示初始行為發(fā)生日期的后一天發(fā)生了留存事件的用戶留存率。

5、漏斗分析

小米的用戶行為分析平臺(tái)支持漏斗分析。漏斗分析是一種用來分析用戶行為狀態(tài)變化從起點(diǎn)到終點(diǎn)各個(gè)階段用戶轉(zhuǎn)化率的分析模型。我們可以跟蹤漏斗的整個(gè)轉(zhuǎn)化過程，在這個(gè)轉(zhuǎn)化過程里，都是以用戶為單位，將用戶的步驟串聯(lián)起來，并不是把每一個(gè)步驟發(fā)生的次數(shù)做一次簡單的計(jì)數(shù)，需要確保進(jìn)入到后續(xù)步驟中的用戶一定是完成了所有的前序步驟。通過漏斗分析，可以了解用戶在漏斗的哪一步流失的最多，以及不同類型用戶轉(zhuǎn)化的情況。

上圖右側(cè)是一個(gè)簡單的漏斗分析模型。漏斗定義了三個(gè)步驟，有 100 個(gè)用戶觸發(fā)了步驟1，其中又有 60 個(gè)用戶觸發(fā)了步驟2，這60個(gè)用戶中又有 20 個(gè)用戶觸發(fā)了步驟3。我們可以看到，從步驟 1 到步驟 2 用戶的轉(zhuǎn)化率是60%，流失率是40%，從步驟 2 到步驟 3 用戶的轉(zhuǎn)化率是33%，流失率是67%。完整的漏斗，總體轉(zhuǎn)化率只有20%，總體的流失率達(dá)到了80%。

為了支持漏斗分析，我們基于Apache Doris 的聚合函數(shù)框架開發(fā)了兩個(gè)聚合函數(shù)，分別用來計(jì)算單個(gè)用戶在漏斗的各個(gè)階段的事件數(shù)據(jù)和全量用戶在漏斗各個(gè)階段的轉(zhuǎn)化率。計(jì)算單個(gè)用戶在漏斗各個(gè)階段的事件數(shù)據(jù)的聚合函數(shù)是 funnel_info()，在這個(gè)函數(shù)中我們可以傳入以下幾個(gè)參數(shù)，第一個(gè)參數(shù) start_time是我們要進(jìn)行漏斗分析的起始時(shí)間，在這個(gè)時(shí)間之后的事件才是有效的事件；第二個(gè)參數(shù)time_window，是有效窗口期，從發(fā)生了漏斗第一個(gè)步驟的事件開始，在這個(gè)窗口期內(nèi)完成了漏斗所有步驟的用戶，才算是完成了一次完整的轉(zhuǎn)化；第三個(gè)參數(shù)step是我們要傳入的事件是漏斗的哪一個(gè)步驟的事件；第四個(gè)參數(shù)是event_time是事件發(fā)生的具體時(shí)間。

圖中的 SQL就是用來做漏斗分析的，使用到了兩個(gè)聚合函數(shù)。內(nèi)層的查詢是按照distinct_id進(jìn)行了分組，每一個(gè)distinct_id對(duì)應(yīng)一個(gè)用戶。然后我們定義了一個(gè)漏斗，包含四個(gè)步驟，view作為第一個(gè)步驟， open 作為第二個(gè)步驟， buy 作為第三個(gè)步驟， use 作為第四個(gè)步驟。在內(nèi)層查詢里就可以計(jì)算出每一個(gè)用戶在漏斗各個(gè)階段的事件數(shù)據(jù)，然后將這些用戶的事件數(shù)據(jù)再交給外層查詢，由 funnel_count() 這個(gè)聚合函數(shù)進(jìn)行聚合分析，最終計(jì)算出全量用戶在漏斗各個(gè)階段的轉(zhuǎn)化情況。

要使用小米的用戶行為分析平臺(tái)進(jìn)行漏斗分析，首先需要?jiǎng)?chuàng)建漏斗。創(chuàng)建漏斗就需要選擇窗口期，用戶觸發(fā)完第一個(gè)步驟之后，只有在這個(gè)窗口期內(nèi)完成整個(gè)漏斗的所有步驟才算作是完成了一個(gè)完整的轉(zhuǎn)化。創(chuàng)建漏斗還需要定義漏斗的所有步驟，漏斗中至少會(huì)包含兩個(gè)步驟，每一個(gè)步驟對(duì)應(yīng)一個(gè)事件。創(chuàng)建好漏斗之后，就可以進(jìn)行漏斗分析了。

在小米的用戶行為分析平臺(tái)，首先需要選擇數(shù)據(jù)源，數(shù)據(jù)源對(duì)應(yīng)了一個(gè)具體的業(yè)務(wù)，在Doris中對(duì)應(yīng)了一張具體的表；然后可以選擇創(chuàng)建好的一個(gè)漏斗模型；接著再選擇時(shí)間，比如進(jìn)行最近7天的漏斗分析；最后點(diǎn)擊查詢，會(huì)生成一條SQL，SQL使用到了我們自定義的兩個(gè)聚合函數(shù)。平臺(tái)會(huì)把SQL下發(fā)給Doris引擎進(jìn)行查詢，平臺(tái)獲取到查詢結(jié)果之后做一些簡單的處理，然后進(jìn)行可視化展示。

在這個(gè)示例中，漏斗包含了四個(gè)步驟，分別是曝光、滑動(dòng)、下載和激活?？梢钥吹?，在第一個(gè)步驟和第二個(gè)步驟之間，用戶的轉(zhuǎn)化率是 26.51%；在第二個(gè)步驟和第三個(gè)步驟之間，用戶的轉(zhuǎn)化率是67%；在第三個(gè)和第四個(gè)步驟之間，用戶的轉(zhuǎn)化率是65%。用戶的總體轉(zhuǎn)化率是 11.68%。也可以看到在第一個(gè)步驟和第二個(gè)步驟之間，用戶的流失率是最高的。觸發(fā)了曝光事件之后，有很大一部分用戶沒有觸發(fā)滑動(dòng)這個(gè)事件，我們就需要根據(jù)計(jì)算出來的這些數(shù)據(jù)去具體地分析用戶在這兩個(gè)階段之間流失的具體原因，然后對(duì)我們的系統(tǒng)或者產(chǎn)品做進(jìn)一步的優(yōu)化。漏斗分析為我們的系統(tǒng)優(yōu)化提供了依據(jù)。

6、路徑分析

小米用戶行為分析平臺(tái)支持了路徑分析，用來分析用戶在使用產(chǎn)品時(shí)的路徑分布的情況，可以洞察到用戶全生命周期的行為特征，可以通過可視化用戶流全面來了解用戶整體的行為路徑。通過路徑分析，我們可以挖掘出用戶頻繁訪問的路徑有哪些，可以尋找用戶在單個(gè)環(huán)節(jié)流失的具體原因，為產(chǎn)品優(yōu)化提供依據(jù)。

為了支持路徑分析，我們也是基于Apache Doris 的聚合函數(shù)框架開發(fā)了兩個(gè)聚合函數(shù)，分別用來計(jì)算單個(gè)用戶的路徑統(tǒng)計(jì)數(shù)據(jù)和全量用戶的路徑統(tǒng)計(jì)數(shù)據(jù)。在第一個(gè)聚合函數(shù) session_del()中可以傳入以下參數(shù)：event_name是事件名稱；event_time 是事件發(fā)生的時(shí)間；session_interval 是事件的時(shí)間間隔，一個(gè)用戶連續(xù)的兩次事件發(fā)生的時(shí)間如果超過了我們指定的這個(gè)時(shí)間間隔，就需要把這兩個(gè)時(shí)間從中間切分開，不能把它們作為同一個(gè)路徑，而是分為兩個(gè)路徑；target_event_name 參數(shù)是目標(biāo)事件，一般會(huì)選擇一個(gè)具體的事件作為路徑的起始事件或者是終止事件，就是通過這個(gè)參數(shù)來設(shè)定的；參數(shù)is_reverse表示前面選擇的target_event_name是路徑的起始事件還是路徑的終止事件；參數(shù)max_level 定義的一個(gè)路徑最長包含的事件數(shù)量。

要去做路徑分析，一般會(huì)選擇一個(gè)時(shí)間范圍，很少對(duì)全量數(shù)據(jù)去做路徑分析。在SQL的內(nèi)層查詢里使用distinct_id進(jìn)行分組，每一個(gè) distinct _id對(duì)應(yīng)的一個(gè)用戶，通過內(nèi)層查詢就可以計(jì)算出單個(gè)用戶的路徑統(tǒng)計(jì)數(shù)據(jù)。然后將所有用戶的路徑統(tǒng)計(jì)數(shù)據(jù)再交給外層的查詢，通過 session_count ()這個(gè)聚合函數(shù)來做計(jì)算，得到全量用戶的統(tǒng)計(jì)數(shù)據(jù)。

7、分布分析

小米的用戶行為分析平臺(tái)也支持了分布分析，這種方式是指用戶在特定指標(biāo)下的頻次、總額等特征的結(jié)構(gòu)化的分段展現(xiàn)。通過分布分析可以洞察到數(shù)據(jù)的分布特征，判斷極端數(shù)值的占比，了解業(yè)務(wù)的健康程度。

上圖就是進(jìn)行分布分析的一個(gè)示例。首先選擇具體的數(shù)據(jù)源，數(shù)據(jù)源對(duì)應(yīng)一個(gè)具體的業(yè)務(wù)，也是在Doris引擎中對(duì)應(yīng)了一張具體的表；然后選擇分布分析的指標(biāo)和維度，比如時(shí)間選擇了2023年5月31號(hào)到6月1 號(hào)這兩天的時(shí)間范圍，我們要進(jìn)行的是瀏覽的總次數(shù)分布的計(jì)算；另外還需要選擇數(shù)據(jù)分布的區(qū)間，這里我們使用了默認(rèn)的區(qū)間，用戶也可以自定義區(qū)間。點(diǎn)擊查詢就會(huì)生成一條SQL，把 SQL 下發(fā)到Doris引擎進(jìn)行查詢，然后查詢的結(jié)果會(huì)由小米用戶行為分析平臺(tái)進(jìn)行一些簡單的處理，并進(jìn)行可視化的展現(xiàn)。

可以看到，在這兩天的瀏覽事件，總次數(shù)分布在 10-30 次這個(gè)區(qū)間里的用戶數(shù)是最多的，通過這種方式進(jìn)行分布分析。

四、未來規(guī)劃

最后簡單介紹一下小米未來在Doris方面的規(guī)劃。

首先，Doris的資源隔離能力不是很好，穩(wěn)定性還存在一些問題，公共集群上的業(yè)務(wù)會(huì)比較多，可能一個(gè)大查詢就會(huì)占滿整個(gè)集群資源，影響到其它業(yè)務(wù)的使用，所以我們希望重點(diǎn)提升 Doris 的穩(wěn)定性，并且在公共集群上支持大查詢的定位和攔截的能力。

另外，小米在部分業(yè)務(wù)上線了 Doris 的向量化版本，目前內(nèi)部使用的 Doris 向量化版本是1.1.2，用戶反饋總體查詢性能提升比較明顯，所以后期我們會(huì)推動(dòng)全量的 Doris 集群上線向量化版本。

其次，小米內(nèi)部對(duì)于 OLAP 分析的需求仍在增長，我們還會(huì)在小米手機(jī)、小米造車等一些核心的業(yè)務(wù)上來推廣Doris。

最后，目前小米內(nèi)部高性能 OLAP 查詢主要還是使用Doris，后面可能還會(huì)探索引入一些其它系統(tǒng)來解決不同業(yè)務(wù)場景的問題，我們需要盡可能對(duì)用戶屏蔽底層引擎的信息，盡量減少對(duì)業(yè)務(wù)的影響，所以我們還會(huì)探索統(tǒng)一SQL入口的解決方案。

關(guān)鍵詞：