本文是學習StarRocks的讀書筆記，讓你快速理解下一代高性能分析數(shù)據(jù)倉庫的架構、數(shù)據(jù)存儲及表設計。
1. 架構
1.1. 整體架構
StarRocks的架構相對簡單。
- 整個系統(tǒng)只包含兩種類型的組件，前端(FE)和后端(BE)，StarRocks不依賴任何外部組件，簡化了部署和維護。
- FE和BE可以在不停機的情況下橫向擴展。
- StarRocks具有元數(shù)據(jù)和服務數(shù)據(jù)的復制機制，這增加了數(shù)據(jù)的可靠性，并有效地防止單點故障(SPOFs)。
- 與MySQL協(xié)議兼容，并支持標準SQL。用戶可以輕松地從MySQL客戶端連接到StarRocks
1.2. 數(shù)據(jù)管理
2. 表設計
2.1. 列存儲
2.2.索引
2.3. 加速策略
- Pre-aggregation
- Partitioning and bucketing
- Materialized view： 物化視圖的數(shù)據(jù)以與表數(shù)據(jù)相同的方式組織和存儲。但是物化視圖可以有自己的前綴索引。在為物化視圖創(chuàng)建前綴索引時，可以指定適當?shù)木酆狭６?、列計?shù)和維列順序，以確保經(jīng)常使用的查詢條件能夠命中物化視圖前綴索引表中的預期條目。
- Per-column index
- A Bloom filter ： Bloom過濾器用于確定數(shù)據(jù)塊是否包含要查詢的值。
- A zone map： 區(qū)域映射用于定位指定范圍內(nèi)的值。
- A bitmap index： 位圖索引用于查找ENUM數(shù)據(jù)類型列中滿足指定查詢條件的行。
3. Data models
StarRocks提供四種數(shù)據(jù)模型： Duplicate Key, Aggregate Key, Unique Key, and Primary Key
3.1. Duplicate Key model
適用場景：
- 分析原始數(shù)據(jù)，如原始日志和原始操作記錄。
- 可以使用多種方法查詢數(shù)據(jù)，不受預聚合方法的限制。
- 加載日志數(shù)據(jù)或時序數(shù)據(jù)。新數(shù)據(jù)以追加模式寫入，現(xiàn)有數(shù)據(jù)不更新。
注意：
- 默認情況下，如果沒有指定排序鍵列，StarRocks將使用前三列作為排序鍵【sort key】列
- 可以在表創(chuàng)建時創(chuàng)建索引，如BITMAP索引和Bloomfilter索引。
- 如果加載了兩條相同的記錄，將它們保留為兩條記錄，而不是一條
- 只能向表中追加數(shù)據(jù)。不能修改表中的現(xiàn)有數(shù)據(jù)。
CREATE TABLE IF NOT EXISTS detail (
event_time DATETIME NOT NULL COMMENT "datetime of event",
event_type INT NOT NULL COMMENT "type of event",
user_id INT COMMENT "id of user",
device_code INT COMMENT "device code",
channel INT COMMENT ""
)
DUPLICATE KEY(event_time, event_type)
DISTRIBUTED BY HASH(user_id) BUCKETS 8;
3.2. Aggregate Key model
此模型有助于減少查詢需要處理的數(shù)據(jù)量，從而加快查詢速度。
適用場景：數(shù)據(jù)統(tǒng)計和分析場景
使用時有如下特點：
- 大多數(shù)查詢是聚合查詢，例如SUM、COUNT和MAX。
- 不需要檢索原始的詳細數(shù)據(jù)。
- 歷史數(shù)據(jù)不經(jīng)常更新。只追加新數(shù)據(jù)。
聚合時機：
- ingestion 階段： 當數(shù)據(jù)批量加載到表中時，每個批量包含一個數(shù)據(jù)版本。生成數(shù)據(jù)版本后，StarRocks將在數(shù)據(jù)版本中具有相同排序鍵的數(shù)據(jù)進行聚合。
- compaction 階段：將數(shù)據(jù)攝取時生成的多個數(shù)據(jù)版本的文件定期壓縮成一個大文件時，StarRocks會在大文件中聚合具有相同排序鍵的數(shù)據(jù)。
- query 階段：在返回查詢結果之前聚合所有數(shù)據(jù)版本中具有相同排序鍵的數(shù)據(jù)。
注意：
- 如果AGGREGATE KEY關鍵字不包括所有維度列，則無法創(chuàng)建表。
- 如果沒有使用AGGREGATE key關鍵字顯式地定義排序鍵列，將選擇除度量列之外的所有列作為排序鍵列
- 在運行查詢時，排序鍵列在多個數(shù)據(jù)版本聚合之前被過濾，而度量列在多個數(shù)據(jù)版本聚合之后被過濾。
- 創(chuàng)建表時，不能在表的度量列上創(chuàng)建BITMAP索引或Bloom Filter索引
- 將數(shù)據(jù)加載到使用聚合鍵模型的表中時，只能更新表的所有列
CREATE TABLE IF NOT EXISTS example_db.aggregate_tbl (
site_id LARGEINT NOT NULL COMMENT "id of site",
date DATE NOT NULL COMMENT "time of event",
city_code VARCHAR(20) COMMENT "city_code of user",
pv BIGINT SUM DEFAULT "0" COMMENT "total page views"
)
AGGREGATE KEY(site_id, date, city_code)
DISTRIBUTED BY HASH(site_id) BUCKETS 8
PROPERTIES ("replication_num" = "1");
3.3. Unique Key
適用場景:
- 需要頻繁實時更新數(shù)據(jù)的業(yè)務場景，如在電子商務場景中，每天可以下數(shù)億個訂單，訂單狀態(tài)經(jīng)常變化
注意:
- 主鍵必須創(chuàng)建在執(zhí)行唯一約束且不能更改名稱的列上
- 在運行查詢時，主鍵列在多個數(shù)據(jù)版本聚合之前被過濾，而度量列在多個數(shù)據(jù)版本聚合之后被過濾
- 在聚合過程中，StarRocks比較所有主鍵列。這很耗時，而且可能會降低查詢性能。因此，不要定義大量的主鍵列
- 創(chuàng)建表時，不能在表的指標列上創(chuàng)建BITMAP索引或Bloom Filter索引。
- 不支持實體化視圖。
- 將數(shù)據(jù)加載到使用唯一鍵模型的表中時，只能更新表的所有列
CREATE TABLE IF NOT EXISTS orders (
create_time DATE NOT NULL COMMENT "create time of an order",
order_id BIGINT NOT NULL COMMENT "id of an order",
order_state INT COMMENT "state of an order",
total_price BIGINT COMMENT "price of an order"
)
UNIQUE KEY(create_time, order_id)
DISTRIBUTED BY HASH(order_id) BUCKETS 8;
3.4. Primary Key
基于StarRocks提供的一個新的存儲引擎設計的
與Unique Key模型不同，Primary Key模型在查詢期間不需要聚合操作，并支持謂詞和索引的下推。因此，Primary Key模型可以提供較高的查詢性能，盡管實時和頻繁的數(shù)據(jù)更新。
Duplicate Key模型采用MoR策略。MoR簡化了數(shù)據(jù)寫入，但需要在線聚合多個數(shù)據(jù)版本。此外，Merge操作符不支持下推謂詞和索引。結果，查詢性能下降。
Primary Key模型采用刪除+插入策略，確保每條記錄都有唯一的主鍵。這樣，主鍵模型就不需要合并操作。詳情如下:
- 對記錄進行更新操作時，它通過搜索主鍵索引來定位該記錄，將該記錄標記為已刪除，并插入一條新記錄。換句話說，StarRocks將更新操作轉換為刪除操作加上插入操作。
- 對記錄進行刪除操作時，它通過搜索主鍵索引來定位記錄，并將記錄標記為已刪除
適用場景：
- 數(shù)據(jù)需要經(jīng)常實時更新
- 實時流數(shù)據(jù)從交易處理系統(tǒng)到StarRocks，這簡化了數(shù)據(jù)同步，并提供比使用唯一鍵模型的MoR (Merge on Read)表高3到10倍的查詢性能
- 通過對單個列執(zhí)行更新操作來連接多個流：這些場景中的上游數(shù)據(jù)可能來自各種應用程序，如購物app、物流app和銀行app，或者來自機器學習系統(tǒng)。主鍵模型非常適合這些場景，因為它支持對單個列的更新。每個應用程序或系統(tǒng)只能更新在自己的服務范圍內(nèi)保存數(shù)據(jù)的列
- 主鍵占用的內(nèi)存【memory occupied by the primary key 】是可控的
-
當將數(shù)據(jù)加載到表中時，StarRocks將主鍵索引加載到內(nèi)存中。因此Primary Key模型需要比其他三個數(shù)據(jù)模型更大的內(nèi)存容量。StarRocks將組成主鍵的字段的總長度限制為編碼后的127字節(jié)
-
表包含快速變化的數(shù)據(jù)和緩慢變化的數(shù)據(jù)?？焖僮兓臄?shù)據(jù)經(jīng)常在最近幾天更新，而緩慢變化的數(shù)據(jù)很少更新，如訂單表，按天分區(qū)，在運行數(shù)據(jù)加載作業(yè)時，主鍵索引不會加載到內(nèi)存中，只有最近更新的訂單的索引項才會加載到內(nèi)存中。
-
表是一個由數(shù)百或數(shù)千列組成的平面表。主鍵只包含表數(shù)據(jù)的一小部分，并且只消耗少量內(nèi)存。如user status or profile table，表的列太多，但只有幾千萬到幾億條
-
注意：
- 必須在強制執(zhí)行唯一約束的列上創(chuàng)建主鍵，并且不能更改主鍵列的名稱。
- 主鍵列可以是以下任何數(shù)據(jù)類型:BOOLEAN、TINYINT、SMALLINT、INT、BIGINT、LARGEINT、STRING、VARCHAR、DATE和DATETIME。但是，主鍵列不能定義為NULL。
- 分區(qū)列和桶列必須參與主鍵。
- the memory occupied by the primary key index 的計算公式： (主鍵長度+9) x 記錄數(shù)量 x 副本數(shù) x 1.5 = 占用內(nèi)存大小
- 9是每行不可變的開銷，1.5是每個哈希表的平均額外開銷
-
enable_persistent_index:主鍵索引可以持久化到磁盤并存儲在內(nèi)存中，以避免占用太多內(nèi)存。 - 從2.3.0版本開始， indicator column現(xiàn)在支持BITMAP、HLL數(shù)據(jù)類型。
- 創(chuàng)建表時，不能在表的 metric columns 上創(chuàng)建BITMAP索引或Bloom Filter索引。
- 從2.4.0版本開始，可以基于主鍵表創(chuàng)建異步物化視圖
create table orders (
dt date NOT NULL,
order_id bigint NOT NULL,
user_id int NOT NULL,
merchant_id int NOT NULL,
good_id int NOT NULL,
good_name string NOT NULL,
price int NOT NULL,
cnt int NOT NULL,
revenue int NOT NULL,
state tinyint NOT NULL
) PRIMARY KEY (dt, order_id)
PARTITION BY RANGE(`dt`) (
PARTITION p20210820 VALUES [('2021-08-20'), ('2021-08-21')),
PARTITION p20210821 VALUES [('2021-08-21'), ('2021-08-22')),
...
PARTITION p20210929 VALUES [('2021-09-29'), ('2021-09-30')),
PARTITION p20210930 VALUES [('2021-09-30'), ('2021-10-01'))
) DISTRIBUTED BY HASH(order_id) BUCKETS 4
PROPERTIES("replication_num" = "3",
"enable_persistent_index" = "true");
create table users (
user_id bigint NOT NULL,
name string NOT NULL,
email string NULL,
address string NULL,
age tinyint NULL,
sex tinyint NULL,
last_active datetime,
property0 tinyint NOT NULL,
property1 tinyint NOT NULL,
property2 tinyint NOT NULL,
property3 tinyint NOT NULL,
....
) PRIMARY KEY (user_id)
DISTRIBUTED BY HASH(user_id) BUCKETS 4
PROPERTIES("replication_num" = "3",
"enable_persistent_index" = "true");
4. 數(shù)據(jù)分布 Data distribution
4.1. 基本概念
-
分區(qū)：
- 在分區(qū)時，可以設置分區(qū)的存儲策略，包括副本數(shù)量、熱數(shù)據(jù)或冷數(shù)據(jù)的存儲策略、存儲介質(zhì)等。
- StarRocks允許在集群中使用多個存儲介質(zhì)。例如，將最新數(shù)據(jù)保存在SSD硬盤上，可以提高查詢性能;將歷史數(shù)據(jù)保存在SATA硬盤上，可以降低存儲成本。
-
分桶：
- 分桶是將一個分區(qū)劃分為多個更易于管理的部分即tablet，tablet是使用和分配的最小存儲單元
- bucket列中具有相同哈希值的數(shù)據(jù)被分布到同一tablet中
- StarRocks為每個tablet創(chuàng)建多個副本(默認為三個)，以防止數(shù)據(jù)丟失。這些副本由單獨的本地存儲引擎管理。創(chuàng)建表時必須指定bucket列。
4.2. 分區(qū)方法
- Round-robin: distributes data across different nodes in a cyclic.
- Range: distributes data across different nodes based on the value range of partitioning columns.
- List: distributes data across different nodes based on the discrete values of partitioning columns, such as age.
- Hash: distributes data across different nodes based on a hash algorithm.
為了實現(xiàn)更靈活的數(shù)據(jù)分布，可以根據(jù)業(yè)務需求組合以上四種分區(qū)方法，例如hash-hash, range-hash, and hash-list。StarRocks提供了以下兩種分區(qū)方法:
# 整個表只有一個分區(qū)，并按site_id分桶
CREATE TABLE site_access(
site_id INT DEFAULT '10',
city_code SMALLINT,
user_name VARCHAR(32) DEFAULT '',
pv BIGINT SUM DEFAULT '0'
)
AGGREGATE KEY(site_id, city_code, user_name)
DISTRIBUTED BY HASH(site_id) BUCKETS 10;
# 先按日期分區(qū)，再按site_id分桶
CREATE TABLE site_access(
event_day DATE,
site_id INT DEFAULT '10',
city_code VARCHAR(100),
user_name VARCHAR(32) DEFAULT '',
pv BIGINT SUM DEFAULT '0'
)
AGGREGATE KEY(event_day, site_id, city_code, user_name)
PARTITION BY RANGE(event_day)
(
PARTITION p1 VALUES LESS THAN ("2020-01-31"),
PARTITION p2 VALUES LESS THAN ("2020-02-29"),
PARTITION p3 VALUES LESS THAN ("2020-03-31")
)
DISTRIBUTED BY HASH(site_id) BUCKETS 10;
4.3. 分區(qū)、分桶列的選擇
- 分區(qū)列的選擇
- 只有DATE、DATETIME或INT類型的列可以用作分區(qū)列，
- 分區(qū)列要求：低基數(shù)、在查詢中經(jīng)常用作篩選器的列、每個分區(qū)的數(shù)據(jù)量必須小于100GB。
- 分桶列的選擇
- 分桶列的要求：高基數(shù)列如ID、在查詢中經(jīng)常用作篩選器的列，列值不能更新
- 分桶列最多為三個，不能太多
- 分桶列在指定后不能被修改。
- tablet反映了StarRocks中數(shù)據(jù)文件的組織方式。從StarRocks 2.5開始，創(chuàng)建表時不需要設置桶數(shù)，StarRocks會自動設置桶數(shù)。
- 建議每個tablet包含大約10GB的原始數(shù)據(jù)
- 要在tablet上啟用并行掃描，請確保啟用了
GLOBAL enable_tablet_internal_parallel。
CREATE TABLE site_access(
event_day DATE,
site_id INT DEFAULT '10',
city_code VARCHAR(100),
user_name VARCHAR(32) DEFAULT '',
pv BIGINT SUM DEFAULT '0'
)
AGGREGATE KEY(event_day, site_id, city_code, user_name)
PARTITION BY RANGE(event_day)
(
PARTITION p1 VALUES LESS THAN ("2020-01-31"),
PARTITION p2 VALUES LESS THAN ("2020-02-29"),
PARTITION p3 VALUES LESS THAN ("2020-03-31")
)
DISTRIBUTED BY HASH(site_id) BUCKETS 10;
CREATE TABLE site_access(
site_id INT DEFAULT '10',
city_code SMALLINT,
user_name VARCHAR(
32
) DEFAULT '',
pv BIGINT SUM DEFAULT '0'
)
AGGREGATE KEY(site_id, city_code, user_name)
DISTRIBUTED BY HASH(site_id,city_code); --do not need to set the number of buckets
管理分區(qū)
- 建表時指定分區(qū)
CREATE TABLE site_access( datekey DATE, site_id INT, city_code SMALLINT, user_name VARCHAR(32), pv BIGINT DEFAULT '0' ) ENGINE=olap DUPLICATE KEY(datekey, site_id, city_code, user_name) PARTITION BY RANGE (datekey) ( START ("2019-01-01") END ("2021-01-01") EVERY (INTERVAL 1 YEAR), START ("2021-01-01") END ("2021-05-01") EVERY (INTERVAL 1 MONTH), START ("2021-05-01") END ("2021-05-04") EVERY (INTERVAL 1 DAY) ) DISTRIBUTED BY HASH(site_id) BUCKETS 10 PROPERTIES( "replication_num" = "1" ); - 修改、刪除、恢復、查看分區(qū)
ALTER TABLE site_access ADD PARTITION p4 VALUES LESS THAN ("2020-04-30") DISTRIBUTED BY HASH(site_id) BUCKETS 20; ALTER TABLE site_access DROP PARTITION p1; RECOVER PARTITION p1 FROM site_access; SHOW PARTITIONS FROM site_access;
5. 數(shù)據(jù)壓縮
StarRocks支持四種數(shù)據(jù)壓縮算法:LZ4、Zstandard(或zstd)、zlib和Snappy。
這些數(shù)據(jù)壓縮算法在壓縮比和壓縮/解壓縮性能上存在差異。
壓縮比：zlib > Zstandard > LZ4 > Snappy.
特別是LZ4和Zstandard具有良好的壓縮比和解壓性能
如果對更小的存儲空間沒有特定的要求，建議使用LZ4或Zstandard。文章來源：http://www.zghlxwxcb.cn/news/detail-604444.html
只能在創(chuàng)建表時為表指定數(shù)據(jù)壓縮算法，不能在創(chuàng)建后更改。文章來源地址http://www.zghlxwxcb.cn/news/detail-604444.html
CREATE TABLE `data_compression` (
`id` INT(11) NOT NULL COMMENT "",
`name` CHAR(200) NULL COMMENT ""
)
ENGINE=OLAP
UNIQUE KEY(`id`)
COMMENT "OLAP"
DISTRIBUTED BY HASH(`id`) BUCKETS 7
PROPERTIES (
"compression" = "ZSTD"
);
到了這里，關于數(shù)據(jù)倉庫系列：StarRocks 下一代高性能分析數(shù)據(jù)倉庫的架構、數(shù)據(jù)存儲及表設計的文章就介紹完了。如果您還想了解更多內(nèi)容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關文章，希望大家以后多多支持TOY模板網(wǎng)！
