快捷導(dǎo)航

Doris實(shí)時(shí)多維分析的解決方案詳解

更新時(shí)間：2023年05月17日 11:40:20 作者：跡_Jason

這篇文章主要為大家介紹了Doris實(shí)時(shí)多維分析的解決方案詳解，有需要的朋友可以借鑒參考下，希望能夠有所幫助，祝大家多多進(jìn)步，早日升職加薪

正文

Doris 這類 MPP 架構(gòu)的 OLAP 數(shù)據(jù)庫，通常都是通過提高并發(fā)，來處理大量數(shù)據(jù)的。本質(zhì)上，Doris 的數(shù)據(jù)存儲在類似 SSTable（Sorted String Table）的數(shù)據(jù)結(jié)構(gòu)中。該結(jié)構(gòu)是一種有序的數(shù)據(jù)結(jié)構(gòu)，可以按照指定的列進(jìn)行排序存儲。在這種數(shù)據(jù)結(jié)構(gòu)上，以排序列作為條件進(jìn)行查找，會非常的高效。

限制

在 Count(*) 語法方面，原生的方式性能不是特別高，需要自行優(yōu)化
不存在除了維度和指標(biāo)之外的字段類型存在，如果需要實(shí)現(xiàn)多種需求場景，需要?jiǎng)?chuàng)建多種表類型來冗余數(shù)據(jù)方式實(shí)現(xiàn)

數(shù)據(jù)存儲結(jié)構(gòu)

在 Doris 中，數(shù)據(jù)以表（Table）的形式進(jìn)行邏輯上的描述。一張表包括行（Row）和列（Column）。Row 即用戶的一行數(shù)據(jù)。Column 用于描述一行數(shù)據(jù)中不同的字段。

Column 可以分為兩大類：Key 和 Value。從業(yè)務(wù)角度看，Key 和 Value 可以分別對應(yīng)維度列和指標(biāo)列。

Doris 的數(shù)據(jù)模型主要分為3類:

Aggregate
Uniq
Duplicate

Aggregate 模型

在 Doris 通過 key 來來決定 value 的聚合粒度大小。

CREATE TABLE IF NOT EXISTS example_db.expamle_tbl
(
    `user_id` LARGEINT NOT NULL COMMENT "用戶id",
    `date` DATE NOT NULL COMMENT "數(shù)據(jù)灌入日期時(shí)間",
    `city` VARCHAR(20) COMMENT "用戶所在城市",
    `age` SMALLINT COMMENT "用戶年齡",
    `sex` TINYINT COMMENT "用戶性別",
    `last_visit_date` DATETIME REPLACE DEFAULT "1970-01-01 00:00:00" COMMENT "用戶最后一次訪問時(shí)間",
    `cost` BIGINT SUM DEFAULT "0" COMMENT "用戶總消費(fèi)",
    `max_dwell_time` INT MAX DEFAULT "0" COMMENT "用戶最大停留時(shí)間",
    `min_dwell_time` INT MIN DEFAULT "99999" COMMENT "用戶最小停留時(shí)間",
)
AGGREGATE KEY(`user_id`, `date`, `timestamp`, `city`, `age`, `sex`)
... /* 省略 Partition 和 Distribution 信息 */
；

像帶有 REPLACE、SUM、MAX、MIN 這種標(biāo)記的字段都是屬于 value，user_id, date, timestamp, city, age, sex 則為key。

Uniq模型

這類數(shù)據(jù)沒有聚合需求，只需保證主鍵唯一性。

CREATE TABLE IF NOT EXISTS example_db.expamle_tbl
(
    `user_id` LARGEINT NOT NULL COMMENT "用戶id",
    `username` VARCHAR(50) NOT NULL COMMENT "用戶昵稱",
    `city` VARCHAR(20) COMMENT "用戶所在城市",
    `age` SMALLINT COMMENT "用戶年齡",
    `sex` TINYINT COMMENT "用戶性別",
    `phone` LARGEINT COMMENT "用戶電話",
    `address` VARCHAR(500) COMMENT "用戶地址",
    `register_time` DATETIME COMMENT "用戶注冊時(shí)間"
)
UNIQUE KEY(`user_id`, `user_name`)
... /* 省略 Partition 和 Distribution 信息 */
；

Duplicate 模型

在某些多維分析場景下，數(shù)據(jù)既沒有主鍵，也沒有聚合需求。因此，我們引入 Duplicate 數(shù)據(jù)模型來滿足這類需求。

這種數(shù)據(jù)模型區(qū)別于 Aggregate 和 Uniq 模型。數(shù)據(jù)完全按照導(dǎo)入文件中的數(shù)據(jù)進(jìn)行存儲，不會有任何聚合。即使兩行數(shù)據(jù)完全相同，也都會保留。而在建表語句中指定的 DUPLICATE KEY，只是用來指明底層數(shù)據(jù)按照那些列進(jìn)行排序。

在 DUPLICATE KEY 的選擇上，我們建議適當(dāng)?shù)倪x擇前 2-4 列就可以。

CREATE TABLE IF NOT EXISTS example_db.expamle_tbl
(
    `timestamp` DATETIME NOT NULL COMMENT "日志時(shí)間",
    `type` INT NOT NULL COMMENT "日志類型",
    `error_code` INT COMMENT "錯(cuò)誤碼",
    `error_msg` VARCHAR(1024) COMMENT "錯(cuò)誤詳細(xì)信息",
    `op_id` BIGINT COMMENT "負(fù)責(zé)人id",
    `op_time` DATETIME COMMENT "處理時(shí)間"
)
DUPLICATE KEY(`timestamp`, `type`)
... /* 省略 Partition 和 Distribution 信息 */
；

數(shù)據(jù)模型的選擇建議

因?yàn)閿?shù)據(jù)模型在建表時(shí)就已經(jīng)確定，且無法修改。所以，選擇一個(gè)合適的數(shù)據(jù)模型非常重要。

Aggregate 模型可以通過預(yù)聚合，極大地降低聚合查詢時(shí)所需掃描的數(shù)據(jù)量和查詢的計(jì)算量，非常適合有固定模式的報(bào)表類查詢場景。但是該模型對 count(*) 查詢很不友好。同時(shí)因?yàn)楣潭?Value 列上的聚合方式，在進(jìn)行其他類型的聚合查詢時(shí)，需要考慮語意正確性。
Uniq 模型針對需要唯一主鍵約束的場景，可以保證主鍵唯一性約束。但是無法利用 ROLLUP 等預(yù)聚合帶來的查詢優(yōu)勢（因?yàn)楸举|(zhì)是 REPLACE，沒有 SUM 這種聚合方式）。
Duplicate 適合任意維度的 Ad-hoc 查詢。雖然同樣無法利用預(yù)聚合的特性，但是不受聚合模型的約束，可以發(fā)揮列存模型的優(yōu)勢（只讀取相關(guān)列，而不需要讀取所有 Key 列）。

前綴索引

在 Aggregate、Uniq 和 Duplicate 三種數(shù)據(jù)模型中。底層的數(shù)據(jù)存儲，是按照各自建表語句中，AGGREGATE KEY、UNIQ KEY 和 DUPLICATE KEY 中指定的列進(jìn)行排序存儲的。

而前綴索引，即在排序的基礎(chǔ)上，實(shí)現(xiàn)的一種根據(jù)給定前綴列，快速查詢數(shù)據(jù)的索引方式。

我們將一行數(shù)據(jù)的前 36 個(gè)字節(jié) 作為這行數(shù)據(jù)的前綴索引。當(dāng)遇到 VARCHAR 類型時(shí)，前綴索引會直接截?cái)?。我們舉例說明：

以下表結(jié)構(gòu)的前綴索引為 user_id(8Byte) + age(4Bytes) + message(prefix 24 Bytes)。

ColumnName	Type
user_id	BIGINT
age	INT
message	VARCHAR(100)
max_dwell_time	DATETIME
min_dwell_time	DATETIME

以下表結(jié)構(gòu)的前綴索引為 user_name(20 Bytes)。即使沒有達(dá)到 36 個(gè)字節(jié)，因?yàn)橛龅?VARCHAR，所以直接截?cái)?，不再往后繼續(xù)。

ColumnName	Type
user_name	VARCHAR(20)
age	INT
message	VARCHAR(100)
max_dwell_time	DATETIME
min_dwell_time	DATETIME

當(dāng)我們的查詢條件，是前綴索引的前綴時(shí)，可以極大的加快查詢速度。比如在第一個(gè)例子中，我們執(zhí)行如下查詢：

SELECT * FROM table WHERE user_id=1829239 and age=20；

該查詢的效率會遠(yuǎn)高于如下查詢：

SELECT * FROM table WHERE age=20；

所以在建表時(shí)，正確的選擇列順序，能夠極大地提高查詢效率。

物化視圖（rollup）

ROLLUP 在多維分析中是“上卷”的意思，即將數(shù)據(jù)按某種指定的粒度進(jìn)行進(jìn)一步聚合。

在 Doris 中，我們將用戶通過建表語句創(chuàng)建出來的表成為 Base 表（Base Table）。Base 表中保存著按用戶建表語句指定的方式存儲的基礎(chǔ)數(shù)據(jù)。

在 Base 表之上，我們可以創(chuàng)建任意多個(gè) ROLLUP 表。這些 ROLLUP 的數(shù)據(jù)是基于 Base 表產(chǎn)生的，并且在物理上是獨(dú)立存儲的。

ROLLUP 表的基本作用，在于在 Base 表的基礎(chǔ)上，獲得更粗粒度的聚合數(shù)據(jù)。

Rollup 本質(zhì)上可以理解為原始表(Base Table)的一個(gè)物化索引。建立 Rollup 時(shí)可只選取 Base Table 中的部分列作為 Schema。Schema 中的字段順序也可與 Base Table 不同。

ROLLUP 創(chuàng)建完成之后的觸發(fā)是程序自動的，不需要任何其他指定或者配置。

例如：創(chuàng)建了 user_id （key），cost（value）格式的 rollup 時(shí)，當(dāng)執(zhí)行下方語句時(shí)，就會觸發(fā)。

SELECT user_id, sum(cost) FROM table GROUP BY user_id;

Aggregate 和 Uniq 兩種數(shù)據(jù)存儲格式時(shí)，使用 rollup 會改變聚合數(shù)據(jù)的粒度，但對于 Duplicate 只是調(diào)整前綴索引。

因?yàn)榻ū頃r(shí)已經(jīng)指定了列順序，所以一個(gè)表只有一種前綴索引。這對于使用其他不能命中前綴索引的列作為條件進(jìn)行的查詢來說，效率上可能無法滿足需求。因此，我們可以通過創(chuàng)建 ROLLUP 來人為的調(diào)整列順序。舉例說明。

Base 表結(jié)構(gòu)如下：

ColumnName	Type
user_id	BIGINT
age	INT
message	VARCHAR(100)
max_dwell_time	DATETIME
min_dwell_time	DATETIME

我們可以在此基礎(chǔ)上創(chuàng)建一個(gè) ROLLUP 表：

ColumnName	Type
age	INT
user_id	BIGINT
message	VARCHAR(100)
max_dwell_time	DATETIME
min_dwell_time	DATETIME

可以看到，ROLLUP 和 Base 表的列完全一樣，只是將 user_id 和 age 的順序調(diào)換了。那么當(dāng)我們進(jìn)行如下查詢時(shí)：

SELECT * FROM table where age=20 and massage LIKE "%error%";

會優(yōu)先選擇 ROLLUP 表，因?yàn)?ROLLUP 的前綴索引匹配度更高。

創(chuàng)建 rollup 語法

ALTER TABLE table1 ADD ROLLUP rollup_city(citycode, pv);
# 取消正在執(zhí)行的作業(yè)
CANCEL ALTER TABLE ROLLUP FROM table1;

ROLLUP 調(diào)整前綴索引

因?yàn)榻ū頃r(shí)已經(jīng)指定了列順序，所以一個(gè)表只有一種前綴索引。這對于使用其他不能命中前綴索引的列作為條件進(jìn)行的查詢來說，效率上可能無法滿足需求。因此，我們可以通過創(chuàng)建 ROLLUP 來人為的調(diào)整列順序。

ROLLUP 的幾點(diǎn)說明

ROLLUP 最根本的作用是提高某些查詢的查詢效率（無論是通過聚合來減少數(shù)據(jù)量，還是修改列順序以匹配前綴索引）。因此 ROLLUP 的含義已經(jīng)超出了 “上卷” 的范圍。這也是為什么我們在源代碼中，將其命名為 Materized Index（物化索引）的原因。
ROLLUP 是附屬于 Base 表的，可以看做是 Base 表的一種輔助數(shù)據(jù)結(jié)構(gòu)。用戶可以在 Base 表的基礎(chǔ)上，創(chuàng)建或刪除 ROLLUP，但是不能在查詢中顯式的指定查詢某 ROLLUP。是否命中 ROLLUP 完全由 Doris 系統(tǒng)自動決定。
ROLLUP 的數(shù)據(jù)是獨(dú)立物理存儲的。因此，創(chuàng)建的 ROLLUP 越多，占用的磁盤空間也就越大。同時(shí)對導(dǎo)入速度也會有影響（導(dǎo)入的ETL階段會自動產(chǎn)生所有 ROLLUP 的數(shù)據(jù)），但是不會降低查詢效率（只會更好）。
ROLLUP 的數(shù)據(jù)更新與 Base 表示完全同步的。用戶無需關(guān)心這個(gè)問題。
ROLLUP 中列的聚合方式，與 Base 表完全相同。在創(chuàng)建 ROLLUP 無需指定，也不能修改。
查詢能否命中 ROLLUP 的一個(gè)必要條件（非充分條件）是，查詢所涉及的所有列（包括 select list 和 where 中的查詢條件列等）都存在于該 ROLLUP 的列中。否則，查詢只能命中 Base 表。
某些類型的查詢（如 count(*)）在任何條件下，都無法命中 ROLLUP。
可以通過 EXPLAIN your_sql; 命令獲得查詢執(zhí)行計(jì)劃，在執(zhí)行計(jì)劃中，查看是否命中 ROLLUP。
可以通過 DESC tbl_name ALL; 語句顯示 Base 表和所有已創(chuàng)建完成的 ROLLUP。

rollup 數(shù)量沒有限制，但數(shù)量越多會消耗比較多的內(nèi)存。支持 SQL 方式變更 rollup 字段數(shù)量。

分區(qū)和分桶

Doris 支持兩級分區(qū)存儲, 第一層為 RANGE 分區(qū)(partition), 第二層為 HASH 分桶(bucket)。

1.3.1. RANGE分區(qū)(partition)

RANGE分區(qū)用于將數(shù)據(jù)劃分成不同區(qū)間, 邏輯上可以理解為將原始表劃分成了多個(gè)子表。業(yè)務(wù)上，多數(shù)用戶會選擇采用按時(shí)間進(jìn)行partition, 讓

時(shí)間進(jìn)行partition有以下好處：

* 可區(qū)分冷熱數(shù)據(jù)

* 可用上Doris分級存儲(SSD + SATA)的功能

* 按分區(qū)刪除數(shù)據(jù)時(shí)，更加迅速

1.3.2. HASH分桶(bucket)

根據(jù)hash值將數(shù)據(jù)劃分成不同的 bucket。

* 建議采用區(qū)分度大的列做分桶, 避免出現(xiàn)數(shù)據(jù)傾斜

* 為方便數(shù)據(jù)恢復(fù), 建議單個(gè) bucket 的 size 不要太大, 保持在 10GB 以內(nèi), 所以建表或增加 partition 時(shí)請合理考慮 bucket 數(shù)目, 其中不同 partition 可指定不同的 buckets 數(shù)。

稀疏索引和 Bloom Filter

Doris對數(shù)據(jù)進(jìn)行有序存儲, 在數(shù)據(jù)有序的基礎(chǔ)上為其建立稀疏索引,索引粒度為 block(1024行)。

稀疏索引選取 schema 中固定長度的前綴作為索引內(nèi)容, 目前 Doris 選取 36 個(gè)字節(jié)的前綴作為索引。

建表時(shí)建議將查詢中常見的過濾字段放在 Schema 的前面, 區(qū)分度越大，頻次越高的查詢字段越往前放。
這其中有一個(gè)特殊的地方,就是 varchar 類型的字段。varchar 類型字段只能作為稀疏索引的最后一個(gè)字段。索引會在 varchar 處截?cái)? 因此 varchar 如果出現(xiàn)在前面，可能索引的長度可能不足 36 個(gè)字節(jié)。具體可以參閱數(shù)據(jù)模型、ROLLUP 及前綴索引。
除稀疏索引之外, Doris還提供bloomfilter索引, bloomfilter索引對區(qū)分度比較大的列過濾效果明顯。如果考慮到varchar不能放在稀疏索引中, 可以建立bloomfilter索引。

Broadcast/Shuffle Join

系統(tǒng)默認(rèn)實(shí)現(xiàn) Join 的方式，是將小表進(jìn)行條件過濾后，將其廣播到大表所在的各個(gè)節(jié)點(diǎn)上，形成一個(gè)內(nèi)存 Hash 表，然后流式讀出大表的數(shù)據(jù)進(jìn)行Hash Join。但是如果當(dāng)小表過濾后的數(shù)據(jù)量無法放入內(nèi)存的話，此時(shí) Join 將無法完成，通常的報(bào)錯(cuò)應(yīng)該是首先造成內(nèi)存超限。

如果遇到上述情況，建議使用 Shuffle Join 的方式，也被稱作 Partitioned Join。即將小表和大表都按照 Join 的 key 進(jìn)行 Hash，然后進(jìn)行分布式的 Join。這個(gè)對內(nèi)存的消耗就會分?jǐn)偟郊旱乃杏?jì)算節(jié)點(diǎn)上。