了解 Doris 數(shù)據(jù)模型對于我們使用 Doris 來解決我們業(yè)務問題非常重要，這個系列我們將詳細介紹 Doris 的三種數(shù)據(jù)模型及 Doris 數(shù)據(jù)分區(qū)分桶的一些策略，幫助用戶更好的使用 Doris 。

這個系列我會講解 Doris 的三種數(shù)據(jù)模型及在這三種數(shù)據(jù)模型之上的 Rollup，物化視圖及前綴索引。還有在這個三種數(shù)據(jù)模型之上的數(shù)據(jù)分區(qū)分桶的策略。

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

列可以劃分為兩類：鍵 Key 和值 Value。從業(yè)務角度來看，鍵和值對應的就是維度列和指標列

Doris 針對不同場景提供了三種數(shù)據(jù)模型

• Aggregate （聚合模型) ： 將表中的列分為了Key和Value兩種，數(shù)據(jù)會根據(jù)維度列進行分組，并對指標列進行聚合。
• Unique （唯一主鍵模型)：這個模型一般我們是在對接業(yè)務系統(tǒng) RDS 的時候，需要 Doris 數(shù)據(jù)和業(yè)務數(shù)據(jù)保持一致，支持Upsert、Delete等操作
• Duplicate （明細模型）： 這個模型不保證數(shù)據(jù)唯一性（如果你數(shù)據(jù)重復導入兩次就會重復），數(shù)據(jù)既沒有主鍵，也沒有聚合需求，一般情況下我們使用這個模型

聚合模型特點

一個正常的模型它肯定會把明細的數(shù)據(jù)存儲在一個數(shù)據(jù)庫中，也就是存在 Doris 中。但是因為 Doris 它最早是給鳳巢的一個廣告報表做的，廣告報表有一個很大的特點，就是它只關心統(tǒng)計分析的結果，而不太關心明細的數(shù)據(jù)，所以 Doris 最早一代的數(shù)據(jù)模型，是一個聚合的模型。

聚合模型的特點就是將表中的列分為了Key和Value兩種。 Key 就是數(shù)據(jù)的維度列，比如時間，地區(qū)等等。 Value 則是數(shù)據(jù)的指標列，比如點擊量，花費等。每個指標列還會有自己的聚合函數(shù)，包括sum、min、max和bitmap_union 等。數(shù)據(jù)會根據(jù)維度列進行分組，并對指標列進行聚合。如下圖：

image.png

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

這個表我們是按照：user_id,date,city,age,sex 來統(tǒng)計用戶最后訪問時間、用戶總消費、用戶最大停留時間、最小停留時間

表中的列按照是否設置了 IndexKeysType 是 AGG_KEYS 表示是聚合模型，分為 Key (維度列) 和 Value（指標列）。

這里我們 Key 列是 true 表示這個字段是 Key 列，false 的表示 Value 列，所有的 value 列我們在建表的時候指定他們的聚合類型（AggregationType）

上面這個對應的建表語句如下：

CREATE TABLE  example_tbl_02
(
    `user_id` LARGEINT NOT NULL COMMENT "用戶id",
    `date` DATE NOT NULL COMMENT "數(shù)據(jù)灌入日期時間",
    `city` VARCHAR(20) COMMENT "用戶所在城市",
    `age` SMALLINT COMMENT "用戶年齡",
    `sex` TINYINT COMMENT "用戶性別",
    `last_visit_date` DATETIME REPLACE DEFAULT "1970-01-01 00:00:00" COMMENT "用戶最后一次訪問時間",
    `cost` BIGINT SUM DEFAULT "0" COMMENT "用戶總消費",
    `max_dwell_time` INT MAX DEFAULT "0" COMMENT "用戶最大停留時間",
    `min_dwell_time` INT MIN DEFAULT "99999" COMMENT "用戶最小停留時間"
)
AGGREGATE KEY(`user_id`, `date`, `city`, `age`, `sex`)
DISTRIBUTED BY HASH(`user_id`) BUCKETS 1
PROPERTIES (
    "replication_allocation" = "tag.location.default: 1"
);

我們插入幾條數(shù)據(jù)：

| user_id | date | city | age | sex | last_visit_date | cost | max_dwell_time | min_dwell_time |
| 10000 | 2017-10-01 | 北京 | 20 | 0 | 2017-10-01 06:00:00 | 20 | 10 | 10 |
| 10000 | 2017-10-01 | 北京 | 20 | 0 | 2017-10-01 07:00:00 | 15 | 2 | 2 |
| 10001 | 2017-10-01 | 北京 | 30 | 1 | 2017-10-01 17:05:45 | 2 | 22 | 22 |
| 10002 | 2017-10-02 | 上海 | 20 | 1 | 2017-10-02 12:59:12 | 200 | 5 | 5 |
| 10003 | 2017-10-02 | 廣州 | 32 | 0 | 2017-10-02 11:20:00 | 30 | 11 | 11 |
| 10004 | 2017-10-01 | 深圳 | 35 | 0 | 2017-10-01 10:00:15 | 100 | 3 | 3 |
| 10004 | 2017-10-03 | 深圳 | 35 | 0 | 2017-10-03 10:20:22 | 11 | 6 | 6 |

上面這個數(shù)據(jù)中我們可以看到，前兩行的數(shù)據(jù) Key 是完全一致的，后面 Value 字段應該按照我們建表時候指定的聚合方式進行自動完成數(shù)據(jù)聚合，我們執(zhí)行下面的語句插入數(shù)據(jù)，看看是否和我們預想的一致：

insert into example_tbl_02 values
(10000,"2017-10-01","北京",20,0,"2017-10-01 06:00:00",20,10,10),
(10000,"2017-10-01","北京",20,0,"2017-10-01 07:00:00",15,2,2),
(10001,"2017-10-01","北京",30,1,"2017-10-01 17:05:45",2,22,22),
(10002,"2017-10-02","上海",20,1,"2017-10-02 12:59:12",200,5,5),
(10003,"2017-10-02","廣州",32,0,"2017-10-02 11:20:00",30,11,11),
(10004,"2017-10-01","深圳",35,0,"2017-10-01 10:00:15",100,3,3),
(10004,"2017-10-03","深圳",35,0,"2017-10-03 10:20:22",11,6,6);

通過下圖來查看我們最后執(zhí)行后的數(shù)據(jù)

image.png

聚合模型支持的聚合方式

當我們導入數(shù)據(jù)時，對于 Key 列相同的行會聚合成一行，而 Value 列會按照設置的 AggregationType 進行聚合。 AggregationType 目前有以下幾種聚合方式和agg_state：

1. SUM：求和，多行的 Value 進行累加。
2. REPLACE：替代，下一批數(shù)據(jù)中的 Value 會替換之前導入過的行中的 Value。
3. MAX：保留最大值。
4. MIN：保留最小值。
5. REPLACE_IF_NOT_NULL：非空值替換。和 REPLACE 的區(qū)別在于對于null值，不做替換，這種聚合方式適用于部分列更新。
6. HLL_UNION：HLL 類型的列的聚合方式，通過 HyperLogLog 算法聚合。
7. BITMAP_UNION：BIMTAP 類型的列的聚合方式，進行位圖的并集聚合。

聚合模型使用場景

我們知道需要再建表的時候指定數(shù)據(jù)模型，一旦創(chuàng)建表后期不能修改數(shù)據(jù)模型，如果你建表的時候沒有指定數(shù)據(jù)模型默認是明細模型 (Duplicate Key).

1. Aggregate 模型可以通過預聚合，極大地降低聚合查詢時所需掃描的數(shù)據(jù)量和查詢的計算量，非常適合有固定模式的報表類查詢場景。但是該模型對 count(*) 查詢很不友好。同時因為固定了 Value 列上的聚合方式，在進行其他類型的聚合查詢時，需要考慮語意正確性
2. 在數(shù)據(jù)分析領域，有很多需要對數(shù)據(jù)進?統(tǒng)計和匯總操作的場景，如需要分析?站和 APP 訪問流量，統(tǒng)計??的訪問總時?，訪問總次數(shù)。或者像?商需要為?告主提供?告點擊的總流量，展?總量，消費統(tǒng)計等指標。在這些不需要保存明細數(shù)據(jù)的場景，只需要按照固定維度和指標進行聚合后的數(shù)據(jù)，通常可以使?聚合模型。
3. 另外再部分列更新場景，如果用戶既需要唯一主鍵約束，又需要更新部分列（例如將多張源表導入到一張 doris 表的情形），則可以考慮使用 Aggregate 模型，同時將非主鍵列的聚合類型設置為 REPLACE_IF_NOT_NULL，不過 Doris 2.0 版本 Unqiue Key 模型開始支持部分列更新，如果你沒有開啟行存情況下，大數(shù)據(jù)量表進行部分列更新對你的 CPU 消耗可能會很高，這個時候如果你沒有特殊的需求，也可以使用聚合模型。Unique Key 模型其實也是聚合模型的一個特例。
4. 聚合模型中不保存明細數(shù)據(jù)，如果你需要保存明細數(shù)據(jù)，就不適合使用聚合模型，建議選擇Unqiue Key 或者 Duplicate Key 模型。

聚合模型限制

在聚合模型中，模型對外展現(xiàn)的，是最終聚合后的數(shù)據(jù)。也就是說，任何還未聚合的數(shù)據(jù)（比如說兩個不同導入批次的數(shù)據(jù)），必須通過某種方式，以保證對外展示的一致性，特別是在聚合模型上做count計算，可能會導致結果不準確，針對這種情況我們怎么去解決。

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

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