以前，數(shù)據(jù)倉庫通常由Apache Hive、MySQL、Elasticsearch和PostgreSQL組成。它們支持?jǐn)?shù)據(jù)倉庫的數(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ù)包。
不過，這樣會(huì)導(dǎo)致數(shù)據(jù)管道又長又復(fù)雜，需要高維護(hù)成本，并且有損于開發(fā)效率。此外，它們無法進(jìn)行特定查詢。因此，作為數(shù)據(jù)倉庫的升級(jí)，可以用Apache Doris替換了其中大部分組件，這是一種基于MPP架構(gòu)的開源分析型數(shù)據(jù)庫。
1. 數(shù)據(jù)流
這是數(shù)據(jù)倉庫的側(cè)面視圖，可以從中看到數(shù)據(jù)如何流動(dòng)。
首先，MySQL的binlog將通過Canal被攝入到Kafka中，而用戶活動(dòng)日志將通過Apache Flume傳輸?shù)終afka中。在Kafka中，數(shù)據(jù)將被清理并組織成平面表，然后將轉(zhuǎn)換為聚合表。然后，數(shù)據(jù)將從Kafka傳遞到Apache Doris，它充當(dāng)存儲(chǔ)和計(jì)算引擎。
我們在Apache Doris中采用不同的數(shù)據(jù)模型來處理不同的場景：來自MySQL的數(shù)據(jù)將按照Unique模型進(jìn)行排列，日志數(shù)據(jù)將放在Duplicate模型中，而DWS層中的數(shù)據(jù)將合并在Aggregate模型中。
這就是Apache Doris如何取代我們數(shù)據(jù)倉庫中Hive、Elasticsearch和PostgreSQL的角色。這種轉(zhuǎn)變在開發(fā)和維護(hù)方面節(jié)省了我們大量的工作量。它還使特定查詢成為可能，并使我們的用戶分割更加高效。
2. 臨時(shí)查詢
之前：每次提出新請(qǐng)求時(shí)，我們都會(huì)在Hive中開發(fā)和測試數(shù)據(jù)模型，并在MySQL中編寫調(diào)度任務(wù)，以便我們面向客戶的應(yīng)用程序平臺(tái)可以從MySQL讀取結(jié)果。這是一個(gè)復(fù)雜的過程，需要大量時(shí)間和開發(fā)工作。
之后：由于Apache Doris擁有所有明細(xì)數(shù)據(jù)，因此每當(dāng)它面臨新請(qǐng)求時(shí)，它只需提取元數(shù)據(jù)并配置查詢條件即可。然后它就可以進(jìn)行特定查詢了。簡而言之，它只需要低代碼配置即可響應(yīng)新請(qǐng)求。
3. 用戶分割
之前：基于元數(shù)據(jù)創(chuàng)建用戶分割任務(wù)后，相關(guān)的用戶ID將被寫入PostgreSQL配置文件列表和MySQL任務(wù)列表中。同時(shí)，Elasticsearch將根據(jù)任務(wù)條件執(zhí)行查詢；在產(chǎn)生結(jié)果后，它將在任務(wù)列表中更新狀態(tài)，并將用戶組位圖包寫入PostgreSQL。（PostgreSQL插件能夠計(jì)算位圖的交集、并集和差集。）然后，PostgreSQL將為下游操作平臺(tái)提供用戶組數(shù)據(jù)包。
Elasticsearch和PostgreSQL中的表格無法重復(fù)使用，這使得這種架構(gòu)成本效益低。此外，我們必須預(yù)定義用戶標(biāo)簽，才能執(zhí)行新類型的查詢。這減慢了速度。
之后：用戶ID僅會(huì)被寫入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為中心的用戶分割過程中，我們不必預(yù)定義新標(biāo)簽。相反，標(biāo)簽可以根據(jù)任務(wù)條件自動(dòng)生成。處理管道具有靈活性，可以使我們基于用戶組進(jìn)行A/B測試更加容易。此外，由于明細(xì)數(shù)據(jù)和用戶組數(shù)據(jù)包都在Apache Doris中，因此我們不必關(guān)注多個(gè)組件之間的讀寫復(fù)雜性。
4. 提高用戶分組速度的技巧，可提高70％
由于風(fēng)險(xiǎn)規(guī)避原因，隨機(jī)生成user_id是許多公司的選擇，但這會(huì)在用戶組數(shù)據(jù)包中產(chǎn)生稀疏和非連續(xù)的用戶ID。在用戶分組中使用這些ID，我們必須忍受等待位圖生成的漫長時(shí)間。
為了解決這個(gè)問題，我們?yōu)檫@些用戶ID創(chuàng)建了連續(xù)和密集的映射。通過這種方式，我們將用戶分組延遲降低了70％。
5. 示例
步驟1：創(chuàng)建用戶ID映射表
我們采用唯一模型用于用戶ID映射表，其中用戶ID是唯一鍵。映射的連續(xù)ID通常從1開始嚴(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é)
我們在Apache Doris中擁有2個(gè)容納數(shù)十TB數(shù)據(jù)的集群，每天幾乎有10億行新數(shù)據(jù)流入。隨著數(shù)據(jù)量的擴(kuò)大，我們曾經(jīng)目睹數(shù)據(jù)攝入速度急劇下降。但是，在使用Apache Doris升級(jí)數(shù)據(jù)倉庫后，我們將數(shù)據(jù)寫入效率提高了75％。此外，在結(jié)果集小于500萬的用戶分組中，它能夠在毫秒內(nèi)響應(yīng)。最重要的是，我們的數(shù)據(jù)倉庫對(duì)開發(fā)人員和維護(hù)人員更加簡單和友好。
