阿里云StarRocks业务使用最佳实践_开源大数据平台 E-MapReduce(EMR)-阿里云帮助中心

表模型设计（内表）

表模型选择

如果有明确的主键且需要更新历史数据，建议使用主键模型。
如果希望保留明细数据且历史数据不会进行更新，建议使用明细模型。
如果只需保留聚合数据，建议使用聚合模型。

建表限制与规范

通用限制

仅支持UTF-8编码。
VARCHAR类型的最大长度为1048576。
数据目录名、数据库名、表名、视图名、用户名和角色名大小写敏感，而列名和分区名大小写不敏感。

主键表限制

在建表语句中，主键列必须在其他列之前定义。
主键必须包含分区列和分桶列。
主键列支持的数据类型为数值（整型、布尔）、日期和字符串。
默认情况下，单条主键值编码后最大长度为128字节。
建表后，主键不可修改。
主键列的值不可更新，避免破坏数据一致性。

创建表

建表语法

CREATE [TEMPORARY] [EXTERNAL] TABLE [IF NOT EXISTS] [database.]table_name
(column_definition1[, column_definition2, ...][, index_definition1[, index_definition2, ...]])[ENGINE = [olap|mysql|elasticsearch|hive|iceberg|hudi|jdbc]][key_desc][COMMENT "table comment"][partition_desc][distribution_desc][rollup_index][ORDER BY (column_definition1,...)][PROPERTIES ("key"="value", ...)][BROKER PROPERTIES ("key"="value", ...)]

常用语句

使用Hash分桶与列存聚合

CREATE TABLE example_db.table_hash (k1 TINYINT,k2 DECIMAL(10, 2) DEFAULT "10.5",v1 CHAR(10) REPLACE,v2 INT SUM
)ENGINE = olap
AGGREGATE KEY (k1, k2)COMMENT "my first StarRocks table"DISTRIBUTED BY HASH(k1);

创建分区表

CREATE TABLE example_db.table_range (k1 DATE,k2 INT,k3 SMALLINT,v1 VARCHAR(2048),v2 DATETIME DEFAULT "2014-02-04 15:36:00")ENGINE = olap
DUPLICATE KEY (k1, k2, k3)PARTITION BY RANGE (k1) (PARTITION p1 VALUES LESS THAN ("2014-01-01"),PARTITION p2 VALUES LESS THAN ("2014-06-01"),PARTITION p3 VALUES LESS THAN ("2014-12-01"))DISTRIBUTED BY HASH(k2);

创建动态分区表

CREATE TABLE example_db.dynamic_partition (    k1 DATE,    k2 INT,    k3 SMALLINT,    v1 VARCHAR(2048),    v2 DATETIME DEFAULT "2014-02-04 15:36:00")ENGINE = olap
DUPLICATE KEY (k1, k2, k3)PARTITION BY RANGE (k1) (    PARTITION p1 VALUES LESS THAN ("2014-01-01"),    PARTITION p2 VALUES LESS THAN ("2014-06-01"),    PARTITION p3 VALUES LESS THAN ("2014-12-01"))DISTRIBUTED BY HASH(k2)PROPERTIES (    "storage_medium" = "SSD",    "dynamic_partition.time_unit" = "DAY",    "dynamic_partition.start" = "-3",    "dynamic_partition.end" = "3",    "dynamic_partition.prefix" = "p");

通过选择创建表

CREATE TABLE employee_new
PRIMARY KEY(order_id)AS SELECT order_list.order_id,SUM(goods.price) AS total
FROM order_list INNER JOIN goods ON goods.item_id1 = order_list.item_id2
GROUP BY order_id;

查看表结构
```
SHOW CREATE TABLE [db_name.]table_name;
```

创建和删除索引

CREATE INDEX index3 ON sales_records (item_id) USING BITMAP COMMENT '';
DROP INDEX index3 ON sales_records;

清空表或分区

TRUNCATE TABLE example_db.tbl;
TRUNCATE TABLE tbl PARTITION (p1, p2);

字段类型选择

正确选择时间类型和数字类型的列，以减少计算的开销。例如，时间类型的数据“2024-01-01 00:00:00”不应使用VARCHAR存储，这样无法有效利用StarRocks内部的 ZoneMap 索引，从而影响过滤速度。
对于需要精确结果的情况，建议使用 DECIMAL 类型，而非 FLOAT 或 DOUBLE 类型。

分区选择

值变化不频繁的时间列常用于 WHERE 过滤，建议使用该列创建分区，可以结合日期（一级分区）和业务分类（二级分区，例如区域、订单类型等枚举类）。
对于有数据淘汰需求的场景，可以选择使用动态分区。
如果数据更新呈现明显的冷热特征，建议强制创建分区。例如，最近一周的数据可以按天分区。
单个分区的数据量建议不超过 100GB。
数据量超过 50GB 或 5,000,000 行（5KW）的表建议创建分区。
按需创建分区，避免过多分区，以免分区元数据占用过多 FE 的内存。
当前支持的分区类型包括：时间类型（范围分区、表达式分区）、字符串（列表分区）、数字（范围分区、列表分区）。
默认情况下，最大支持 1024 个分区，可以通过参数进行调整，但通常情况下无需调整。

分桶选择

在生产环境中强制使用3个副本（仅适用于存算一体架构下）。
分桶个数的判断：
- 当表或分区数据量超过50 GB时，每个桶预估为1 GB。
- 当表或分区数据量小于50 GB时，每个桶预估为500 MB。
- 根据以上策略估算出的分桶数如果小于 BE 节点数，则最终分桶数以 BE 节点数为准。例如，如果有 6 个 BE 节点且根据 500MB 每个桶预估得出的分桶数为 1，最终分桶数取 6。
- 单个桶的预估大小应在 500MB 至 1GB 之间，而原始数据的大小通常在 5GB 至 10GB（导入 StarRocks 后，压缩比约为 7:1 至 10:1）。
- 对于非分区表，避免使用动态分桶，应根据实际数据量评估分桶个数。
- 如果分区表各分区的数据差异很大，建议不要使用动态分桶策略。
分桶裁剪与数据倾斜的选择
- 如果分桶列在 WHERE 子句中频繁使用且重复度较低（例如用户 ID、事务 ID 等），则可将该列用作分桶列。
- 如果查询条件中包含 city_id 和 site_id，而 city_id 的取值只有几十，仅使用 city_id 作为分桶列可能导致某些桶的数据量过大，从而产生数据倾斜。此时可考虑将 city_id 和 site_id 联合作为分桶字段，但这样做的缺点是，如果查询条件中仅包含 city_id，则无法利用分桶裁剪。
- 如果没有合适的字段打散数据，可以考虑使用随机分桶，但此方式无法利用分桶裁剪的优势。
- 对于有两个或多个超过 100,000 行的表进行 JOIN 操作，建议使用 Colocate Join，详情请参见Colocate Join。

索引选择

排序列和前缀索引选择

自3.0版本起，主键表支持使用ORDER BY定义排序键，自3.3版本起，明细表、聚合表和更新表也支持此功能。排序键在写入时自动生成前缀索引。前缀索引是一种稀疏索引，其大小通常会比数据量小至少1024倍，因此一般可以全量缓存于内存中，从而加速查询性能。

排序列的选择：3.0版本以前，主键模型中排序列由PRIMARY KEY指定，3.0版本起通过ORDER BY指定。
数据处理顺序：
- 在聚合表中，数据首先按照聚合键（AGGREGATE KEY）进行聚合，然后再按照排序键（ORDER BY）排序。ORDER BY 和 AGGREGATE KEY 中的列需一致，但顺序可以不同。
- 在更新表中，数据首先根据唯一键（UNIQUE KEY）进行替换（REPLACE），然后按照排序键（ORDER BY）排序。ORDER BY 和 UNIQUE KEY 中的列需一致，但顺序可以不同。
- 在主键表中，数据首先根据主键（PRIMARY KEY）进行替换（REPLACE），然后按照排序键（ORDER BY）排序。
前缀索引的设计考虑：
- 前缀索引是在排序列的基础上引入的稀疏索引，进一步提升查询效率，并能够全部加载到内存中。
- 经常作为查询条件的列建议选为排序列。
- 排序列建议选择为3至4列，尽量不超过 4 列，以避免增大排序开销和降低导入效率。
- 前缀索引不应超过36字节，且不能包含超过 3 列。遇到 VARCHAR 类型时会截断，且前缀索引中不能包含 FLOAT 或 DOUBLE 类型的列。
- 在前缀字段中，CHAR、VARCHAR 和 STRING 类型的列只能出现一次，且应处于末尾位置。

在确定键列及其顺序时，应结合实际业务查询场景，充分考虑前缀索引带来的优势。尽可能将经常需要查询的键列放置在前面，字段数据类型尽量选择 DATE、整型（如 INT）等高效的类型。

Bitmap索引

适合基数在 10,000 至 100,000 之间的列。
Bitmap索引优化等值查询（=）、范围查询（例如>、>=、<、<=）和IS NULL查询，但不适用于不等于查询（!=）和LIKE查询。
不支持FLOAT、DOUBLE、BOOLEAN和DECIMAL类型的列创建Bitmap索引。
对于基数低于 255 的列（如城市、性别），不需要创建 Bitmap 索引，因为 StarRocks 会自动针对这些情况创建低基数字典以加速查询。
在明细模型和主键模型中，可以为所有列创建 Bitmap 索引。在聚合模型和更新模型中，仅支持为Key创建 Bitmap 索引。

Bloom Filter索引

Bloom Filter 索引可以快速判断表的数据文件中是否可能包含要查询的数据。如果确定不包含，查询可以直接跳过该文件，从而减少扫描的数据量。
适合基数在 100,000 以上且列的重复度很低的列。
适用于IN和等值（=）过滤条件的查询。
不支持为 TINYINT、FLOAT、DOUBLE 和 DECIMAL 类型的列创建 Bloom Filter 索引。
在主键模型和明细模型中，所有列均可创建Bloom Filter索引；聚合模型和更新模型中，仅维度列（Key列）支持创建。

数据生命周期

建议使用TRUNCATE删除数据，而非DELETE。
完整的UPDATE语法仅适用于3.0版本及以上的主键模型；高并发的 UPDATE 操作受到限制，建议每次更新操作之间间隔至少一分钟。
如果必须使用 DELETE 删除数据，务必带上 WHERE 条件，并且禁止并发执行 DELETE。例如，删除 id=1, 2, 3, ..., 1000 时，建议DELETE FROM tbl1 WHERE id IN (1, 2, 3, ..., 1000)的方式，而非分开执行 1000 条 DELETE 语句。
DROP 操作：
- DROP 操作默认将数据移入 FE 回收站，默认保留 86,400 秒（1 天），此期间可恢复以避免误操作。该时间受参数 catalog_trash_expire_second 控制。
- 超过 1 天后，数据将进入 BE 的 trash 目录，默认保留 259,200 秒（3 天）。在 2.5.17、3.0.9 和 3.1.6 之后，默认值已改为 86,400 秒（1 天），受参数 trash_file_expire_time_sec 控制。
- 如果在 DROP 后希望尽快释放磁盘空间，可以考虑调小 FE 和 BE 的 trash 保留时间。

SQL查询

SQL基本使用

基本语法

详情请参见SELECT。

常用SQL

简单聚合分析

SELECT tiny_column, SUM(short_column)FROM small_table 
GROUP BY tiny_column 
HAVING SUM(short_column) = 1;

使用GROUPING SETS

SELECT a, b, SUM(c)FROM tab1 
GROUP BY GROUPING SETS ((a, b), (a), (b), ());

使用LIMIT进行分页

SELECT varchar_column 
FROM big_table 
ORDER BY varchar_column 
LIMIT 1 OFFSET 0;

SQL查询注意事项

避免使用SELECT *，建议指定需要查询的列，例如SELECT col0, col1 FROM tb1;。
避免全表扫描，建议增加过滤条件，例如SELECT col0, col1 FROM tb1 WHERE id = 123;。
避免大数据量下载，如果要使用，强制使用分页，例如SELECT col0, col1, col2, ..., col50 FROM tb ORDER BY id LIMIT 0, 50000;。
分页操作需加上ORDER BY以确保结果有序。
虽然StarRocks已进行隐式转换以达到最佳性能，但建议使用类型一致的字段进行JOIN，避免使用FLOAT或DOUBLE类型的JOIN以导致结果不准确。

关联字段不得使用函数或表达式。

SELECT *
FROM table1 
JOIN table2 
ON DATE_FORMAT(tb1.col1, '%Y-%m-%d') = DATE_FORMAT(tb2.col1, '%Y-%m-%d');

在处理两个或多个超过KW行的表JOIN时，推荐使用Colocate Join。
避免笛卡尔积。

避免使用一些不必要的函数或者表达式。

移除不必要的函数

-- Q1 bad case
SELECT l_tax 
FROM lineitem 
WHERE CAST(l_shipdate AS VARCHAR) > SUBSTR('1990-01-02 12:30:31', 1, 10);

-- Q2 good case
SELECT l_tax 
FROM lineitem 
WHERE l_shipdate > '1990-01-02';

避免过度使用函数处理表达式

-- Q1 bad case
SELECT COUNT(1) 
FROM lineitem 
WHERE l_shipdate >= REGEXP_EXTRACT("TIME:1996-01-02 20:00:00", "(\\d{4}-\\d{2}-\\d{2})", 1);


-- Q2 good case
SELECT COUNT(1) 
FROM lineitem 
WHERE l_shipdate >= "1996-01-02";

查询多个表需要指定连接条件

-- bad case
SELECT * FROM table1, table2;

-- good case
SELECT * FROM table1 JOIN table2 ON table1.column1 = table2.column1;

正确使用子查询

-- bad case
SELECT *FROM table1 WHERE column1 IN (SELECT column2 FROM table2);

-- good case
SELECT * FROM table1 WHERE column1 IN (SELECT column2 FROM table2 WHERE table1.column3 = table2.column3);

使用AND条件代替OR条件

-- bad case
SELECT *
FROM table1
JOIN table2
WHERE (table1.column1 = table2.column1 OR table1.column2 = table2.column2);


-- good case
SELECT *
FROM table1
JOIN table2 ON table1.column1 = table2.column1 AND table1.column2 = table2.column2;

慢SQL分析

Profile分析，请参见Query Profile介绍。

诊断建议，请参见Query Profile诊断建议。

高并发场景

尽量利用分区和分桶裁剪，具体参考上文的分区和分桶选择部分。
调高用户的并发限制，可以设置为1000（默认值为100）。
```
SET PROPERTY FOR 'jack' 'max_user_connections' = '1000';
```
开启Page Cache和Query Cache以优化性能。

物化视图

在阿里云EMR Serverless StarRocks中查看和管理物化视图更为便捷，相关信息可参阅查看物化视图。

基本用法

异步物化视图
适用以下场景：
- 分钟级以上的预聚合加工场景。
- 多表关联，重复查询较多的情况。
- 数据仓库中建模分层，替代传统ETL场景。
- 数据湖加速，将数据湖中的数据自动加工到StarRocks内表，提升查询性能。
同步物化视图：适用于基于单表的实时预聚合场景，例如精准去重、近似去重，以及增加前缀索引加速等。
查询改写：StarRocks能够在不修改查询语句的前提下，自动将基表上的查询改写为基于物化视图的查询。详见物化视图查询改写文档。
透明加速：提供查询性能的自然提升。

常用命令

创建物化视图

CREATE MATERIALIZED VIEW order_mv 
DISTRIBUTED BY HASH(`order_id`)REFRESH ASYNC START('2022-09-01 10:00:00') EVERY (INTERVAL 1 DAY)AS SELECT    order_list.order_id,    SUM(goods.price) AS total 
FROM order_list 
INNER JOIN goods ON goods.item_id1 = order_list.item_id2 
GROUP BY order_id;

查看异步物化视图创建语句
```
SHOW CREATE MATERIALIZED VIEW order_mv;
```
查看当前数据仓库内所有异步物化视图
```
SHOW MATERIALIZED VIEWS;
```

查看特定异步物化视图

SHOW MATERIALIZED VIEWS WHERE NAME = "order_mv";

通过名称匹配查看异步物化视图

SHOW MATERIALIZED VIEWS WHERE NAME LIKE "order%";

异步调用刷新任务
```
REFRESH MATERIALIZED VIEW order_mv;
```

同步调用刷新任务

REFRESH MATERIALIZED VIEW order_mv WITH SYNC MODE;

查看任务表中的最新任务

SELECT * FROM information_schema.tasks ORDER BY CREATE_TIME DESC LIMIT 1;

查看基于查询到的TASK_NAME的执行状态

SELECT * FROM information_schema.task_runs WHERE task_name = 'mv-59299' ORDER BY CREATE_TIME;

删除物化视图
```
DROP MATERIALIZED VIEW order_mv;
```
常用参数
enable_materialized_view_rewrite：是否启用物化视图的自动改写，取值为true（自2.5版本起为默认值）和false。

物化视图注意事项

刷新时间建议：异步物化视图的刷新时间建议设置为10分钟以上，具体取决于业务量和集群规模，强烈不建议小于5分钟。异步物化视图基于分区级别进行刷新。
刷新资源管理：对于拥有较多分区的异步物化视图，单次刷新可能消耗较多资源。可以通过设置刷新机制来限制每次刷新的最大分区数量，从而将刷新任务拆分，以确保数据量大的物化视图能够分批、稳定地完成刷新。
存储空间管理：为异步物化视图的分区指定存活时间（TTL），以减少所占用的存储空间。
Multi-Warehouse支持：在存算分离架构下，如果您有Multi-Warehouse，可以为物化视图指定独立的Warehouse进行处理，以避免干扰正常业务查询。
嵌套层数：物化视图支持嵌套层数，但在生产环境中建议嵌套层数不超过三层。
查询语句限制：创建物化视图的查询语句中不支持非确定性函数，例如rand()、random()、uuid()和sleep()。
推迟刷新时间：默认情况下，执行CREATE MATERIALIZED VIEW语句后，StarRocks 会立即开始刷新任务，这将占用一定的系统资源。如需推迟刷新时间，请添加 REFRESH DEFERRED 参数。

数据湖分析（外表）

基本用法

请参见数据目录。

常用Catalog

阿里云 DLF 1.0 Catalog
- 适用于阿里云EMR Serverless StarRocks集群。
- dlf.catalog.id 可为空，如果为空则使用默认的DLF Catalog。
```
CREATE EXTERNAL CATALOG hive_catalog
PROPERTIES (    "type" = "dlf",    "dlf.catalog.id" = "xxxxxx");
```

阿里云 DLF 2.0 Catalog

适用于阿里云EMR Serverless StarRocks集群。

CREATE EXTERNAL CATALOG <catalog_name> PROPERTIES ("type" = "paimon", "paimon.catalog.type" = "dlf-paimon","dlf.catalog.id" = "clg-paimon-xxxx");

创建Hive Catalog

CREATE EXTERNAL CATALOG hive_catalog PROPERTIES ("type" = "hive", "hive.metastore.uris" = "thrift://xx.xx.xx.xx:9083");

查看Catalog列表及创建语句

SHOW CATALOGS;
SHOW CREATE CATALOG hive_catalog;

删除Catalog
```
DROP CATALOG hive_catalog;
```
手动刷新缓存元数据
自StarRocks 2.5.5版本起，支持周期性刷新Hive元数据缓存。默认每10分钟自动刷新，只有在新增分区后需要立即查询这些数据时，才需手动更新。
```
REFRESH EXTERNAL TABLE <table_name> [PARTITION ('partition_name', ...)];
```
启用Trino语法进行数据湖分析
```
SET sql_dialect = 'trino';
```

外表注意事项

使用建议：建议通过External Catalog方式创建外表，而非External Table方式。
JDBC Catalog使用：在频繁查询或数据量较大的情况下，建议定时通过物化视图将数据加载到内表，以提高性能并减少对源库的查询压力。
对象存储查询：在查询OSS、S3等对象存储数据时，请注意API访问费用。建议开启Data Cache或使用物化视图加工到内表，以减少API访问频率并提高查询性能，避免全表扫描等高成本操作。
权限配置：特别是使用阿里云DLF 2.0服务时，请确保已正确设置相关权限，避免因权限不足而导致的操作失败。

数据导入

基本用法

导入方案概览
Flink写入StarRocks
- 适用于将多种数据来源（如MySQL、Kafka、PostgreSQL、SQL Server等）实时导入StarRocks，详情请参见连接器。
- 基于实时计算，使用CTAS语句将MySQL数据同步至StarRocks，详情请参见基于实时计算Flink使用CTAS语句同步MySQL数据至StarRocks。
- 使用Flink CDC（Change Data Capture）同步MySQL数据至StarRocks，详情请参见使用Flink CDC同步MySQL数据至StarRocks。
Kafka导入StarRocks
使用Routine Load导入Kafka中的数据，详情请参见使用 Routine Load 导入数据。
Spark导入StarRocks
适用于将数据湖或HDFS中的数据导入至StarRocks，详情请参见使用 Spark connector 导入数据（推荐）。
OSS数据导入StarRocks
通过Broker Load从OSS导入数据，详情请参见从对象存储导入。

数据导入注意事项

禁止使用插入语句：在生产环境中，请勿使用INSERT INTO VALUES() 导入数据。
设置导入批次间隔：建议导入批次间隔为 10 秒或更长时间，尤其是在实时场景下。例如，Flink写入时建议设置时间间隔在10秒以上，以提高性能。
主键模型更新场景：建议开启索引落盘，确保使用SSD、NVMe或更高性能的磁盘，以提升写入效率。
ETL场景务必注意：在多个ETL（INSERT INTO SELECT）场景中，建议开启spill落盘功能，以避免内存超过限制。
导入频率与数据合并：如果导入频率过快，数据可能无法及时合并（Compaction），这会导致未合并版本数超过最大限制（默认最大未合并版本数为1000）。因此，建议：
- 增大单次导入的数据量。
- 降低导入频率。
- 修改 BE 配置文件 be.conf 中的相关参数配置，以加快数据合并（Compaction）的速度。

数据预热

数据预热仅适用于存算分离架构下，并在使用多计算组（Multi-Warehouse）功能的情况下。

CN加速

计算组一（CN）：主要用于在数据仓库的ETL加工。在表数据写入场景中，会自动触发表的预热。在同一个CN查询时，无需手动进行数据预热。
计算组二和三（CN）：主要用于数据查询加速。在读取数据之前，需要主动对表进行预热。预热方式如下：
- 方式一：将数据预热到指定的Warehouse
```
SET WAREHOUSE = 'XXX_warehouse';
CACHE SELECT * FROM xxx_table WHERE xxx;
```
- 方式二：在指定Warehouse下提交周期性预热任务
```
SUBMIT TASK ALWAYS_CACHE SCHEDULE EVERY (INTERVAL 5 MINUTE) AS CACHE SELECT * FROM xxx_table WHERE xxx;
```
  由于周期性任务无法设置依赖，预热时机可能不够准确。建议在周期性ETL任务结束时，使用方式一进行主动预热。更多信息，请参见数据预热。

指定计算组进行数据查询

方式一：在JDBC连接串中通过sessionVariables指定

jdbc.url=jdbc:mysql://<mysql_host>:3306/dbName?sessionVariables=warehouse=<warehouse_name>

方式二：通过JDBC连接字符串中的sessionVariables指定

SET warehouse=<warehouse_name>;
SELECT * FROM my_db.my_table;

方式三：通过SQL Hint中的SET_VAR指定

SELECT /*+SET_VAR(warehouse="warehouse_name")*/ * FROM my_db.my_table;

查看预热效果

了解预热效果需要监控系统的三层数据存储模式：
- Page Cache：自动工作。在查询首次请求访问数据块时，系统会将其加载到缓存中，后续查询自动加速。
- Data Cache预热：导入数据自动预热，或通过手动/定时任务执行预热操作。
查看预热效果：可以在SQL执行详情页的Profile执行树中找到CONNECTOR_SCAN节点，主要关注以下指标：
- CompressedBytesReadLocalDisk：从本地缓存读取的字节数。
- CompressedBytesReadRemote：从远端OSS对象存储读取的字节数。
需要注意的是，PageCountMemory指标（从Page Cache读取）。若所有数据都是从Page Cache获取，则无法判断Data Cache预热是否生效。
验证CN加速效果：为了更好地验证CN加速效果（数据预热），您可以暂时关闭Page Cache机制。
```
SET disable_storage_page_cache=false;  #关闭Page Cache
```
评估加速效果：关闭Page Cache后，通过观察以下指标评估预热效果。
- CompressedBytesReadLocalDisk > 0 且 CompressedBytesReadRemote = 0：表示全部数据命中预热。
- CompressedBytesReadLocalDisk = 0 且 CompressedBytesReadRemote > 0：表示全部不命中预热。
- CompressedBytesReadLocalDisk > 0 且 CompressedBytesReadRemote > 0：表示部分命中预热。

修改表分桶数

方式一：使用ALTER命令修改分桶数（不推荐大批量调整）
```
ALTER TABLE XXX_table DISTRIBUTED BY HASH(`ds`, `user_id`) BUCKETS 48;
```
执行此命令后，会启动数据重分布任务，时间可能较长，且在执行期间不支持SELECT查询。
查看重分布任务进度。
```
SHOW ALTER TABLE OPTIMIZE; 
```
如果发现表数据重分布任务卡死，可以执行以下命令取消表优化任务。
```
CANCEL ALTER TABLE OPTIMIZE  FROM XXX_table; 
```
方式二：通过创建新表、INSERT INTO 和 RENAMING（推荐）
这种方式性能会比较好，但比较麻烦，需要人工处理，超大表需要分批次执行。

权限管理

StarRocks内部权限

可以对不同用户和角色的权限进行合理配置，实现权限的最小粒度分配。

更多信息，请参见StarRocks RBAC权限。

Ranger权限集成

在数据湖分析场景下，Ranger权限的集成需要与Ranger实现权限的统一，因此可以考虑进行Ranger的集成。

更多信息，请参见使用 Apache Ranger 管理权限。

数据审计日志

-- 查询审计日志记录
SELECT * FROM _starrocks_audit_db_.starrocks_audit_tbl t ;

更多信息，请参见审计日志。

StarRocks迁移方案

您可以将您创建的StarRocks迁移至EMR Serverless StarRocks。

更多信息，请参见从自建StarRocks集群向Serverless StarRocks的迁移方案。

联系我们

如果您有业务问题或者产品疑难问题，可加入钉钉群24010016636咨询。