以前，數(shù)據(jù)倉(cāng)庫(kù)通常由Apache Hive、MySQL、Elasticsearch和PostgreSQL組成。它們支持?jǐn)?shù)據(jù)倉(cāng)庫(kù)的數(shù)據(jù)計(jì)算和數(shù)據(jù)存儲(chǔ)層：

• 數(shù)據(jù)計(jì)算：Apache Hive作為計(jì)算引擎。
• 數(shù)據(jù)存儲(chǔ)：MySQL為DataBank、Tableau和我們面向客戶的應(yīng)用程序提供數(shù)據(jù)。Elasticsearch和PostgreSQL用于我們的DMP用戶分割系統(tǒng)：前者存儲(chǔ)用戶分析數(shù)據(jù)，后者存儲(chǔ)用戶組數(shù)據(jù)包。

不過(guò)，這樣會(huì)導(dǎo)致數(shù)據(jù)管道又長(zhǎng)又復(fù)雜，需要高維護(hù)成本，并且有損于開(kāi)發(fā)效率。此外，它們無(wú)法進(jìn)行特定查詢。因此，作為數(shù)據(jù)倉(cāng)庫(kù)的升級(jí)，可以用Apache Doris替換了其中大部分組件，這是一種基于MPP架構(gòu)的開(kāi)源分析型數(shù)據(jù)庫(kù)。

1. 數(shù)據(jù)流

這是數(shù)據(jù)倉(cāng)庫(kù)的側(cè)面視圖，可以從中看到數(shù)據(jù)如何流動(dòng)。

首先，MySQL的binlog將通過(guò)Canal被攝入到Kafka中，而用戶活動(dòng)日志將通過(guò)Apache Flume傳輸?shù)終afka中。在Kafka中，數(shù)據(jù)將被清理并組織成平面表，然后將轉(zhuǎn)換為聚合表。然后，數(shù)據(jù)將從Kafka傳遞到Apache Doris，它充當(dāng)存儲(chǔ)和計(jì)算引擎。

我們?cè)贏pache Doris中采用不同的數(shù)據(jù)模型來(lái)處理不同的場(chǎng)景：來(lái)自MySQL的數(shù)據(jù)將按照Unique模型進(jìn)行排列，日志數(shù)據(jù)將放在Duplicate模型中，而DWS層中的數(shù)據(jù)將合并在Aggregate模型中。

這就是Apache Doris如何取代我們數(shù)據(jù)倉(cāng)庫(kù)中Hive、Elasticsearch和PostgreSQL的角色。這種轉(zhuǎn)變?cè)陂_(kāi)發(fā)和維護(hù)方面節(jié)省了我們大量的工作量。它還使特定查詢成為可能，并使我們的用戶分割更加高效。

2. 臨時(shí)查詢

之前：每次提出新請(qǐng)求時(shí)，我們都會(huì)在Hive中開(kāi)發(fā)和測(cè)試數(shù)據(jù)模型，并在MySQL中編寫(xiě)調(diào)度任務(wù)，以便我們面向客戶的應(yīng)用程序平臺(tái)可以從MySQL讀取結(jié)果。這是一個(gè)復(fù)雜的過(guò)程，需要大量時(shí)間和開(kāi)發(fā)工作。

之后：由于Apache Doris擁有所有明細(xì)數(shù)據(jù)，因此每當(dāng)它面臨新請(qǐng)求時(shí)，它只需提取元數(shù)據(jù)并配置查詢條件即可。然后它就可以進(jìn)行特定查詢了。簡(jiǎn)而言之，它只需要低代碼配置即可響應(yīng)新請(qǐng)求。

3. 用戶分割

之前：基于元數(shù)據(jù)創(chuàng)建用戶分割任務(wù)后，相關(guān)的用戶ID將被寫(xiě)入PostgreSQL配置文件列表和MySQL任務(wù)列表中。同時(shí)，Elasticsearch將根據(jù)任務(wù)條件執(zhí)行查詢；在產(chǎn)生結(jié)果后，它將在任務(wù)列表中更新?tīng)顟B(tài)，并將用戶組位圖包寫(xiě)入PostgreSQL。（PostgreSQL插件能夠計(jì)算位圖的交集、并集和差集。）然后，PostgreSQL將為下游操作平臺(tái)提供用戶組數(shù)據(jù)包。

Elasticsearch和PostgreSQL中的表格無(wú)法重復(fù)使用，這使得這種架構(gòu)成本效益低。此外，我們必須預(yù)定義用戶標(biāo)簽，才能執(zhí)行新類(lèi)型的查詢。這減慢了速度。

之后：用戶ID僅會(huì)被寫(xiě)入MySQL任務(wù)列表中。對(duì)于第一次分割，Apache Doris將根據(jù)任務(wù)條件執(zhí)行特定查詢。在隨后的分割任務(wù)中，Apache Doris將執(zhí)行微批量滾動(dòng)，并計(jì)算與先前生成的用戶組數(shù)據(jù)包相比的差異集，并通知下游平臺(tái)進(jìn)行任何更新。（這是由Apache Doris中的位圖函數(shù)實(shí)現(xiàn)的。）

在這個(gè)以Doris為中心的用戶分割過(guò)程中，我們不必預(yù)定義新標(biāo)簽。相反，標(biāo)簽可以根據(jù)任務(wù)條件自動(dòng)生成。處理管道具有靈活性，可以使我們基于用戶組進(jìn)行A/B測(cè)試更加容易。此外，由于明細(xì)數(shù)據(jù)和用戶組數(shù)據(jù)包都在Apache Doris中，因此我們不必關(guān)注多個(gè)組件之間的讀寫(xiě)復(fù)雜性。

4. 提高用戶分組速度的技巧，可提高70％

由于風(fēng)險(xiǎn)規(guī)避原因，隨機(jī)生成user_id是許多公司的選擇，但這會(huì)在用戶組數(shù)據(jù)包中產(chǎn)生稀疏和非連續(xù)的用戶ID。在用戶分組中使用這些ID，我們必須忍受等待位圖生成的漫長(zhǎng)時(shí)間。

為了解決這個(gè)問(wèn)題，我們?yōu)檫@些用戶ID創(chuàng)建了連續(xù)和密集的映射。通過(guò)這種方式，我們將用戶分組延遲降低了70％。

5. 示例

步驟1：創(chuàng)建用戶ID映射表

我們采用唯一模型用于用戶ID映射表，其中用戶ID是唯一鍵。映射的連續(xù)ID通常從1開(kāi)始嚴(yán)格遞增。

步驟2：創(chuàng)建用戶組表：

我們采用聚合模型用于用戶組表，其中用戶標(biāo)簽作為聚合鍵。

假設(shè)我們需要挑選出ID在0到2000000之間的用戶。

以下代碼段分別使用非連續(xù)（tyc_user_id）和連續(xù)（tyc_user_id_continuous）用戶ID進(jìn)行用戶分組。它們的響應(yīng)時(shí)間之間存在很大差距：

• 非連續(xù)用戶ID：1843ms
• 連續(xù)用戶ID：543ms

6. 總結(jié)

我們?cè)贏pache Doris中擁有2個(gè)容納數(shù)十TB數(shù)據(jù)的集群，每天幾乎有10億行新數(shù)據(jù)流入。隨著數(shù)據(jù)量的擴(kuò)大，我們?cè)?jīng)目睹數(shù)據(jù)攝入速度急劇下降。但是，在使用Apache Doris升級(jí)數(shù)據(jù)倉(cāng)庫(kù)后，我們將數(shù)據(jù)寫(xiě)入效率提高了75％。此外，在結(jié)果集小于500萬(wàn)的用戶分組中，它能夠在毫秒內(nèi)響應(yīng)。最重要的是，我們的數(shù)據(jù)倉(cāng)庫(kù)對(duì)開(kāi)發(fā)人員和維護(hù)人員更加簡(jiǎn)單和友好。