了解 Doris 數據模型對于我們使用 Doris 來解決我們業務問題非常重要，這個系列我們將詳細介紹 Doris 的三種數據模型及 Doris 數據分區分桶的一些策略，幫助用戶更好的使用 Doris 。
這個系列我會講解 Doris 的三種數據模型及在這三種數據模型之上的 Rollup，物化視圖及前綴索引。還有在這個三種數據模型之上的數據分區分桶的策略。
我們知道在 Doris 中，數據以表（Table）的形式進行邏輯上的描述。 一張表包括行（Row）和列（Column）。Row 即用戶的一行數據。Column 用于描述一行數據中不同的字段。
列可以劃分為兩類：鍵 Key 和值 Value。從業務角度來看，鍵和值對應的就是維度列和指標列
Doris 針對不同場景提供了三種數據模型
- Aggregate （聚合模型) ： 將表中的列分為了Key和Value兩種，數據會根據維度列進行分組，并對指標列進行聚合。
- Unique （唯一主鍵模型)：這個模型一般我們是在對接業務系統 RDS 的時候，需要 Doris 數據和業務數據保持一致，支持Upsert、Delete等操作
- Duplicate （明細模型）： 這個模型不保證數據唯一性（如果你數據重復導入兩次就會重復），數據既沒有主鍵，也沒有聚合需求，一般情況下我們使用這個模型
聚合模型特點
一個正常的模型它肯定會把明細的數據存儲在一個數據庫中，也就是存在 Doris 中。但是因為 Doris 它最早是給鳳巢的一個廣告報表做的，廣告報表有一個很大的特點，就是它只關心統計分析的結果，而不太關心明細的數據，所以 Doris 最早一代的數據模型，是一個聚合的模型。
聚合模型的特點就是將表中的列分為了Key和Value兩種。 Key 就是數據的維度列，比如時間，地區等等。 Value 則是數據的指標列，比如點擊量，花費等。每個指標列還會有自己的聚合函數，包括sum、min、max和bitmap_union 等。數據會根據維度列進行分組，并對指標列進行聚合。如下圖：
通過上面的圖我們可以看到，這是一個典型的用戶信息和訪問行為的事實表。 在一般星型模型中，用戶信息和訪問行為一般分別存放在維度表和事實表中。這里我們為了更加方便的解釋 Doris 的數據模型，將兩部分信息統一存放在一張表中。
這個表我們是按照：user_id,date,city,age,sex 來統計用戶最后訪問時間、用戶總消費、用戶最大停留時間、最小停留時間
表中的列按照是否設置了 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 "數據灌入日期時間",
`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"
);
我們插入幾條數據：
| 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 |
上面這個數據中我們可以看到，前兩行的數據 Key 是完全一致的，后面 Value 字段應該按照我們建表時候指定的聚合方式進行自動完成數據聚合，我們執行下面的語句插入數據，看看是否和我們預想的一致：
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);
通過下圖來查看我們最后執行后的數據
聚合模型支持的聚合方式
當我們導入數據時，對于 Key 列相同的行會聚合成一行，而 Value 列會按照設置的 AggregationType 進行聚合。 AggregationType 目前有以下幾種聚合方式和agg_state：
- SUM：求和，多行的 Value 進行累加。
- REPLACE：替代，下一批數據中的 Value 會替換之前導入過的行中的 Value。
- MAX：保留最大值。
- MIN：保留最小值。
- REPLACE_IF_NOT_NULL：非空值替換。和 REPLACE 的區別在于對于null值，不做替換，這種聚合方式適用于部分列更新。
- HLL_UNION：HLL 類型的列的聚合方式，通過 HyperLogLog 算法聚合。
- BITMAP_UNION：BIMTAP 類型的列的聚合方式，進行位圖的并集聚合。
聚合模型使用場景
我們知道需要再建表的時候指定數據模型，一旦創建表后期不能修改數據模型，如果你建表的時候沒有指定數據模型默認是明細模型 (Duplicate Key).
- Aggregate 模型可以通過預聚合，極大地降低聚合查詢時所需掃描的數據量和查詢的計算量，非常適合有固定模式的報表類查詢場景。但是該模型對 count(*) 查詢很不友好。同時因為固定了 Value 列上的聚合方式，在進行其他類型的聚合查詢時，需要考慮語意正確性
- 在數據分析領域，有很多需要對數據進?統計和匯總操作的場景，如需要分析?站和 APP 訪問流量，統計??的訪問總時?，訪問總次數。或者像?商需要為?告主提供?告點擊的總流量，展?總量，消費統計等指標。在這些不需要保存明細數據的場景，只需要按照固定維度和指標進行聚合后的數據，通常可以使?聚合模型。
- 另外再部分列更新場景，如果用戶既需要唯一主鍵約束，又需要更新部分列（例如將多張源表導入到一張 doris 表的情形），則可以考慮使用 Aggregate 模型，同時將非主鍵列的聚合類型設置為 REPLACE_IF_NOT_NULL，不過 Doris 2.0 版本 Unqiue Key 模型開始支持部分列更新，如果你沒有開啟行存情況下，大數據量表進行部分列更新對你的 CPU 消耗可能會很高，這個時候如果你沒有特殊的需求，也可以使用聚合模型。Unique Key 模型其實也是聚合模型的一個特例。
- 聚合模型中不保存明細數據，如果你需要保存明細數據，就不適合使用聚合模型，建議選擇Unqiue Key 或者 Duplicate Key 模型。
聚合模型限制
在聚合模型中，模型對外展現的，是最終聚合后的數據。也就是說，任何還未聚合的數據（比如說兩個不同導入批次的數據），必須通過某種方式，以保證對外展示的一致性，特別是在聚合模型上做count計算，可能會導致結果不準確，針對這種情況我們怎么去解決。
第一種方式：增加一個 count 列，并且導入數據中，該列值恒為 1。則 select count(*) from table; 的結果等價于 select sum(count) from table;。而后者的查詢效率將遠高于前者。不過這種方式也有使用限制，就是用戶需要自行保證，不會重復導入 AGGREGATE KEY 列都相同的行。否則，select sum(count) from table; 只能表述原始導入的行數，而不是 select count(*) from table; 的語義。
另一種方式：就是 將如上的 count 列的聚合類型改為 REPLACE，且依然值恒為 1。那么 select sum(count) from table; 和 select count(*) from table; 的結果將是一致的。并且這種方式，沒有導入重復行的限制。
