以前，數據倉庫通常由Apache Hive、MySQL、Elasticsearch和PostgreSQL組成。它們支持數據倉庫的數據計算和數據存儲層：

• 數據計算：Apache Hive作為計算引擎。
• 數據存儲：MySQL為DataBank、Tableau和我們面向客戶的應用程序提供數據。Elasticsearch和PostgreSQL用于我們的DMP用戶分割系統：前者存儲用戶分析數據，后者存儲用戶組數據包。

不過，這樣會導致數據管道又長又復雜，需要高維護成本，并且有損于開發效率。此外，它們無法進行特定查詢。因此，作為數據倉庫的升級，可以用Apache Doris替換了其中大部分組件，這是一種基于MPP架構的開源分析型數據庫。

1. 數據流

這是數據倉庫的側面視圖，可以從中看到數據如何流動。

首先，MySQL的binlog將通過Canal被攝入到Kafka中，而用戶活動日志將通過Apache Flume傳輸到Kafka中。在Kafka中，數據將被清理并組織成平面表，然后將轉換為聚合表。然后，數據將從Kafka傳遞到Apache Doris，它充當存儲和計算引擎。

我們在Apache Doris中采用不同的數據模型來處理不同的場景：來自MySQL的數據將按照Unique模型進行排列，日志數據將放在Duplicate模型中，而DWS層中的數據將合并在Aggregate模型中。

這就是Apache Doris如何取代我們數據倉庫中Hive、Elasticsearch和PostgreSQL的角色。這種轉變在開發和維護方面節省了我們大量的工作量。它還使特定查詢成為可能，并使我們的用戶分割更加高效。

2. 臨時查詢

之前：每次提出新請求時，我們都會在Hive中開發和測試數據模型，并在MySQL中編寫調度任務，以便我們面向客戶的應用程序平臺可以從MySQL讀取結果。這是一個復雜的過程，需要大量時間和開發工作。

之后：由于Apache Doris擁有所有明細數據，因此每當它面臨新請求時，它只需提取元數據并配置查詢條件即可。然后它就可以進行特定查詢了。簡而言之，它只需要低代碼配置即可響應新請求。

3. 用戶分割

之前：基于元數據創建用戶分割任務后，相關的用戶ID將被寫入PostgreSQL配置文件列表和MySQL任務列表中。同時，Elasticsearch將根據任務條件執行查詢；在產生結果后，它將在任務列表中更新狀態，并將用戶組位圖包寫入PostgreSQL。（PostgreSQL插件能夠計算位圖的交集、并集和差集。）然后，PostgreSQL將為下游操作平臺提供用戶組數據包。

Elasticsearch和PostgreSQL中的表格無法重復使用，這使得這種架構成本效益低。此外，我們必須預定義用戶標簽，才能執行新類型的查詢。這減慢了速度。

之后：用戶ID僅會被寫入MySQL任務列表中。對于第一次分割，Apache Doris將根據任務條件執行特定查詢。在隨后的分割任務中，Apache Doris將執行微批量滾動，并計算與先前生成的用戶組數據包相比的差異集，并通知下游平臺進行任何更新。（這是由Apache Doris中的位圖函數實現的。）

在這個以Doris為中心的用戶分割過程中，我們不必預定義新標簽。相反，標簽可以根據任務條件自動生成。處理管道具有靈活性，可以使我們基于用戶組進行A/B測試更加容易。此外，由于明細數據和用戶組數據包都在Apache Doris中，因此我們不必關注多個組件之間的讀寫復雜性。

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

由于風險規避原因，隨機生成user_id是許多公司的選擇，但這會在用戶組數據包中產生稀疏和非連續的用戶ID。在用戶分組中使用這些ID，我們必須忍受等待位圖生成的漫長時間。

為了解決這個問題，我們為這些用戶ID創建了連續和密集的映射。通過這種方式，我們將用戶分組延遲降低了70％。

5. 示例

步驟1：創建用戶ID映射表

我們采用唯一模型用于用戶ID映射表，其中用戶ID是唯一鍵。映射的連續ID通常從1開始嚴格遞增。

步驟2：創建用戶組表：

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

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

以下代碼段分別使用非連續（tyc_user_id）和連續（tyc_user_id_continuous）用戶ID進行用戶分組。它們的響應時間之間存在很大差距：

• 非連續用戶ID：1843ms
• 連續用戶ID：543ms

6. 總結

我們在Apache Doris中擁有2個容納數十TB數據的集群，每天幾乎有10億行新數據流入。隨著數據量的擴大，我們曾經目睹數據攝入速度急劇下降。但是，在使用Apache Doris升級數據倉庫后，我們將數據寫入效率提高了75％。此外，在結果集小于500萬的用戶分組中，它能夠在毫秒內響應。最重要的是，我們的數據倉庫對開發人員和維護人員更加簡單和友好。