Apache Doris數(shù)據(jù)模型的介紹

這篇文章主要介紹“Apache Doris數(shù)據(jù)模型的介紹”，在日常操作中，相信很多人在Apache Doris數(shù)據(jù)模型的介紹問題上存在疑惑，小編查閱了各式資料，整理出簡單好用的操作方法，希望對大家解答”Apache Doris數(shù)據(jù)模型的介紹”的疑惑有所幫助！接下來，請跟著小編一起來學(xué)習(xí)吧！

基本概念

在 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類:

• Duplicate 明細(xì)模型

• Aggregate 聚合模型

• Unique 唯一主鍵模型

下面我們分別介紹。

Duplicate 明細(xì)模型

明細(xì)模型是 Doris 默認(rèn)使用的數(shù)據(jù)模型。該數(shù)據(jù)模型不會(huì)對導(dǎo)入的數(shù)據(jù)進(jìn)行任何處理。表中的數(shù)據(jù)即用戶導(dǎo)入的原始數(shù)據(jù)。

建表語句如下：

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 信息 */
；

建表語句中指定的 DUPLICATE KEY，只是用來指明底層數(shù)據(jù)按照那些列進(jìn)行排序。（更貼切的名稱應(yīng)該為 “Sorted Column”，這里取名 “DUPLICATE KEY” 只是用以明確表示所用的數(shù)據(jù)模型。關(guān)于 “Sorted Column”的更多解釋，索引文檔）。在 DUPLICATE KEY 的選擇上，我們建議適當(dāng)?shù)倪x擇前 2-4 列就可以。

這種數(shù)據(jù)模型適用于既沒有聚合需求，又沒有主鍵唯一性約束的原始數(shù)據(jù)的存儲。同時(shí)，用戶也可以通過物化視圖功能功能在這種模型基礎(chǔ)上建立聚合視圖，因此是一種比較推薦的數(shù)據(jù)模型。

Aggregate 聚合模型

聚合模型需要用戶在建表時(shí)顯式的將列分為 Key 列和 Value 列。該模型會(huì)自動(dòng)的對 Key 相同的行，在 Value 列上進(jìn)行聚合操作。

我們以實(shí)際的例子來說明什么是聚合模型，以及如何正確的使用聚合模型。

示例1：導(dǎo)入數(shù)據(jù)聚合

假設(shè)業(yè)務(wù)有如下數(shù)據(jù)表模式：

如果轉(zhuǎn)換成建表語句則如下（省略建表語句中的 Partition 和 Distribution 信息）

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 信息 */
；

可以看到，這是一個(gè)典型的用戶信息和訪問行為的事實(shí)表。 在一般星型模型中，用戶信息和訪問行為一般分別存放在維度表和事實(shí)表中。這里我們?yōu)榱烁臃奖愕慕忉?Doris 的數(shù)據(jù)模型，將兩部分信息統(tǒng)一存放在一張表中。

表中的列按照是否設(shè)置了 AggregationType，分為 Key (維度列) 和 Value（指標(biāo)列）。沒有設(shè)置 AggregationType 的，如 user_id、date、age ... 等稱為 Key，而設(shè)置了 AggregationType 的稱為 Value。

當(dāng)我們導(dǎo)入數(shù)據(jù)時(shí)，對于 Key 列相同的行會(huì)聚合成一行，而 Value 列會(huì)按照設(shè)置的 AggregationType 進(jìn)行聚合。 AggregationType 目前有以下四種聚合方式：

1. SUM：求和，多行的 Value 進(jìn)行累加。

2. REPLACE：替代，下一批數(shù)據(jù)中的 Value 會(huì)替換之前導(dǎo)入過的行中的 Value。

3. MAX：保留最大值。

4. MIN：保留最小值。

假設(shè)我們有以下導(dǎo)入數(shù)據(jù)（原始數(shù)據(jù)）：

我們假設(shè)這是一張記錄用戶訪問某商品頁面行為的表。我們以第一行數(shù)據(jù)為例，解釋如下：

那么當(dāng)這批數(shù)據(jù)正確導(dǎo)入到 Doris 中后，Doris 中最終存儲如下：

可以看到，用戶 10000 只剩下了一行聚合后的數(shù)據(jù)。而其余用戶的數(shù)據(jù)和原始數(shù)據(jù)保持一致。這里先解釋下用戶 10000 聚合后的數(shù)據(jù)：

前5列沒有變化，從第6列 last_visit_date 開始：

• 2017-10-01 07:00:00：因?yàn)?last_visit_date 列的聚合方式為 REPLACE，所以 2017-10-01 07:00:00 替換了 2017-10-01 06:00:00 保存了下來。

  注：在同一個(gè)導(dǎo)入批次中的數(shù)據(jù)，對于 REPLACE 這種聚合方式，替換順序不做保證。如在這個(gè)例子中，最終保存下來的，也有可能是 2017-10-01 06:00:00。而對于不同導(dǎo)入批次中的數(shù)據(jù)，可以保證，后一批次的數(shù)據(jù)會(huì)替換前一批次。

• 35：因?yàn)?cost 列的聚合類型為 SUM，所以由 20 + 15 累加獲得 35。

• 10：因?yàn)?max_dwell_time 列的聚合類型為 MAX，所以 10 和 2 取最大值，獲得 10。

• 2：因?yàn)?min_dwell_time 列的聚合類型為 MIN，所以 10 和 2 取最小值，獲得 2。

經(jīng)過聚合，Doris 中最終只會(huì)存儲聚合后的數(shù)據(jù)。換句話說，即明細(xì)數(shù)據(jù)會(huì)丟失，用戶不能夠再查詢到聚合前的明細(xì)數(shù)據(jù)了。

示例2：保留明細(xì)數(shù)據(jù)

接示例1，我們將表結(jié)構(gòu)修改如下：

即增加了一列 timestamp，記錄精確到秒的數(shù)據(jù)灌入時(shí)間。

導(dǎo)入數(shù)據(jù)如下：

那么當(dāng)這批數(shù)據(jù)正確導(dǎo)入到 Doris 中后，Doris 中最終存儲如下：

我們可以看到，存儲的數(shù)據(jù)，和導(dǎo)入數(shù)據(jù)完全一樣，沒有發(fā)生任何聚合。這是因?yàn)椋@批數(shù)據(jù)中，因?yàn)榧尤肓?timestamp 列，所有行的 Key 都不完全相同。也就是說，只要保證導(dǎo)入的數(shù)據(jù)中，每一行的 Key 都不完全相同，那么即使在聚合模型下，Doris 也可以保存完整的明細(xì)數(shù)據(jù)。

示例3：導(dǎo)入數(shù)據(jù)與已有數(shù)據(jù)聚合

接示例1。假設(shè)現(xiàn)在表中已有數(shù)據(jù)如下：

我們再導(dǎo)入一批新的數(shù)據(jù)：

那么當(dāng)這批數(shù)據(jù)正確導(dǎo)入到 Doris 中后，Doris 中最終存儲如下：

可以看到，用戶 10004 的已有數(shù)據(jù)和新導(dǎo)入的數(shù)據(jù)發(fā)生了聚合。同時(shí)新增了 10005 用戶的數(shù)據(jù)。

數(shù)據(jù)的聚合，在 Doris 中有如下三個(gè)階段發(fā)生：

1. 每一批次數(shù)據(jù)導(dǎo)入的 ETL 階段。該階段會(huì)在每一批次導(dǎo)入的數(shù)據(jù)內(nèi)部進(jìn)行聚合。

2. 底層 BE 進(jìn)行數(shù)據(jù) Compaction 的階段。該階段，BE 會(huì)對已導(dǎo)入的不同批次的數(shù)據(jù)進(jìn)行進(jìn)一步的聚合。

3. 數(shù)據(jù)查詢階段。在數(shù)據(jù)查詢時(shí)，對于查詢涉及到的數(shù)據(jù)，會(huì)進(jìn)行對應(yīng)的聚合。

數(shù)據(jù)在不同時(shí)間，可能聚合的程度不一致。比如一批數(shù)據(jù)剛導(dǎo)入時(shí)，可能還未與之前已存在的數(shù)據(jù)進(jìn)行聚合。但是對于用戶而言，用戶只能查詢到聚合后的數(shù)據(jù)。即不同的聚合程度對于用戶查詢而言是透明的。用戶需始終認(rèn)為數(shù)據(jù)以最終的完成的聚合程度存在，而不應(yīng)假設(shè)某些聚合還未發(fā)生。（可參閱聚合模型的局限性一節(jié)獲得更多詳情。）

Unique 唯一主鍵模型

在某些多維分析場景下，用戶更關(guān)注的是如何保證 Key 的唯一性，即如何獲得 Primary Key 唯一性約束。因此，我們引入了 Unique 的數(shù)據(jù)模型。該模型本質(zhì)上是聚合模型的一個(gè)特例，也是一種簡化的表結(jié)構(gòu)表示方式。我們舉例說明。

這是一個(gè)典型的用戶基礎(chǔ)信息表。這類數(shù)據(jù)沒有聚合需求，只需保證主鍵唯一性。（這里的主鍵為 user_id + username）。那么我們的建表語句如下：

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 信息 */
；

而這個(gè)表結(jié)構(gòu)，完全同等于以下使用聚合模型描述的表結(jié)構(gòu)：

及建表語句：

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) REPLACE COMMENT "用戶所在城市",
    `age` SMALLINT REPLACE COMMENT "用戶年齡",
    `sex` TINYINT REPLACE COMMENT "用戶性別",
    `phone` LARGEINT REPLACE COMMENT "用戶電話",
    `address` VARCHAR(500) REPLACE COMMENT "用戶地址",
    `register_time` DATETIME REPLACE COMMENT "用戶注冊時(shí)間"
)
AGGREGATE KEY(`user_id`, `user_name`)
... /* 省略 Partition 和 Distribution 信息 */
；

即 Unique 模型完全可以用聚合模型中的 REPLACE 方式替代。其內(nèi)部的實(shí)現(xiàn)方式和數(shù)據(jù)存儲方式也完全一樣。這里不再繼續(xù)舉例說明。

聚合模型的局限性

聚合模型（包括 Unique 模型），通過一種預(yù)計(jì)算的方式來減少查詢時(shí)需要實(shí)時(shí)計(jì)算的數(shù)據(jù)量，加速查詢。但是這種模型會(huì)有使用上的局限性。

在聚合模型中，模型對外展現(xiàn)的，是最終聚合后的數(shù)據(jù)。也就是說，任何還未聚合的數(shù)據(jù)（比如說兩個(gè)不同導(dǎo)入批次的數(shù)據(jù)），必須通過某種方式，以保證對外展示的一致性。我們舉例說明。

假設(shè)表結(jié)構(gòu)如下：

假設(shè)存儲引擎中有如下兩個(gè)已經(jīng)導(dǎo)入完成的批次的數(shù)據(jù)：

batch 1

batch 2

可以看到，用戶 10001 分屬在兩個(gè)導(dǎo)入批次中的數(shù)據(jù)還沒有聚合。但是為了保證用戶只能查詢到如下最終聚合后的數(shù)據(jù)：

我們在查詢引擎中加入了聚合算子，來保證數(shù)據(jù)對外的一致性。

另外，在聚合列（Value）上，執(zhí)行與聚合類型不一致的聚合類查詢時(shí)，要注意語意。比如我們在如上示例中執(zhí)行如下查詢：

SELECT MIN(cost) FROM table;

得到的結(jié)果是 5，而不是 1。

同時(shí)，這種一致性保證，在某些查詢中，會(huì)極大的降低查詢效率。

我們以最基本的 count(*) 查詢?yōu)槔?/p>

SELECT COUNT(*) FROM table;

在其他數(shù)據(jù)庫中，這類查詢都會(huì)很快的返回結(jié)果。因?yàn)樵趯?shí)現(xiàn)上，我們可以通過如 “導(dǎo)入時(shí)對行進(jìn)行計(jì)數(shù)，保存 count 的統(tǒng)計(jì)信息”，或者在查詢時(shí) “僅掃描某一列數(shù)據(jù)，獲得 count 值” 的方式，只需很小的開銷，即可獲得查詢結(jié)果。但是在 Doris 的聚合模型中，這種查詢的開銷非常大。

我們以剛才的數(shù)據(jù)為例：

batch 1

batch 2

因?yàn)樽罱K的聚合結(jié)果為：

所以，select count(*) from table; 的正確結(jié)果應(yīng)該為 4。但如果我們只掃描 user_id 這一列，如果加上查詢時(shí)聚合，最終得到的結(jié)果是 3（10001, 10002, 10003）。而如果不加查詢時(shí)聚合，則得到的結(jié)果是 5（兩批次一共5行數(shù)據(jù)）?？梢娺@兩個(gè)結(jié)果都是不對的。

為了得到正確的結(jié)果，我們必須同時(shí)讀取 user_id 和 date 這兩列的數(shù)據(jù)，再加上查詢時(shí)聚合，才能返回 4 這個(gè)正確的結(jié)果。也就是說，在 count() 查詢中，Doris 必須掃描所有的 AGGREGATE KEY 列（這里就是 user_id 和 date），并且聚合后，才能得到語意正確的結(jié)果。當(dāng)聚合列非常多時(shí)，count() 查詢需要掃描大量的數(shù)據(jù)。

因此，當(dāng)業(yè)務(wù)上有頻繁的 count(*) 查詢時(shí)，我們建議用戶通過增加一個(gè)值恒為 1 的，聚合類型為 SUM 的列來模擬 count(*)。如剛才的例子中的表結(jié)構(gòu)，我們修改如下：

增加一個(gè) count 列，并且導(dǎo)入數(shù)據(jù)中，該列值恒為 1。則 select count(*) from table; 的結(jié)果等價(jià)于 select sum(count) from table;。而后者的查詢效率將遠(yuǎn)高于前者。不過這種方式也有使用限制，就是用戶需要自行保證，不會(huì)重復(fù)導(dǎo)入 AGGREGATE KEY 列都相同的行。否則，select sum(count) from table; 只能表述原始導(dǎo)入的行數(shù)，而不是 select count(*) from table; 的語義。

另一種方式，就是 將如上的 count 列的聚合類型改為 REPLACE，且依然值恒為 1。那么 select sum(count) from table; 和 select count(*) from table; 的結(jié)果將是一致的。并且這種方式，沒有導(dǎo)入重復(fù)行的限制。

Duplicate 模型

Duplicate 模型沒有聚合模型的這個(gè)局限性。因?yàn)樵撃Ｐ筒簧婕熬酆险Z意，在做 count(*) 查詢時(shí)，任意選擇一列查詢，即可得到語意正確的結(jié)果。

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

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

1. Aggregate 模型可以通過預(yù)聚合，極大地降低聚合查詢時(shí)所需掃描的數(shù)據(jù)量和查詢的計(jì)算量，非常適合有固定模式的報(bào)表類查詢場景。但是該模型對 count(*) 查詢很不友好。同時(shí)因?yàn)楣潭?Value 列上的聚合方式，在進(jìn)行其他類型的聚合查詢時(shí)，需要考慮語意正確性。

2. Unique 模型針對需要唯一主鍵約束的場景，可以保證主鍵唯一性約束。但是無法利用 ROLLUP 等預(yù)聚合帶來的查詢優(yōu)勢（因?yàn)楸举|(zhì)是 REPLACE，沒有 SUM 這種聚合方式）。

3. Duplicate 適合任意維度的 Ad-hoc 查詢。雖然同樣無法利用預(yù)聚合的特性，但是不受聚合模型的約束，可以發(fā)揮列存模型的優(yōu)勢（只讀取相關(guān)列，而不需要讀取所有 Key 列）。

到此，關(guān)于“Apache Doris數(shù)據(jù)模型的介紹”的學(xué)習(xí)就結(jié)束了，希望能夠解決大家的疑惑。理論與實(shí)踐的搭配能更好的幫助大家學(xué)習(xí)，快去試試吧！若想繼續(xù)學(xué)習(xí)更多相關(guān)知識，請繼續(xù)關(guān)注億速云網(wǎng)站，小編會(huì)繼續(xù)努力為大家?guī)砀鄬?shí)用的文章！