StarRocks表类型之聚合表

建表时,支持定义排序键和指标列,并为指标列指定聚合函数。当多条数据具有相同的排序键时,指标列会进行聚合。在分析统计和汇总数据时,聚合表能够减少查询时所需要处理的数据,提升查询效率。

适用场景

  • 适用于分析统计和汇总数据

在这些场景中,数据查询和导入,具有以下特点:

  • 多为汇总类查询,比如 SUM、MAX、MIN等类型的查询。
  • 不需要查询原始的明细数据。
  • 旧数据更新不频繁,只会追加新的数据。

原理

数据导入至数据查询阶段,聚合表内部同一排序键的数据会多次聚合

  • 数据导入阶段:数据按批次导入至聚合表时,每一个批次的数据形成一个版本。在一个版本中,同一排序键的数据会进行一次聚合。
  • 后台文件合并阶段 (Compaction):数据分批次多次导入至聚合表中,会生成多个版本的文件,多个版本的文件定期合并成一个大版本文件时,同一排序键的数据会进行一次聚合。
  • 查询阶段:所有版本中同一排序键的数据进行聚合,然后返回查询结果。

使用说明

  • 在建表语句中,排序键必须定义在其他列之前。

  • 排序键可以通过 AGGREGATE KEY 显式定义。

  • 如果 AGGREGATE KEY 未包含全部维度列(除指标列之外的列),则建表会失败。 如果不通过 AGGREGATE KEY
    显示定义排序键,则默认除指标列之外的列均为排序键。 排序键必须满足唯一性约束,必须包含全部维度列,并且列的值不会更新。

  • 指标列:通过在列名后指定聚合函数,定义该列为指标列。一般为需要汇总统计的数据。

  • 聚合函数:指标列使用的聚合函数。聚合表支持的聚合函数,请参见 CREATE TABLE。

举例:

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)
PROPERTIES (
"replication_num" = "3"
);
### StarRocks 中 JOIN 的用法与优化 #### 1. 星型模型中的 JOIN 使用场景 StarRocks 是一种专为 OLAP 场景设计的分布式数据库,广泛应用于星型模型的数据仓库架构中。在这种架构下,JOIN 常用于连接事实和维度。例如,在零售分析场景中,可以通过以下 SQL 查询实现销售数据与产品信息的关联: ```sql SELECT f.sale_amount, d.product_name FROM fact_sales AS f LEFT JOIN dim_product AS d ON f.product_id = d.product_id; ``` 此查询展示了如何通过 `LEFT JOIN` 将事实 (`fact_sales`) 和维度 (`dim_product`) 进行连接[^1]。 --- #### 2. 左连接 (Left Join) 和 右连接 (Right Join) 的性能优化 在 StarRocks 中,左连接和右连接的选择取决于业务需求以及数据分布特性。通常建议优先考虑小作为驱动(Build Side),以减少内存消耗并提升执行效率。如果存在较大的事实和较小的维度,则应将维度设置为 Build Side。 对于复杂的多层嵌套 JOIN 操作,可以参考 MySQL 的优化策略来重构查询逻辑。例如,当涉及多个子查询时,可将其转换为显式的笛卡尔积形式再附加过滤条件[^2]: ```sql -- 复杂嵌套 JOIN 转化为显式笛卡尔积 SELECT * FROM table_1 t1 LEFT JOIN ( SELECT * FROM table_2 t2 CROSS JOIN table_3 t3 WHERE t2.a = t3.b ) subquery ON t1.id = subquery.t2_a; ``` 上述方法有助于简化计划树结构,从而降低解析开销。 --- #### 3. 排序合并连接 (Sort-Merge Join) vs Hash Join 在处理大规模数据集时,选择合适的物理算子至关重要。Hash Join 更适合于中小规模的数据集;而 Sort-Merge Join 则适用于那些无法完全加载到内存的大文件操作。这是因为 SMJ 不仅能够有效利用磁盘 I/O 来完成排序过程,而且还能保持较低的时间复杂度 O(n log n)[^3]。 然而需要注意的是,无论采用哪种方式都需要确保参与比较的关键字已经过适当索引或者分区预处理,这样才能最大程度发挥算法优势。 --- #### 4. 实际案例分享 - 高效批量导入后的 JOIN 加速技巧 假设我们正在构建一个电商推荐系统,并希望快速统计每种商品在过去一个月内的总销量。此时可以先创建物化视图提前计算好每日汇总结果,然后再基于这些预先聚合好的中间态做进一步联接运算: ```sql CREATE MATERIALIZED VIEW mv_daily_sales_summary AS SELECT product_id, SUM(sale_quantity) as total_sold FROM daily_transaction_log GROUP BY product_id; -- 后续只需简单引用该 MV 即可获得最新统计数据 SELECT p.name, s.total_sold FROM products p INNER JOIN mv_daily_sales_summary s USING(product_id); ``` 这种方法不仅减少了实时扫描原始日志记录的工作量,同时也让最终呈现给用户的报更加及时准确。 --- ### 总结 通过对不同类型的 JOIN 算法深入理解及其应用场景合理选用,配合良好的建模习惯如建立恰当索引、充分利用缓存机制等手段,可以在很大程度上改善 StarRocks 上运行的各种复杂查询的整体现。
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值