本文導讀：

當前，電商運營的主要痛點不僅來自多變的市場和客户需求，也受困於碎片化用户觸達等帶來的競爭與挑戰。為了深度挖掘用户價值、培養用户忠誠度、實現業績增長，有贊為商家搭建了全方位 OLAP 分析系統，提供實時與離線分析報表、智能營銷與人羣圈選等 SaaS 服務。本文將詳細介紹有贊從 Clickhouse 至 Apache Doris 的遷移規劃和性能對比測試實踐，分享如何基於 Apache Doris 統一 OLAP 技術棧，並滿足龐大數據體量下的實時分析與極速查詢，最終有贊在多個場景下實現查詢平均提速 200% 。

作者：李闖 有贊 基礎平台數據研發工程師

有贊是國內領先的電商 SaaS 服務商，目前擁有社交電商、新零售、美業、教育及有贊國際化五大業務體系，通過旗下的社交電商、門店管理、解決方案以及其他新零售 SaaS 軟件產品，全面幫助商家解決在移動互聯網時代遇到的推廣獲客、成交轉化、客户留存、復購增長、分享裂變等問題，幫助每一位重視產品和服務的商家實現顧客資產私有化、互聯網客羣拓展、經營效率提升，最終助力商家成功。

在面對商家與開發者的定製化服務需求的同時，為了能夠更好地支持商家有效解決引流獲客、分銷體系等難題，有贊為商家搭建了 OLAP 分析系統，提供以下 SaaS 服務場景：

• 商家離線後台報表： 面向 B 端為商家提供 T+1 報表查詢，對計算精度、查詢性能及穩定性要求較高，同時會面臨複雜查詢場景。
• 人羣圈選與智能營銷： 從私域觸點、線下觸點獲取用户數據，結合常用社交平台中接入的用户數據，根據業務需求在客户數據平台（Customer Data Platform - 以下簡稱 CDP）、數據管理平台（ Data Management Platform -以下簡稱 DMP）、客户關係管理系統（Customer Relationship Management- 以下簡稱 CRM） 進行不同消費者的全方位畫像分析。該場景會面臨大量高頻的數據實時更新，同時查詢體量較大、QPS 較高，時常出現複雜 SQL 查詢場景。
• 商家實時分析報表： 面向 B 端為商家提供相關實時報表分析查詢，該場景特點是 QPS 比較高，商家可以選擇不同的維度組合進行查詢，對實時性和穩定性要求高。
• 天網日誌分析系統： 為所有業務系統提供日誌採集、消費、分析、存儲、索引和查詢的一站式日誌服務。該場景寫入吞吐高，需要達到每秒百萬級別的數據寫入；且查詢頻率低，涉及天網 TopN 日誌查詢，因此係統要求具備實時聚合以及模糊搜索能力。

隨着業務數據體量逐漸龐大，業務對於時效性、聯邦查詢分析的需求也愈加迫切，現有組件在使用過程中對業務人員開發、運維人員維護都存在一定痛點，因此決定升級數據架構並基於 Apache Doris 來統一 OLAP 技術棧。本文將詳細介紹早期架構的組成、 OLAP 系統運轉流程、以及實際應用痛點，分享系統架構在遷移過程中的技術與調優經驗。

早期架構痛點

早期架構如圖所示，數據主要來源於業務數據庫 Binlog 與用户日誌等原始數據，通過實時與離線兩條鏈路分別對數據進行處理。其中原始數據首先導入至 Apache Kafka 與 NSQ 消息中間件，一部分會通過 Apache Flink 進行流處理計算並與存儲在 HBase 中的維度明細表進行關聯，另一部分數據會存儲於 Apache Hive 與 HDFS 中作為離線數據，通過 Apache Spark 計算寫入至 OLAP 引擎中。

有贊數據架構主要使用了以下三種 OLAP 引擎，各個組件根據業務場景的特點與需求為上游應用提供不同場景的查詢與分析：

• Apache Kylin： 基於 Apache Kylin 搭建商家離線報表後台，為商家提供 T+1 報表查詢。目前後台已經具有超 500 萬家的商家數量，對於部分體量較大的商家，其單點會員數能夠達到千萬級別、商品 SKU 達到數十萬、平台構建 Cube 數量達 400+。
• Clickhouse： 基於 Clickhouse 進行人羣圈選與 TopN 日誌查詢業務，其中人羣圈選主要通過實時的明細查詢來輔助用户行為數據分析。
• Apache Druid： 針對 B 端商家實時分析報表場景，基於 Druid 構建維度查詢系統，為商家提供實時指標查詢服務。

然而由於該架構組件過多、架構冗餘等問題導致維養、開發、業務應用等方面帶來了一系列的挑戰，具體如下：

01 Clickhouse ：查詢性能不足

針對部份 SaaS 場景的高併發高 QPS 查詢場景，Clickhouse 的查詢能力表現不夠理想。由於 Clickhouse 組件本身設計的問題，無法支持多表或大表 Join 的查詢場景，這就導致一旦出現關聯查詢場景，業務方需要重新尋找解決方案，使整體查詢效率低下。

02 Apache Druid ：數據修復處理難度大

• 數據修復難度大： 當出現 Apache Flink 自身容錯導致數據重複的情況，Druid 完全依賴寫入側進行冪等操作，由於自身不支持數據更新或刪除，只能對數據進行全量替換，導致數據準確性低、修復難度大。
• 數據一致性問題： 對於 Druid 而言，導入數據後需要構建完 Segment 才能響應查詢結果。一旦上游 Flink 寫入 Kafka 的過程中出現數據延遲，則無法按照預期時間寫入 Druid 中，指標數據就會出現較大波動，數據一致性無法得到保障。
• 數據修復鏈路過長、成本過高：為了解決部份臨時數據修復問題，我們首先需要花費小時級時間將 Apache Kafka 數據備份至 HDFS上，在備份完成後還需要將數據重新導入 Druid 之後進行修復，整體修復的鏈路過長，投入的時間與研發成本會隨之升高。

03 Apache Kylin : T+1 時效性低

Apache Kylin 在數據處理過程中採用了預計算的方式，通過在多維 Cube 構建過程中完成聚合計算，並生成 T+1 數據報表。對部分在夜間經營的商家而言，他們需要等待一天時間才能查看前一天的報表數據，這無法滿足用户對於時效性的需求。

04 整體架構：運維成本高、研發效能低、架構靈活度差

• 研發成本高： 業務方需要學習每種組件（Clickhouse、Druid、Apache Kylin)的使用方式、並且查詢 SQL 標準各異，這會使學習成本加大，並且在後期進行研發、監控、運維、周邊生態工具等開發工作過程中，需要投入大量的人力與開發接入成本，降低開發效率。
• 運維瓶頸： 在擴縮容期間業務方需要停寫進行集羣調整，且單次擴容需要將所有的庫表都進行遷移，不僅無法保證運維時間成本，還會增加過高的人力成本。而目前有贊存在大量的擴容需求，現有架構的運維成本則成為系統的一大痛點。
• 架構靈活度差： Apache Kylin 僅在維度和指標提前設定、表結構固定的場景下能夠正常運行，一旦增加維度和指標則需要新建 Cube 並重刷歷史數據；Clickhouse 在寬表補數時會出現需要重新全量導入數據，這些架構缺陷在業務運行過程中都會引發資源使用增加、運維成本增加、研發效能較低的問題。

技術調研與收益成本評估

基於上述架構痛點，我們對市面上的架構進行了調研與選型，希望選擇一款能夠簡化當前複雜架構、統一 OLAP 技術棧的引擎。我們除了分析 OLAP 性能本身對於業務的幫助，還需要評估架構改造所帶來的收益成本比，思考架構進行遷移和重構之後所帶來的 ROI 是否符合預期。

對於收益而言，我們需要評估新架構引入後的性能是否如預期提升，將 Apache Doris 分別與 Clickhouse、Druid、Kylin 進行對比評估。

對於成本而言，我們首先會考慮在替換過程中，周邊工具開發的成本，其中涉及監控、告警、上下游依賴平台等一系列工具的構建與研發；其次業務的遷移會涉及大量業務改造與協調，如何催動業務方進行改造、提供更豐富的改造工具、儘可能降低投入成本也是我們主要考慮的問題。

經過一系列評估後，我們發現基於 Apache Doris 進行架構迭代，其不論是在業務賦能還是成本方面，都能夠有效解決當前架構的痛點，極大程度地實現降本增效的目標，整體迭代的預期收益明顯高於改造代價，因此我們決定基於 Apache Doris 構建統一實時數倉，具體評估分析如下：

• 查詢性能優異： 解決了 Clickhouse 在高 QPS 查詢與大表關聯查詢場景下的弊端，提供了優秀的併發查詢能力。此外，在 Apache Doris 2.0 發佈後，倒排索引功能支持任意維度快速檢索、文本分詞全文檢索，在日誌場景下的查詢性能提升尤為明顯。
• 高效的數據更新： Apache Doris 的 Unique Key 支持大批量數據更新、小批量數據實時寫入，覆蓋我們 90 % 業務場景，其 Duplicate Key 與 Aggregate Key 模型還能夠支持部分列更新，整體數據模型豐富，幫助提升寫入與查詢效率。
• 保證數據正確性： Apache Doris 支持事務導入，Bitmap 功能支持精準去重，保證數據不丟不重；同時支持精準寫入，保證數據基表與物化視圖強一致性、副本數據強一致性。
• 簡單易用、開發成本低： Apache Doris 高度兼容 MySQL，使開發簡單使用門檻降低，且 Doris 的遷移與擴縮容成本較低，在橫向擴容等運維操作方面特別簡單。其周邊組件的接入與監控的接入皆相對簡單，Doris 社區提供 Flink & Doris Connector、Spark & Doris Connector 等接入工具，並且監控模版能夠直接取用，無需再開發。
• 社區活躍度高： 在過往加入的開源社區中，Apache Doris 社區活躍度非常高，社區開發者多、迭代更新快，對於社區內的問題解答也十分積極，在開發過程給予了非常多的幫助。

基於 Apache Doris 構建統一實時數倉

如上圖所示，新架構將基於 Apache Doris 搭建統一實時數倉，替換原架構中的三個 OLAP 組件，解決由組件過多引起的接入成本高、資源使用增加、數據鏈路過長等問題，最終能夠減輕業務方的負擔、減少整體框架的硬件成本、實現引擎與技術棧統一等目標。

在有贊絕大多數應用場景中，原架構都存在數據重複、數據延遲需要修復的情況，引入 Apache Doris 之後，我們將利用其 Unique Key、Duplicate Key、Aggregate Key 模型功能實現高效的數據更新，保證寫入效率，並且 Doris 架構具備彈性伸縮的能力，引入後能夠極大程度地降低故障發生的概率以及出現故障時數據恢復的效率。

此外我們還將引入 Apache Doris 以下功能：

• 倒排索引： Apache Doris 2.0 版本的倒排索引功能優化天網日誌分析系統，實現多維度快速檢索，加速日誌場景的查詢分析性能。
• 主鍵模型寫時合併（Merge-on-Write）： Apache Doris 提供豐富的導入方式，可以將小批量數據實時導入 Doris 中，為後續上架門店業務提供實時報表查詢，與原價構使用對比，Doris 能夠極大程度提升導入時效性。

從 Clickhouse 到 Apache Doris 的遷移經驗

在確定架構遷移之後，我們首先選擇用 Apache Doris 來替換 Clickhouse 組件，主要由於在業務增長時 Clickhouse 查詢性能瓶頸較大、集羣擴縮容操作過於複雜等痛點使運維團隊的工作量大幅增加，加之大表 Join 能力差、高 QPS 查詢性能差等一系列問題無法滿足業務方訴求，且 Clickhouse 功能與 Apache Doris 相似，業務方更便於遷移， 因此我們優先替換 Clickhouse 組件。

接下來，我們將分享 Doris 替換 Clickhouse 的遷移方案，架構迭代的整體節奏分為 SQL 語句改寫實現自動導入（包含建表語句與查詢語句的改寫）、查詢性能測試、穩定性測試、導入性能測試與優化，在結束一系列測試後最終進行整體業務數據的遷移。

01 SQL 建表語句與查詢語句改寫

目前，我們針對 Unique Key 模型與 Duplicate Key 模型製作了 SQL 建表語句改寫工具，如上圖所示，支持通過配置參數自動將 Clickhouse 建表語句轉為 Doris 建表語句，該工具的主要功能具體如下：

• 字段類型映射： 由於 Doris 與 Clickhouse 字段不一致，存在一些特殊要求的轉換，例如 Key 值類型 String 需要轉為 Varchar 以及設置對應長度、分區字段 String 需要轉為 Date V2 等；
• 動態分區錶的歷史分區數確定： 因為部份表存在歷史分區，需要在建表時指定分區數量，否則插入數據會出現 No Partition 異常；
• Buckets 數量確定： 雖然歷史分區表可以進行統一配置，但是往往歷史分區數據量不完全一致，因此我們根據歷史分區的實際數據量推算出歷史分區的分桶數，同時對於非分區表可以根據歷史數據量設置 Properties 進行自動分桶配置；
• TTL 週期確定： 可以設定動態分區表的轉換週期，設定保留時間後再轉換；
• Unique 模型的 Sequence 設置： 在導入時可以指定 Sequence 列導入順序，解決了導入順序無法確定的問題，有效保證數據導入過程中的有序性。

與建表語句改寫工具類似，SQL 查詢語句改寫能夠自動將 Clickhouse 查詢語句轉成 Doris 查詢語句，主要為了雙跑進行數據準確性和穩定性驗證。在改寫過程中，我們梳理了以下注意事項：

• 查詢表名轉換： 在 Clickhouse 與 Doris 建表過程中存在一定的映射規則，在進行雙跑測試的過程中，我們可以直接根據映射規則直接進行轉換。
• 函數轉換： 由於 Clickhouse 與 Doris 使用函數差異較大，需要根據 Doris 和 Clickhouse 的函數映射關係進行函數映射轉換。其中我們遇到一些比較特殊的函數轉換需要進行特別處理，例如 Clickhouse 中的 COUNTIF() 需要轉換為 SUM（CASE WHEN _ THEN 1 ELSE 0) 以達到相同的效果， ORDER BY 與 GROUP BY 需要利用 Doris 開窗函數進行轉化，此外 Clickhouse 利用 Array Join 進行列傳行，對應 Doris 則需要利用 Explode 、 Lateral View 來展開；
• 語法層面的不兼容： 由於 Clickhouse 不兼容 MySQL 協議而 Doris 高度兼容，因此在子查詢中需要進行別名設置。特別是在人羣圈選的業務場景中存在多個子查詢，因此在售後轉換的時候需要把對應子查詢利用 sqlparse 進行遞歸，檢查出所有的子查詢進行設置。

02 Apache Doris 與 Clickhouse 性能壓測

查詢性能測試主要通過 Apache Doris 與原架構 Clickhouse 組件在三個核心業務場景（CDP、DMP、CRM）下的對比表現。我們選用了線上等比的集羣規模，通過查詢 SQL 性能對比、大表 Join 性能兩方面進行對比壓測，同時檢測 Doris 在查詢期間的 CPU 以及 內存損耗。接下來我們將詳細介紹壓測過程與具體性能數據對比。測試集羣規模3 FE + 16 BE，BE單節點配置為（ 32C 128 G 7T SSD）。

核心場景下查詢 SQL 性能對比

在進行查詢 SQL 性能測試中，我們主要基於當前實際應用場景最多的三大系統進行查詢，分別是 CDP、DMP、CRM 場景的對比。最終有效查詢 SQL 16 條，線上場景下查詢 SQL 的具體特點如下：

如表格所示，我們將 Doris 與 Clickhouse 16 條 SQL 查詢時間對比，其中有 10 條 SQL Doris 查詢性能優於 Clickhouse。 此外我們將 Doris 與 Clickhouse 查詢時間總和進一步對比，在對 Doris 表結構設計優化後，Doris 整體查詢速度相比 Clickhouse 快 2-3 倍。

大表 Join 查詢性能測試

在關聯查詢測試中，以 CDP 場景下的相關數據表為基礎，我們選用了不同數據量級的主表與維表數據，主表測試數據量分別為 40 億的用户行為表、250 億的用户額外屬性表、960 億的用户額外屬性表；維表以 kdt_id + user_id 為基礎，測試量級分別為 100 萬、1000 萬、5000 萬、1 億、5 億、10 億及 25 億維表數據量。為了測試更加全面，關聯查詢測試分為完全關聯與過濾關聯兩種測試，完全關聯是將主表與維度表直接進行 Join，過濾關聯是在相同主表量級關聯中，增加了 WHERE 條件對指定的兩個店鋪 ID 進行過濾。

具體的查詢測試表現如下：

• 全關聯 40 億： 在 40 億主表完全關聯查詢中，Doris 查詢性能均優於 Clickhouse，且隨着維表數據量級增大，Doris 與 Clickhouse 查詢耗時差距越大，其中 Doris 最高能夠達到 5 倍性能提升；
• 過濾指定店鋪關聯 40 億： 在過濾條件關聯查詢中，主表按照 WHERE 條件過濾後的數據為 4100 萬，相較於 Clickhouse，Doris 在維表數據量小的情況下能夠達到 2-3 倍的性能提升，在維表數據量大的情況達到 10 倍以上的性能提升，其中當維度數據表超過 1 億後，Doris 依舊可以穩定查詢，而 Clickhouse 由於 OOM 情況導致查詢失敗。
• 全關聯 250 億： 在 250 億 50 字段寬表作為主表完全關聯時，Doris 查詢性能依舊優於 Clickhouse，Doris 在所有維表量級中均能跑出，而 Clickhouse 在超過 5000 萬後出現 OOM 情況；
• 與過濾指定店鋪關聯 250 億： 在條件關聯查詢中，主表按照店鋪 ID 過濾數據為 5.7 億，Doris 的查詢響應時間均達到了秒級，而 Clickhouse 最快響應時間也需要分鐘級耗時，在數據量大的情況下更是無法跑出。
• 全關聯與過濾指定店鋪關聯 960 億： 不論是主表關聯查詢還是條件關聯查詢，Doris 均可跑出且響應速度較快，Clickhouse 則在所有維表量級中無法跑出。

除響應性能外，我們還對於 Doris 的 CPU 與內存損耗進行檢測，發現 Doris 在數百億計大表關聯查詢的情況下集羣負載依舊穩定。綜上，Apache Doris 在絕大部份場景查詢響應速度快於 Clickhosue ，特別是在大表 Join 場景下，Apache Doris 性能表現完全優於 Clickhouse。

03 Clickhouse 線上流量回放穩定性測試

在查詢壓測完成後，我們開始將 Doris 與 Clickhouse 線上雙跑以進一步驗證 Doris 的穩定性。具體步驟如下：

1. 通過定時採集 Clickhouse 最近 1 分鐘的查詢狀態為 QueryFinish 的有效查詢信息。
2. 將查詢信息上報至 Kafka，接着通過 Flink 消費 Kafka Topic 獲取 Clickhouse 查詢 SQL 並統計結果。
3. 在 Flink 中實現 UDF 將 Clickhouse 查詢 SQL 轉化為 Doris 查詢 SQL，並由 JDBC 執行。
4. 獲取執行結果與統計結果，與 Clcikhouse 執行信息進行對比最終存放至 RDS。
5. 最終通過對線上 Clickhouse 查詢流量回放的統計，分析 Doris 查詢性能與查詢數據準確性。

04 Apache Doris 數據導入性能測試與優化

數據導入性能測試是我們重要關注的環節之一，Apache Doris 本身對於實時數據和離線數據的導入提供了比較豐富的導入方式，實時數據的導入方式主要是通過 Apache Flink 將 NSQ 和 Apache Kafka 的數據實時通過 Stream Load 方式寫入 Apache Doris 中。在離線數據中，Doris 提供了多種導入方式：

• 支持通過 Spark SQL 讀取外部數據，通過 Stream Load 方式寫入 Apache Doris；
• 支持通過 Spark Load 方式，利用 Spark 集羣資源將數據排序操作在 HDFS 中完成，再通過 Broker Load 將數據寫入 Doris；
• 支持 Doris Multi-Catalog 功能直接讀取 外部數據源並通過 Insert Into 方式寫入 Doris。

由於離線數據量較大，針對這類數據我們將幾種數據導入方式進行了性能測試對比，通過明細數據的各個數據量級對比測試導入時間。 測試集羣規模 3 FE + 16 BE，BE 單節點配置為（ 32C 128 G 7T SSD）測試結果：

Spark Doris Connector 格式導入的並行度為 80，單批為 100 萬，集羣的負載情況如下：

根據上方測試結果，我們進一步分析各種導入方式的優勢與後續調優方案，希望以下的調優實踐能夠幫助到有類似需求的開發者們：

Doris Insert Into

Insert Into 方式能夠提供快速導數性能，在用法上也相對簡單，目前該方式的導入性能已經足夠支持我們的業務需求。

Spark Doris Connector 支持阻塞寫入

Spark Doris Connector 導入方式更具有通用性，能夠解決大量數據導入的問題，導入性能相對穩定，在導入過程我們需要合理控制導入速率與導入並行度。考慮到我們的業務場景每天會涉及千億級別的數據量並花費 5-6 個小時進行導入，對於這類大表數據的導入如果因為 BE 寫入被拒絕導致失敗，會造成下游數據產出延遲等問題。此外，在 2.0 版本中，類似 -235，-238 錯誤已經在 Apache Doris 內核層面解決，無需用户再手動處理此類問題。

我們主要從控制寫入速度入手，整體改造原理是通過指數退避寫入的方式延遲阻塞，利用配置參數使大數據量出現導入異常時可以等待重試，不讓任務失敗。通過最大阻塞次數、單次最大阻塞時間、需要阻塞異常捕獲關鍵詞這三個參數來捕獲阻塞異常情況，實現阻塞退避功能。最終在該設置下，我們的大表導入數據成功率達 95%以上。

[1] 相關 PR： https://github.com/apache/doris-spark-connector/pull/117

Spark Doris Connector 支持 Bitmap 數據導入

在閲讀 Apache Doris 官方文檔時，我們發現 Spark Load 的方式可以對 Bitmap 數據進行導入，同時能夠將 Bitmap 數據計算放在 Spark 集羣中進行計算。在業務實踐中，我們使用 Spark Doris Connector 更為常用，於是開始探索通過 Spark Doris Connector 的方式實現 Bitmap 數據導入。

如上圖所示，Bitmap 建表語句主要分為三個字段，其中最後一個字段是將 CASE_ID 進行 Bitmap 計算。在與社區成員溝通之後，提供一種設置 Doris Read Field 選項，寫除 Bitmap 列外的其他列，同時在 Doris Write Field 中做映射處理。最終實現如上圖所示方式通過 Spark Doris Connect 直接將 Apache Hive 明細數據導入 Apache Doris 的 Bitmap 數據中。

Spark Doris Connector CSV 格式導入優化

在我們的導入流程中，無論是 Spark Doris Connector 還是 Flink Doris Connector，最終都是利用 Stream Load 的方式進行導入，其導入文件 CSV 與 JSON 有兩種導入格式且對於不同格式的選擇，導入性能的損耗與速率也是不同的。

在優化前，我們進行了測試，以數十億數據規模、26 個字段的業務表進行導入性能測試，發現 CSV 格式比 JSON 的導入速度快近 40% 且其內存消耗是更低的，這也是為什麼 Apache Doris 官方推薦使用 CSV 格式。

其中值得注意的是使用 CSV 格式進行導入時，設置合理的字段分隔符和換行符對於 CSV Reader 識別效率是至關重要的，如果 BE 的 CSV Reader 對於字段中最後一個字符和分隔符的首字符相同時，則無法識別分隔符。

通過官方文檔的提示，我們發現 Stream Load 中能夠支持參數配置去除字段最外層的雙引號，基於此我們決定在 Spark Doris Connector 寫入階段添加用户設置配置，在字段外層拼接雙引號，保證不用選定特殊字符依然能夠有效分隔，同時在 Stream Load 寫入階段添加去除最外層雙引號的配置。通過兩端配置，能夠保證即使業務數據很複雜的情況下，也無需為字段符號的識別而煩惱，有效保證字段能夠正常分割。

[2] 相關 PR: https://github.com/apache/doris-spark-connector/pull/119

Spark Load

Spark Load 導入方式的特點是基於 Spark 資源進行 Shuffle、排序等工作將文件輸出在 HDFS 中，之後 BE 節點能夠直接讀取 HDFS 上的文件並按照 Doris 格式寫入。基於這種方式，在測試過程中我們發現當數據量越大時導入速度越快、越能夠節省 Doris 的集羣資源，不會帶來較大性能損耗。

由於 Spark Load 在臨時修復數據場景中使用頻繁，我們也基於測試進一步優化。通過官網文檔與社區幫助下我們發現，Spark Load 階段的導入速率主要由單次導入併發度和單次 BE 導入數據處理量兩方面參數影響，且兩個參數都與源文件大小、BE 節點密切相關。當控制其他變量的情況下，源文件越小，導入速度越慢，因此我們認為在 ETL 階段充分利用 Spark 經營資源並且合理設置 Bucket 數量能夠有效加速導入速率。

未來規劃與展望

在整體測試環節中，基於 Apache Doris 2.0 正式版本的性能測試已經完成，我們對於 Doris 的查詢性能表現是十分滿意的。此外，對於導入性能，我們在測試時首先採用的是 Doris 2.0-Alpha 版本，發現在導入過程中存在偶發性 CPU 瓶頸的問題，例如當通過 Spark Doris Connector 的方式，Spark 使用資源和 Doris 導入數據 CPU 存在一定的瓶頸。同時，我們也將問題反饋給社區，在經過社區優化與 2.0-Beta 版本發佈後，穩定性得到了改善。

目前，我們正在與 Clickhouse 線上雙跑對 Doris 的穩定性進一步驗證，同時我們正在對 Spark Doris Connector 導入方式的的進行性能優化、開發導入周邊工具以完成組件替換等落地工作。後續在逐步完成 Clickhouse 的業務遷移後，基於 Clickhouse 的遷移經驗，對未遷移的存量業務逐步完成 Druid、Kylin 兩個組件的遷移，最終基於 Apache Doris 構建極速分析、實時統一的數據倉庫。

在此非常感謝 SelectDB 技術團隊的積極響應與專業解答，加速有贊業務的遷移進程，也希望通過這篇文章為準備進行架構遷移的企業提供相關實踐經驗和 OLAP 選型參考。最後，我們也會持續參與社區活動，將相關成果貢獻回饋社區，希望 Apache Doris 飛速發展，越來越好！

參考 GitHub PR：

[1] Spark Doris Connector 支持阻塞寫入

https://github.com/apache/doris-spark-connector/pull/117

[2] Spark Doris Connector CSV 格式導入優化

https://github.com/apache/doris-spark-connector/pull/119

[3] Spark Load 創建 Hive 外表支持 Hive 版本設置

https://github.com/apache/doris/pull/20622

[4] Spark Load 系統環境變量獲取優化

https://github.com/apache/doris/pull/21837

[5] HIve 外表屬性在 Spark Load 不生效優化

https://github.com/apache/doris/pull/21881