打破資料孤島，Apache Doris 助力縱騰集團建構流批一體數倉架構

福建縱騰網絡有限公司（簡稱“縱騰集團”）成立于 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 越來越好，日臻完善！

# 相關連結：

SelectDB 官網：

Apache Doris 官網：

Apache Doris Github：