快捷導航

StarRocks數(shù)據(jù)庫查詢加速及Colocation Join工作原理

更新時間：2025年03月10日 09:45:44 作者：吵吵叭火

本文詳細解釋了StarRocks數(shù)據(jù)庫中數(shù)據(jù)的分區(qū)和分桶策略,重點介紹了ColocationJoin的工作原理,即如何通過相同分桶列和副本數(shù)確保在本地進行Join操作,從而提升查詢性能,感興趣的朋友一起看看吧

一、StarRocks數(shù)據(jù)劃分

在介紹Colocation Join之前，再回顧下StarRocks的數(shù)據(jù)劃分及tablet多副本機制。

StarRocks支持兩層的數(shù)據(jù)劃分，第一層是Range Partition，第二層是Hash Bucket（Tablet）。StarRocks的數(shù)據(jù)表按照分區(qū)分桶規(guī)則，被水平切分成若干個數(shù)據(jù)分片（Tablet，也稱作數(shù)據(jù)分桶 Bucket）存儲在不同的be節(jié)點上，每個tablet都有多個副本（默認是3副本）。各個 Tablet 之間的數(shù)據(jù)沒有交集，并且在物理上是獨立存儲的。Tablet 是數(shù)據(jù)移動、復制等操作的最小物理存儲單元。一個 Tablet 只屬于一個數(shù)據(jù)分區(qū)（Partition），而一個 Partition 包含若干個 Tablet。

下圖說明 Table、Partition、Bucket（Tablet）的關(guān)系：

假設(shè)Table 按照 Range 的方式按照 date 字段進行分區(qū)，得到了 N 個 Partition
每個 Partition 通過相同的 Hash 方式將其中的數(shù)據(jù)劃分為 M 個 Bucket（Tablet）
從邏輯上來說，Bucket 1 可以包含 N 個 Partition 中劃分得到的數(shù)據(jù)，比如下圖中的 Tablet 11、Tablet 21、Tablet N1

1.1 分區(qū)

邏輯概念，分區(qū)用于將數(shù)據(jù)劃分成不同的區(qū)間，主要作用是將一張表按照分區(qū)鍵拆分成不同的管理單元。查詢時，通過分區(qū)裁剪，可以減少掃描的數(shù)據(jù)量，顯著優(yōu)化查詢性能。

1.2 分桶

物理概念，StarRocks一般采用Hash算法作為分桶算法。在同一分區(qū)內(nèi)，分桶鍵哈希值相同的數(shù)據(jù)會劃分到同一個tablet（數(shù)據(jù)分片），tablet以多副本冗余的形式存儲，是數(shù)據(jù)均衡和恢復的最?單位，數(shù)據(jù)導入和查詢最終都下沉到所涉及的 tablet副本上。

二、Colocation Join實現(xiàn)原理

2.1 Colocate Join概述

在數(shù)據(jù)分布滿足一定條件的前提下，計算節(jié)點只需做本地 Join，減少跨節(jié)點的數(shù)據(jù)移動和網(wǎng)絡(luò)傳輸開銷，提高查詢性能。Colocate Join 十分適合幾張大表按照相同字段分桶的場景，這樣可以將數(shù)據(jù)預先存儲到相同的分桶中，實現(xiàn)本地計算。

要理解這個算法，需要先了解以下幾個概念：

Colocation Group（CG）：同一 CG 內(nèi)的表需遵循相同的 Colocation Group Schema（CGS），即表對應(yīng)的分桶副本具有一致的分桶鍵、副本數(shù)量和副本放置方式。如此可以保證同一 CG 內(nèi)，所有表的數(shù)據(jù)分布在相同一組 BE 節(jié)點上。
Colocation Group Schema（CGS）：用于描述一個 CG 中的Table，和Colocation相關(guān)的通用 Schema 信息。包括分桶列類型，分桶數(shù)以及副本數(shù)等。
分桶編號Bucket Seq：一個表的數(shù)據(jù)，根據(jù)分桶列 Hash、對桶數(shù)取模后落在某一個分桶內(nèi)。假設(shè)一個 Table 的分桶數(shù)為 8，則共有 [0, 1, 2, 3, 4, 5, 6, 7] 8 個分桶（Bucket）。因此【分桶列 Hash %桶數(shù) 】一致的數(shù)據(jù)會劃分到同一個桶中。

2.2 Colocate Join工作原理

Colocation Join 功能，是將一組擁有相同CGS 的 Table 組成一個 CG。并保證這些 Table 對應(yīng)的數(shù)據(jù)分片會落在同一個 BE 節(jié)點上。使得當 CG 內(nèi)的表進行分桶列上的 Join 操作時，可以通過直接進行本地數(shù)據(jù) Join，減少數(shù)據(jù)在節(jié)點之間的傳輸耗時。

因此核心問題直接轉(zhuǎn)變成【如果保證這些table對應(yīng)的數(shù)據(jù)分片會落在同一個be節(jié)點上？】

同一 CG 內(nèi)的Table必須保證以下屬性：

（1）分桶列和分桶數(shù)

同一 CG內(nèi)表的分桶鍵的類型、數(shù)量和順序完全一致，并且桶數(shù)一致，從而保證多張表的數(shù)據(jù)分片能夠一一對應(yīng)地進行分布控制。

分桶列，即在建表語句中distributed by hash(col1, col2, ...) 中指定的列。分桶列決定了一張表的數(shù)據(jù)通過哪些列的值進行Hash劃分到不同的Tablet 中。同一 CG內(nèi)的 Table 必須保證分桶列的類型和數(shù)量完全一致，并且桶數(shù)一致，才能保證多張表的數(shù)據(jù)分片能夠一一對應(yīng)的進行分布控制。

（2）副本數(shù)

同一個 CG內(nèi)所有表的所有分區(qū)（Partition）的副本數(shù)必須一致。如果不一致，可能出現(xiàn)某一個 Tablet 的某一個副本，在同一個 BE 上沒有其他的表分片的副本對應(yīng)。不過，同一個 CG 內(nèi)的表，分區(qū)的個數(shù)、范圍以及分區(qū)列的類型不要求一致。

ps：同一個 CG 內(nèi)所有表的分區(qū)鍵，分區(qū)數(shù)量可以不同。因為Partition只是一個邏輯上的分區(qū)，真正影響數(shù)據(jù)分布在哪一個BE節(jié)點的是由Bucket決定的。

綜上，在固定了分桶列和分桶數(shù)后，同一個CG內(nèi)的表會擁有相同的Buckets Seq。而副本數(shù)決定了每個分桶內(nèi)的 Tablet 的多個副本分別存放在哪些 BE 上。假設(shè)Buckets Seq為 [0, 1, 2, 3, 4, 5, 6, 7]，BE 節(jié)點有 [A, B, C, D] 4個。則一個可能的數(shù)據(jù)分布如下：

CG 內(nèi)表的一致的數(shù)據(jù)分布定義和tablet副本映射，能夠保證分桶列值相同的數(shù)據(jù)都在同一個 BE 節(jié)點上，可以進行本地數(shù)據(jù) Join。其核心思想是「兩次映射」，保證相同的 Distributed Key 的數(shù)據(jù)會被映射到相同的 Bucket Seq，再保證 Bucket Seq對應(yīng)的 Bucket 映射到相同的 BE 節(jié)點：