**作者介紹：** 馬成，慧策 JAVA高 級研發工程師

慧策（原旺店通）是一家技術驅動型智慧零售服務商，基於雲端計算 PaaS、SaaS 模式，以一體化智慧零售解決方案，幫助零售企業數字化智慧化升級，實現企業規模化發展。憑藉技術、產品、服務優勢，慧策現已成為行業影響力品牌並被零售企業廣泛認可。2021年7月，慧策完成最新一輪 D 輪 3.12 億美元的融資，累計完成四輪逾 4.52 億美元的融資，與諸多國際企業、行業頭部企業並列而行，被全球頂尖投資公司看好。

# 業務需求

慧經營是一款資料分析產品，主要提供經營分析、運營分析、應收對賬三大功能，面向企業的經營、運營、財務三個角色。如圖所示，慧經營上游為常見的電商平臺、直播平臺以及慧策主要的產品旺店通，這些平臺在交易過程中會產生大量的資料，包括收入、成本以及多種費用相關的資料。這些資料都比較分散，如果客戶手動進行資料彙總和分析，過程繁瑣、難度較高且展示不夠直觀。而慧經營可以在客戶授權下獲取、彙總這些資料，根據客戶需求提供經營分析、報表生成、賬單彙總等多項資料分析服務，以幫助客戶更好地經營店鋪。

![](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/5c0e3ea7aa6444df9c67e59bcba2bdcb~tplv-k3u1fbpfcp-zoom-1.image)

**為了能承載上述資料相關的服務，我們在系統架構設計之初需要考慮以下幾點：**

-   低成本：慧經營的付費模式為按需付費，這要求架構必須具有輕量化、易維護的特性。基於這點考慮，首先排除基於 Hadoop 的生態架構，雖然 Hadoop 足夠成熟，但是元件依賴度較高、繁瑣複雜，無論是運維成本還是使用成本都非常高。
-   高效能：電商資料為慧經營的主要資料來源，資料維度豐富， ETL 複雜度高；另外，在很多使用場景中明細查詢與聚合查詢是並存的，既需要夠快速定位資料範圍，又需要高效的計算能力，因此需要一個強大的 OLAP 引擎來支撐。
-   合理資源分配：客戶規模差異較大，有月單量只有 1 萬的小客戶，也有月單量高達千萬級別的大客戶，資源合理分配在這樣的場景下異常重要，因此要求 OLAP 引擎可以在不影響使用者體驗的前提下，可以根據客戶的需求進行資源分配，避免大小查詢資源搶佔帶來的效能問題。
-   高併發：能夠承受上游平臺多來源、高併發的大量資料的複雜 ETL，尤其在 618、雙 11 這樣的業務高峰期，需要具備高效查詢能力的同時，能夠承擔大量的寫入負載。

# 架構演進

## 架構 1.0

![](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/5a087c2634c944cd8c908ca9c2781bf6~tplv-k3u1fbpfcp-zoom-1.image)

基於以上考慮，我們在架構 1.0 中引入 Clickhouse 作為 OLAP 引擎。從上圖可看出該架構是一個完全基於後端 Java 以及 Spring 的技術架構，透過 Binlog 同步的方式透過 Canal 和 Kafka 將資料從 MySQL 同步至Clickhouse，來承接前端的各種經營分析報表服務。

架構 1.0 在上線不久後就遭遇了慢查詢問題。在早期客戶和資料量較少時，查詢效能尚可滿足客戶需求，但是隨著資料量的不斷增大，受限於 MySQL 本身的特性， ETL 效率逐漸低到無法令人接受，尤其在面對大客戶場景時，即使命中索引、掃描資料範圍僅在百萬級別，MySQL 應對該場景也已十分吃力。其次，面對激增的資料，ClikHouse 的多表 Join 也遭遇效能問題，由於其幾乎不支援分散式 Join，儘管提供了 Join 語義、但在使用上對多表 Join 的支撐較弱、複雜的關聯查詢常常會引起 OOM。

在 ClickHouse 單機效能不能支撐業務時，我們考慮擴充套件搭建叢集以提高效能，而 ClickHouse 分散式場景需要依賴 Zookeeper，同時需要單獨維護一套分散式表，這將使運維管理的難度和成本不斷升高。

除此之外，ClickHouse 還有幾個較大的問題，背離了我們最初對架構的選型要求：

-   不支援高併發，即使一個查詢也會用伺服器一半的 CPU。對於三副本的叢集，通常會將 QPS 控制在 100 以下。
-   ClickHouse 的擴容縮容複雜且繁瑣，目前做不到自動線上操作，需要自研工具支援。
-   ClickHouse 的 ReplacingMergeTree 模型必須新增final 關鍵字才能保證嚴格的唯 一性，而設定為final後效能會急劇下降。

## 架構 2.0

我們在架構 2.0 中引入 [Apache Doris](https://github.com/apache/doris) 作為 OLAP 引擎，並進行了一次整體的架構升級。選擇 Apache Doris 的主要原因有如下幾條：

-   **使用成本低：** 只有 FE 和 BE 兩類程式，部署簡單，支援彈性擴縮容，不依賴其他元件，運維成本非常低；同時相容 MySQL協議 和標準 SQL，開發人員學習難度小，專案整體遷移使用成本也比較低。
-   **Join 效能優異：** 專案存在很多歷史慢 SQL ，均為多張大表 Join，Apache Doris 良好的 Join 效能給我們提供了一段最佳化改造的緩衝期。
-   **社群活躍度高：** 社群技術氛圍濃厚，且 SelectDB 針對社群有專職的技術支援團隊，在使用過程中遇到問題均能快速得到響應解決。

![](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/87dd2f9784504e63a2b6c295edff6af8~tplv-k3u1fbpfcp-zoom-1.image)

如上圖所示，我們將原本基於 MySQL 的基礎資料儲存遷移到 Doris 中，同時將大部分的 ETL 遷移至在 Doris 內部進行，MySQL 只用於儲存配置資訊。同時引入了 Flink，DolphinScheduler 等元件，成功構建了一套以 Doris 為核心、架構簡潔、運維簡單的資料生產體系。

全新的架構也給我們帶來的顯著的收益：

-   **ETL 效率極大提升**：慧經營的資料維度豐富、 ETL 複雜度高，得益於 Apache Doris 強大的運算能力及豐富的資料模型，將 ETL 過程放在 Doris 內部進行後效率得到顯著提升；
-   **Join 耗時大幅降低**：查詢效能同樣得到極大提升，在 SQL 未經過改造的情況下，多表 Join 查詢耗時相較於過去有了大幅降低。
-   **並發表現出色**：在業務查詢高峰期可達數千 QPS，而 Apache Doris 面對高併發查詢時始終表現平穩；
-   **儲存空間節省**：Apache Doris 的列式儲存引擎實現了最高 1:10 的資料壓縮率，使得儲存成本得到有效降低。
-   **運維便捷**：Apache Doris 架構簡單、運維成本低，擴容升級也非常方便，我們前後對 Doris 進行了 3 次升級擴容，基本都在很短的時間內完成。

在使用 Apache Doris 的過程中，我們對 Doris 如何更好地應用也進行了探索，在此期間總結出許多實踐經驗，透過本文分享給大家。

# 實踐應用

## 分割槽分桶最佳化

在執行 SQL 時，SQL 的資源佔用和分割槽分桶的大小有著密切的關係，合理的分割槽分桶將有效提升資源的利用率，同時避免因資源搶佔帶來的效能下降。

因此我們在建立事實表分割槽時，會根據客戶的資料規模提供相匹配的分割槽方案，比如資料規模較小按年分割槽、規模大按月分割槽。在這種分割槽方式下，可以有效避免小查詢佔用過多資源問題，而大客戶的使用體驗也由於細粒度的分割槽方式得到了提升。

```
CREATE TABLE DWD_ORDER_... (    
...)    
...
PARTITION BY RANGE(tenant,business_date)
(
PARTITION p1_2022_01_01 VALUES [("1", '2022- 01- 01'), ("1", '2023- 01- 01')),
PARTITION p2_2022_01_01 VALUES [("2", '2022- 01- 01'), ("2", '2022- 07- 01')),
PARTITION p3_2022_01_01 VALUES [("3", '2022- 01- 01'), ("3", '2022- 04- 01')),
PARTITION p4_2022_01_01 VALUES [("4", '2022- 01- 01'), ("4", '2022- 02- 01')),    
...
)
```

而分桶的設定上我們採用了最新版本中增加的自動分桶推算功能，使用方式非常便捷，不用再去測算和預估每張表的資料量以及對應 Tablet 的增長關係，系統自動幫助我們推算出合理分桶數，提升效能的同時也使得系統資源得到更好利用。

參考文章：[一文教你玩轉 Apache Doris 分割槽分桶新功能｜新版本揭秘](https://mp.weixin.qq.com/s?__biz=Mzg3Njc2NDAwOA==&mid=2247514115&idx=1&sn=e009656026c1a7eb64a345d651ce7f49&chksm=cf2fb604f8583f12379675d5df9885dd84573d8c9d373606888f698045dc26ef63bca9b565be&token=2062446849&lang=zh_CN#rd)

## 多租戶和資源隔離方案

在 SaaS 業務場景中，多租戶和資源劃分是架構設計過程中必不可少的部分。多租戶（Multi-Tenancy ）指的是單個叢集可以為多個不同租戶提供服務，並且仍可確保各租戶間資料隔離性。透過多租戶可以保證系統共性的部分被共享，個性的部分被單獨隔離。

對於我們來說，客戶規模差異較大，有月單量只有 1 萬的小客戶，也有月單量高達千萬級別的大客戶，資源的合理分配與隔離在這樣的場景下異常重要。如果為每個租戶建立一個資料庫叢集，則叢集規模不可控且造成資源浪費。如果多個租戶共享一套資料庫叢集，使用者的需求可以相互補償，總體來時可以有很大的資源節約，並且計算規模越大成本越低，而在應對客戶查詢時，可以根據客戶的資料規模和查詢需求將資源池劃分給各客戶。

這裡我們採用了 Apache Doris 的節點資源組來區分大小客戶，避免了不同租戶以及查詢間的資源搶佔問題。

**節點資源組劃分**

節點資源劃分指將一個 Doris 叢集內的 BE 節點設定標籤（Tag），標籤相同的 BE 節點組成一個資源組（Resource Group），資源組可以看作是資料儲存和計算的一個管理單元。資料入庫的時候按照資源組配置將資料的副本寫入到不同的資源組中，查詢的時候按照資源組的劃分使用對應資源組上的計算資源對資料進行計算。

![](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/33f5290112104daabe651e8c6ad9e338~tplv-k3u1fbpfcp-zoom-1.image)

例如我們將一個叢集中的 3 個 BE 節點劃分為 2 個資源組，分別為資源組 A 和資源組 B，BE-1 和 BE-2 屬於資源組A，BE-3 屬於資源組B。資源組 A 有 2 副本的資料，資源組 B 有一個副本的資料。那麼當客戶 A 在寫入資料和查詢資料的時候會按照資源組配置使用資源組 A 上的儲存和計算資源，當客戶 B 寫入資料和查詢資料的時候會按照資源組配置使用資源組 B上 的儲存和計算資源。**這樣便能能很好的實現同一個叢集，為不同租戶提供不同的負載能力。**

具體操作如下：

1.  設定標籤：

為 BE 節點設定標籤。假設當前 Doris 叢集有 3 個 BE 節點。分別為 `host[1-3]`。在初始情況下，所有節點都屬於一個預設資源組（Default）。

我們可以使用以下命令將這6個節點劃分成3個資源組：`group_a`、`group_b`：

```
  alter system modify backend "host1:9050" set ("tag.location" = "group_a");
  alter system modify backend "host2:9050" set ("tag.location" = "group_a");
  alter system modify backend "host3:9050" set ("tag.location" = "group_b");
```

這裡我們將 ` host[1-2]  `組成資源組 `group_a`，` host[3]  `組成資源組`  group_b `。

2.  設定資源組資料分配策略

副本分佈策略定義：資源組劃分好後，我們可以將客戶資料的不同副本分佈在不同資源組內。假設一張使用者表 UserTable。我們希望資源組 A 記憶體放 2 個副本，資源組 B 存放 1 分副本

```
  create table UserTable (k1 int, k2 int)
  distributed by hash(k1) buckets 1
  properties(
      "replication_allocation"="tag.location.group_a:2, tag.location.group_b:1"
  )
```

資源組繫結：透過設定客戶的資源組使用許可權，來限制某一客戶的資料匯入和查詢只能使用指定資源組中的節點來執行。

```
  set property for 'user_a' 'resource_tags.location' = 'group_a';
  set property for 'user_b' 'resource_tags.location' = 'group_b';
```

這裡將 ` user_a  `和`  group_a  `資源繫結，`user_b` 和`  group_b ` 資源繫結。繫結完成後，`user_a` 在發起對 UserTable 表的查詢時，只會訪問 ` group_a  `資源組內節點上的資料副本，並且查詢僅會使用 `group_a` 資源組內的節點計算資源。

**透過 Apache Doris 提供多租戶和資源隔離方案，能夠將叢集資源更合理的分配給各** **客戶** **，可以讓多租戶在同一 Doris 叢集內進行資料操作時，減少相互之間的干擾，同時達到資源成本的有效降低。**

## 高併發場景的支援

高併發也通常是 SaaS 服務場景面臨的挑戰，一方面是慧經營已經為眾多客戶提供了分析服務，需要去同時承載大規模客戶的併發查詢和訪問，另一方面，在每日早晚業務高峰期也會面臨更多客戶的同時線上，通常 QPS 最高可達數千，而這也是 Apache Doris 表現得非常出色的地方。在上游 Flink 高頻寫入的同時，Apache Doris 表現極為平穩，隨著查詢併發的提升，查詢耗時相較於平時幾乎沒有太大的波動。

應對高併發場景的關鍵在於利用好分割槽分桶裁剪、索引、快取等系統機制來減少底層資料掃描。在 Doris 中會將資料表的前幾列作為排序鍵來構建字首索引，同時還有 ZoneMap 以及 Bloom Filter 等索引。在執行查詢時，透過分割槽分桶裁剪以及索引可以快速過濾到不在查詢範圍內的資料，減少 CPU 和 IO 的壓力。

在與社群的溝通中還了解到，即將釋出的新版本還將進一步提升併發支援，引入行儲存格式、短路徑最佳化以及預處理語句等來實現上萬 QPS 的超高併發，可以滿足更高併發要求的 Data Serving 場景，這也是我們十分期待的功能。

## 資料生命週期管理

![](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/7b8911c198ec4859876052a869b786e3~tplv-k3u1fbpfcp-zoom-1.image)

我們自研了一套生命週期管理工具，基於資源的分配，可以提供客戶級定製化冷卻策略。根據各個業務場景的客戶需求及付費情況，提供不同長度的資料保留策略，同時得益於 Apache Doris 提供的 OutFile 功能，實現刪除或者匯出 S3 兩種冷卻方式，當我們再次需要這些資料時，可透過 Load 的方式從 S3 導回資料。

除了透過 OutFile 將資料檔案匯出至 S3 以外，社群在後續版本中還將提供分割槽級別的冷熱資料分離策略。當前我們資料分割槽都是基於日期範圍來設定，因此可以利用時間分割槽進行冷熱資料的劃分。透過配置分割槽級別的 Freeze Time，轉冷後的歷史資料可以自動下沉至成本更低的物件儲存上。在面對歷史冷資料的查詢時，Doris 會自動拉取物件儲存上的資料並在本地 Cache 以加速查詢，而無需執行匯入操作。透過冷熱資料分離以及冷資料 Cache，既能保證資源節省，也能保證冷資料的查詢效能不受影響。

# 總結規劃

## 收益

引入 Apache Doris 之後，新架構的整體查詢響應速度都有了較大的提升， 儲存成本顯著降低，後續我們將繼續探索 Doris 新特性，進一步實現降本增效。

## 規劃

-   目前正在強化 Apache Doris 的後設資料管理建設，我們希望透過該服務能更好的協助開發人員使用 Doris，包括資料血緣追蹤等；
-   嘗試使用更多 Apache Doris 的新功能，在 1.2.0 版本中新增的 Java UDF 功能可以極大降低資料出入庫的頻率，更便捷地在 Doris 內部進行資料 ETL，這一功能我們正在嘗試使用中；
-   探索更好的資源分配的方案，包括 SQL 代理以及嘗試 Doris 後續提供的 Spill 功能，以更好進行資源分配應用。

最後，再次感謝 Apache Doris 社群和 SelectDB 技術團隊在我們使用過程中提供的許多指導和幫助，提出問題都會及時的響應並儘快協助解決，未來我們也希望深度參與到社群建設中，為社群的發展出一份力。

從 Clickhouse 到 Apache Doris，慧策電商 SaaS 高併發資料服務的改造實踐

相關文章