Doris 實戰

目錄

• 概述
• 安裝
• 簡單使用
  • 導入數據
• 高級使用
• 數據模型、ROLLUP 及前綴索引
  • Aggregate 模型
  • 保留明細數據
  • Uniq 模型
  • Duplicate 模型
  • ROLLUP
    • 前綴索引與 ROLLUP
    • ROLLUP 的幾點說明
  • 聚合模型的局限性
  • 數據模型的選擇建議
• 數據划分
  • 數據划分

概述

安裝

FE URL地址如下：
http://hostname:8030/system?path=//frontends
SHOW PROC '/backends';

SHOW PROC '/frontends';

簡單使用

Doris 采用 MySQL 協議進行通信，用戶可通過 MySQL client 或者 MySQL JDBC連接到 Doris 集群。選擇 MySQL client 版本時建議采用5.1 之后的版本

HELP CREATE TABLE; 語法提示支持
Doris支持支持單分區和復合分區兩種建表方式。
在復合分區中：

• 第一級稱為 Partition，即分區。用戶可以指定某一維度列作為分區列（當前只支持整型和時間類型的列），並指定每個分區的取值范圍。
• 第二級稱為 Distribution，即分桶。用戶可以指定一個或多個維度列以及桶數對數據進行 HASH 分布。
  單分區：
  建立一個名字為 table1 的邏輯表。分桶列為 siteid，桶數為 10。

CREATE TABLE table1
(
    siteid INT DEFAULT '10',
    citycode SMALLINT,
    username VARCHAR(32) DEFAULT '',
    pv BIGINT SUM DEFAULT '0'
)
AGGREGATE KEY(siteid, citycode, username)
DISTRIBUTED BY HASH(siteid) BUCKETS 10
PROPERTIES("replication_num" = "1");

復合分區
我們使用 event_day 列作為分區列，建立3個分區: p201706, p201707, p201708

p201706：范圍為 [最小值, 2017-07-01)
p201707：范圍為 [2017-07-01, 2017-08-01)
p201708：范圍為 [2017-08-01, 2017-09-01)
注意區間為左閉右開。

每個分區使用 siteid 進行哈希分桶，桶數為10
AGGREGATE KEY(event_day, siteid, citycode, username) 代表按照這些列聚合，然后對 pv 列進行sum 計算。
PROPERTIES("replication_num" = "1"); 代表一副本，但是為了高可用生產環境中建議設置為 3 副本，保證高可用

CREATE TABLE table2
(
    event_day DATE,
    siteid INT DEFAULT '10',
    citycode SMALLINT,
    username VARCHAR(32) DEFAULT '',
    pv BIGINT SUM DEFAULT '0'
)
AGGREGATE KEY(event_day, siteid, citycode, username)
PARTITION BY RANGE(event_day)
(
    PARTITION p201706 VALUES LESS THAN ('2017-07-01'),
    PARTITION p201707 VALUES LESS THAN ('2017-08-01'),
    PARTITION p201708 VALUES LESS THAN ('2017-09-01')
)
DISTRIBUTED BY HASH(siteid) BUCKETS 10
PROPERTIES("replication_num" = "1");

導入數據

流式導入
流式導入通過 HTTP 協議向 Doris 傳輸數據，可以不依賴其他系統或組件直接導入本地數據。詳細語法幫助可以參閱 HELP STREAM LOAD;
示例1：以 "table1_20170707" 為 Label，使用本地文件 table1_data 導入 table1 表。
FE_HOST 是任一 FE 所在節點 IP，8030 為 fe.conf 中的 http_port。
可以使用任一 BE 的 IP，以及 be.conf 中的 webserver_port 進行導入。如：BE_HOST:8040

curl --location-trusted -u test:test_passwd -H "label:table1_20170707" -H "column_separator:," -T table1_data http://FE_HOST:8030/api/example_db/table1/_stream_load

curl --location-trusted -u 'root:xxxxx' -H "label:table1_20170707" -H "column_separator:," -T ./table1_data http://172.26.xx.xx:8030/api/rtdw_bm/table1/_stream_load

table1_data數據結構大概如下：
1,1,jim,2
2,1,grace,2
3,2,tom,2
4,3,bush,3
5,3,helen,3

curl --location-trusted -u test:test -H "label:table2_20170707" -H "column_separator:|" -T table2_data http://127.0.0.1:8030/api/example_db/table2/_stream_load
注意事項：

1. 采用流式導入建議文件大小限制在 10GB 以內，過大的文件會導致失敗重試代價變大。
2. 每一批導入數據都需要取一個 Label，Label 最好是一個和一批數據有關的字符串，方便閱讀和管理。Doris 基於 Label 保證在一個Database 內，同一批數據只可導入成功一次。失敗任務的 Label 可以重用。
3. 流式導入是同步命令。命令返回成功則表示數據已經導入，返回失敗表示這批數據沒有導入。

Broker 導入
Broker 導入通過部署的 Broker 進程，讀取外部存儲上的數據進行導入。
示例：以 "table1_20170708" 為 Label，將 HDFS 上的文件導入 table1 表

LOAD LABEL table1_20170708
(
    DATA INFILE("hdfs://your.namenode.host:port/dir/table1_data")
    INTO TABLE table1
)
WITH BROKER hdfs 
(
    "username"="hdfs_user",
    "password"="hdfs_password"
)
PROPERTIES
(
    "timeout"="3600",
    "max_filter_ratio"="0.1"
);

Broker 導入是異步命令。以上命令執行成功只表示提交任務成功。導入是否成功需要通過 SHOW LOAD; 查看。如：
SHOW LOAD WHERE LABEL = "table1_20170708";

高級使用

表結構變更
我們新增一列 uv，類型為 BIGINT，聚合類型為 SUM，默認值為 0: SUM 是 Doris區別於 MySQL的地方
其代表着可以用於預聚合計算，也就相當於CK的聚合視圖

ALTER TABLE table1 ADD COLUMN uv BIGINT SUM DEFAULT '0' after pv;
-- 以下查看 ALTER 進度， 查看列操作進度
SHOW ALTER TABLE COLUMN;

Rollup
Rollup 可以理解為 Table 的一個物化索引結構。物化 是因為其數據在物理上獨立存儲，而 索引 的意思是，Rollup可以調整列順序以增加前綴索引的命中率，也可以減少key列以增加數據的聚合度。
如果業務方經常有看城市 pv 總量的需求，可以建立一個只有 citycode, pv 的rollup。
ALTER TABLE table1 ADD ROLLUP rollup_city(citycode, pv);

以下命令查看ROLLUP任務進度
SHOW ALTER TABLE ROLLUP;

Rollup 建立完成之后可以使用 DESC table1 ALL 查看表的 Rollup 信息。
Rollup 建立之后，查詢不需要指定 Rollup 進行查詢。還是指定原有表進行查詢即可。程序會自動判斷是否應該使用 Rollup。是否命中 Rollup可以通過 EXPLAIN your_sql; 命令進行查看。
如下實驗結果發現 rollup: rollup_city 使用了該 rollup_city 預上卷結果

數據表的查詢注意事項

1. 內存限制
   為了防止用戶的一個查詢可能因為消耗內存過大。查詢進行了內存控制，一個查詢任務，在單個 BE 節點上默認使用不超過 2GB 內存。
   用戶在使用時，如果發現報 Memory limit exceeded 錯誤，一般是超過內存限制了。
   遇到這種問題優先優化SQL語句，如果確切發現2GB內存不能滿足，可以手動設置內存參數。

顯示查詢內存限制，查詢資源使用

SHOW VARIABLES LIKE "%mem_limit%";
以下看到默認內存大小是2GB

可以使用如下進行修改
SET exec_mem_limit = 8589934592;
以上修改都是 session級別的， 如果需要修改全局變量，可以這樣設置：SET GLOBAL exec_mem_limit = 8589934592;。設置完成后，斷開 session 重新登錄，參數將永久生效。

2. 查詢超時
   當前默認查詢時間設置為最長為 300 秒，如果一個查詢在 300 秒內沒有完成，則查詢會被 Doris 系統 cancel 掉。用戶可以通過這個參數來定制自己應用的超時時間，實現類似 wait(timeout) 的阻塞方式。
   SHOW VARIABLES LIKE "%query_timeout%";
   
   SET query_timeout = 60;

3. Broadcast/Shuffle Join
   系統默認實現 Join 的方式，是將小表進行條件過濾后，將其廣播到大表所在的各個節點上，形成一個內存 Hash 表，然后流式讀出大表的數據進行Hash Join。但是如果當小表過濾后的數據量無法放入內存的話，此時 Join 將無法完成，通常的報錯應該是首先造成內存超限。
   如果遇到上述情況，建議顯式指定 Shuffle Join，也被稱作 Partitioned Join。即將小表和大表都按照 Join 的 key 進行 Hash，然后進行分布式的 Join。這個對內存的消耗就會分攤到集群的所有計算節點上。
   Doris會自動嘗試進行 Broadcast Join，如果預估小表過大則會自動切換至 Shuffle Join。注意，如果此時顯式指定了 Broadcast Join 也會自動切換至 Shuffle Join。
   使用 Broadcast Join（顯式指定）:

select sum(table1.pv) from table1 join [broadcast] table2 where table1.siteid = 2;

使用 Shuffle Join:

select sum(table1.pv) from table1 join [shuffle] table2 where table1.siteid = 2;

4. 查詢重試和高可用
   當部署多個 FE 節點時，用戶可以在多個 FE 之上部署負載均衡層來實現 Doris 的高可用。

• 自己在應用層代碼進行重試和負載均衡。比如發現一個連接掛掉，就自動在其他連接上進行重試。應用層代碼重試需要應用自己配置多個doris前端節點地址。
• 如果使用 mysql jdbc connector 來連接Doris，可以使用 jdbc 的自動重試機制:
  jdbc:mysql://[host:port],[host:port].../[database][?propertyName1][=propertyValue1][&propertyName2][=propertyValue2]...
• 應用可以連接到和應用部署到同一機器上的 MySQL Proxy，通過配置 MySQL Proxy 的 Failover 和 Load Balance 功能來達到目的。
  http://dev.mysql.com/doc/refman/5.6/en/mysql-proxy-using.html

數據模型、ROLLUP 及前綴索引

Column 可以分為兩大類：Key 和 Value。從業務角度看，Key 和 Value 可以分別對應維度列和指標列。
Doris 的數據模型主要分為3類:

• Aggregate
• Uniq
• Duplicate

Aggregate 模型

就類比於 CK 的 聚合表， 通過聚合視圖提前進行數據聚合，不存儲明細
表中的列按照是否設置了 AggregationType，分為 Key (維度列) 和 Value（指標列）。沒有設置 AggregationType 的，如 user_id、date、age ... 等稱為 Key，而設置了 AggregationType 的稱為 Value。
當我們導入數據時，對於 Key 列相同的行會聚合成一行，而 Value 列會按照設置的 AggregationType 進行聚合。 AggregationType 目前有以下四種聚合方式：

1. SUM：求和，多行的 Value 進行累加。
2. REPLACE：替代，下一批數據中的 Value 會替換之前導入過的行中的 Value。
3. MAX：保留最大值。
4. MIN：保留最小值。
   經過聚合，Doris 中最終只會存儲聚合后的數據。換句話說，即明細數據會丟失，用戶不能夠再查詢到聚合前的明細數據了。
   對於聚合表，數據聚合大概分為三個階段
   1、每一批次數據導入的 ETL 階段。該階段會在每一批次導入的數據內部進行聚合。
   2、底層 BE 進行數據 Compaction 的階段。該階段，BE 會對已導入的不同批次的數據進行進一步的聚合。
   3、數據查詢階段。在數據查詢時，對於查詢涉及到的數據，會進行對應的聚合。

保留明細數據

即增加了一列 timestamp，記錄精確到秒的數據灌入時間。因為加入了 timestamp 可以保證 key 肯定不一樣，即使在聚合模型下，也能保證保存完整的數據。

Uniq 模型

在某些多維分析場景下，用戶更關注的是如何保證 Key 的唯一性，即如何獲得 Primary Key 唯一性約束。因此，我們引入了 Uniq 的數據模型。
此種方式就類似於 Aggregate 模型的把非 UNIQUE KEY 的 column 設置為 REPLACE 指標

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 "用戶注冊時間"
)
UNIQUE KEY(`user_id`, `username`)
... /* 省略 Partition 和 Distribution 信息 */
；

Duplicate 模型

在某些多維分析場景下，數據既沒有主鍵，也沒有聚合需求。因此，我們引入 Duplicate 數據模型來滿足這類需求。舉例說明。
這種數據模型區別於 Aggregate 和 Uniq 模型。數據完全按照導入文件中的數據進行存儲，不會有任何聚合。即使兩行數據完全相同，也都會保留。
而在建表語句中指定的 DUPLICATE KEY，只是用來指明底層數據按照那些列進行排序。（更貼切的名稱應該為 “Sorted Column”，這里取名 “DUPLICATE KEY” 只是用以明確表示所用的數據模型。

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

ROLLUP

ROLLUP 在多維分析中是“上卷”的意思，即將數據按某種指定的粒度進行進一步聚合。
在 Doris 中，我們將用戶通過建表語句創建出來的表稱為 Base 表（Base Table）。Base 表中保存着按用戶建表語句指定的方式存儲的基礎數據。
在 Base 表之上，我們可以創建任意多個 ROLLUP 表。這些 ROLLUP 的數據是基於 Base 表產生的，並且在物理上是獨立存儲的。
ROLLUP 表的基本作用，在於在 Base 表的基礎上，獲得更粗粒度的聚合數據。
對 table 創建一個 ROLLUP （user_id，cost） 則以下 SQL Doris 會自動命中這個 ROLLUP 表，從而只需掃描極少的數據量，即可完成這次聚合查詢。
SELECT user_id, sum(cost) FROM table GROUP BY user_id;
在 Doris 里 Rollup 作為一份聚合物化視圖，其在查詢中可以起到兩個作用：

• 索引
• 聚合數據（僅用於聚合模型，即aggregate key）

前綴索引與 ROLLUP

前綴索引
Doris 不支持在任意列上創建索引。Doris 這類 MPP 架構的 OLAP 數據庫，通常都是通過提高並發，來處理大量數據的。 這塊是 MPP架構和 MySQL的最本質區別，MySQL適合在多個列上建索引，提高查詢性能。
MPP的話 主要是使用多進程多線程並發模型提高OLAP分析的效率，底層存儲是 Sorted String Table ，基於排序列查詢會非常快。此處類比 CK 的 order by 屬性當建表時候不指定主鍵時，order by 字段組就是主鍵，這些字段組會建立索引，並且每個shard 數據存儲的排序方式
就是order by 指定的字段。 CK 的這種索引是稀疏索引，可以使用很小的空間對大量的數據提供所有能力。

本質上，Doris 的數據存儲在類似 SSTable（Sorted String Table）的數據結構中。該結構是一種有序的數據結構，可以按照指定的列進行排序存儲。在這種數據結構上，以排序列作為條件進行查找，會非常的高效。
在 Aggregate、Uniq 和 Duplicate 三種數據模型中。底層的數據存儲，是按照各自建表語句中，AGGREGATE KEY、UNIQ KEY 和 DUPLICATE KEY 中指定的列進行排序存儲的。
而前綴索引，即在排序的基礎上，實現的一種根據給定前綴列，快速查詢數據的索引方式。
我們將一行數據的前 36 個字節 作為這行數據的前綴索引。當遇到 VARCHAR 類型時，前綴索引會直接截斷。
當我們的查詢條件，是前綴索引的前綴時，可以極大的加快查詢速度。
所以在建表時，正確的選擇列順序，能夠極大地提高查詢效率。
因為建表時已經指定了列順序，所以一個表只有一種前綴索引。 可以調整 ROLLUP 修改列順序，引導使用索引。

Doris 會把 Base/Rollup 表中的前 36 個字節（有 varchar 類型則可能導致前綴索引不滿 36 個字節，varchar 會截斷前綴索引，並且最多使用 varchar 的 20 個字節）在底層存儲引擎單獨生成一份排序的稀疏索引數據(數據也是排序的，用索引定位，然后在數據中做二分查找)

Base 表結構如下：

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

我們可以在此基礎上創建一個 ROLLUP 表：

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

ROLLUP 的幾點說明

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

聚合模型的局限性

Doris select count(*) 的本質就是 掃描所有的 AGGREGATE KEY 列，查詢時聚合， 所以性能比較弱
可以的優化手段包括：

1. 增加一個 count BIGINT SUM 類型的列，要是 AGGREGATE KEY 列不重復，直接 select count 就行
2. 要是有重復的， 改為 replace類型，直接 select sum(count) 就行
   Duplicate 模型數據不會重復沒有聚合語義， 隨便select 一個字段都可以

數據模型的選擇建議

1. Aggregate 模型可以通過預聚合，極大地降低聚合查詢時所需掃描的數據量和查詢的計算量，非常適合有固定模式的報表類查詢場景。但是該模型對 count(*) 查詢很不友好。同時因為固定了 Value 列上的聚合方式，在進行其他類型的聚合查詢時，需要考慮語意正確性。
2. Uniq 模型針對需要唯一主鍵約束的場景，可以保證主鍵唯一性約束。但是無法利用 ROLLUP 等預聚合帶來的查詢優勢（因為本質是 REPLACE，沒有 SUM 這種聚合方式）。
3. Duplicate 適合任意維度的 Ad-hoc 查詢。雖然同樣無法利用預聚合的特性，但是不受聚合模型的約束，可以發揮列存模型的優勢（只讀取相關列，而不需要讀取所有 Key 列）。

數據划分

Row & Column
Column 可以分為兩大類：Key 和 Value。從業務角度看，Key 和 Value 可以分別對應維度列和指標列。從聚合模型的角度來說，Key 列相同的行，會聚合成一行。其中 Value 列的聚合方式由用戶在建表時指定。
一個 Tablet 只屬於一個 Partition。而一個 Partition 包含若干個 Tablet。
若干個 Partition 組成一個 Table。Partition 可以視為是邏輯上最小的管理單元。數據的導入與刪除，都可以或僅能針對一個 Partition 進行。
也就是 一個 Partition 可能由多個 Tablet 進行存儲。

數據划分

-- Range Partition

CREATE TABLE IF NOT EXISTS example_db.expamle_range_tbl
(
    `user_id` LARGEINT NOT NULL COMMENT "用戶id",
    `date` DATE NOT NULL COMMENT "數據灌入日期時間",
    `timestamp` DATETIME 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 "用戶最小停留時間"
)
ENGINE=olap
AGGREGATE KEY(`user_id`, `date`, `timestamp`, `city`, `age`, `sex`)
PARTITION BY RANGE(`date`)
(
    PARTITION `p201701` VALUES LESS THAN ("2017-02-01"),
    PARTITION `p201702` VALUES LESS THAN ("2017-03-01"),
    PARTITION `p201703` VALUES LESS THAN ("2017-04-01")
)
DISTRIBUTED BY HASH(`user_id`) BUCKETS 16
PROPERTIES
(
    "replication_num" = "3",
    "storage_medium" = "SSD",
    "storage_cooldown_time" = "2018-01-01 12:00:00"
);

-- List Partition

CREATE TABLE IF NOT EXISTS example_db.expamle_list_tbl
(
    `user_id` LARGEINT NOT NULL COMMENT "用戶id",
    `date` DATE NOT NULL COMMENT "數據灌入日期時間",
    `timestamp` DATETIME 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 "用戶最小停留時間"
)
ENGINE=olap
AGGREGATE KEY(`user_id`, `date`, `timestamp`, `city`, `age`, `sex`)
PARTITION BY LIST(`city`)
(
    PARTITION `p_cn` VALUES IN ("Beijing", "Shanghai", "Hong Kong"),
    PARTITION `p_usa` VALUES IN ("New York", "San Francisco"),
    PARTITION `p_jp` VALUES IN ("Tokyo")
)
DISTRIBUTED BY HASH(`user_id`) BUCKETS 16
PROPERTIES
(
    "replication_num" = "3",
    "storage_medium" = "SSD",
    "storage_cooldown_time" = "2018-01-01 12:00:00"
);

分區與分桶
DORIS 支持2種數據划分方式
第一層是 Partition，支持 Range 和 List 的划分方式。
第二層是 Bucket（Tablet），僅支持 Hash 的划分方式。
Partition：
Partition 列可以指定一列或多列。分區類必須為 KEY 列。
當不使用 Partition 建表時，系統會自動生成一個和表名同名的，全值范圍的 Partition

Bucket：
如果使用了 Partition，則 DISTRIBUTED ... 語句描述的是數據在各個分區內的划分規則。如果不使用 Partition，則描述的是對整個表的數據的划分規則。 也就是說
分桶列的選擇，是在 查詢吞吐 和 查詢並發 之間的一種權衡：

1. 分桶越細則查詢沒到細節末節時，會觸發全桶掃描， 適合這樣能均衡的把數據均衡分布到不同的桶中，適合高吞吐低延遲的查詢
2. 分桶粗點， 可能就一個字段，則會導致點查大部分只在一個bucket中， 適合低延時搞並發查詢，但是吞吐低一些， 試想大量的數據都需要從一個 bucket出，尤其是存儲數據量非常大的適合
   一個表的 Tablet 總數量等於 (Partition num * Bucket num)。
   一個表的 Tablet 數量，在不考慮擴容的情況下，推薦略多於整個集群的磁盤數量。
   單個 Tablet 的數據量理論上沒有上下界，但建議在 1G - 10G 的范圍內。如果單個 Tablet 數據量過小，則數據的聚合效果不佳，且元數據管理壓力大。如果數據量過大，則不利於副本的遷移、補齊，且會增加 Schema Change 或者 Rollup 操作失敗重試的代價（這些操作失敗重試的粒度是 Tablet）。

ENGINE：
本示例中，ENGINE 的類型是 olap，即默認的 ENGINE 類型。在 Doris 中，只有這個 ENGINE 類型是由 Doris 負責數據管理和存儲的。其他 ENGINE 類型，如 mysql、broker、es 等等，本質上只是對外部其他數據庫或系統中的表的映射，以保證 Doris 可以讀取這些數據。而 Doris 本身並不創建、管理和存儲任何非 olap ENGINE 類型的表和數據。
保留字。當用戶自定義名稱遇到保留字時，需要用反引號 `` 引起來。建議所有自定義名稱使用這個符號引起來。