腳本之家服務(wù)器常用軟件

快捷導(dǎo)航

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

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

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

數(shù)據(jù)存儲(chǔ)結(jié)構(gòu)
Aggregate 模型
Uniq模型
Duplicate 模型
數(shù)據(jù)模型的選擇建議
前綴索引
物化視圖（rollup）
ROLLUP 調(diào)整前綴索引
ROLLUP 的幾點(diǎn)說(shuō)明
分區(qū)和分桶
稀疏索引和 Bloom Filter
Broadcast/Shuffle Join

問(wèn)題

總結(jié)

正文

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

限制

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

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

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

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

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

Aggregate
Uniq
Duplicate

Aggregate 模型

在 Doris 通過(guò) key 來(lái)來(lái)決定 value 的聚合粒度大小。

CREATE TABLE IF NOT EXISTS example_db.expamle_tbl
(
    `user_id` LARGEINT NOT NULL COMMENT "用戶(hù)id",
    `date` DATE NOT NULL COMMENT "數(shù)據(jù)灌入日期時(shí)間",
    `city` VARCHAR(20) COMMENT "用戶(hù)所在城市",
    `age` SMALLINT COMMENT "用戶(hù)年齡",
    `sex` TINYINT COMMENT "用戶(hù)性別",
    `last_visit_date` DATETIME REPLACE DEFAULT "1970-01-01 00:00:00" COMMENT "用戶(hù)最后一次訪(fǎng)問(wèn)時(shí)間",
    `cost` BIGINT SUM DEFAULT "0" COMMENT "用戶(hù)總消費(fèi)",
    `max_dwell_time` INT MAX DEFAULT "0" COMMENT "用戶(hù)最大停留時(shí)間",
    `min_dwell_time` INT MIN DEFAULT "99999" COMMENT "用戶(hù)最小停留時(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模型

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

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

Duplicate 模型

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

這種數(shù)據(jù)模型區(qū)別于 Aggregate 和 Uniq 模型。數(shù)據(jù)完全按照導(dǎo)入文件中的數(shù)據(jù)進(jìn)行存儲(chǔ)，不會(huì)有任何聚合。即使兩行數(shù)據(jù)完全相同，也都會(huì)保留。而在建表語(yǔ)句中指定的 DUPLICATE KEY，只是用來(lái)指明底層數(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 "日志類(lèi)型",
    `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)確定，且無(wú)法修改。所以，選擇一個(gè)合適的數(shù)據(jù)模型非常重要。

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

前綴索引

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

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

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

以下表結(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)。即使沒(méi)有達(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)我們的查詢(xún)條件，是前綴索引的前綴時(shí)，可以極大的加快查詢(xún)速度。比如在第一個(gè)例子中，我們執(zhí)行如下查詢(xún)：

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

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

SELECT * FROM table WHERE age=20；

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

物化視圖（rollup）

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

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

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

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

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

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

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

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

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

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

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)行如下查詢(xún)時(shí)：

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

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

創(chuàng)建 rollup 語(yǔ)法

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è)表只有一種前綴索引。這對(duì)于使用其他不能命中前綴索引的列作為條件進(jìn)行的查詢(xún)來(lái)說(shuō)，效率上可能無(wú)法滿(mǎn)足需求。因此，我們可以通過(guò)創(chuàng)建 ROLLUP 來(lái)人為的調(diào)整列順序。

ROLLUP 的幾點(diǎn)說(shuō)明

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

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

分區(qū)和分桶

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

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

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

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

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

* 可用上Doris分級(jí)存儲(chǔ)(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 以?xún)?nèi), 所以建表或增加 partition 時(shí)請(qǐng)合理考慮 bucket 數(shù)目, 其中不同 partition 可指定不同的 buckets 數(shù)。

稀疏索引和 Bloom Filter

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

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

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

Broadcast/Shuffle Join

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

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