本文旨在为您介绍StarRocks的基础使用方法和常见操作,适用于首次接触StarRocks的用户。
表模型设计(内表)
表模型选择
如果有明确的主键且需要更新历史数据,建议使用主键模型。
如果希望保留明细数据且历史数据不会进行更新,建议使用明细模型。
如果只需保留聚合数据,建议使用聚合模型。
建表限制与规范
通用限制
仅支持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。
联系我们
如果您有业务问题或者产品疑难问题,可加入钉钉群24010016636咨询。
- 本页导读 (1)
- 表模型设计(内表)
- 表模型选择
- 建表限制与规范
- 创建表
- SQL查询
- SQL基本使用
- 慢SQL分析
- 高并发场景
- 物化视图
- 数据湖分析(外表)
- 基本用法
- 常用Catalog
- 外表注意事项
- 数据导入
- 基本用法
- 数据导入注意事项
- 数据预热
- CN加速
- 指定计算组进行数据查询
- 查看预热效果
- 修改表分桶数
- 权限管理
- StarRocks内部权限
- Ranger权限集成
- 数据审计日志
- StarRocks迁移方案
- 联系我们