導(dǎo)讀：極越是高端智能汽車機(jī)器人品牌，基于領(lǐng)先的百度 AI 能力和吉利 SEA 浩瀚架構(gòu)生態(tài)賦能，致力于打造智能化領(lǐng)先的汽車機(jī)器人，以高階智駕、智艙產(chǎn)品和創(chuàng)新數(shù)字化服務(wù)，為用戶創(chuàng)造標(biāo)桿級智能科技出行體驗。隨著全球汽車行業(yè)向電動化、智能化加速轉(zhuǎn)型，對車端數(shù)據(jù)實時精準(zhǔn)響應(yīng)的需求也越來越高，經(jīng)過對比選型，極越汽車選擇 Apache Doris 作為實時數(shù)倉底座來升級 BI 分析平臺和用戶畫像系統(tǒng)。截至目前，基于 Apache Doris 開發(fā)的數(shù)據(jù)智能服務(wù)體系 2.0 已經(jīng)部署在多套生產(chǎn)集群，其優(yōu)秀的讀寫性能、低成本數(shù)據(jù)接入流程和豐富的大數(shù)據(jù)生態(tài)支持，既提升了車端、云端的數(shù)據(jù)處理效率，又簡化實時數(shù)據(jù)流架構(gòu)，還能一定程度上節(jié)約計算和存儲成本、簡化運(yùn)維。

近年來，全球汽車行業(yè)向電動化、智能化加速轉(zhuǎn)型，隨著技術(shù)的不斷迭代，智能化能力已成為行業(yè)頭部公司間互相比拼的重點(diǎn)。2023 年以來，中國汽車市場的新能源滲透率更是進(jìn)一步提升，智能駕駛已成為影響用戶購車的核心因素之一。極越汽車作為高端智能汽車機(jī)器人品牌，致力于打造智能化領(lǐng)先的汽車機(jī)器人，以高階智駕、智艙產(chǎn)品和創(chuàng)新數(shù)字化服務(wù)，為用戶創(chuàng)造標(biāo)桿級智能科技出行體驗。

與互聯(lián)網(wǎng)行業(yè)相比，新能源汽車的數(shù)據(jù)來源更豐富，數(shù)據(jù)場景也更加多樣化。為了滿足客戶端、車端、門店端等海量數(shù)據(jù)實時分析的需求，以數(shù)據(jù)驅(qū)動汽車智能化的演進(jìn)，極越汽車選擇 Apache Doris 作為數(shù)據(jù)底座來升級整體數(shù)據(jù)智能服務(wù)體系。截至目前，Apache Doris 已經(jīng)在實時數(shù)倉、BI 多維分析、用戶畫像、車云中心（Serving）等多個業(yè)務(wù)場景中落地。

業(yè)務(wù)挑戰(zhàn)和訴求

在實際運(yùn)營過程中，新能源汽車每天都會產(chǎn)生海量的、對汽車全生命周期至關(guān)重要的復(fù)雜數(shù)據(jù)，這些數(shù)據(jù)來源主要包括：APP 與小程序、門店與工廠、車端數(shù)據(jù)、云端數(shù)據(jù)等。

為了充分發(fā)揮數(shù)據(jù)背后的價值，我們構(gòu)建了多個業(yè)務(wù)平臺來響應(yīng)一線業(yè)務(wù)人員和經(jīng)營管理者的分析系統(tǒng)，例如統(tǒng)一的實時/離線數(shù)據(jù)倉庫體系、BI 多維分析引擎、用戶畫像 CDP 平臺以及車輛中心云平臺等。豐富多樣的數(shù)據(jù)服務(wù)場景和高時效性的業(yè)務(wù)要求，其中所依賴的核心便是 OLAP 數(shù)據(jù)庫，因此我們希望其具備以下能力：

• 支持多種數(shù)據(jù)分析場景：例如對于 APP 與小程序、門店與工廠以及車端等各種來源的復(fù)雜數(shù)據(jù)都能提供高效的數(shù)據(jù)支持，為業(yè)務(wù)決策賦能。
• 實時數(shù)據(jù)分析響應(yīng)：在數(shù)據(jù)實時寫入和更新的同時，支持快速及時的查詢響應(yīng)；
• 運(yùn)維難度低：生態(tài)獨(dú)立，不依賴其他技術(shù)棧，運(yùn)維簡單且利于上手。

OLAP 調(diào)研與技術(shù)選型

在選型調(diào)研階段，我們深入考察了 Apache Doris、ClickHouse、Apache Kylin 和某云廠商產(chǎn)品 H 這四款 OLAP 數(shù)據(jù)庫產(chǎn)品，主要從數(shù)據(jù)實時更新能力、多維數(shù)據(jù)分析和 JOIN 性能三個方面進(jìn)行考察。

考慮實時數(shù)據(jù)更新能力和 Join 性能的高優(yōu)先級需求，我們首先排除了 ClickHouse 和 Apache Kylin，再對比與某云廠商的產(chǎn)品，由于其產(chǎn)品非開源且產(chǎn)品生態(tài)較為封閉，綜合對比下來 Apache Doris 與我們的目標(biāo)訴求高度匹配：

• 多維數(shù)據(jù)分析能力強(qiáng)：在系統(tǒng)并發(fā)、Join 性能以及多個功能的易用性方面皆滿足我們對數(shù)倉高效數(shù)據(jù)處理的要求；
• 數(shù)據(jù)更新及時：支持批次事務(wù)更新，有效實現(xiàn)數(shù)據(jù)的實時采集、處理和分析；
• 運(yùn)維保障：可視化運(yùn)維管控與可視化查詢，運(yùn)維簡單，且官網(wǎng)中英文檔較完善，易于上手。同時，由于 Doris 不依賴其他大數(shù)據(jù)生態(tài)，在生態(tài)發(fā)展方面更加獨(dú)立，使用起來更加靈活。

實時數(shù)倉建設(shè)與實踐優(yōu)化

在引入 Apache Doris 之前，過去的實時數(shù)倉基于 Kafka 流式數(shù)據(jù)構(gòu)建。由于 Kafka 對海量數(shù)據(jù)的存儲能力比較有限，限制了長時間歷史數(shù)據(jù)的查詢和回溯。另外加工好的數(shù)據(jù)需要存放在不同的查詢引擎，導(dǎo)致數(shù)據(jù)加工的成本比較高，且難以支持復(fù)雜的即席查詢。

以 Apache Doris 升級實時數(shù)據(jù)倉庫，可以充分有效解決我們目前面臨的問題。因此，我們基于 Apache Doris 打造了統(tǒng)一的離線/實時數(shù)倉體系，實時響應(yīng)業(yè)務(wù)需求。下圖是引入 Apache Doris 后的實時數(shù)倉架構(gòu)圖，具體工作機(jī)制如下：

• ODS 貼源層：主要用于存放未經(jīng)處理的原始數(shù)據(jù)，通過 Flume 等實時采集工具，將數(shù)據(jù)湖中未經(jīng)處理的原始日志以及告警數(shù)據(jù)統(tǒng)一匯集到 ODS 層，同時完全相同的數(shù)據(jù)也會被存入 HDFS 中一份，作為原始數(shù)據(jù)核查依據(jù)或進(jìn)行數(shù)據(jù)回放。
• DWD 明細(xì)層：該層為事實表，數(shù)據(jù)通過 Flink 計算引擎實時對生產(chǎn)數(shù)據(jù)及字段進(jìn)行清洗、標(biāo)準(zhǔn)化、回填、脫敏之后寫入 Kafka 。Kafka 中的數(shù)據(jù)還會對接到 Doris 中，以支持明細(xì)日志數(shù)據(jù)回溯查詢、實時數(shù)據(jù)分析及其他業(yè)務(wù)。
• DWS 匯總層：以 DWD 明細(xì)層數(shù)據(jù)為基礎(chǔ)，通過動態(tài)規(guī)則引擎進(jìn)行細(xì)粒度的聚合分析，為后續(xù)業(yè)務(wù)查詢和 OLAP 分析做準(zhǔn)備，同時大部分建模分析的結(jié)果也集中在 DWS 層。
• ADS 應(yīng)用層：該層主要使用 Doris 的 Aggregate Key 模型和 Unique Key 模型對以上三層的數(shù)據(jù)進(jìn)行自動聚合或自動更新，以滿足業(yè)務(wù)場景的具體分析需求。
• DIM 維度層：主要存放維度數(shù)據(jù)，例如客戶端數(shù)據(jù)、門店數(shù)據(jù)、車機(jī)數(shù)據(jù)、活動數(shù)據(jù)等，存放的數(shù)據(jù)最終將結(jié)合具體業(yè)務(wù)場景來使用。

初期階段，我們也遇到了一些性能方面的挑戰(zhàn)。下面結(jié)合兩個具體應(yīng)用場景，分享我們在使用過程中的性能調(diào)優(yōu)經(jīng)驗。

01 高頻 DDL Alter 優(yōu)化

在離線/實時數(shù)倉 ETL 場景，每天凌晨 5 點(diǎn)常常出現(xiàn) Doris DDL 頻繁操作失敗的情況。經(jīng)過排查，原因如下：

1. 線程池在重建過程中，默認(rèn)的異步線程返回時間設(shè)置不當(dāng)，導(dǎo)致超時。
2. 跟蹤源碼發(fā)現(xiàn)，由于當(dāng)前線程池規(guī)模相對較小，當(dāng)多個 DDL 操作并行執(zhí)行時線程資源不足，引發(fā)了線程等待，最終超時失敗。

針對上述問題，我們調(diào)整了以下線程池參數(shù)：

• 單個 Tablet 超時參數(shù)從 1 改為 2：

  tablet_create_timeout_second = 2

• 創(chuàng)建 tablet 線程池參數(shù)，由 3 調(diào)整為 6：

  create_tablet_worker_count = 6

• 修改 tablet 線程池參數(shù)，由 3 調(diào)整為 6：

  alter_tablet_worker_count = 6

調(diào)優(yōu)后，操作失敗率顯著改善。相比于之前 90% 的失敗率，現(xiàn)在的失敗率僅有 10% 左右。

調(diào)整以上參數(shù)后，DDL 高頻操作失敗的問題暫時得以解決，但進(jìn)一步了解業(yè)務(wù)場景后發(fā)現(xiàn)，為了將離線數(shù)據(jù)導(dǎo)入到 Doris ，前期我們進(jìn)行了 Truncate 表操作和添加 Partition 操作，其中 Truncate 表操作會造成所有的 Tablet 重建，這個操作消耗了大量的內(nèi)存，而且存在數(shù)據(jù) GAP 時間（在 GAP 時間內(nèi)，用戶查詢數(shù)據(jù)時得到的結(jié)果并非最新數(shù)據(jù)）。

針對這種場景，我們在 Doris 中有一個推薦的最佳實踐方案：

• 非分區(qū)表：創(chuàng)建原表對應(yīng)的臨時表，寫入數(shù)據(jù)到臨時表中，然后進(jìn)行表替換操作（表替換操作是原子性的）；

• 分區(qū)表：創(chuàng)建原表分區(qū)對應(yīng)的臨時分區(qū)，寫入數(shù)據(jù)到臨時分區(qū)中，然后進(jìn)行分區(qū)替換操作（分區(qū)替換是原子性的）。

02 Stream Load 寫入性能調(diào)優(yōu)

智能汽車在行駛過程中，系統(tǒng)會對驅(qū)動電機(jī)、能耗情況、通訊定位等數(shù)據(jù)全面監(jiān)測，因此在離線和實時場景下，都需要寫入大規(guī)模車輛數(shù)據(jù)。

為了提升 Stream Load 的寫入性能，我們進(jìn)行了多處參數(shù)調(diào)優(yōu)：

• 提升單磁盤 Compaction 的頻率，將任務(wù)線程由 2 增加到 4：

  compaction_task_num_per_disk = 4

• 增加 Compaction 線程總數(shù)，從默認(rèn) 10 增加到 16：

  max_compaction_threads compaction = 16

• 減少 Compaction 合并任務(wù)量：

  max_cumulative_compaction_num_singleton_deltas = 500
  max_tablet_version_num = 1500
  min_compaction_failure_interval_sec = 5
  

• 更換海量日志存儲場景修改表的壓縮方式，將數(shù)據(jù)壓縮算法從默認(rèn)的 lz4 換成 zstd。在原 lz4 壓縮格式下 230GB 的數(shù)據(jù)，改為 zstd 后只占用 150GB 的存儲空間，壓縮率提升了 35 %：

  "compression" = "zstd"

另外，在大批量 Stream Load 導(dǎo)入的過程中容易遇到 -235 的問題，因為我們加入了 Stream Load 寫入保護(hù)機(jī)制，具體為：

• 擁塞避免：當(dāng) Stream Load 寫入數(shù)據(jù)返回 -235 異常時，寫入線程進(jìn)行休眠，初次休眠時間為 1 秒（后續(xù)每次休眠時間是上次休眠時間的 2 倍），等待休眠時間結(jié)束后再次重試寫入，如果仍然失敗則繼續(xù)休眠，直至達(dá)到設(shè)置的休眠上限后（總休眠時間或者總次數(shù)），才將該次 Stream Load 寫入請求置為失敗。

• 慢恢復(fù)：當(dāng) Stream Load 寫入數(shù)據(jù)返回 -235 異常時，如果在休眠之后的某次重試成功了，此時為了避免 Doris 有過大的寫入壓力，不直接進(jìn)行下一次的 Stream Load 寫入請求，而是將寫入休眠時間進(jìn)行指數(shù)級減少，直至 Doris 恢復(fù)正常寫入速度。

這兩個寫入保護(hù)機(jī)制的引用，有效緩解了 Doris 寫入大量數(shù)據(jù)時的壓力，使得數(shù)據(jù)導(dǎo)入場景的任務(wù)成功率和吞吐率提升了 50%。

BI 分析平臺實踐及優(yōu)化

BI 分析平臺涵蓋豐富的汽車數(shù)據(jù)業(yè)務(wù)場景，包括經(jīng)營決策分析、市場趨勢分析、銷量預(yù)測、增長分析等。在數(shù)據(jù)分析模塊，我們往往傾向于使用可視化查詢分析引擎，為業(yè)務(wù)決策賦能。

01 早期業(yè)務(wù)痛點(diǎn)

上圖是 1.0 平臺架構(gòu)圖，早期的業(yè)務(wù)十分依賴第三方引擎的數(shù)據(jù)處理能力， 由于構(gòu)建成熟度低，系統(tǒng)性能瓶頸很快暴露出來，對業(yè)務(wù)支持帶來嚴(yán)峻挑戰(zhàn)：

• 訴求響應(yīng)不夠及時：第三方廠商查詢引擎在客戶訪問量較大情況下，響應(yīng)速率明顯下降，無法滿足智能汽車對實時數(shù)據(jù)分析處理的要求。
• 數(shù)據(jù)安全風(fēng)險高：用戶數(shù)據(jù)與車端數(shù)據(jù)面臨信息泄露的風(fēng)險，數(shù)據(jù)安全治理的問題亟待解決。
• 使用成本高：隨著多方位的分析業(yè)務(wù)數(shù)據(jù)量增長，第三方產(chǎn)品的使用成本也越來越高
• 分析局限：對某些特殊場景的支持不夠友好
• 技術(shù)兼容難度大：與內(nèi)部的其他系統(tǒng)的技術(shù)兼容性差，數(shù)據(jù)互通面臨龐大的開發(fā)成本。

02 BI 分析平臺 2.0

面對雙向復(fù)雜的數(shù)據(jù)架構(gòu)環(huán)境，首要挑戰(zhàn)是數(shù)據(jù)實時響應(yīng)的壓力，我們需要確保 BI 分析平臺能夠迅速、準(zhǔn)確地應(yīng)對各種車端及用戶端數(shù)據(jù)變化，這也促使我們開始了 BI 分析平臺 2.0 的改造計劃。在整個 BI 分析平臺的改造過程中，我們充分將業(yè)務(wù)需求與 Apache Doris 的各項優(yōu)勢相結(jié)合：

• 查詢性能突出：Apache Doris 能支持多種復(fù)雜的業(yè)務(wù)場景，特別是在需要快速查詢響應(yīng)的場景中表現(xiàn)突出。例如在車端信號數(shù)據(jù)的實時響應(yīng)中，能夠?qū)崟r接收和處理來自車輛的各種信號數(shù)據(jù)，為業(yè)務(wù)決策提供實時、準(zhǔn)確的數(shù)據(jù)支持。
• 實時響應(yīng)：在某些場景中對數(shù)據(jù)的時效性有著極其敏感的需求，以預(yù)知車輛拋錨情況為例，能夠更快分析車輛運(yùn)行數(shù)據(jù)、及時發(fā)現(xiàn)潛在的故障隱患、觸發(fā)相應(yīng)的預(yù)警機(jī)制，并規(guī)劃相應(yīng)的救援安排。
• 技術(shù)棧統(tǒng)一：原本實時和離線數(shù)據(jù)分別由多個不同數(shù)據(jù)庫進(jìn)行存儲，在升級后通過 Apache Doris 實現(xiàn)離線數(shù)據(jù)和實時數(shù)據(jù)的統(tǒng)一處理，實現(xiàn)技術(shù)棧的統(tǒng)一。
• 成本節(jié)約：減少部署多個系統(tǒng)帶來的硬件成本，且自身的易用性和可維護(hù)性也降低了運(yùn)維成本。

基于 Apache Doris 我們重新構(gòu)造了 BI 分析平臺 2.0，在數(shù)據(jù)處理、分析應(yīng)用等方面進(jìn)行了架構(gòu)升級。在重構(gòu)過程中，我們也積累了一些 Doris 性能優(yōu)化的經(jīng)驗，與大家一同分享。

03 內(nèi)存占用優(yōu)化

在使用 BI 分析 2.0 平臺時，部分用戶反饋某頁面圖標(biāo)無法展現(xiàn)，此時 Doris BE 內(nèi)存占用率高達(dá) 99%，導(dǎo)致其他查詢失敗。經(jīng)排查，某個 SQL 掃描了全表，而 Doris Session 級別和 Global 級別的內(nèi)存保護(hù)機(jī)制均未生效。

進(jìn)一步排查發(fā)現(xiàn)，MemTracker 的兩個參數(shù) mem_tracker_cancel_query 、proc_meminfo_cancel_query 默認(rèn)值都是 False ，當(dāng)內(nèi)存超過一定限制時攔截?zé)o法生效；改為 true 后，內(nèi)存保護(hù)機(jī)制正常運(yùn)行，問題得以解決。

1.2.x 版本后，這兩個參數(shù)默認(rèn)值已調(diào)整為 true。

點(diǎn)擊 Memtracker 參考詳情功能解析

04 BE Crash 問題定位

2.0 平臺的某單個 Query 異常導(dǎo)致 BE 崩潰，這類問題需要第一時間定位到災(zāi)難場景，以便進(jìn)行診斷與快速修復(fù)。在使用過程中，我們遇到了兩個未產(chǎn)生 Query Id 的場景，審計日志、be.INFO 日志中都未發(fā)現(xiàn)目標(biāo) Query 。

于是我們嘗試以下 2 個方法進(jìn)行問題定位：

1. 查看 Core Dump 文件，未找到有效信息；
2. 查看客戶端日志，在 RPC Exception 的超時上下文部分中，定位到了目標(biāo) Query。

經(jīng)分析，導(dǎo)致 Crash 的原因主要有以下兩點(diǎn)：

• 客戶使用不當(dāng)觸發(fā) Bug：BI 分析 2.0 平臺支持用戶編寫 SQL ，由于語法錯誤，觸發(fā)了 Doris 1.1.5 版本 Bug，當(dāng)前新版本已修復(fù)。
• 暴力使用的邊界場景：平臺未限制 where 條件的數(shù)量，當(dāng) OR 條件大于等于 218 時，SQL prepare 過程中的遞歸調(diào)用引發(fā) Linux 線程棧內(nèi)存溢出。

針對以上問題，我們也提出了相應(yīng)的修復(fù)方案，主要包括：

• 調(diào)整 Linux 內(nèi)核線程?？臻g大小，防止內(nèi)存溢出。
• 查找 Issues 及 PR，打 Patch 修復(fù)。
• 限制 where 條件，最高不可超過 100。

用戶畫像實踐及優(yōu)化

01 背景

用戶畫像包括用戶畫像 CDP 平臺引擎，涵蓋人群圈選、事件分析、路徑分析等，為極越汽車的增長、銷售、運(yùn)營、售后等關(guān)鍵環(huán)節(jié)提供了統(tǒng)一全面的用戶打標(biāo)、人群圈選、用戶畫像分析以及用戶行為分析的能力，從而幫助極越汽車更精準(zhǔn)地把握用戶需求，優(yōu)化數(shù)據(jù)服務(wù)策略。

在用戶畫像的構(gòu)建過程中，我們通常會對數(shù)據(jù)進(jìn)行離散化處理，轉(zhuǎn)化為 KV 格式后，利用 Bitmap 高效存儲，確保用戶畫像的精準(zhǔn)性和實時性。用戶畫像業(yè)務(wù)架構(gòu)圖如下：

根據(jù)圖中所示，數(shù)據(jù)服務(wù)和數(shù)據(jù)分析兩個模塊充分利用了 Doris 強(qiáng)大的多維分析能力。數(shù)據(jù)分析師或者業(yè)務(wù)運(yùn)營同學(xué)通過 CDP 平臺在用戶屬性、行為數(shù)據(jù)、業(yè)務(wù)數(shù)據(jù)等基礎(chǔ)上建立人群圈選的規(guī)則之后，規(guī)則可直接轉(zhuǎn)換為 Doris SQL 進(jìn)行計算，計算后的圈選結(jié)果（數(shù)據(jù)集）通過 Bitmap 的方式存入到 Doris 并供下游服務(wù)。

02 查詢問題定位

下圖是用戶標(biāo)簽管理模塊的 tag_ser_Bitmap 表，其中， user_ID 的數(shù)據(jù)類型是 Bitmap。在生產(chǎn)環(huán)境（5 BE）下，查詢 user_ID 為 1 的所有用戶標(biāo)簽時，執(zhí)行時間長達(dá) 19 秒之多，執(zhí)行時間遠(yuǎn)超預(yù)期，而此時數(shù)據(jù)量只有 5000 多行。基于此，我們開始探索 Bitmap 快速查詢問題所在。

Profile

一開始我們嘗試從 Profile 入手，先是對比了 1.1.5 和 1.2.5 兩個版本的核心參數(shù)：CompressedBytesRead、Uncompressed BytesRead、RawRowsRead 和 BlockLoadTime。

經(jīng)測試，在測試和生產(chǎn)環(huán)境中，讀取數(shù)據(jù)量都存在解壓縮情況，數(shù)據(jù)體積膨脹約 1 倍多；IOtimer 時間較短，但 BlockLoadTime 時間很長，這說明讀的過程存在明顯的數(shù)據(jù)傾斜，猜測是 BlockLoadTime 出現(xiàn)了性能瓶頸。針對以上問題，我們改善了對應(yīng)數(shù)據(jù)分布：

• 將表的 Buckets 分桶數(shù)從 10 改為 48；
• 將標(biāo)簽分布從 name 改成 name + value；

優(yōu)化后，查詢結(jié)果從 19 秒 縮短到 5 秒，查詢速度提升 3.4 倍，但仍未達(dá)到一秒返回查詢結(jié)果的要求。

Bitmap

隨后我們嘗試從 Bitmap 入手，猜測慢查詢是 BlockLoadtime 運(yùn)行過程中 Segmentlteror 讀取迭代源碼時磁盤 IO、反序列化較慢導(dǎo)致的，隨后進(jìn)行了驗證操作：

• 只讀取非 user ID 列，響應(yīng)速度非?？?。
• 只讀取 user ID，查詢速度較慢，并且與是否使用函數(shù)、是否聚合無關(guān)。

驗證結(jié)果表明，問題在于 Bitmap Value的存儲結(jié)構(gòu)存在序列化和 IO 瓶頸問題。由于 Bitmap 底層由 Roaring Bitmap 構(gòu)建，存儲方面不存在資源浪費(fèi)的問題，因此我們繼續(xù)關(guān)注 Bitmap 底層的工作原理。通過進(jìn)一步探索發(fā)現(xiàn)：

• 僅有 30 多個高基數(shù)列 Bitmap Value，剩下的 Bitmap Value 基數(shù)均不超過 100 萬。（通過 bitmap_count 發(fā)現(xiàn)）
• 存入 Bitmap 的數(shù)據(jù)高達(dá) 19 位，超過了 32 位整數(shù)范圍最大值。（通過 bitmap_min 和 bitmap_max 發(fā)現(xiàn)）

結(jié)合 Bitmap32 和 Bitmap64 的存儲原理：

• Bitmap32 使用 Roaring Bitmap 存儲，高 16 位決定分桶，低 16 位包含三個 container 并根據(jù)容量決定桶的存儲方式：
  • Array Container ：存入 Bitmap 個數(shù)小于或等于 4096；
  • Bitmap Container：存入 Bitmap 個數(shù)超過 4096；
  • Run Container：利用步長來壓縮數(shù)字，降低 Bitmap 存儲。
• Bitmap64 使用紅黑樹+ Roaring Bitmap 存儲：
  • 高 32 位決定在紅黑樹 Key 節(jié)點(diǎn)；
  • 低 32 位時 Roaring Bitmap 會存儲在紅黑Value 中。

針對該用戶標(biāo)簽管理場景，user ID 為 64 位，存儲方式是紅黑樹 + Roaring Bitmap，這就會產(chǎn)生兩個問題：

• 反序列化：紅黑樹每個 key 對應(yīng) value 都是 Roaring Bitmap，反序列化時會涉及多個 roaring Bitmap 32。
• User ID 分布稀疏：產(chǎn)生多個節(jié)點(diǎn)，相當(dāng)于內(nèi)存中查詢 IO 開銷增加，造成網(wǎng)絡(luò)傳輸中的 IO time 值偏大。

03 優(yōu)化方案

基于以上分析，我們提出了 2 種優(yōu)化方案：

1. 利用 IdMapping 服務(wù)將 user_id 轉(zhuǎn)換成 Bitmap 32：Bitmap 32 最高可達(dá)到 46 億用戶量，滿足業(yè)務(wù)系統(tǒng)的數(shù)據(jù)存儲需求。

測試時，我們加入了 100 個測試標(biāo)簽，每個標(biāo)簽值內(nèi)（Bitmap Value）的基數(shù)達(dá) 400 多萬個。全部轉(zhuǎn)化成 32 位 Bitmap 后，查詢結(jié)果僅需 55 毫秒，查詢效率提升近百倍。

2. 正交 Bitmap：將高 32 位拆成額外一列（例如：user_id_prefix）存儲中，不同的高 32 位膨脹到不同的行中每次查詢和寫入都通過高 32 位查詢判斷哪些行存在 Roaring Bitmap。

04 問題排查小結(jié)

經(jīng)過上述實踐，我們簡單總結(jié)了問題排查思路與具體步驟，與大家分享一下：

日志探查與分析

• 從服務(wù)端查詢數(shù)據(jù)，包括 BE 日志、審計日志和 Query Profile，BE 日志通常包括執(zhí)行查詢時的詳細(xì)信息和可能的錯誤信息，審計日志記錄了所有數(shù)據(jù)庫操作的歷史、有助于追蹤問題的來源，而 Profile 提供了查詢執(zhí)行的詳細(xì)統(tǒng)計信息，如掃描行數(shù)、執(zhí)行時間等，是調(diào)優(yōu)和診斷性能問題的關(guān)鍵。
• 當(dāng)服務(wù)端沒有目標(biāo)數(shù)據(jù)時，考慮從客戶端定位嫌疑 SQL。

問題復(fù)現(xiàn)與反饋

• 確認(rèn)版本號，是否為當(dāng)前社區(qū)主要推薦的穩(wěn)定版本，建議根據(jù)社區(qū)的發(fā)版節(jié)奏進(jìn)行升級。當(dāng)前社區(qū)主要維護(hù)的版本為 2.0.x 和 2.1.x ，建議選擇三位版本數(shù)字最大的版本。
• 定位嫌疑 SQL 后，確保問題可復(fù)現(xiàn)，并主動查閱 Doris 文檔。
• 前往 Doris 社區(qū)積極反饋，可以提交 GitHub Issue 或者向 dev@doris.apache.org 社區(qū)開發(fā)者郵件組發(fā)送郵件。在反饋時提供盡可能多的信息，如版本號、復(fù)現(xiàn)步驟、錯誤日志等，便于社區(qū)可以快速解決問題，也可以與社區(qū)伙伴共同學(xué)習(xí)進(jìn)步。

源碼分析與調(diào)試

• 閱讀并 Debug 源碼，注意關(guān)閉 O2 和 O3 的優(yōu)化，避免部分源碼在編譯時被忽略。
• 如果進(jìn)程崩潰并生成了 Core Dump 文件，可以使用 GDB 等調(diào)試工具來分析 Core Dump 文件，以準(zhǔn)確定位導(dǎo)致崩潰的代碼行和堆棧信息。

總結(jié)與展望

截至目前，基于 Apache Doris 的數(shù)據(jù)智能服務(wù)體系已經(jīng)部署了近十套生產(chǎn)集群，節(jié)點(diǎn)規(guī)模已經(jīng)接近百臺，存儲的數(shù)據(jù)總量達(dá)數(shù)百 T，覆蓋了實時數(shù)倉、BI 多維分析、用戶畫像、車云中心（Serving）、日常分析等多個業(yè)務(wù)場景。從業(yè)務(wù)側(cè)來看，Apache Doris 為極越汽車在提升客戶用車體驗、實時監(jiān)測車輛信息、保障安全駕駛等方面提供了更全面、更準(zhǔn)確的業(yè)務(wù)洞察和決策支持，有力推進(jìn)了極越汽車創(chuàng)新數(shù)字化服務(wù)的步伐。從技術(shù)側(cè)看，Doris 優(yōu)秀的讀寫性能、低成本數(shù)據(jù)接入流程和豐富的大數(shù)據(jù)生態(tài)支持，既提升了車端、云端數(shù)據(jù)處理效率，又簡化實時數(shù)據(jù)流架構(gòu)，還能一定程度上節(jié)約計算和存儲成本、簡化運(yùn)維。

未來，我們計劃在以下幾個方面繼續(xù)升級和優(yōu)化：

• 版本升級：Doris 版本從 1.1.x 升級至 1.2.x 或2.x 穩(wěn)定版本（截至發(fā)稿前生產(chǎn)環(huán)境多個集群已經(jīng)全部升級至 1.2.7.1 及 2.0.1 以上版本），進(jìn)一步提升查詢性能。同時，計劃引入 2.1.x 版本的基于 WorkGroup 的資源隔離特性，降低多租戶使用過程中的相互干擾，提升穩(wěn)定性。

• Doris 可視化治理：引入 Doris Manager，接管多個集群，集成可視化慢查詢分析，實現(xiàn)降本增效。

• 數(shù)據(jù)湖分析加速：在多 Catalog 場景下，引入 Hive/Paimon Catalog 并集成 Ranger 統(tǒng)一權(quán)限管理，加速湖倉一體落地。

• 車云中心平臺版本嘗鮮：

  • 車輛中心云平臺實現(xiàn)了車端靜態(tài)數(shù)據(jù)的周期性上報和動態(tài)事件觸發(fā)上報，涉及到數(shù)據(jù)的存儲和在線實時分析。vidb-report 通過 log service 將數(shù)據(jù)傳到 log 中，再上報到 Kafka 層，對離線和實時數(shù)據(jù)進(jìn)行存儲。
  • 目前云平臺使用 Elasticsearch 分析日志，在性能方面存在一些瓶頸，經(jīng)過大量測試驗證后，我們計劃上線 Doris 2.1 版本來替代 Elasticsearch。
  • 在 Join 性能優(yōu)化、Rollup 與物化視圖等方面持續(xù)積極探索。