【技术预研】StarRocks官方文档浅析（3）

背景说明

基于starRocks官方文档，对其内容进行一定解析，方便大家理解和使用。

若无特殊标注，startRocks版本是3.2。

下面的章节和官方文档保持一致。

参考文档

StarRocks

StarRocks 是一款高性能分析型数据仓库，使用向量化、MPP 架构、CBO、智能物化视图、可实时更新的列式存储引擎等技术实现多维、实时、高并发的数据分析。StarRocks 既支持从各类实时和离线的数据源高效导入数据，也支持直接分析数据湖上各种格式的数据。StarRocks 兼容 MySQL 协议，可使用 MySQL 客户端和常用 BI 工具对接。同时 StarRocks 具备水平扩展，高可用、高可靠、易运维等特性。广泛应用于实时数仓、OLAP 报表、数据湖分析等场景。

内容	说明
高性能分析型数据仓库	相比于oltp，更适合olap
向量化	基于CPU层级的优化（clickhouse有相关优化）
MPP 架构	相比于hadoop架构更适合olap
CBO	优化多表join的执行时，starRocks内部的执行先后顺序
智能物化视图	用于实现单表的实时数据转换，类似clickhouse的物化视图
可实时更新的列式存储引擎	可支持实时update
兼容 MySQL	可使用mysql相关语法和client工具

查询加速

CBO统计信息

采用 Cascades 框架。简单描述，就是判断预估来优化重型SQL的执行策略。具体内容，可以自行了解。
CBO 统计信息 | StarRocks

同步物化视图

同步物化视图和异步物化视图比较。

从下图比较中可以看到，同步物化视图的功能比较简单，基本上是两个场景，分别是map映射和简单聚合。

map映射：实现字段间转换，例如时间戳转换为日期，string转int

简单聚合：计数器类的函数，单表groupby维度信息，计算sum、max、min等可以直接比较的函数

	异步物化视图	同步物化视图（Rollup）
本质	物理表，进行预计算（提升查询效率，先匹配是否命中）	基表的索引
处理方式	定时或者手动计算	实时计算
风险点	多张大表关联是否存在执行失败的风险，而且依赖血缘关系，没有外部调度的话，时效性如何确认	对单张表做多个同步物化视图，会影响性能（瞬时并发量大）建议：1对1
使用场景	理论上可以适用于全部场景，但在单表简单处理上没有同步物化视图效率高

map映射：实现字段间转换
简单聚合：计数器类的函数
|
| 单表聚合 | 是 | 仅部分聚合函数 |
| 多表关联 | 是 | 否 |
| 查询改写 | 是 | 是 |
| 刷新策略 |
异步刷新
手动刷新
| 导入同步刷新 |
| 基表 | 支持多表构建。基表可以来自：
Default Catalog
External Catalog（v2.5）
已有异步物化视图（v2.5）
已有视图（v3.1）
| 仅支持基于 Default Catalog 的单表构建 |

同步物化视图支持的函数：

原始查询聚合函数	同步物化视图构建聚合函数
sum	sum
min	min
max	max
count	count
bitmap_union, bitmap_union_count, count(distinct)	bitmap_union
hll_raw_agg, hll_union_agg, ndv, approx_count_distinct	hll_union

异步物化视图

和同步物化视图进行比较，比较内容参考从上。

Colocate Join

就是多张表关联，把相同的关联键作为分桶键，这样相关的数据就会出现在相同节点。

能够减少数据多节点分布时 Join 操作引起的数据移动和网络传输，从而提高查询性能。

使用 Lateral Join 实现列转行

实现列拆分，转换为多行数据。

sql 复制代码

mysql> select * from lateral_test2;

+------+-------+------+
| v1   | v2    | v3   |
+------+-------+------+
|    1 | 1,2,3 | 1,2  |
|    2 | 1,3   | 1,3  |
+------+-------+------+

sql 复制代码

-- 对单行数据进行 Unnest 操作。
mysql> select v1, unnest from lateral_test2, unnest(split(v2, ","));

+------+--------+
| v1   | unnest |
+------+--------+
|    1 | 1      |
|    1 | 2      |
|    1 | 3      |
|    2 | 1      |
|    2 | 3      |
+------+--------+

-- 对多行数据进行 Unnest 操作，需要指定别名。
mysql> select v1, t1.unnest as v2, t2.unnest as v3 from lateral_test2, unnest(split(v2, ",")) t1, unnest(split(v3, ",")) t2;

+------+------+------+
| v1   | v2   | v3   |
+------+------+------+
|    1 | 1    | 1    |
|    1 | 1    | 2    |
|    1 | 2    | 1    |
|    1 | 2    | 2    |
|    1 | 3    | 1    |
|    1 | 3    | 2    |
|    2 | 1    | 1    |
|    2 | 1    | 3    |
|    2 | 3    | 1    |
|    2 | 3    | 3    |
+------+------+------+

Query Cache

2.5版本以后上线的功能，需要配置FE、BE参数启动。查询的执行引擎为 Pipeline。

相当于缓存该表的之前的查询内容。

之后的查询，如果有类似的，可以直接获取，提升查询效率。

如果判断是否类似，需要通过执行计划。

索引

除增长的排序键和前缀索引，还提供bitmap和bloom filter两种索引。

前者适合基数比较低的列（就是枚举值比较少的，例如订单状态），后者适合基数比较高的列（例如店铺id）。

Bloom filter是判断文件中是否包含对应的数据，为了保证不缺失数据，存在下面说的假阳性。

Bloom filter 索引有一定的误判率，也称为假阳性概率 (False Positive Probability)，即判断某行中包含目标数据，而实际上该行并不包含目标数据的概率。