当前位置：首页 > news >正文

starocks创建表后还需要设置什么

news 2025/10/12 7:08:18

在 StarRocks 中创建表时，除了定义列名和数据类型，还需要设置一些关键的参数，这些参数对表的存储方式、查询性能和数据管理有着重要的影响。以下是一些你需要重点关注的设置：

1. 表类型 (Table Type)

StarRocks 提供了几种表类型，适用于不同的业务场景：

Duplicate Key (DUP_KEYS)：
- 特点： 这是 StarRocks 的默认表类型。数据完全按导入顺序存储，不会对主键进行去重或聚合。如果导入的数据中存在完全相同的行，它们都会被保留。
- 适用场景： 适用于需要保留所有原始数据，特别是日志、明细数据等场景。
- 设置： DUPLICATE KEY (key_column1, ...)。你需要指定用于排序的列 (Sort Key)，这些列通常是你查询中经常用作过滤条件的列。
Primary Key (PRI_KEYS)：
- 特点： 支持主键约束，每行数据都有一个唯一的主键。当导入数据时，如果存在相同主键的数据，新数据会覆盖旧数据。它支持高效的实时更新和部分列更新。
- 适用场景： 适用于需要频繁实时更新数据的场景，例如用户画像、订单状态更新、指标实时汇总等。
- 设置： PRIMARY KEY (pk_column1, ...)。主键列必须是 NOT NULL 且唯一的。
Aggregate Key (AGG_KEYS)：
- 特点： 在数据导入或合并时，对相同 Key 列的数据进行预聚合。可以显著减少存储空间和查询时的计算量。
- 适用场景： 适用于需要进行大量聚合分析，且聚合逻辑相对固定的场景，例如统计报表、指标看板等。
- 设置： AGGREGATE KEY (key_column1, ...) value_column1 SUM, value_column2 REPLACE。你需要定义 Key 列和 Value 列，并为 Value 列指定聚合函数（如 SUM, REPLACE, MAX, MIN 等）。
Unique Key (UNQ_KEYS)：
- 特点： 类似 Primary Key，也支持唯一键约束。与 Primary Key 的主要区别在于，Unique Key 适用于一些历史遗留或特殊场景，在性能上 Primary Key 通常更优。
- 适用场景： 较少使用，通常推荐使用 Primary Key 代替。

2. 分区 (Partitioning)

分区是将表数据按照某个列的值范围或列表进行逻辑划分，并将不同分区的数据存储在不同的物理存储单元上。这对于管理大数据量、提高查询效率（通过分区裁剪）至关重要。

分区方式：
- RANGE 分区 (推荐用于日期/时间类型)： PARTITION BY RANGE (partition_column) (...)。例如按日期、月份、年份进行分区。

PARTITION BY RANGE(event_date) (PARTITION p202301 VALUES [('2023-01-01'), ('2023-02-01')),PARTITION p202302 VALUES [('2023-02-01'), ('2023-03-01')),-- ...PARTITION p_latest VALUES [('2025-01-01'), ('2026-01-01'))
)

- **动态分区 (Dynamic Partitioning)：** StarRocks 支持动态分区，可以自动创建和删除分区，简化分区管理。在 `PROPERTIES` 中设置。

PROPERTIES ("dynamic_partition.enable" = "true","dynamic_partition.time_unit" = "DAY", -- 或 MONTH, YEAR"dynamic_partition.start" = "-3",      -- 从今天往前推3天开始分区"dynamic_partition.end" = "3",         -- 到今天往后推3天结束分区"dynamic_partition.prefix" = "p",      -- 分区名前缀"dynamic_partition.create_history_partition" = "true" -- 是否创建历史分区
)

- **LIST 分区 (较少用，针对离散值)：** `PARTITION BY LIST (partition_column) (...)`。适用于分区列是枚举值或少量离散值的情况。

分区粒度选择： 根据数据量和查询模式选择合适的分区粒度。过细的分区可能导致文件过多，管理复杂；过粗的分区则可能无法有效利用分区裁剪。

3. 分桶 (Bucketing)

分桶是将每个分区内的数据再通过哈希算法散列到多个桶 (Bucket) 中。分桶的目的是进一步将数据打散到不同的物理节点，实现查询的并行化，并提高 Join、聚合等操作的效率。

分桶方式：
- HASH 分桶 (推荐)： DISTRIBUTED BY HASH(bucket_column) BUCKETS num_buckets。
  - 分桶列选择： 建议选择基数高（唯一值多）、且在查询中经常作为过滤条件或 Join 条件的列。例如用户 ID、订单 ID 等。
  - 桶数 (BUCKETS)： 桶数通常设置为 BE (Backend) 节点数量的整数倍，或根据数据量进行调整。过少的桶可能导致数据倾斜，过多的桶会增加元数据管理开销。一个常见的经验法则是 BE节点数 * (2~4)，或根据数据规模来决定，一般推荐桶数小于等于128个。
- RANDOM 分桶 (极少用)： DISTRIBUTED BY RANDOM BUCKETS num_buckets。数据随机分布，适用于没有明显查询分桶列的场景，但可能会导致 Join 性能不佳。

4. 排序键 (Sort Key / Order By)

排序键定义了数据在存储时的物理顺序，这对于前缀索引和查询过滤非常关键。

Duplicate Key 表： 通过 DUPLICATE KEY (col1, col2, ...) 定义。
Primary Key 表： Primary Key 本身就是排序键。
Aggregate Key 表： 通过 AGGREGATE KEY (col1, col2, ...) 定义。
选择原则：
- 将查询中最常作为过滤条件的列放在最前面。
- 将基数高的列放在前面，有助于更快的定位数据。
- 排序键的数量不宜过多，通常3-5个为宜，总长度不超过36字节（对于前缀索引）。

5. 表属性 (Table Properties)

通过 PROPERTIES 子句可以设置表的各种属性，这些属性控制了表的行为、存储和复制策略。

"replication_num"：
- 中文：副本数。
- 作用： 设置数据副本的数量，用于数据冗余和高可用。通常生产环境建议设置为 3。
- 示例： "replication_num" = "3"
"compression"：
- 中文：压缩算法。
- 作用： 指定数据存储的压缩算法，影响存储空间和查询性能。常见的有 LZ4 (默认)、ZSTD、SNAPPY。ZSTD 通常压缩比最高，但解压开销略大；LZ4 性能最佳，压缩比适中。
- 示例： "compression" = "ZSTD"
"dynamic_partition.enable"等动态分区相关属性： 如果启用动态分区，需要在此处配置。
"enable_persistent_index"** (Primary Key 表特有)：**
- 作用： 是否为 Primary Key 表开启持久化索引。开启后，Primary Key 索引会存储在磁盘上，可以减少内存占用，但会增加查询延迟。根据内存资源和查询需求决定。
- 示例： "enable_persistent_index" = "true"
"storage_medium"** 和 "storage_cooldown_ttl"：**
- 作用： 用于管理数据冷热分层存储。可以指定数据存储在 SSD (热数据) 还是 HDD (冷数据)，并设置热数据自动转冷的时间。
- 示例：

"storage_medium" = "SSD",
"storage_cooldown_ttl" = "72h" -- 72小时后自动转冷

"in_memory"：
- 作用： 是否将表数据完全加载到内存中。适用于数据量小但查询非常频繁的场景。
- 示例： "in_memory" = "true"

6. 索引 (Indexes)

StarRocks 内置了前缀索引 (Prefix Index)、有序索引 (Ordinal Index) 和 ZoneMap 索引。此外，你还可以显式创建：

Bitmap 索引： 适用于基数较低的列，通常用于 WHERE col = 'value' 或 WHERE col IN ('v1', 'v2') 的查询。
Bloom Filter 索引： 适用于加速 WHERE col IN (list) 或 WHERE col != 'value' 的查询，可以快速判断某个值是否不在数据块中。

总结来说，创建 StarRocks 表时，你需要根据你的数据特点和查询需求，综合考虑以下几点：