StarRocks 1.19 新版本特性介绍

StarRocks 2021-10-28

2256

StarRocks 近期发布了1.19 版本，下面介绍一下新版本的核心功能：

Global Runtime Filter

关系型数据库中，表的关联查询是十分常见的操作。StarRocks 在1.19版本中实现了 Global Runtime Filter，通过动态过滤那些不会命中 join 的输入数据来大幅减少数据的传输和计算，从而提升 join 的执行性能。

在使用过程中，规划器会根据右表的数据量自动选择是否构建 Global Runtime Filter，不需要用户进行额外的参数调整。下面以 TPCH 100G Query 17为例，其中 lineitem 表数量是 600M，orders 表数量是 150M。运行并行度设置为8。

# TPCH Query 17

select sum(l_extendedprice)  7.0 as avg_yearly 
from lineitem, part 
where p_partkey = l_partkey 
    and p_brand = 'Brand#23'  
    and p_container = 'MED BOX'   
    and l_quantity < ( select  0.2 * avg(l_quantity) from  lineitem  where l_partkey = p_partkey );
复制

测试结果如下，通过开启 Global Runtime Filter，性能提升了6倍。

BE节点内的磁盘均衡

随着数据量逐渐增大，当用户有加盘需求时，需要 StarRocks 自动进行数据均衡。StarRocks 在1.19版本中优化了磁盘均衡算法，在保证数据在各个BE之间均衡的基础上，新增了单个BE内部磁盘之间的 tablet 均衡，从而更好地利用新加的盘。

均衡步骤如下：

进行所有BE之间的磁盘均衡。
当集群达到均衡之后，进行每个 BE 内部磁盘之间的均衡。包括每个 BE 内部磁盘之间磁盘使用率的均衡和磁盘之间 tablet 分布的均衡。

[实验功能]Primary Key

为更好地支持实时/频繁更新功能，StarRocks 在1.19版本中新增了一种表的类型: 主键模型（Primary Key）。相较 Unique Key，该类型的表更好地解决了行级别的更新和删除操作，同时也极大地支撑了MySQL或其他数据库同步到 StarRocks 的场景。

原有的表类型整体上采用了读时合并（Merge-On-Read）的策略，写入时处理简单高效，但是读取(查询)时需要在线合并多版本，严重影响了查询性能。Primary Key 使用内存索引消除了这一问题，获得读性能的提升，其性能基本可以和 Duplicate Key 相近，是 Unique Key 的3-15倍（取决于版本的数量）。测试数据效果如下：

另外，在 TPCH 测试中，有导入的查询相较没有导入的查询，性能下降仅在10%左右。

当前，Primary Key 支持 Stream Load、Broker Load 和 Routine Load。同时配合Flink-connector 可以实现 MySQL 数据的秒级同步。

StarRocks-migrate-tools 可以根据 MySQL 和 StarRocks 的集群信息和表结构自动生成 source table 和 sink table 的建表语句。通过 Flink-cdc-connector 消费 MySQL 的 binlog，然后通过 Flink-connector-starrocks 写入 StarRocks。

参考文档：https://docs.starrocks.com/zh-cn/main/table_design/Data_model#主键模型

[实验功能]StarRocks外表写入

StarRocks 支持以外部表的形式接入其他数据源，当前支持的数据源类型有 MySQL、HDFS、ElasticSearch、Hive 以及 StarRocks。

StarRocks 在1.19版本中支持了将数据通过外表的方式写入另一个 StarRocks 集群的表中，以解决用户的读写分离需求，提供更好的资源隔离。仅需三步用户即可完成外表的周期性写入。