阿里云StarRocks业务使用最佳实践

更新时间:2025-03-11 09:52:04

本文旨在为您介绍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_idsite_id,而 city_id 的取值只有几十,仅使用 city_id 作为分桶列可能导致某些桶的数据量过大,从而产生数据倾斜。此时可考虑将 city_idsite_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)排序。

  • 前缀索引的设计考虑:

    • 前缀索引是在排序列的基础上引入的稀疏索引,进一步提升查询效率,并能够全部加载到内存中。

    • 经常作为查询条件的列建议选为排序列。

    • 排序列建议选择为34列,尽量不超过 4 列,以避免增大排序开销和降低导入效率。

    • 前缀索引不应超过36字节,且不能包含超过 3 列。遇到 VARCHAR 类型时会截断,且前缀索引中不能包含 FLOAT 或 DOUBLE 类型的列。

    • 在前缀字段中,CHARVARCHAR 和 STRING 类型的列只能出现一次,且应处于末尾位置。

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

Bitmap索引
  • 适合基数在 10,000 至 100,000 之间的列。

  • Bitmap索引优化等值查询(=)、范围查询(例如>、>=、<、<=)和IS NULL查询,但不适用于不等于查询(!=)和LIKE查询。

  • 不支持FLOAT、DOUBLE、BOOLEANDECIMAL类型的列创建Bitmap索引。

  • 对于基数低于 255 的列(如城市、性别),不需要创建 Bitmap 索引,因为 StarRocks 会自动针对这些情况创建低基数字典以加速查询。

  • 在明细模型和主键模型中,可以为所有列创建 Bitmap 索引。在聚合模型和更新模型中,仅支持为Key创建 Bitmap 索引。

Bloom Filter索引
  • Bloom Filter 索引可以快速判断表的数据文件中是否可能包含要查询的数据。如果确定不包含,查询可以直接跳过该文件,从而减少扫描的数据量。

  • 适合基数在 100,000 以上且列的重复度很低的列。

  • 适用于IN和等值(=)过滤条件的查询。

  • 不支持为 TINYINTFLOATDOUBLE 和 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,避免使用FLOATDOUBLE类型的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 CacheQuery 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服务时,请确保已正确设置相关权限,避免因权限不足而导致的操作失败。

数据导入

基本用法

数据导入注意事项

  • 禁止使用插入语句:在生产环境中,请勿使用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;

查看预热效果

image.png

  • 了解预热效果需要监控系统的三层数据存储模式:

    • 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咨询。

  • 本页导读 (1)
  • 表模型设计(内表)
  • 表模型选择
  • 建表限制与规范
  • 创建表
  • SQL查询
  • SQL基本使用
  • 慢SQL分析
  • 高并发场景
  • 物化视图
  • 数据湖分析(外表)
  • 基本用法
  • 常用Catalog
  • 外表注意事项
  • 数据导入
  • 基本用法
  • 数据导入注意事项
  • 数据预热
  • CN加速
  • 指定计算组进行数据查询
  • 查看预热效果
  • 修改表分桶数
  • 权限管理
  • StarRocks内部权限
  • Ranger权限集成
  • 数据审计日志
  • StarRocks迁移方案
  • 联系我们