福建縱騰網路有限公司（簡稱“縱騰集團”）成立於 2009 年， 以“全球跨境電商基礎設施服務商”為企業定位，聚焦跨境倉儲與物流， 為全球跨境電商商戶、出口貿易企業、出海品牌商提供海外倉儲、商業專線物流、定製化物流等一體化物流解決方案， 旗下擁有穀倉海外倉 、雲途物流 、WORLDTECH 等知名品牌 。

作者｜縱騰集團資料技術架構師 張彬華

隨著縱騰集團業務的快速發展，各產品線提出的資料需求越發嚴格，而早期基於多套 CDH 大資料架構的技術棧和元件繁雜，開發和運維難度高、效率低，資料質量和時效難以保障，已無法滿足當下資料分析需求，嚴重影響相關工作的開展。因此，縱騰集團在 2022 年正式引入 Apache Doris，基於 Apache Doris 構建了新的流批一體資料架構，同時建立了以 Apache Doris 為核心的資料中臺。 構建過程中對讀寫時效性、服務的穩定性及高併發讀寫等多方面進行了優化，在這一過程中我們也積累了諸多實踐經驗，在此總結分享給大家。

早期架構

早期數倉架構主要分為兩套基於 CDH 的大資料叢集，這兩套架構用於不同產品線的數倉需求、資料大屏和 BI 報表等應用。

這兩套架構為獨立的資料管道，具有耦合度低，叢集間相互獨立等特點，便於精細化管理。但隨著業務需求的不斷變化，這樣的特點也引發出許多新的問題。

遇到的問題

• 元資料和資料質量缺乏管控，資料質量無法得到保證
• 不同業務資料獨立儲存維護導致資料孤島，不利於資料整合
• 每個叢集的機房分佈不一，維護成本非常高
• 叢集間的技術棧和元件較多且存在差異性，對統一開發運維和資料整合都極具挑戰性

架構選型

為了解決早期架構的痛點、更好滿足日益嚴苛的資料需求，我們希望能有一款產品幫助我們快速構建流批一體的數倉架構、構建資料中臺服務。

我們對傳統數倉、 實時數倉和資料湖進行了對比。從上圖可知，傳統數倉可以支撐超 PB 級的海量資料，但是互動查詢效能相對差一些，偏離線場景，不滿足我們對資料實時性的要求；資料湖可以支撐超海量的資料，支援資料更新，查詢效能適中，但是資料湖近兩年才開始應用，成熟度較低，使用風險較大；實時數倉適用 PB 級資料儲存，支援資料更新且查詢效能非常好。結合我們的要求，實時數倉與我們的使用和需求場景都比較貼合，因此我們最終決定選擇實時數倉作為資料底座。

接著我們對市面上較為流行的三款實時數倉：ClickHouse、Apache Druid、Apache Doris 進行了選型對比，對比圖如下：

對比可知，Apache Doris 優勢明顯、價效比更高，具有獨立主從架構簡單、運維更靈活便捷、豐富的資料模型、優秀的查詢效能和周全的生態規劃等諸多優勢，對比這三個產品，Apache Doris 最符合我們的選型要求。

新資料架構

新資料架構基於 Apache Doris 簡化了資料採集、儲存和計算的流程：

• 結合 DataHub 實現自研元資料採集和週期管理
• 通過 Seatunnel 整合 Flink Doris Connector 稍加改造實現全量加增量資料的一體化採集
• 簡化儲存媒介，對 ClickHouse、Kudu、HBase 等技術棧進行收斂，由 Apache Doris 進行流批資料的統一儲存
• 以 Apache Doris 為核心資料底座，結合 Apache Kyuubi 的 JDBC 引擎直連查詢（自研）和 Spark 引擎中的 Spark Doris Connector 進行 ETL 開發（原生），統一計算引擎管理、許可權管控和對外服務。

基於上述幾點進行了資料應用開發及對外提供資料服務，構建了資料中臺。

資料中臺

我們以 Apache Doris 為核心底座建立了資料平臺，核心功能包括：指標中心、元資料中心、基礎配置中心、即席分析和資料介面服務中心，其中指標中心和即席分析的資料主要來源於 Aapche Doris ，當前已上線幾百個指標。

數倉建模

我們結合 Apache Doris 的特性重新對數倉進行了建模，數倉分層與傳統數倉類似，其中 ODS 資料為存量加增量一體的匯入模式，同時為防止出現[隨機查詢結果問題]，ODS 層最終選用 Unique 資料模型，相比於 Aggregate 模型可以實現寫時合併（Merge-on-Write），有效提高資料實時性，且 Aggregate 模型查詢效能更接近於 Duplicate 模型，對於 ODS 層是非常好的選擇。

DIM/DED/DWS/ADS 層主要選用 Aggregate 資料模型；Aggregate 資料模型提供的四種聚合方式可以在大部分場景下達到事半功倍的效果，幫助我們快速應對不同的需求場景。

• SUM： 能夠高效實現 PV 類指標計算，但對於 UV 類的指標需要考慮預去重。
• MAX/MIN： 常用於最大最小運單時間節點類指標或包裹體積/重量最大最小值的指標計算。
• REPLACE_IF_NOT_NULL： 可以自動地過濾空值，非常便捷地實現僅記錄最後一條資料，適用於大部分 DW 場景。

資料匯入

ODS 層的資料匯入目前主要以 Stream Load 為主，在 HDFS 上的歷史存量資料也會通過 Broker Load 或Spark Load 匯入。DW 層資料主要以 insert into 方式匯入，同時為減輕 Doris 記憶體壓力，我們將部分 ETL 任務放到 Kyuubi On Spark 引擎上去計算，目前在 DolphinScheduler 每天平穩排程 Doris DW 任務有上萬個，其中大部分為 T+1 任務，小部分為小時級任務。

實踐經驗

對於以 Apache Doris 為核心的新資料架構，我們規劃了6個階段進行執行測試，直至可以上線執行。（重點關注壓測階段和執行階段，有一些除錯優化經驗分享給大家）

1、準備階段

引入 Apache Doris 時是 2022 年 2月，因此選擇當時最新版本 Apache Doris 0.15 Release 版本進行應用，主要考慮維度如下：

• 支援事務性插入語句功能
• 支援 Unique Key 模型下的 Upsert
• 支援 SQL 阻塞 List 功能，可以通過正則、雜湊值匹配等方式防止某些 SQL 的執行
• 官方不支援跨兩位版本號進行升級，而 0.15 為當時最新的 Release 版本，選用該版本利於後期版本升級
• 可通過資源標籤的方式將一個Apache Doris 叢集中的 BE 節點劃分為多個資源組，實現多租戶和資源隔離
• 該版本提供了官方認可的 Flink-Doris-Connector/Spark-Doris-Connector/DataX Doriswriter 等外掛，利於ETL流程建設

2、驗證階段

該階段主要是為了二次驗證官方文件中介紹的功能是否滿足我們的實際運用場景，比如生態擴充套件中的 Connector、外表聯邦查詢、各種 Load 方式、多租戶隔離及物化檢視等。

3、壓測階段

壓測階段首先進行資料生成，資料集選用的是 TPC-DS 資料，接著根據 Doris 的特性對 DDL 和 SQL 等規則進行對應調整，最後通過指令碼將資料匯入到 Apache Doris 儲存中，再通過自動化指令碼進行查詢及匯入壓測，最終將壓測結果輸出到 MySQL 表中，量化為圖表進行展示。下方為本階段的基本配置及壓測過程介紹：

- 硬體環境

• 記憶體：256G
• CPU：96C
• 硬碟：SSD 1.92T * 8

- 軟體環境

• Apache Doris 版本：0.15-release/1.0-release（該階段進行時，1.0-release 版本剛好釋出）
• Apache Doris 叢集：3 FE + 9 BE
• 系統：CentOS Linux release 7.9.2009

- 資料集資訊

我們生成了 1T、5T、10T 的 TPC-DS 資料集，1T 的資料集約有 30 億資料量。

查詢壓測

壓測過程中，最初使用 0.15-release 版本進行測試，正巧 1.0-release 版本釋出，後決定更換為 1.0-release 版本進行後續的壓測。下圖是基於 1T 的 TPC-DS 資料在同等硬體配置環境下和某商業 MPP 資料庫的對比結果：

如圖所示，Apache Doris 的查詢壓測效能優異，有著明顯的效能優勢，作為開源產品能夠達到這樣的效果是非常優秀也是十分不易的。

匯入壓測

• 匯入方式：通過 DataX Doriswriter 以 StreamLoad 方式進行寫入壓測
• 資料來源：為避免因 Source 端原因影響寫入時效，選擇 100 張相同大表，即 100 個併發從內網 Hive 中匯入（例如 tpcds-ds 的 store_sales_1t 表）
• 資料模型：選用 Unique 模型（模擬ODS層），同時為充分考慮 Compaction 效能及小檔案場景，每張表設定 70 個 Tablet

經調整優化後，最大寫入時效為 269 MB/S&680K ops/s，平均寫入時效 70 MB/S&180K ops/s，寫入時效大幅提升。

4、上線階段

該階段主要是確認 Apache Doris 上線需要的檢查清單、預調引數、BE 資源組規劃及使用者許可權的劃分。

• 檢查清單：包括但不限於 FE & BE 埠、網路檢查及 Apache Doris 的一些功能性驗證，例如讀寫是否正常等。
• 預調引數：確認優化後的 FE&BE 引數是否配置，是否開啟global enable_profile、動態分割槽以及資料盤儲存位置是否有誤等。
• BE 資源組：由於我們需要通過 Apache Doris 的多租戶特性對不同的使用者進行資源隔離，所以需要提前規劃好每個 BE 節點對應的資源組。
• 使用者許可權：對於不同的使用者群體提前規劃好許可權範圍，比如分析師開發只需要SELECT_PRIV許可權，而 ETL 工程師需要SELECT_PRIV、LOAD_PRIV和CREATE_PRIV許可權。

5、宣導階段

該階段主要是輸出前面各階段的 TimeLine、總結以及上線後使用 Apache Doris 的注意事項說明，比如我們用到多租戶隔離，那麼 DDL 建表時則需要在 Properties 中顯示指定各副本對應的資源組：

create table zt_table
......
properties(
    "replication_allocation"="tag.location.group_a:1, tag.location.group_b:1, tag.location.group_c:1"
)

6、執行階段

Tablet 規範問題

問題描述： 上線執行一段時間後，隨著越來越多的資料增長，叢集每次重啟後一週左右，讀寫就會開始變得越來越慢，直到無法正常進行讀寫。

問題處理：

• 經過對生產和 UAT 環境的對比測試以及對數倉表的 Schema 的分析，我們發現有些表資料並不大，但是 Bucket 卻設定的非常大。

• 結合show data from database命令，我們將整個叢集所有表的 Bucket 資訊羅列出來，明確了大部分表的 Bucket 設定的不合理；而當前叢集共 20T 左右資料，平均 1T 資料近 10W 個 Tablet，這就會導致小檔案過多，造成 FE 元資料負載過高，從而影響匯入和查詢效能。
• 定位原因後與社群小夥伴二次確認，並根據官方建議將 Bucket 設定不合理的表全部調整，調整後集群逐步恢復讀寫正常。（即將釋出的 Apache Dorie 1.2.2 版本將推出 Auto Bucket 動態分桶推算功能，可以根據歷史資料和機器數目自動推算新建 Partition 的分桶個數，保證分桶數始終保持在合理範圍內，可有效解決上述問題）

問題小結：

• Tablet數 = 分割槽數 * 桶數 * 副本數
• 1TB 資料的 Tablet 數量控制在 8000 個左右（三副本控制到 2.4W 左右）
• 建議大表的單個 Tablet 儲存資料大小在 1G-10G 區間，可防止過多的小檔案產生
• 建議百兆左右的維表 Tablet 數量控制在 3-5 個，保證一定的併發數也不會產生過多的小檔案

叢集讀寫優化

問題描述： 1.1.3 release 版本中，高併發的同時進行 Stream Load、Broker Load、insert into 和查詢時，讀寫會變得非常慢，如下圖 11/01 19:00 併發上來後的 Txn Load 所示：

問題處理：

\1. 我們進行了十幾輪對比測驗，結論如下：

• • 寫入速度與併發的增長成反比（但不會驟變，而是緩慢變化）
  • 單表 Bucket（Tablet）設定過大會導致叢集寫入速度驟減；例如 A 庫的 TA 表，設定 80 個 Bucket 時，啟動相關 Flink Sink Job 就會導致叢集整體寫入速度迅速變慢，降低 Bucket（9~10個）時寫入恢復正常。
  • insert into select 的 ETL 任務與 Stream Load 寫入任務會進行資源搶佔，同時併發執行會使整個叢集讀寫變慢。

\2. 通過be.INFO發現，80 個 Bucket 表寫入某個 Tablet 的memsize/rows/flushsize/duration數值比 10 個 Bucket 寫入時的數值呈數倍之差，即 80 個 Bucket 表的資料寫入時效無論 Memsize 還是 Flushsize 都非常小、但花費時間卻很長。

\3. 同時收集 Pstack 日誌，經過分析可以確定，Tcmalloc 在頻繁地尋找pageheap_lock，導致高頻競爭鎖從而降低了讀寫效能。

\4. 於是，進行如下引數調整：

減少doris_be程序記憶體返回給linux系統的頻率，從而減少tcmalloc頻繁競爭鎖的情況
tc_use_memory_min = 207374182400
tc_enable_aggressive_memory_decommit = false
tc_max_total_thread_cache_bytes=20737418240

\5. 調參並滾動重啟 BE 後，叢集狀況如下圖所示：

18:50 前將 Broker Load、insert into 和查詢任務同時開啟，18:50 後將 Stream Load 任務也開啟（包括 80 bucket的表），叢集整體的讀寫效能不僅沒有下降，反而 Stream Load 時效突破了壓測階段的最大值 269 MB/S&680K /ops/s，並且持續穩定。

問題小結：

使用 Apache 1.1.3 及以上版本，非常推薦調整 Tcmalloc 相關引數，減少doris_be程序與系統之間的記憶體申請回收過程，可明顯減少鎖競爭的現象，大大提升讀寫效能和叢集穩定性。（從 Apache Doris 1.1.5 版本開始，增加了Tcmalloc 簡化配置，可將眾多 Tcmalloc 引數歸約到引數memory_mode中，compact 為節約記憶體模式，performance 為效能模式，使用者可根據實際需求進行調整）

總結收益

當前 Apache Doris 的生產叢集為 3 FE + 9 BE 組合， 已匯入集團存量和增量資料的 60%以及部分 DW 資料生成，3 副本共佔 44.4TB 的儲存。

依賴 Apache Doris 自身優異特性及其生態圈幫助我們快速構建了一套新的流批一體資料架構，平均每天實時入庫的資料量達到上億規模，同時支援上萬個* 排程任務平穩執行，相比早期架構單表查詢效率提升近 5 倍 ，資料匯入效率提升近 2 倍*，記憶體資源使用率顯著減少。除此之外，Apache Doris 以下優勢也是我們快速構建資料架構的重要推動力：

• 擴充套件表：聯邦查詢的設計，便於整合其它儲存
• 資料表設計：豐富的資料模型，可快速應對不同的資料需求。
• 資料查詢：不同的 Join 運算元結合自身完善的優化器，讓查詢快而穩。
• 架構設計：架構清晰明瞭且運維簡單，大大地降低了我們的運維成本。
• 資料匯入：各種 Load 方式及 Connector 的擴充套件，基本涵蓋大部分的資料同步場景應用。
• 活躍度：社群高度活躍，SelectDB 為 Apache Doris 社群組建了一支專職技術支援團隊，疑難雜症基本能在 12H 內快速響應並有社群小夥伴跟進和協助解決。

未來規劃

結合當下業務場景的考慮，未來我們將引入資料湖進行非結構化和結構化資料一體儲存，進一步完善流批一體架構。同時也會將 Apache Doris 迴歸它最本質的定位，專注於 OLAP 分析場景，並通過 Apache Doris 統一湖倉查詢引擎層，發揮其最大的功效。

最後，非常感謝 Apache Doris 社群和 SelectDB 團隊的張家鋒、曲率和楊勇強等小夥伴對我們無私的技術支援，未來我們也將持續參與 Apache Doris 社群建設中，貢獻綿薄之力。祝 Apache Doris 社群和 SelectDB 越來越好，日臻完善！