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

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

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

業務挑戰和訴求

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

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

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

OLAP 調研與技術選型

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

考慮實時數據更新能力和 Join 性能的高優先級需求，我們首先排除了 ClickHouse 和 Apache Kylin，再對比與某云廠商的產品，由于其產品非開源且產品生態較為封閉，綜合對比下來 Apache Doris 與我們的目標訴求高度匹配：

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

實時數倉建設與實踐優化

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

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

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

初期階段，我們也遇到了一些性能方面的挑戰。下面結合兩個具體應用場景，分享我們在使用過程中的性能調優經驗。

01 高頻 DDL Alter 優化

在離線/實時數倉 ETL 場景，每天凌晨 5 點常常出現 Doris DDL 頻繁操作失敗的情況。經過排查，原因如下：

1. 線程池在重建過程中，默認的異步線程返回時間設置不當，導致超時。
2. 跟蹤源碼發現，由于當前線程池規模相對較小，當多個 DDL 操作并行執行時線程資源不足，引發了線程等待，最終超時失敗。

針對上述問題，我們調整了以下線程池參數：

• 單個 Tablet 超時參數從 1 改為 2：

  tablet_create_timeout_second = 2

• 創建 tablet 線程池參數，由 3 調整為 6：

  create_tablet_worker_count = 6

• 修改 tablet 線程池參數，由 3 調整為 6：

  alter_tablet_worker_count = 6

調優后，操作失敗率顯著改善。相比于之前 90% 的失敗率，現在的失敗率僅有 10% 左右。

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

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

• 非分區表：創建原表對應的臨時表，寫入數據到臨時表中，然后進行表替換操作（表替換操作是原子性的）；

• 分區表：創建原表分區對應的臨時分區，寫入數據到臨時分區中，然后進行分區替換操作（分區替換是原子性的）。

02 Stream Load 寫入性能調優

智能汽車在行駛過程中，系統會對驅動電機、能耗情況、通訊定位等數據全面監測，因此在離線和實時場景下，都需要寫入大規模車輛數據。

為了提升 Stream Load 的寫入性能，我們進行了多處參數調優：

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

  compaction_task_num_per_disk = 4

• 增加 Compaction 線程總數，從默認 10 增加到 16：

  max_compaction_threads compaction = 16

• 減少 Compaction 合并任務量：

  max_cumulative_compaction_num_singleton_deltas = 500
  max_tablet_version_num = 1500
  min_compaction_failure_interval_sec = 5
  

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

  "compression" = "zstd"

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

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

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

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

BI 分析平臺實踐及優化

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

01 早期業務痛點

上圖是 1.0 平臺架構圖，早期的業務十分依賴第三方引擎的數據處理能力， 由于構建成熟度低，系統性能瓶頸很快暴露出來，對業務支持帶來嚴峻挑戰：

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

02 BI 分析平臺 2.0

面對雙向復雜的數據架構環境，首要挑戰是數據實時響應的壓力，我們需要確保 BI 分析平臺能夠迅速、準確地應對各種車端及用戶端數據變化，這也促使我們開始了 BI 分析平臺 2.0 的改造計劃。在整個 BI 分析平臺的改造過程中，我們充分將業務需求與 Apache Doris 的各項優勢相結合：

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

基于 Apache Doris 我們重新構造了 BI 分析平臺 2.0，在數據處理、分析應用等方面進行了架構升級。在重構過程中，我們也積累了一些 Doris 性能優化的經驗，與大家一同分享。

03 內存占用優化

在使用 BI 分析 2.0 平臺時，部分用戶反饋某頁面圖標無法展現，此時 Doris BE 內存占用率高達 99%，導致其他查詢失敗。經排查，某個 SQL 掃描了全表，而 Doris Session 級別和 Global 級別的內存保護機制均未生效。

進一步排查發現，MemTracker 的兩個參數 mem_tracker_cancel_query 、proc_meminfo_cancel_query 默認值都是 False ，當內存超過一定限制時攔截無法生效；改為 true 后，內存保護機制正常運行，問題得以解決。

1.2.x 版本后，這兩個參數默認值已調整為 true。

點擊 Memtracker 參考詳情功能解析

04 BE Crash 問題定位

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

于是我們嘗試以下 2 個方法進行問題定位：

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

經分析，導致 Crash 的原因主要有以下兩點：

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

針對以上問題，我們也提出了相應的修復方案，主要包括：

• 調整 Linux 內核線程棧空間大小，防止內存溢出。
• 查找 Issues 及 PR，打 Patch 修復。
• 限制 where 條件，最高不可超過 100。

用戶畫像實踐及優化

01 背景

用戶畫像包括用戶畫像 CDP 平臺引擎，涵蓋人群圈選、事件分析、路徑分析等，為極越汽車的增長、銷售、運營、售后等關鍵環節提供了統一全面的用戶打標、人群圈選、用戶畫像分析以及用戶行為分析的能力，從而幫助極越汽車更精準地把握用戶需求，優化數據服務策略。

在用戶畫像的構建過程中，我們通常會對數據進行離散化處理，轉化為 KV 格式后，利用 Bitmap 高效存儲，確保用戶畫像的精準性和實時性。用戶畫像業務架構圖如下：

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

02 查詢問題定位

下圖是用戶標簽管理模塊的 tag_ser_Bitmap 表，其中， user_ID 的數據類型是 Bitmap。在生產環境（5 BE）下，查詢 user_ID 為 1 的所有用戶標簽時，執行時間長達 19 秒之多，執行時間遠超預期，而此時數據量只有 5000 多行。基于此，我們開始探索 Bitmap 快速查詢問題所在。

Profile

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

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

• 將表的 Buckets 分桶數從 10 改為 48；
• 將標簽分布從 name 改成 name + value；

優化后，查詢結果從 19 秒 縮短到 5 秒，查詢速度提升 3.4 倍，但仍未達到一秒返回查詢結果的要求。

Bitmap

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

• 只讀取非 user ID 列，響應速度非常快。
• 只讀取 user ID，查詢速度較慢，并且與是否使用函數、是否聚合無關。

驗證結果表明，問題在于 Bitmap Value的存儲結構存在序列化和 IO 瓶頸問題。由于 Bitmap 底層由 Roaring Bitmap 構建，存儲方面不存在資源浪費的問題，因此我們繼續關注 Bitmap 底層的工作原理。通過進一步探索發現：

• 僅有 30 多個高基數列 Bitmap Value，剩下的 Bitmap Value 基數均不超過 100 萬。（通過 bitmap_count 發現）
• 存入 Bitmap 的數據高達 19 位，超過了 32 位整數范圍最大值。（通過 bitmap_min 和 bitmap_max 發現）

結合 Bitmap32 和 Bitmap64 的存儲原理：

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

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

• 反序列化：紅黑樹每個 key 對應 value 都是 Roaring Bitmap，反序列化時會涉及多個 roaring Bitmap 32。
• User ID 分布稀疏：產生多個節點，相當于內存中查詢 IO 開銷增加，造成網絡傳輸中的 IO time 值偏大。

03 優化方案

基于以上分析，我們提出了 2 種優化方案：

1. 利用 IdMapping 服務將 user_id 轉換成 Bitmap 32：Bitmap 32 最高可達到 46 億用戶量，滿足業務系統的數據存儲需求。

測試時，我們加入了 100 個測試標簽，每個標簽值內（Bitmap Value）的基數達 400 多萬個。全部轉化成 32 位 Bitmap 后，查詢結果僅需 55 毫秒，查詢效率提升近百倍。

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

04 問題排查小結

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

日志探查與分析

• 從服務端查詢數據，包括 BE 日志、審計日志和 Query Profile，BE 日志通常包括執行查詢時的詳細信息和可能的錯誤信息，審計日志記錄了所有數據庫操作的歷史、有助于追蹤問題的來源，而 Profile 提供了查詢執行的詳細統計信息，如掃描行數、執行時間等，是調優和診斷性能問題的關鍵。
• 當服務端沒有目標數據時，考慮從客戶端定位嫌疑 SQL。

問題復現與反饋

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

源碼分析與調試

• 閱讀并 Debug 源碼，注意關閉 O2 和 O3 的優化，避免部分源碼在編譯時被忽略。
• 如果進程崩潰并生成了 Core Dump 文件，可以使用 GDB 等調試工具來分析 Core Dump 文件，以準確定位導致崩潰的代碼行和堆棧信息。

總結與展望

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

未來，我們計劃在以下幾個方面繼續升級和優化：

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

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

• 數據湖分析加速：在多 Catalog 場景下，引入 Hive/Paimon Catalog 并集成 Ranger 統一權限管理，加速湖倉一體落地。

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

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