資料分片（Sharding）是分散式資料庫分而治之 (Divide And Conquer) 這一設計思想的體現。過去的單機資料庫在大資料量下往往面臨儲存和 IO 的限制，而分散式資料庫則透過資料劃分的規則，將資料打散分佈至不同的機器或節點上，形成分散式儲存，因此突破了單機儲存空間和 IO 的瓶頸、使庫表資料量可以無限擴充。

資料分片主要有範圍分片或雜湊分片這兩種方式，而在實際資料庫的實現中，往往呈現為分割槽和分桶兩種形式。分割槽一般是按照時間或其他連續值對資料進行劃分，在執行查詢操作時可以透過分割槽裁剪過濾不必要的範圍掃描，提升執行效率，同時也使得對分割槽資料的增刪改等管理操作更為便捷。而分桶則是按照某個關鍵字執行雜湊運算，將相同雜湊值的資料放到一起，這樣可以有效定位資料、避免資料傾斜。

在[ Apache Doris](http://doris.apache.org) 中，同樣也遵從一定的資料分佈規則。資料以關係表（Table）的形式進行呈現，會依次按照先分割槽（Partition）、再分桶（Bucket）的方式劃分，最終在同一個分桶中的資料會形成資料分片（Tablet）。Tablet 是 Apache Doris 中多副本高可用、叢集間資料排程與均衡的最小物理儲存單位。

![圖片](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/156b3142b40e41af821de796525390e1~tplv-k3u1fbpfcp-zoom-1.image)

圖1：Table-Partition-Tablet 之間的關係

# **#  現狀與問題**

在 Doris 中，分割槽與分桶是如何建立的？我們以一個網站站點的建表例項說明分割槽與分桶的建立方式，該網站的站點建表語句如下：

```sql
-- 該表記錄了某個時間點，在某個站點上各個使用者的pv資料
CREATE TABLE demo.test_tbl(
    sdate      DATETIME,  -- 日期
    site       INT,  -- 站點id
    city       VARCHAR(64),  -- 城市
    user       VARCHAR(32)  DEFAULT '', -- 使用者名稱
    pv         BIGINT -- pv量
) ENGINE=olap DUPLICATE KEY(sdate, site, city)
[PARTITION_DESC]
[BUCKET_DESC]
PROPERTIES ("replication_num" = "1");
```

其中 [PARTITION_DESC] 表示建立分割槽的詳細語句，[BUCKET_DESC] 表示建立分桶的語句。

### 建立分割槽

Apache Doris 支援兩種分割槽形式，List Partition 與 Range Partition。

**List Partition**

List Partition 相當於對分割槽的列值進行列舉，因此選擇的分割槽列最好是有區分度的可列舉值，例如本例中的 city。根據 city 列的列舉值建立多個 List Partition，則 `PARTITION_DESC`可以寫為：

```sql
-- 以city作為分割槽列，建立華北、東北、華中、西南等分割槽
PARTITION BY LIST(city)
(
    PARTITION `p_huabei` VALUES IN ("beijing", "tianjin", "shijiazhuang"),
    PARTITION `p_dongbei` VALUES IN ("shenyang", "dalian"),
    PARTITION `p_huazhong` VALUES IN ("wuhan", "changsha")
    PARTITION `p_xinan` VALUES IN ("chengdu", "chongqing")
)
```

**Range Partition**

建立 Range partition 一般使用時間列，Range Partition 又可以分為靜態和動態兩種方式：

**- 靜態 Range Partition**

此類 Partition 的建立會生成一個左閉右開的區間，定義一個分割槽只需要指定右邊界，該分割槽的左邊界由上一個分割槽的右邊界確定，`PARTITION_DESC`可以寫為：

```sql
-- 以sdate這個時間列作為分割槽列，
-- 日期處於[min, 2023-01-01)的資料，都放到名為p2022的分割槽下；
-- 日期處於[2023-01-01, 2023-01-02)的資料，都放到名為p20230101的分割槽下；
-- 日期處於[2023-01-02, 9999-12-31)的資料，都放到名為pmax的分割槽下；
PARTITION BY RANGE(sdate)
(
    PARTITION `p2022` VALUES LESS THAN ("2023-01-01"),
    PARTITION `p20230101` VALUES LESS THAN ("2023-01-02"),
    PARTITION `pmax` VALUES LESS THAN ("9999-12-31")
)
```

可以看出，p20230101 這個分割槽的左邊界由 p2022 分割槽的右邊界確定，而 pmax 的左邊界由 p20230101 的右邊界確定。需注意的是，此處為了舉例說明動態分割槽，使用了一個很大的邊"9999-12-31"，實際業務中很少會直接建立從 2023-01-02 到 9999-12-31 的分割槽。

**- 動態 Range Partition**

上述靜態的分割槽需要手動指定邊界，分割槽個數太多使用起來也不方便。動態 Range Partition 幫助我們解決了這個問題，只需指定一些分割槽的引數即可動態建立，PARTITION_DESC 相對更簡單，只需指定哪個列作為分割槽列即可：

```sql
PARTITION BY RANGE(sdate)()
```

剩餘引數需要在`PARTITION`進行配置：

```sql
PROPERTIES (
  "dynamic_partition.enable" = "true",
  "dynamic_partition.time_unit" = "DAY",
  "dynamic_partition.start" = "-30",
  "dynamic_partition.end" = "3",
  "dynamic_partition.prefix" = "p",
  "dynamic_partition.create_history_partition"="true",
  "replication_num" = "1"
);
```

動態分割槽引數說明如下：

![圖片](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/0ce12f4f67ce4927bb7fb0fb283711a7~tplv-k3u1fbpfcp-zoom-1.image)

### 建立分桶

分桶在物理層面即資料分片（Tablet）。在資料表完成分割槽後，指定部分列作為分桶列，將這些列資料中相同雜湊值的資料合到一起，形成了 Tablet。一個表中 **Tablet 總數量 = 分割槽數（Partition num）x 分桶數（Bucket num）x 資料副本數（Replication_num）** 。

[BUCKET_DESC] 語句非常簡單，只需要一句：

```sql
DISTRIBUTED BY HASH(site) BUCKETS 20
```

此時指定以 site 列的雜湊值作為分桶，並且分桶個數設定為 20 個，**需要注意的是這裡的 20 僅作為示例，合適的分桶個數需要根據分割槽大小來確定**。實際上單個分桶即 Tablet 的資料量理論上沒有上下界，但建議在 **1GB - 10GB** 的範圍內，即假設分割槽大小為 20GB，那麼分桶個數設定為 10-20 個是合適的。

### 不足與思考

從以上對分割槽分桶的介紹，相信有不少使用者和讀者仍能發現其中一些不足之處：

-   分割槽數量過多的情況下，使用 List Partition 或者靜態 Range Partition 會使得 **SQL 較為繁瑣，編寫起來費時費力**；
-   若是使用動態 Range Partition，則需要掌握多個引數，**使用方式不友好且學習成本較高**；而當存在大量歷史冷資料來說，動態 Range Partition 只能指定單一粒度，**無法靈活組合不同的分割槽粒度**；
-   分桶個數的設定十分依賴使用者對 Apache Doris 資料分佈機制和業務資料本身的理解，**使用門檻較高**。不合理的分桶設定將對系統效能和穩定性造成一定程度衝擊：分桶數太多將導致單個 Tablet 的資料量過小，資料聚合效果不佳、查詢效能不能得到有效發揮，並且後設資料管理壓力大；個數太少則單個 Tablet 包含的資料量過大，不利於副本的遷移、補齊，且會增加 Schema Change 或者 Rollup 操作失敗重試的代價。

# **#** **批次分割槽與Auto Bucket的設計與實現**

克服資料庫的複雜性是 Apache Doris 一直追求的目標之一，針對以上分割槽分桶存在的易用性問題，在 Apache Doris 最新的版本中已經得到解決。在 **Apache Doris 1.2.1 版本中，我們新增了批次建立分割槽功能**，簡潔的語法和靈活的使用方式讓批次建立歷史分割槽更加得心應手；而針對分桶設定帶來的學習成本，**Apache Doris 在即將釋出的 1.2.2 版本中新增了 Auto Bucket 自動分桶推算功能**，分桶個數不再依賴於人工設定，透過規則的智慧計算即可保證合理的資料劃分，降低使用者學習成本的同時還可以最大化提升使用者開發效率。

### **批次建立分割槽**

批次建立分割槽功能在前期充分調研了使用者的需求，本著簡潔、強大、易用的設計目標，將設計核心鎖定在幾個要素中：

-   時間區間範圍（會考慮開閉問題）
-   時間跨度（即每個分割槽的時間維度的大小）
-   時間單位（年、月、日、時、周等）

結合前面提到的網站站點模型，假設其資料包含從幾年前直到現在的全量資訊，想要將十年內的資料按每一天一個分割槽進行建立。在批次分割槽功能中，`PARTITION_DESC`只需要一句，並且不用在`PARTITION`中設定分割槽相關引數：

```sql
-- 當然，分割槽建立個數受到max_multi_partition_num引數控制，該值預設為4096，有需求可以修改
PARTITION BY RANGE(sdate)
(
   FROM ("2013-01-01") TO ("2023-01-01") INTERVAL 1 DAY
)從這個 case 來看，批次分割槽功能的語法更為簡潔，但該功能的易用性和靈活性遠不止於此。
```

從這個 case 來看，批次分割槽功能的語法更為簡潔，但該功能的易用性和靈活性遠不止於此。

假設有另一批資料：公司前幾年的資料量較大且為冷資料，故可以將一年的資料合到一個分割槽裡面；而後來因為業務迅速發展，需要將每一月的資料作為一個分割槽；隨著公司業務進一步發展，按月分割槽已經不能滿足快速增長的資料需求，需要按周進行分割槽；……；時至今日，公司每天產生海量資料，可能需要按小時分割槽才能符合需求。根據這個場景，不難寫出批次分割槽建立的 PARTITION_DESC：

```sql
-- 此處需要注意，如果要使用小時級別的分割槽，則分割槽列必須是datetime型別
-- 同樣的，分割槽建立個數也受到max_multi_partition_num引數控制
PARTITION BY RANGE(sdate)
(
   FROM ("2000-01-01") TO ("2021-01-01") INTERVAL 1 YEAR,
   FROM ("2021-01-01") TO ("2022-01-01") INTERVAL 1 MONTH,
   FROM ("2022-01-01") TO ("2023-01-01") INTERVAL 1 WEEK,
   FROM ("2023-01-01") TO ("2023-02-01") INTERVAL 1 DAY,
   FROM ("2023-02-01 00") TO ("2099-12-31 23") INTERVAL 1 HOUR
)
```

除了上述不同時間粒度的分割槽可以靈活組合外，還可以將靜態 Range Partition 和批次分割槽功能結合起來。例如需要將該公司 2022-01-01 到 2023-01-01 的資料按天建立分割槽，2022-01-01 之前的資料歸到一個名為"pold"分割槽中，我們可以將靜態分割槽和批次分割槽組合起來，PARTITION_DESC如下：

```sql
PARTITION BY RANGE(sdate)
(
   PARTITION pold VALUES LESS THAN ("2022-01-01"),
   FROM ("2022-01-01") TO ("2023-01-01") INTERVAL 1 DAY
)
```

**批次分割槽建立功能支援不同時間粒度，其語法簡潔有力，且各種型別分割槽可以靈活組合，在面對大量歷史分割槽和部分特殊分割槽的需求時，該功能顯得遊刃有餘，可以極大提高開發效率。** 批次分割槽功能 PR：*https://github.com/apache/doris/pull/13772*****

### **Auto Bucket 自動分桶推算**

以往建立分桶時需要手動設定分桶數，而自動分桶推算功能是 Apache Doris 可以動態地推算分桶個數，使得分桶數始終保持在一個合適範圍內，讓使用者不再操心桶數的細枝末節。首先說明一點，為了方便闡述該功能，該部分會將桶拆分為兩個時期的桶，即初始分桶以及後續分桶。 *（這裡的初始和後續只是本文為了描述清楚該功能而採用的術語，Apache Doris 分桶本身沒有初始和後續之分）* 從上文中建立分桶一節我們知道，`BUCKET_DESC`非常簡單，但是需要指定分桶個數；而在自動分桶推算功能上，`BUCKET_DESC`的語法直接將分桶數改成"**Auto**"，並新增一個 Properties 配置即可：

```sql
-- 舊版本指定分桶個數的建立語法
DISTRIBUTED BY HASH(site) BUCKETS 20

-- 新版本使用自動分桶推算的建立語法
DISTRIBUTED BY HASH(site) BUCKETS AUTO
properties("estimate_partition_size" = "100G")
```

新增的配置引數`estimate_partition_size`表示一個單分割槽的資料量。該引數是可選的，如果沒有給出則 Doris 會將 estimate_partition_size 的預設值取為 10GB。從上文中已經得知，一個分桶在物理層面就是一個Tablet，為了獲得最好的效能，建議 Tablet 的大小在 **1GB - 10GB** 的範圍內。那麼自動分桶推算是如何保證 Tablet 大小處於這個範圍內的呢？總結起來不外乎幾個原則：

-   若是整體**資料量較小**，則分桶數不要設定過多
-   若是整體**資料量較大**，則應使桶數跟總的磁碟塊數相關，充分利用每臺 BE 機器和每塊磁碟的能力

#### **初始分桶推算**

從原則出發，理解自動分桶推算功能的詳細邏輯就變得簡單了：首先來看初始分桶：

1. 先根據資料量得出一個桶數 N。首先使用 estimate_partition_size 的值除以 5（按文字格式存入 Doris 中有 5 比 1 的資料壓縮比計算），得到的結果為：

-   -   < 100MB，則取 N=1
    -   < 1GB，則取 N=2
    -   >= 1GB，則每一個 GB 一個分桶

2. 根據 BE 節點數以及每個 BE 節點的磁碟容量，計算出桶數 M。其中每個 BE 節點算 1，每 50G 的磁碟容量算 1，那麼 M 的計算規則為：**M = BE 節點數 *( 一塊磁碟塊大小 / 50GB) * 磁碟塊數，** 例如有 3 臺 BE，每臺 BE 都有 4 塊 500GB 的磁碟，那麼 M = 3 * (500GB / 50GB) * 4 = 1203. 得到最終的分桶個數計算邏輯：

-   -   先計算一箇中間值 x = min(M, N, 128)，
    -   如果 x < N並且x < BE節點個數，則最終分桶為 y 即 BE 節點個數；否則最終分桶數為 x

**上述過程虛擬碼表現形式為：**

```sql
int N = 計算N值;
int M = 計算M值;

int y = BE節點個數;
int x = min(M, N, 128);

if (x  有6個delta值，分別是S7 - S6 = delta1,S6 - S5 = delta2,...S2 - S1 = delta6由此得到平均的delta值：avg_delta = (delta1 + delta2 + ... + delta6) / 6 = (S7 - S1) / 6那麼，今天的estimate_partition_size = S7 + avg_delta

2.  非第一種的情況，此時直接取前幾天的 EMA 平均值

> 今天的 estimate_partition_size = EMA(S1, ..., S7)

根據上述演算法，初始分桶個數以及後續分桶個數都能被計算出來。跟之前只能指定固定分桶數不同，由於業務資料的變化，有可能前面分割槽的分桶數和後面分割槽的分桶數不一樣，這對使用者是透明的，使用者無需關心每一分割槽具體的分桶數是多少，而這一自動推算的功能會讓分桶數更加合理。

自動分桶推算功能 PR：*https://github.com/apache/doris/pull/15250*

###  **效果**

當我們有了合適的分割槽分桶時，匯入資料導到 Doris 後，資料會依照建表語句中的分割槽分桶列進行儲存。上述網站站點資料的儲存示例如圖示：

![image.png](https://p6-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/a7679f8709ed4e7db4af3b8e3698db73~tplv-k3u1fbpfcp-watermark.image?)

圖2：Doris 分割槽分桶後的資料儲存

此時如果執行 SQL 查詢：
```sql
select * from test_tbl where sdate = "2020-03-23"  and site = 1
```

根據謂詞 sdate = "2020-03-23" 可以定位到分割槽 p20200323，謂詞 site = 1 能定位到該分割槽下的 bucket_1。假設有 30 天資料，自動分桶推算得到的分桶個數為 20 個。則經過明確的分割槽分桶謂詞下推，則可以將資料全表掃描量變為原來的 1/600（30 天*20 個桶 = 600），**極大減少了資料的掃描範圍、提高了查詢的效率**。

# **#  總結**

整體來看，**批次建立分割槽功能語法簡潔有力**，解決了使用者針對大量歷史資料分割槽建立的難題，既避免了手動建立大量分割槽的低效語法，又避免了動態分割槽大量引數的學習使用成本，且方式靈活多變、隨意搭配組合各種型別的分割槽，**大大提升了 Doris 在建表過程中的易用性**。**自動分桶推斷功能智慧高效**，使用者不需再關心分桶的細枝末節，系統自動幫助使用者擴縮不同分割槽的分桶數，真正做到桶隨業務變，**降低學習成本的同時更是提升了查詢效率**。在與社群使用者持續溝通中，我們也不斷收穫著許多新的需求，例如分割槽列為非時間列等，因此後續我們仍將繼續完善對其他分割槽列的支援，例如數字分割槽列的批次建立等。最後，我們期待傾聽更多使用者的聲音，在不斷回饋使用者以極簡易用的使用體驗的同時，也期待有更多人參與到 Apache Doris 的建設中來，歡迎你的加入！

**本文引用**

[1] https://zhuanlan.zhihu.com/p/587187198

**作者介紹：**

許瑞亮，SelectDB 儲存研發工程師

胡得潮，SelectDB 生態研發工程師

李仕楊，SelectDB 生態研發工程師

一文教你玩轉 Apache Doris 分割槽分桶新功能

相關文章