中通快遞作為快遞行業(yè)領(lǐng)軍企業(yè)之一，年包裹數(shù)達(dá)數(shù)百億件，市場份額穩(wěn)定在 20% 左右，展現(xiàn)出強(qiáng)勁的市場競爭力和持續(xù)發(fā)展態(tài)勢(shì)。在業(yè)務(wù)規(guī)模持續(xù)擴(kuò)張下，其對(duì)大數(shù)據(jù)基礎(chǔ)設(shè)施建設(shè)要求日益提高，對(duì)數(shù)據(jù)處理及分析的需求也持續(xù)增加。

中通快遞原先使用以 Hadoop 為核心的離線數(shù)倉，但隨著數(shù)據(jù)的不斷增長、數(shù)據(jù)處理需求不斷變化， Hadoop 這一多套異構(gòu)的復(fù)雜架構(gòu)逐步暴露瓶頸，面臨數(shù)據(jù)時(shí)效性、查詢性能、并發(fā)能力、維護(hù)成本等多種挑戰(zhàn)。

在此背景下，引入基于 Apache Doris 內(nèi)核的 SelectDB 構(gòu)建了湖倉分析架構(gòu)，補(bǔ)齊 OLAP 分析能力，為離線、實(shí)時(shí)分析提供了高效的查詢能力。在離線場景中，實(shí)現(xiàn) 2000+ QPS 并發(fā)點(diǎn)查；在實(shí)時(shí)場景中，僅以 1/3 原集群機(jī)器數(shù)量覆蓋所有業(yè)務(wù)，90% 分析任務(wù)從 10 分鐘縮短至 1 分鐘內(nèi)，投入產(chǎn)出比大幅提升。

一、早期架構(gòu)及挑戰(zhàn)

在引入 SelectDB 之前，中通基于 Hadoop 構(gòu)建離線數(shù)倉應(yīng)對(duì)數(shù)據(jù)分析需求。在業(yè)務(wù)量高速增長的背景下，該架構(gòu)面臨嚴(yán)峻挑戰(zhàn)：

• 數(shù)據(jù)時(shí)效性不足：離線數(shù)倉 T+1 數(shù)據(jù)抽取產(chǎn)出模式無法滿足報(bào)表和數(shù)據(jù)大盤實(shí)時(shí)更新的需求；
• 查詢性能較差：離線數(shù)倉讀取、寫入等操作均基于 HDFS 進(jìn)行，耗時(shí)普遍為分鐘級(jí)別，以及 Spark SQL 的處理時(shí)間亦為分鐘級(jí)，嚴(yán)重影響查詢效率，無法支持需要秒級(jí)響應(yīng)的交互式分析場景。
• 查詢穩(wěn)定性與高并發(fā)支持能力弱：在超大的 Hadoop 集群規(guī)模下，NameNode 的輕微抖動(dòng)就會(huì)嚴(yán)重影響短平快的即席查詢和報(bào)表分析的穩(wěn)定性，Trino 在處理高并發(fā)查詢時(shí)效率也遠(yuǎn)低于預(yù)期，難以支撐日益增長的高并發(fā)需求。

二、基于 SelectDB 的湖倉分析架構(gòu)

隨著業(yè)務(wù)的不斷發(fā)展，昔日雙 11 的業(yè)務(wù)高峰現(xiàn)已成為每日常態(tài)。為了滿足各大場景對(duì)實(shí)時(shí)分析時(shí)效的要求，并確保數(shù)據(jù)的快速寫入和高效查詢，亟需合適的 OLAP 引擎來補(bǔ)充現(xiàn)有架構(gòu)。

1. 技術(shù)選型

中通技術(shù)團(tuán)隊(duì)通過深入的技術(shù)調(diào)研和測試驗(yàn)證，了解到 基于 Apache Doris 內(nèi)核構(gòu)建的 SelectDB。SelectDB 以高效的向量化引擎、Pipeline 執(zhí)行模式、完善的緩存機(jī)制支持、高度兼容的 SQL 語法以及靈活的湖倉分析能力吸引了他們

為了驗(yàn)證 SelectDB 向量化引擎和 Pipeline 執(zhí)行模式的高性能查詢能力，團(tuán)隊(duì)進(jìn)行了多輪對(duì)比測試，以評(píng)估二者之間的性能差異：

• 在生產(chǎn)環(huán)境 SQL 測試中，單表 100GB 數(shù)據(jù)量的查詢場景下，SelectDB 相比 Trino 有 1-2 倍的性能提升；
• 在 1TB TPC-DS 標(biāo)準(zhǔn)測試中，SelectDB 完成 99 個(gè)查詢的總耗時(shí)僅為 Trino 的 1/5。

2. 湖倉分析實(shí)時(shí)架構(gòu)

中通基于 SelectDB 構(gòu)建了新一代的湖倉分析架構(gòu)，其核心是將 SelectDB 作為統(tǒng)一、高性能的查詢加速引擎覆蓋在數(shù)據(jù)湖之上。數(shù)據(jù)依然存儲(chǔ)在 Hive 數(shù)據(jù)湖中，保持其經(jīng)濟(jì)性和容納海量原始數(shù)據(jù)的能力。

具體而言，SelectDB 通過 Multi-Catalog 直接對(duì)接 Hive Metastore，無需數(shù)據(jù)遷移即可創(chuàng)建外部表，實(shí)現(xiàn)對(duì) Hive 湖中數(shù)據(jù)的直接、高速查詢。為了進(jìn)一步提升查詢體驗(yàn)，中通廣泛采用了 SelectDB 的緩存加速、數(shù)據(jù)預(yù)熱、索引體系、分區(qū)分桶等能力，有效保障了系統(tǒng)的穩(wěn)定性及查詢的高效性。

截止當(dāng)前，在 OLAP 分析層面， Trino 集群規(guī)模已超過 130 臺(tái)，日峰值響應(yīng)接近 56 萬個(gè)查詢。相比之下，SelectDB 雖僅擁有三套集群規(guī)模，總數(shù)為 60 臺(tái)，但日峰值響應(yīng)量接近 90 萬個(gè)查詢。這一數(shù)據(jù)表明，SelectDB 在實(shí)時(shí)計(jì)算的響應(yīng)能力方面具有顯著優(yōu)勢(shì)，能夠更加高效地滿足大量查詢需求。

三、場景實(shí)踐

1. BI 報(bào)表與離線分析

在 BI 報(bào)表和離線分析場景中，原有 Trino 架構(gòu)面臨查詢穩(wěn)定性差和并發(fā)能力不足的雙重挑戰(zhàn)。特別是在早高峰時(shí)段，業(yè)務(wù)人員集中訪問報(bào)表系統(tǒng)，頻繁出現(xiàn)查詢超時(shí)和系統(tǒng)卡頓。同時(shí)，Trino 和 SparkSQL 在在面對(duì)高并發(fā)查詢時(shí)，處理效率與預(yù)期存在較大差距。

在查詢超時(shí)問題上，我們開啟了數(shù)據(jù)緩存（Data Cache）功能，并配置大容量本地磁盤，將熱數(shù)據(jù)持久化緩存。在每日數(shù)據(jù)就緒后，通過定時(shí)任務(wù)觸發(fā)對(duì)關(guān)鍵報(bào)表數(shù)據(jù)的預(yù)加載，使其在業(yè)務(wù)高峰前已緩存至本地。避免了查詢延遲高的問題，同時(shí)降低早高峰期間集中訪問導(dǎo)致帶寬拉滿的問題。在同等查詢量下，SelectDB 的慢 SQL（>10s）僅為 Trino 的百分之一。

在高并發(fā)查詢挑戰(zhàn)的應(yīng)對(duì)上，中通快遞在實(shí)時(shí)數(shù)倉建設(shè)階段，將離線數(shù)據(jù) DIM 維度層、應(yīng)用層的數(shù)據(jù)通過 SeaTunnel 寫入了 SelectDB 中，實(shí)現(xiàn)了結(jié)果表的查詢加速。從而實(shí)現(xiàn) 2000+ QPS 并發(fā)點(diǎn)查，數(shù)據(jù)報(bào)表更新及時(shí)度大大提高。

其次，SelectDB 提供了靈活豐富的 SQL 函數(shù)公式，并擁有高吞吐量的計(jì)算能力，數(shù)據(jù)分析師、產(chǎn)品經(jīng)理等業(yè)務(wù)人員通過可視化報(bào)表工具 + SelectDB 即可基本滿足 BI 的數(shù)據(jù)探索需求，大部分查詢響應(yīng)速度都在秒級(jí)完成。

該場景下，在保持高性能、高并發(fā)的同時(shí)，顯著節(jié)約了計(jì)算資源，SelectDB 集群規(guī)模約為 Trino 的 1/4。

2. 實(shí)時(shí)數(shù)據(jù)分析

面向決策層和運(yùn)營監(jiān)控的實(shí)時(shí)數(shù)據(jù)大屏，對(duì)查詢時(shí)效性要求極高，需要支持靈活的多維篩選和聚合分析。該場景涉及一張日增量超 6 億、總量超 45 億、字段超 200 列的超級(jí)寬表，并需基于該寬表進(jìn)行分鐘級(jí)準(zhǔn)實(shí)時(shí)分析。

原有 OLAP 引擎在任務(wù)增多時(shí)，負(fù)載過高時(shí)，任務(wù)執(zhí)行時(shí)效難以保證。比如，當(dāng)總?cè)蝿?wù)數(shù)超 50 時(shí)，執(zhí)行時(shí)間達(dá) 5-10 分鐘，效率極為低下。

因此，基于 SelectDB 以下特性成功解決上述問題：

• 查詢加速：借助倒排、BloomFilter 來支持多維分析，通過合理的分區(qū)分桶，在查詢時(shí)過濾非必要的數(shù)據(jù)，使數(shù)據(jù)掃描快速定位，加速查詢響應(yīng)時(shí)間。使 90% 以上的查詢從 10 分鐘左右縮短到 1 分鐘內(nèi)，部分達(dá)到秒級(jí)，性能提升 10 倍。
• 數(shù)據(jù)寫入秒級(jí)可見：SelectDB 支持主鍵表（Unique Key），并對(duì) Upsert、條件更新/條件刪除、部分列更新、分區(qū)覆蓋等各類更新提供了完備的支持，借助 Flink，可完成對(duì)數(shù)據(jù)的秒級(jí)可見，滿足高效靈活的數(shù)據(jù)更新需求

注意：對(duì)表結(jié)構(gòu)的設(shè)計(jì)需要結(jié)合業(yè)務(wù)、因地制宜，合理規(guī)劃 Key 和分區(qū)分桶列，一般將 where 條件或者 join 的字段定義成分桶較為合適

在該場景下，SelectDB 僅使用原集群 1/3 的資源就覆蓋了所有業(yè)務(wù)，實(shí)現(xiàn)了高效且經(jīng)濟(jì)的運(yùn)行。滿足了業(yè)務(wù)方對(duì)數(shù)據(jù)“既快又準(zhǔn)”的嚴(yán)格要求，提升了監(jiān)控和決策的效率。

四、成果及價(jià)值

中通引入 SelectDB 后，查詢性能實(shí)現(xiàn)巨大飛躍，延遲大幅下降，并發(fā)能力顯著提升，同時(shí)成本大幅降低，系統(tǒng)穩(wěn)定性與易維護(hù)性也得到增強(qiáng)。

未來，中通將會(huì)深化與 SelectDB 的合作：

• 提升易用性：利用 SelectDB 提供的更精煉、直觀的 Profile 信息，降低 SQL 調(diào)優(yōu)的難度和復(fù)雜度，提升開發(fā)運(yùn)維效率；
• 增強(qiáng)系統(tǒng)可觀測性：強(qiáng)化文件緩存等功能的可觀測性，加強(qiáng)數(shù)據(jù)傾斜處理能力，以提升整個(gè)系統(tǒng)的可靠性與可維護(hù)性；
• 深化湖倉一體：加強(qiáng) Multi Catalog 功能的應(yīng)用，提升湖倉分析能力，并測試 SelectDB 讀寫 Hive 外表的能力，實(shí)現(xiàn)更靈活的數(shù)據(jù)流轉(zhuǎn)；
• 打通權(quán)限與集成：推動(dòng)實(shí)現(xiàn) Hive Catalog 權(quán)限通過 JDBC 賬號(hào)的透傳，與公司現(xiàn)有大數(shù)據(jù)權(quán)限體系無縫融合，確保數(shù)據(jù)安全。